Industry News, Trends and Technology, and Standards Updates

Background

At SEMI in North America, the Information & Control Committee meets three times per year; spring summer and fall. This year the spring meetings were held on April 3-5. The meetings include task forces with leaders from Cimetrix on the GEM 300, ABFI (Advanced Backend Factory Integration), GUI, DDA, CDS task forces as well as the committee meeting on the final day. This is a summary of what happened in the task forces I am highly involved in including GEM 300, ABFI and DDA. 

GEM 300 Task Force

After very busy previous GEM 300 task force meetings over the last couple of years, this is the first time in a long time that the GEM 300 task force did not have a major ballot up for voting. A major update to the GEM standard (SEMI E30), ballot 6572C, is awaiting publication at SEMI but was previously approved. In our task force meeting this week, we primarily discussed a new ballot proposed by a couple of active task force members regarding SEMI E172, SPECIFICATION FOR SECS EQUIPMENT DATA DICTIONARY (SEDD). The proposed new ballot would enhance the E172 SEDD file to add: 

1. alarm names
2. a new “well known” element to all collection events, data variables, status variables, equipment constants and alarms.
3. enhanced comments in the schema file
4. possibly a few schema changes regarding the handling of empty lists

The major new feature is the “well known” element. When an equipment supplier creates a GEM interface on the equipment and related GEM 300 standards, the implemented SEMI standards define required collection events, data variables, status variables, equipment constants and alarms which much be available. However, the actual name for each required item published in the GEM interface is not specified in the standard and is not a strict requirement. As a result, implementations of GEM and GEM 300 standards use different names for the same required item. For example, the GEM standard requires collection event “Control State REMOTE” to notify when the operator changes the equipment to remote control. One implementation might call this collection event “ControlStateRemote” while other implementations might call this collection event “Control State REMOTE” or “CntrlStateREMOTE”. All of these names are valid and GEM Compliant. The “well known” element in the E172 SEDD file would allow items in the GEM interface to be assigned a tag mapping it to a required item in a SEMI standard. Each SEMI standard in turn will need to be updated to define “well known” names to use in the E172 SEDD File. This new feature will allow GEM host software to have increased plug-and-play intelligence when connecting to a GEM interface to identify standard features. EDA (Equipment Data Acquisition) interfaces solved this problem in the SEMI E164 standard. The proposed “well known” names to be used in a GEM interface are expected to use the same names currently found in SEMI E164. Then SEMI E164 can be updated to reference the same “well known” names. This will be a lot of work to standardize, but will be a valuable feature. The upcoming GEM revision already defines how an SEDD file can be transmitted through the GEM interface using Stream 21 messages. 

Additionally, the task force discussed SEMI E87 and the new carrier ready to unload prediction. Prior to these discussions on April 3, I had thought that the state model was stabilized enough to implement. However, the work for ballot 6835 has been redefined to include additional work to modify the state model yet again. With this redefined scope, a new ballot number will be issued by SEMI. The task force is investigating changing the state model to predict transition to a final carrier accessing state (carrier complete or carrier stopped) instead of predicting transition to the carrier ready-to-unload state. The assumption is that the time between carrier completion and ready-to-unload states is fixed, and that it might be more useful for internal buffer equipment to predict carrier completion instead than ready-to-unload. Additionally, a few of the states are proposed to be changed. 

Both activities are expected to happen quickly and be submitted for SEMI voting cycle 5 in 2023. 

ABFI (Advanced Backend Factory Integration) Task Force

A new specification (ballot 6924, Specification for Equipment Management of Consumable and Durables) and subordinate standard (ballot 6925, Specification for SECS-II Protocol for Equipment Management of Consumable and Durables) were submitted for voter feedback since the committee last met in the fall. During the Spring meetings, the voter feedback was adjudicated. The ABFI Task Force and the I&C (Information & Control) Committee agreed to fail ballots 6924 and 6925. There were a few technical mistakes in the ballots that need to be reworked. Most of the feedback identified editorial mistakes or improvements in the ballot. Only a few minor technical issues need to be ironed out. I will be reworking both ballots, seeking task force member feedback and submitting them to the upcoming SEMI Cycle 5 voting. The voting feedback from the last cycle makes me optimistic that the ballots will soon pass and become new standards. 

The task force also spent time discussing and debating SEMI E142 substrate maps and how they might be used in specific traceability situations. 

DDA (Diagnostics Data Acquisition) Task Force

The DDA task force and Information & Control committee pass several ballots proposed by the DDA task force including:

• Ballot 7001 – Revision to SEMI E125-1022 Specification for Equipment Self Description (EqSD) and SEMI E125.2-1022 Specification for Protocol Buffers for Equipment Self Description (EqSD)
• Ballot 7002 – Revision to SEMI E132-0922 Specification for Equipment Client Authentication and Authorization and SEM E132.2-0422e Specification for Protocol Buffers for Equipment Client Authentication and Authorization (ECA)
• Ballot 7003 - Revision to SEMI E134-1022 Specification for Data Collection Management and SEMI E134.2-1022 Specification for Protocol Buffers of Data Collection Management
• Ballot 7017 - Line Item Revision To SEMI E120.2-0922: Specification For Protocol Buffers For Common Equipment Model (CEM)

All of these ballots are part of the effort to develop a “freeze 3” version of the EDA (Equipment Data Acquisition) standards, where the underling protocol will use gRPC and Protocol Buffer technology instead of the current SOAP and HTTP seen in EDA freeze versions 1 and 2. 

Ballot 7002 includes multiple editorial changes and technical changes. The technical changes will result in a Ratification ballot for SEMI Cycle 4 voting. If the Ratification ballot passes, then ballot 7002 will pass. But if it fails then ballot 7002 will also fail and have to be reworked. 

While handling the considerable work adjudicating all of the ballot negatives and comments, the task force considered some new cases. For example, the task force discussed the role of the Security Admin, and whether it should be used only for EDA interface management as designed today or whether it should also provide additional EDA diagnostics capabilities. 

For the first time in a very long time, no DDA ballots are proposed for the next voting cycle (other than the Ratification ballot). The task force co-leaders are hoping to let SEMI publication catch up and to plan another event where companies can test EDA against other implementations. The previous tests were limited to E132. Since then some major changes have been made to E132. The new tests would include testing E132, E125 and E134 together to ensure that the standards define compatible and useful EDA implementations. After these tests, it is expected that one more round of changes might be needed for E132, E125 and E134 to correct defects or missing features identified by members participating in this testing. 

Information & Control Committee

For the first time in a very long time, the committee meeting was unable to complete all planned business. To comply with SEMI regulations, the meeting was required to end on time with unfinished business. The unfinished business will be handled by the Information & Control GCS chairs. This group includes the co-chairs from the SEMI Information & Control Committees in North America, Japan, South Korea, Taiwan and China. 

Earlier this quarter (October 2022) the SEMI Smart Manufacturing Council conducted one of its regular meetings with factory stakeholders to determine what sort of SEMI-sponsored activities could accelerate this important industry initiative. One focus area of the discussion was getting more and better data out of the sub-fab, since the performance and integration of these components is becoming more important for many of the leading manufacturers. The related, familiar topic of achieving better visibility into equipment and process behavior was also raised.

In that context, as it often does, the role of industry standards came up as a key enabling technology. The following question was posed: “Are the current standards sufficient to support the broad range of smart manufacturing use cases that factories envision, or does more need to be done? Specifically, since the Information and Control Committee is working on the Freeze 3 version of the EDA (Equipment Data Acquisition, also known as Interface A) suite of standards, are there problems that need to be addressed to improve the adoption of usage of these standards?”

This question triggered a lively (but non-convergent!) conversation among the participants in the meeting, many of whom have years (no, decades) of experience working in the standards community. Before long, it became clear that the group had no clear answer to these questions, and that more information from the actual user community was needed. Someone suggested that the Council pose the questions to a broader audience in survey form, and this proposal was enthusiastically accepted. Several of us volunteered to generate a draft survey for SEMI’s review and refinement, which got the activity off to a running start.

Given this opportunity to connect directly with the ultimate beneficiaries of SEMI Standards, there was a temptation to broaden the survey’s scope to cover other topics of interest in the smart manufacturing domain. Cognizant of the fact that the longer surveys have a lower chance of being returned with useful data, however, the group largely resisted this temptation, including the most important questions in an easy-to-answer format, leaving room for optional additional information in the responses for those so inclined.  

The final survey was issued by SEMI around October 21,2022 with a requested response date of November 15 (which has been extended to gather more feedback). Rather than repeat the entire content here, I include the following excerpts from the introduction and the table of contents:

The purpose of this questionnaire is to assess the status of the industry’s experience with and impressions of the SEMI EDA (Equipment Data Acquisition) standards suite to guide current and future initiatives that improve its capabilities, communicate implementation best practices, and foster broader adoption to realize the vision of SEMI’s Smart Manufacturing Community.

Respondents to this questionnaire should include companies that have already deployed the EDA standards in volume production as well as those that have yet to do so. Respondents in the latter category can simply skip the questions about current usage/issues.

The target audience was originally thought to be stakeholders in 300mm wafer fabs, but with the growing interest in enhanced data collection and automation for backend (packaging, assembly, and test) factories AND growth in the 200mm wafer fab segment (including new models of 200mm manufacturing equipment), it has been broadened to include these domains as well.  

Most questions are posed in multiple choice format, but additional detail is always welcome in the Comments fields where appropriate.

SEMI will compile the responses and share the result with the industry while preserving the anonymity of individual responses.

1. Manufacturing Stakeholders
2. Manufacturing KPIs (Operational Performance)
3. Manufacturing Application Support
4. Automation Requirements and Equipment Acceptance
5. Current (or intended) Usage
6. Issues and Expectations
7. Other Data Collection Needs

Appendix – Stakeholders and Acronyms

 

 

Moreover, at this writing, the link to the on-line survey is still active here: 
à SEMI Equipment Data Acquisition / Interface A Standards Survey – Questionnaire on Usage, Requirements, Expectations, and Issues.

Finally, if you are interested in the details of the survey, and especially if you would like to provide your inputs directly to SEMI, you should contact Mark da Silva, Chair, SEMI Smart Manufacturing, Global Executive Committee, at mdasilva@semi.org.

And as always, to discuss your company’s specific Smart Manufacturing journey and to understand how we at Cimetrix by PDF Solutions can help, click on the contact button below. We look forward to hearing from you!

Background

Chris Maloney of Intel and I are the North American GEM 300 Task Force co-leaders. We lead the task force activity related to all SEMI standards related to GEM technology. This includes a long list of SEMI standards.

APCSM Conference

I recently participated in the APCSM (Advanced Process Control Smart Manufacturing) conference in Austin, Texas by teaching about the GEM standard. In the material I presented, I included what I called the “core philosophies of GEM”. These are the features in GEM that justify the increased adoption and usage of GEM technology. These core philosophies include:

Background

As one of the North American DDA Task Force co-leaders, I am often asked when EDA Freeze 3 will be ready to implement. The SEMI DDA Task Force has been working on developing an EDA Freeze 3 standard for several years. This is an updated version of the data collection standard for manufacturing equipment. Unfortunately, due to many factors, this work has been slow to develop. For more information on a “freeze version” see SEMI standard E178 where official freeze versions are defined.

Status

To date the following ballots have been completed:

At no point is an EDA client required to include the password or hashed password when establishing a session. To keep passwords secure, administrative EDA clients should use SSL when adding ACL entries. This increase in security is expected to allow for the adoption of EDA standards in a wider spectrum of applications.

Known Future Ballots

• An update to E164.
• Another update to E132, E125, and E134. A proposal was made to redefine the terms “client” and “consumer”. This week, the task force decided to go forward with this proposal.
  • The adoption of gRPC allows EDA clients to receive NewData messages with a bi-directional (full duplex) connection. In EDA freeze 1 and 2, SOAP message over HTTP are only one-directional. This new bi-directional use case muddied the meaning of “client” and “consumer”. The proposal will clarify how a “client” is the entity that initiates communication with the “equipment server”. When configured to do so, an “equipment server” can initiate communication with a “consumer”. So there may or may not be a consumer present.
  • EDA Freeze 3 also introduces three classifications of messages from the equipment server, heartbeat, operational, and notification messages. The heartbeat and operational are sent either to the client (in bi-directional mode), to the consumer or are disabled entirely. Notification messages can be sent to client and/or consumer.
• The task force plans to organize another test session open to anyone interested, where E132, E120, E125 and E134 can all be tested together. This had been planned for early 2023, but dates have not been proposed and these plans may slip. This test is expected to validate whether the published standards are ready. The task force leaders expect that some issues might be revealed and further changes to E125 and E134 may be required. If so, EDA freeze 3 might not be ready until spring 2024.
• An update to E178 Guide for EDA Freeze Version. This is the final step to officially declare the freeze 3 version.
  
  

To summarize, while the EDA Freeze 3 is not getting completed as quickly as most would like, the work is progressing. There aren’t any major hurdles at this time, but it lots of time and effort to complete the work that has already been planned.

What’s new with CIMControlFramework^TM (CCF)?

CCF is a software development kit (SDK) that enables users to design and implement a high-quality equipment control solution using provided components for supervisory control, material handling, operator interface, platform and process control, and automation requirements. CCF is built on the reliable Cimetrix connectivity products which provide GEM/GEM300/EDA interface functionality.

We released CCF 6.0 in March of 2021. Since that time, we have released four additional versions of CCF. In CCF 6.1 we added a continuous flow sample. We created a blog post for that sample that can be read here. We thought it would be fun to create another blog to keep readers up to date on some of the additional cool things that have been added to CCF in these subsequent releases.

GUI Changes

Many of the visible changes to CCF have been made in the operator interface.

New WPF OI for vacuum sample

The trend for most of our CCF customers has been to implement their equipment control application GUI using Windows Presentation Foundation (WPF). In previous releases, CCF had fully functional WPF GUIs for the Atmospheric and Continuous Flow samples. CCF now has a full WPF operator interface for the Vacuum Sample. The picture below shows the default main screen for the WPF GUI for the Vacuum Sample.

New visualization library

In addition to full operator interfaces created with WPF, a visualization library has been added to CCF. In previous versions, visualizations were achieved using bitmaps that were updated when states changed. While the results were adequate, they did not scale very well, and it was difficult to customize the visualizations. The new visualization library uses vector graphics to draw the visualizations. This makes the lines and images in the visualizations crisp and clear regardless of the scale. It also allows for easy customization so that CCF application developers can create a visualization to exactly match their equipment. The Developer Guide and training labs have instructions for using the new visualization library.

The picture of the full GUI main screen above shows the default visualization for the vacuum sample. The following image is a visualization from the continuous flow sample.

Both visualization examples were created with the same visualization library.

Additional GUI changes

In addition to the GUI changes listed above, Cimetrix has made more changes to the GUI and added new screens for both WinForms and WPF. These screens include:

• GEM300 E39 objects screen
• GEM Traces screen
• GEM Reports screen
• EFEM Robot service screen
• Aligner Service screen

Simulation Changes

Cimetrix has always been a proponent of using simulators as much as possible during equipment control application development and testing. (See blog post on simulation here.) Simulation in CCF has always been easy to use, but now it is even easier and has more functionality. Simulators should be interchangeable with hardware so that regardless of whether you are running against simulation or real hardware, the application makes the same calls and receives the same feedback. In the latest versions of CCF, Cimetrix has:

• Added simulation for Kawasaki D60 robot
• Added simulation for TDK TAS300 LP
• Made simulation more extensible
• Added simulation templates

Efficiency Changes

A change that is not very flashy but is probably one of the most important changes made to CCF is that the efficiency has been greatly improved. While CCF has never been a resource hog, there were some instances where it was using more CPU and memory than was needed. This was the case especially when GUI screens were being updated with large amounts of data.

In these instances, a data structure dealing with material locations and another dealing with process and control job data were being sent from the supervisory layer to the GUI more frequently than was needed. By being more intelligent about sending these data structures, we have greatly reduced the CPU usage.

Another change that has reduced CPU usage and data traffic is that the user can now set up trace reports to the GUI that are only sent when data changes rather than on a 10 Hz timer.

Additionally, CCF now has a performance monitor class that allows users to monitor performance counters like CPU, Disk usage, and memory usage.

CCF provides history objects for storing certain data to a database. This history includes:

• Wafer history
• Equipment Performance Tracking (EPT)
• Alarms

As a final efficiency enhancement, these objects now share a base class and are more efficient in writing to the database.

Interlocks

Software interlocks are designed to prevent executing an unsafe command. Using multiple levels to do safety checks provides redundancy and reduces the chance an unsafe command could be executed.

These interlocks are generally based on states and are equipment-dependent. Software interlocks are not a replacement for hardware interlocks. Software interlocks are like a safety net—they are not normally needed, but when they are, there is a much lower risk of damage.
CCF has previously had interlock functionality available. However, in the latest release, the interlock functionality has been consolidated, centralized, and simplified. Using a single interlock class gathers all the interlock code into one location instead of scattering interlock code through all the Components.

Interlocks have been added to each of the CCF samples to show how they work and how they could be implemented in your application.

Conclusion

These are just some of the cool and useful features that have been added to CCF in the last two years since the release of CCF 6.0. To learn more about these features or the other new features that have been added, please schedule a time to talk with a Cimetrix representative.

Background

The North America Information & Control Committee (I&CC or NA I&CC) is comprised of several task forces including GEM 300, Diagnostic Data Acquisition (DDA), Advanced Backend Factory Integration (ABFI), Fab & Equipment Computer and Device Security (CDS), and Graphical User Interfaces (GUI). These task forces and the committee all met during the week of SEMICON West, July 11-13, 202. Not long ago, SEMI regulations were modified to allow TC Chapter (Committee) voting in virtual meetings; therefore, the standards activities continue to move forward. In-person task force participation was much higher than the last meetings, but remote participation also remains strong. This blog is a summary of the activities in each task force.

GEM 300 Task Force

Here is a summary of worldwide activities related to the GEM 300 task force as of the start of the GEM 300 task force meeting.

Three ballots were adjudicated during the GEM 300 task force meeting. The term “adjudication” means we review the voting and recommend handling of all negative votes and comments received to ultimately accept the ballot for publication or reject the ballot for rework. The recommendations by the task force are then finalized at the committee meeting. Usually, the task force recommendation is accepted by the committee, as was the case in all three ballots.

6916 E5

This ballot proposes to modify the E5 SECS-II standard and included the following minor changes:

• Allow data variable OperatorCommand to be type ASCII.
• Correct various typographical errors
• Remove the dependency between variables MDLN (equipment model number) and EqpSerialNum (equipment serial number).

This ballot passed after the only negative was withdrawn by the voter.

6572B E30

This ballot proposes to modify the GEM (E30) standard. It is a revision ballot, meaning the entire E30 standard is subject to review. This is the third time the ballot has been submitted. It is a major update to the GEM standard and includes the following changes:

• Process Program Management changes
  • The terms “recipe” and “process program” are currently used nearly interchangeably. The proposal is to use the term “process program” exclusively.
  • References to E42, large formatted and large process programs are moved out of the main standard and into the appendix.
  • Stream 21 messages are introduced for process program management, including both the single and multiple message techniques. This provides a simplified way for GEM interfaces to upload and download large process programs.
  • The entire process program management section is vastly reorganized to help implementers understand the available alternatives and the scenarios for each available alternative. New tables were introduced to compare and summarize implementation alternatives.
  • Collection event ‘Process Program Error’ is specifically listed as required, rather than just as an implied requirement.
• A series of new SECS-II messages are introduced including S2F51-S2F64. These are new capabilities to make a GEM interface more transparent.
• S5F7/F8 is added to the alarm management capability for similar reasons.
• Two new GEM documentation features are added and made available through the GEM interface using Stream 21 messages including PDF documentation and SEDD (see SEMI E172) documentation. This should make it easier to distribute GEM documentation and ensure that the right documentation is referenced.
• Two new equipment identification features are added, one to identify the equipment supplier and one to uniquely identify each individual equipment. This should make it easier to identify and track specific equipment on the factory floor.
• Some changes related to terminology are included. SEMI regulations recently were updated with a list of restricted bias terminology which are not allowed in any SEMI standards and a list of terms to avoid when possible.

This ballot failed due to a disagreement regarding a proposed change to the GEM control state model collection on transition 10 related to the host off-line state. The task force remains evenly divided on this issue; therefore, this change will be withdrawn from the next revision of this ballot.

I am optimistic that the 6572C revision of this ballot will pass voting with little controversy. This ballot has already been distributed to the task force for final review. Little controversy remains unless some voter raises a new issue.

6859 E116

Originally ballot 6859 intended to add significant new features to the E116 standard. However, the aggressive changes have been abandoned. Instead, this ballot is focused on making one change to E116. Currently the E116 specification implements collection events in a manner inconsistent with E30, E40, E87, E90, E94, E109, and E157. This E116 ballot failed. After further discussion in the task force, consensus on the proposed changes seems possible in the next voting cycle. The updated ballot 6859A has already been submitted for review by the task force.

DDA Task Force

The DDA task force has been and continues to update the Equipment Data Acquisition (EDA a.k.a. Interface A) standards with the goal to approve an EDA Freeze 3 set of standards based on gRPC technology. To date the following ballots have been completed:

During these meetings, three DDA task force ballots failed adjudication, 6927 (E125, E125.2), 6928 (E132, E132.2) and 6929 (E134, E134.2) due to procedural errors which violated SEMI regulations. This is primarily due to a long backlog of publications on previously approved specifications. Discussions were held in several meetings in an attempt to find ways to help SEMI get caught up on publications. The delay in publication is partly due to the several large ballots that were backlogged when COVID activity prevented the committee from completing adjudication in remote or hybrid meetings.

Test Session #1

The most important activity for the DDA task force was “vender test session #1” held on Thursday, July 14. An open invitation was made to all task force members to participate in an E132 test session. Anyone could submit a client and/or equipment server implemented with the current E132 and E179 specifications. Four companies came together and ran tests against each other’s software. Each participant will provide the task force with a list of issues in E132 and E179. This was a great opportunity to try the gRPC technology together and get a sense of what issues still need to be resolved before EDA Freeze 3 is complete.

DDA Freeze 3 Plans

The DDA Task force plans an update to E125, E132, and E134 including changes from the recently failed ballots as well as topics raised in the test session. Due to the expanded scope, new ballot numbers will be issued. Additionally plans to update E164 are also moving forward. The biggest challenge for E164 will be converting the XML files into JSON files. Either JSON5 or JSONC will likely be used since comments are mandatory in the E164 complementary files which show how to create GEM 300 capable EDA equipment models.

ABFI Task Force

The Advanced Backend Factory Integration task force is actively working on two ballots.
One ballot is a minor update to the E142, the substrate mapping specification which facilitates traceability and other application where substrate, tray, feeder, and other information can be shared between a factory and equipment. The minor update will add additional substrate types so E142 substrate maps can be used in more applications.

Additionally, the task force is working on ballots 6924 and 6925. The 6924 specifications will define the management of Consumable and Durables on manufacturing equipment. Features include allowing the host to accept or reject newly mounted consumables and durables. Additionally, the equipment will be able to report on consumable and durable usage. While technically both can already be done, the specification establishes a standard way for the features to be implemented. The 6925 ballot maps 6924 for usage in a GEM interface. The plan is to submit the ballot for the next voting cycle.

GUI Task Force

The GUI task force continues to work on a major revision of the E95 specification for Human Interfaces for Semiconductor Equipment. In addition to updating the specification with changes in software development, this revision will establish requirements for the usage of human interfaces on equipment using devices with small screens. The task force seems to be gaining consensus of many topics and getting ready to submit the ballot for voting.

Getting Involved

For those interested in participating, it is easy to join SEMI standards activities. Anyone can register at www.semi.org/standardsmembership.

All SEMI task force ballot activities are logged here.

After joining the standards activities, anyone can get involved. The task forces post everything on the connected @ SEMI website https://connect.semi.org/home. Here are the community names for the task forces covered in this blog:

• GEM 300 Task Force - North America
• Diagnostic Data Acquisition Task Force - North America
• Fab & Equipment Computer and Device Security (CDS) Task Force – North America
• Advanced Backend Factory Integration (ABFI) Task Force – North America
• Graphical User Interfaces (GUI) Task Force - North America

In the late 1980s and early 1990’s the Semiconductor Equipment Communication Standard (SECS) was starting to gain traction. Back then it was based on RS232 serial communication defined by the SEMI E4 SECS-I Standard. Later, SECS-I was replaced by the SEMI E37 HSMS standard. The content of the messages was defined by the SEMI E5 SECS-II standard. At the time, that was all that was defined. It was a bit like the Wild West with each equipment vendor implementing SECS-II messages as they saw fit.

While it was cool to be able to connect to process or metrology equipment and collect data, specify the process, and monitor alarms, it was a big task to develop factory systems that interface to the equipment because each SECS-II interface was unique. One of the first tasks required when developing an interface was to perform an equipment characterization to understand and document the details of the SECS messages used by each equipment. The characterization report became the guide for developing the factory side interface to that particular piece of equipment.

Semiconductor factories were buying hundreds of pieces of equipment for their factories, and though there were usually multiple pieces of the same equipment, there were still many unique equipment interfaces in each factory. The factories had to develop unique interfaces for all the equipment they wanted to automate. This issue was a bit like the tail wagging the dog.

To change things so that each equipment interface wasn’t completely unique, semiconductor factories worked with SEMI to better define how the communication between factory control systems and equipment should work in the factory. In 1992 SEMI published the first version of the E30 standard – Specification for the Generic Equipment Model for Communications and Control of Manufacturing Equipment (GEM). This standard provided a stable base for both factories and equipment manufacturers to work from in developing equipment interfaces. Message usage and contents were consistent, state models were defined, and interface capabilities were well-documented.

Since that time, other equipment communication standards have been developed and approved for use in semiconductor manufacturing. The GEM300 standards for factory automation (E39, E40, E87, E90, E94, E116, E148, and E157) have made it possible to enable fully automated manufacturing. The EDA standards (E120, E125, E132, E134, and E164) make it possible to implement consistent, well-defined data collection.

Even though the SEMI standards are quite well-defined, they are only as good as the implementation on the equipment. Compliance testing is essential for both equipment manufacturers and factories to ensure the interfaces are compliant to the standards and function as defined. In the early days of GEM, compliance testing was an essential piece of factory acceptance of the equipment. Initially, there wasn’t a lot of experience with developing or using the equipment interfaces. This meant that we needed some way to test compliance to ensure the interfaces worked as expected. Even though GEM and GEM300 are now quite established, compliance testing is still important to ensure the communication interfaces will support the functionality needed in the factories.

Compliance testing for the EDA standards hasn't been as well-defined as it has been for GEM and GEM300. In 2011 the International SEMATECH Manufacturing Initiative (ISMI) published the ISMI Equipment Data Acquisition (EDA) Evaluation Method document which provided step-by-step instructions for testing and evaluating an EDA interface. Using that document, Cimetrix developed EDATester which automates the instructions defined in the Evaluation Method document. This automation allows testing that would normally take several days to be done in a few hours, or less.

Having standard, well-defined communication interfaces for semiconductor manufacturing equipment is important to automated manufacturing and data collection. The ability to test developed interfaces and assure that they are compliant with the SEMI standards is essential to successfully introducing the equipment into a semiconductor factory.

Cimetrix compliance test tools automate the testing process making the acceptance process smooth.

Cimetrix CIMControlFramework^TM Software Enables First Delivery to a 300mm Factory

Press release from May 5, 2022

Click here for the PDF

May 5, 2022, Santa Clara, CA – PDF Solutions, Inc. (Nasdaq: PDFS), a leading provider of unified data and cloud analytics for the semiconductor ecosystem, today announced that Infinitesima, a European based equipment supplier for the semiconductor industry, has selected the Cimetrix CIMControlFramework software to meet its demanding needs for precision equipment control and the data connectivity requirements of its Metron3D metrology system incorporating its innovative Rapid Probe Microscope (RPM) technology.

As the global semiconductor and electronics industries race to transform manufacturing floors into “smart factories,” one critical aspect of this transformation is ensuring that the equipment in the factory is enabled with modern software architectures that fully support industry standards for data connectivity such as SEMI GEM, GEM 300 and EDA/Interface A. In order to mitigate the time-to-market risk associated with developing high-quality software in its overall equipment development cycle, Infinitesima turned to PDF Solutions to ensure its innovative RPM system would include the data connectivity and control capabilities that the market and Infinitesima’s customers require.

Before working with PDF Solutions, Infinitesima had sold RPM modules that were integrated into larger 3rd party machines. Driven by the growing need for 3D metrology, the company developed Metron^3D, a standalone platform they could sell directly to semiconductor 300mm factories. This required adding full automation to transport wafers throughout the equipment, as well as a control system supporting GEM300 communication, something that was not required when the RPM was integrated into a larger equipment solution. Infinitesima had limited experience working directly with 300mm factories and the testing and integration a standalone, fully-automated piece of equipment would require.

By selecting Cimetrix CIMControlFramework software for its control and connectivity needs, Infinitesima was able to take advantage of three key benefits: a single software solution that could support the Metron3D and future standalone products, robust and production-proven equipment control framework with built-in GEM300 testing capabilities that greatly reduced the time for completing the software development, and lastly, a team of industry experts that can assist and augment the Infinitesima internal software development team.

“Integrating the Cimetrix CIMControlFramework software for factory connectivity was what we needed to accomplish. However, the Cimetrix professional services team also took care of the supervisory and equipment control responsibilities of the project by integrating our metrology module (RPM) to the Cimetrix solution. This allowed our team to focus on our core competency, investing our time working on what we know best,” said Colin O’Brien, Engineering Director at Infinitesima. “We were able to get our Metron^3D product to market much faster because of the Cimetrix CIMControlFramework software and the professional services team.”

“We have extensive experience helping customers successfully deliver equipment to 300mm factories and this experience can be a vital asset in situations where a company may have limited or no familiarity with the 300mm factory requirements,” said Bob Reback, VP, and GM, Cimetrix products at PDF Solutions. “We seek to provide quality software products, backed by excellent service and support teams. By working closely with the Infinitesima team, the essential equipment control and connectivity needs of the Metron3D system were removed from the critical path of their time-to-market objectives.”

About Cimetrix CIMControlFramework

PDF Solutions’ Cimetrix CIMControlFramework software is an equipment automation framework based on Microsoft .NET technology and is designed to allow equipment manufacturers to meet the supervisory control, material handling, process control, user interface, and factory automation requirements of the factories. Equipment suppliers can leverage framework components or customize them when unique requirements are needed. For more information about Cimetrix CIMControlFramework visit www.pdf.com or contact us at cimetrix_sales@pdf.com.

About PDF Solutions

PDF Solutions (NASDAQ: PDFS) provides comprehensive cloud analytics platforms designed to empower organizations across the semiconductor ecosystem to improve the yield and quality of their products and operational efficiency for increased profitability. The Company’s products and services are used by Fortune 500 companies across the semiconductor ecosystem to impact business outcomes and achieve smart manufacturing goals by connecting and controlling equipment, collecting data generated during manufacturing and test operations, and performing advanced analytics and machine learning to enable profitable, high-volume manufacturing.

Founded in 1991, PDF Solutions is headquartered in Santa Clara, California, with operations across North America, Europe, and Asia. The Company (directly or through one or more subsidiaries) is an active member of SEMI, INEMI, TPCA, IPC, the OPC Foundation, and DMDII. For the latest news and information about PDF Solutions, visit https://www.pdf.com/.

PDF Solutions, the PDF Solutions logo, Cimetrix, and Cimetrix CIMControlFramework are trademarks or registered trademarks of PDF Solutions, Inc. or its subsidiaries. All other trademarks cited in this release are the property of their respective owners.

This blog is the conclusion to the blog: Identifying Custom Test Cases in the SEMI E30 GEM Standard found here.

Unhappy Path Testing

Though this post will focus on the so-called “happy path” (i.e., no errors), it is also important to test unhappy paths.

Conditions that might show up in the “unhappy path” testing include:

1. Card reader loses internet connection.
2. Card reader loses power
3. Vending machine loses communication with Card reader

Happy Path Test Case

The happy path is the program flow that is followed given the user (or in this case, the equipment) only enters valid data. I

n this simple test, we ignore the Error/Alarm cases (Transitions T2 and T4).

Transition Test Steps for Happy Path

1. Initializing T1 =>
2. Wait_Payment T3 =>
3. Wait_Selection T5 =>
4. Dispense_Item T7=>
5. while (User wants more items && has sufficient funds)
   {
   Dispense_Item T6
   Wait_Selection T5
   }
6. Transaction Complete T8

EquipmentTest plugin setup

Prerequisites:

1. EquipmentTest 1.0.3 or later installed.
2. Visual Studio 2019 or later (Targeting .NET Framework)
3. .NET 4.8 SDK
4. A unit of GEM-enabled equipment (or equivalent) to test against
5. Follow the instructions in the EquipmentTest Developer Guide Section titled: “Creating a plug-in using Visual Studio”,

Test Flow

Sometimes I find it beneficial to assert the data as it occurs. For the sake of brevity, this test will gather all the data, and then verify it at the end of the test.

Documentation

Documentation is one if the items the user will see in the EquipmentTest User Interface. Each Test Step must be documented in the plug-in so the user understands what the test is doing.

User Parameters

In GEM, each Collection Event, Variable, and Alarm will have an ID. These IDs are needed for host-side testing. Most modern equipment allows us to get these IDs through characterization messaging. For this example, we will allow the user of our test (plug-in) to enter the values manually.

Custom Test Overview

The HSMS settings are retrieved from the set the user entered in the EquipmentTest user interface.

In Step 1, the Event Report for the Processing State Transitions and associated variables are created.

In Step 2, the test waits for an Auto Reset Event “timeOutWait”. If the result times out, the test fails. If the test receives Transition 8, the test continues.

Steps 1-2

Create Reports

The CreateReports API call sends an S2F33 message to create the report number specified by the user parameter ProcessState Report. The report will contain the status variables ProcessState and PreviousProcessState. Both have a value type of Ascii in this example.

Test Steps 3-4

Step 3 inspects the data to make sure all the state transitions occurred in the expected order.

The first 4 states should always be T1, T3, T5, and T7 respectively. However, the next states will vary depending on how the user responds. This requires the test to dynamically assert the data.

In test step 4, we extract the variable values, and then use the same approach as step 3 to ensure the previous and current process states were reported correct.

Conclusion

Though developing this test took a basic understanding of GEM and C#, running the test requires the user to understand neither. This means anyone with access to the equipment and an EquipmentTest run-time license can run successfully run this test.

Cimetrix EquipmentTest allows the developer to harness the extensibility of the .NET Framework. Furthermore, the well-written and proven GEM libraries flatten a significant portion of the learning curve associated with writing GEM tests.

For more information on Cimetrix EquipmentTest, to request a demo, or to speak with an expert, please click the button below.

Testing the interface capabilities of GEM-enabled equipment not only during development but also while in production has measurable benefits. There are portions of the GEM standard that are not explicitly specified, allowing implementations to vary from equipment to equipment. As a result, equipment manufacturers should write equipment-specific tests that will continue to provide value throughout the equipment’s service life.

Processing State Model

One GEM item that will almost always vary is the equipment’s processing state model. I will use the Cimetrix GEM test utility EquipmentTest to show an example of creating a custom test for an equipment’s processing state. You can request an evaluation of EquipmentTest on our website.

The E30 standard provides an example Processing State Diagram and Transition table.

Process State Requirements

Though implementations can vary without violating the standard, the processing state section includes the following requirements which must be followed for the interface to be compliant:

SEMI E030-00-0520

Explanation:

The examples for the Processing States (INIT, IDLE, SETUP, etc.) are not absolutely required in a GEM implementation. However, the equipment manufacturer must identify the equipment’s states and document them similarly to the examples.

SEMI E030-00-0520

Explanation:

• There must be a collection event for each state transition in the processing state model.
• The following status variables must be provided:
  
  • ProcessState
  • PreviousProcessState
• Whenever any state transition occurs, the ProcessState and PreviousProcessState status variable values must be updated

Pseudo example Vending Machine

Though it is unlikely a GEM interface would ever be implemented on a vending machine, it is a universally known system, often used as a state machine teaching example in academia. Therefore, we will likewise use our imaginary GEM-compliant Vending Machine as an example.

Assumptions to Maintain Simplicity

• The vending machine uses contact-less payment that authorizes $5.00 at the beginning of the transaction.
• The vending machine has no knowledge of the items it contains except their location and prices.
• All items are always in stock.

Make a Diagram

When your GEM documentation is final, the Process State diagram should be in Harel notation. For the purposes of brainstorming, I have used a simple UML diagram.

When building a diagram, first identify all the possible GEM states, transition/collection events, variables, alarms, and errors.

Transition Table

Note the above diagram has each state transition marked in red e.g. T1.

Each state transition must be documented in the Transition Table. The Transition Table will be crucial for developing an effective test.

Part 2 - The Conclusion will be published next week. In the meantime, if you have questions, would like to request a demo, or would like to speak with one of our experts, please click the button below.