Industry News, Trends and Technology, and Standards Updates

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.

With semiconductor factories worldwide running a full capacity in most market segments, it is no wonder that productivity is now an important careabout across the industry. Factory managers carefully monitor their Key Performance Indices (KPIs) for any indications of lost productivity so they can react quickly to identify and address the root causes of these excursions. At the same time, they question whether their productivity metrics are presenting an accurate picture of factory performance, since these tracking systems may have been in place for many years and not updated to leverage the full suite of available productivity standards and the associated data collection infrastructure.

If you are one of the people harboring such questions, this blog posting and the information conveyed in the underlying presentation are for you. In them, we highlight the key principles of productivity management in a complex manufacturing environment, describe the spectrum of SEMI standards that have been defined and refined over many years to support this process, identify the various data sources, collection methods, and system components necessary to implement them, and provide several concrete examples of how these pieces fit together.

Productivity Principles

Manufacturing productivity management can be tricky because there are inherent tradeoffs in some of the metrics (see intuitive illustration). Consequently, they must be considered as a set rather than individually…

• Quality
• Capacity
• Throughput
• Cycle time
• WIP levels
• On-time delivery
• Equipment utilization

One of the most obvious examples is the conflict between equipment utilization and cycle time, especially in a wafer fab setting with reentrant, cyclical processes that use the same equipment multiple times. To minimize cycle time, you would want to ensure that product material never had to wait for equipment to become available. However, that will leave non-bottleneck equipment idle some of the time. On the other hand, if you maximize equipment utilization, WIP (Work in Process) levels will rise, degrading the cycle time for material queued for the next equipment type in its process flow. And so on.

SEMI Standards for Productivity Improvement

SEMI has a long history of defining standard metrics for the measurement and monitoring of equipment and factory productivity, but few, if any, companies take full advantage of these standards. Likely reasons for this include lack of awareness of what standards are available, limited understanding of what it takes to implement them, insufficient connectivity to the data sources required for a robust implementation, limited financial and personnel resources to build such a system, and no continuity of the subject matter expertise needed to oversee a comprehensive productivity management strategy. Daunting challenges, to be sure, but worthwhile to overcome in the current capacity-constrained environment.

This posting targets the first two of these challenges, and with the connectivity solutions in our product portfolio, we at the Cimetrix Connectivity Group of PDF Solutions can help address the third.

The SEMI standards that address Overall Equipment Effectiveness/Efficiency (OEE) include:

• E10, E58 – Equipment Reliability, Availability, Maintainability (RAM, ARAMS)
• E79, E116 – Measurement of Equipment Productivity, Equipment Performance Tracking

The principal objective of these standards is to account for every minute of an equipment’s life in the factory, dividing that time up into non-overlapping states to highlight and maximize the time spent in “productive” states while minimizing and identifying the root causes of the time spent in “non-productive” states. These standards have evolved over time from the initial definition of the six E10 equipment states (see figure below) to the definition of many useful sub-states, specification of formulas for calculating various measures of efficiency and “loss” categories based on these states, adaptation of these formulas to complex, multi-module equipment types, description of methods for automating the collection of event data that chronicle the transitions from state to state, and so on.

It’s a lot of information to absorb, but each step along an implementation path can yield a return on that investment through the improvement of OEE-related KPIs.

A more recent but less familiar SEMI productivity standard has the same “account for every minute” objective but looks at the life cycle of the product material (lots, substrates, devices) in the factory rather than the equipment. These standards emerged from the Sematech “Wait Time Waste” initiative—now called Product Time Measurement—and consist of the following:

• E168 – Specification of Product Time Measurement (terminology, concepts, time elements, etc.)
• E168.1, .2, .3 – PTM for 300mm production equipment, Material Control Systems (MCS), and transport equipment (AMHS)

These standards divide product material time into two major states—“active” and “wait”—and then define explicit “time elements” (and associated GEM/GEM 300 begin/end triggering events) within those categories that describe what was happening to the material (processing, movement, outgassing, etc.) during its “active” time, and what/who it was waiting for (FOUP unload, robot arm, gate valve opening, recipe start, etc.) during its “wait” time. The figure below shows a sequence of wait and active time elements for a lot between the completion events of two contiguous process steps.

Conservative estimates from factory operations managers familiar with the behavior of complex multi-chamber equipment suggest that there is 5-7% of untapped capacity in this kind of equipment that a product material-focused standard like E168 could expose and capture.

Infrastructure Implementation Technologies

After determining which of these standards you want to implement and to what extent, the remaining tasks deal with identifying the specific data sources/elements in the factory that must be connected to your data collection infrastructure and creating the pathways for this data to flow. Fortunately, over 95% of the information needed is referenced in at least one of the following SEMI standards suites:

GEM/GEM300

• E30, E40, E94 – Machine States, Process Job Management, Control Job Management
• E87, E90 – Carrier Management, Substrate Tracking
• E157 – Module Process Tracking, Recipe Execution Tracking

Equipment Data Acquisition (EDA / Interface A)

• E120, E125, E164 – Equipment Metadata Model
• E132 – Authentication and Authorization
• E134 – Data Collection Management

Moreover, there is plenty of commercial software available that implements these standards, so there is absolutely no reason to tackle this in-house. Nevertheless, the remaining challenge in this process is validating that the suppliers have faithfully implemented the standards in their equipment and that the semantics of the events called for in the productivity standards are consistent across the factory. For example, 300mm process equipment that provide a SEMI E164-compliant (EDA Common Metadata) EDA implementation will include the complete set of GEM 300 events with identical sets of state/event/parameter names. Other equipment interface implementations may have slight variations that require a custom mapping layer in the event handling.

The figure below shows the E90 (Substrate Tracking) state machines used in some of the E168 time element definitions, and the corresponding E164-compliant metadata model content used to define the EDA Data Collection Plans (DCPs) that provide this information in real-time.

On the “factory side of the wire,” it makes sense to incorporate modern commercial system technology as well, especially since a new productivity infrastructure could be implemented as a separate, complementary system rather than trying to squeeze it into an existing factory system architecture. A high-level diagram of a cloud-native instance of such a system is shown below. Note that it features a broad range of data source types (equipment, subsystems, sensors) using multiple connectivity standards (GEM, EDA, OPC UA, MQTT) at its lowest layer, all abstracted by a layer of RESTful APIs that in turn support a multi-supplier application ecosystem.

Want to know more?

This material has recently been accepted for presentation at the 20th European Advanced Process Control and Manufacturing Conference (apc|m) in Toulon, France (4-6 April 2022) – we hope to see (or hear) you there. Between now and then, you can access a preview copy here, and feel free to contact us with any questions.