Industry News, Trends and Technology, and Standards Updates

The Cimetrix EquipmentTest software product provides a feature for creating a user interface which can be thoroughly customized according to user preferences. The user interface is created as a user control in Microsoft Windows Presentation Framework (WPF) using the standard .NET Integrated Development Environment, and appears as a separate tab following the default “Tests” tab in EquipmentTest. The tab header can also be customized to fit different testing scenarios. Note that the EquipmentTest Pro version is required to develop a customized GUI tab in any plug-in.

This feature is useful for a variety of user types. For instance, factories can run tests back to back on their equipment and use the custom GUI feature to save the output logs as separate files on the system to efficiently identify failed cases. Equipment manufacturers can use this feature to customize their test scenarios and analyze results in a way that enables the comparison of previous test output data to the latest results. Other user types may imagineer all sorts of additional possibilities, making EquipmentTest a truly versatile tool. 

How To Add a Custom GUI Tab To a Plug-in

One can either override or append to the OtherTabs property of the PluginBaseModel class to add as many GUI tabs as needed. The examples below include code snippets for both cases.

The following image shows a general plug-in with two GUI tabs in which the custom GUI has been modified to contain a single button.

Uses for Customized GUIs in a Plug-In

The following paragraphs discuss two elegant uses for customized GUIs in EquipmentTest.

Duplicate a Different Control Panel

If you are a new user of EquipmentTest, you can use the custom GUI feature to recreate familiar interfaces from other test systems. Since the GUI is developed in WPF, you have a great deal of flexibility and control over the layout and operation of the GUI. This means that the tests can be modified to be run according to  specific user selections, and/or additional information specific to the chosen tests can be included on the GUI. For instance, logs can be modified to include more detail than is currently shown on the default screen.

The following Images show the TESTConnect user interface and its recreated GUI on EquipmentTest. Of course, it is not an exact replica, but most of the original functionality can be supported, and with some effort, the GUI could be modified to become an exact match.

Compile On the Fly

The EquipmentTest custom GUI feature enables use of the compile-on-the-fly capability of .NET. If you can dynamically write and run test code, tests scenarios can be changed without editing, rebuilding, and loading the plug-in each time a change is required. this results in a faster and more efficient testing process.

The “Compile” method defined below takes in the test code to be run as a parameter. It is then compiled to create a DLL library with the required references. Any compilation errors are written to a designated TextBox on the GUI through the event handler “WriteLog”.

The following image is a GEM plug-in with an additional custom control panel for dynamically running code. The TextBox is dedicated for writing code, and the various buttons are used to control the testing procedures. This example is part of a project that supported direct execution of TESTConnect scripts in EquipmentTest.

The first task was creating a console application to generate an XML file containing the converted C# test code of the TESTConnect script to be passed as the argument. The next task was developing an EquipmentTest plug-in that loads the XML file and displays each script as a separate test on the example GUI shown below. This example is designed to support any number of tests, and new tests can be added using the “New” button. In this way, you can directly write code to send messages and check to see if the reply message is the expected one. The example also defines wrapper methods to reuse this messaging code and thereby speeding the development process for similar use cases. Console output can be redirected to text boxes designated for logging, and wrapper methods can be defined to log message details. Although this feature effectively enables scripting in EquipmentTest, there are a few drawbacks that must be addressed. Whenever you need to use a new API method, you must add the reference to the required library in the plug-in, rebuild and load it again to continue testing. A good solution is a 'Save' button which allows you to create an XML file similar to the one you initially loaded with the current changes so you can directly load it after adding the library references. Another issue is that the aesthetic feel code written in Visual Studio will differ from that of the text boxes in EquipmentTest.

However, the overall picture is bigger than what I have explained here. You can customize EquipmentTest to run your tests in any way you prefer. If you need more space to write your test code, you can edit the test code in a C# file stored on your computer and directly run it from EquipmentTest. You may or may not display the code on a text box on the EquipmentTest GUI. Moreover, you can also save the generated output logs in a local file as well. It is up to you to further explore this feature.

Conclusion

In the previous paragraphs, we explained what a custom GUI plug-in is and how to access it with a dedicated GUI tab. This is a powerful capability that opens up a wide range of possibilities for all the users of EquipmentTest. We highly recommend that you explore this feature and puttit to good use to increase your testing productivity while reducing the overall effort to achieve results. The EquipmentTest documentation is a great source of additional information, and we sincerely hope we’ve convinced you to give it a try!

Process Recipe Management Custom Message Handling

Process Recipe Management provides a means to transfer process specifications and to share the management of these specifications between the host and the equipment. CCF provides GEM-compliant Process Recipe Management through class RecipeHandler which handles Steam 7 functions used for formatted and unformatted process programs. In some cases, CCF users may want to implement equipment-specific recipe handling, which can be done by extending the methods of RecipeHandler. For example, to customize host-initiated S7F5 for a recipe to be uploaded from the equipment, create a subclass MyRecipeHandler from RecipeHandler, and override the RecipeRequest method.

Follow this same approach to use the customized message handling class properly: before creating the FactoryAutomationServer, create a CimConnectServices and assign it to the CimConnectServices instance. Then create the custom message handling class MyRecipeHandler and assign it to the corresponding property on the CimConnectServices.Instance.

Custom SECS-II Message Handling

CCF provides a mechanism that enables the equipment’s GEM interface to support any SECS-II messages. These can be additional SECS-II messages defined in the SEMI E5 standard but not supported by CCF, and/or they can be custom SECS-II messages defined by and required by the end user or by the equipment supplier. For example, if a user wants to handle a custom message S100F1, they can create a subclass CustomMessageHandler and let it implement the IGemHandler interface, and then initialize it by overriding the Initialize method of CIMConnectServices.

To learn more about GEM interface custom message handling, please schedule a time to talk with a Cimetrix representative by clicking the button below.

This blog explains an approach that Cimetrix CIMControlFramework^TM (CCF) developers can use to dynamically generate ECVs (EquipmentConstant Variables) in source code as a convenient, effective alternative to including them in the default configuration file.

When implementing the GEM interface for equipment, it is often necessary to define EquipmentConstant Variables (ECVs). If the GEM interface is part of a CCF-based equipment control system, you would normally define the ECVs in the Equipment.epj file. However, registering the ECVs with this approach can take a lot of effort in a number of situations. Among them:

• When you need to register hundreds or even thousands of ECVs;
• When you need to dynamically register ECVs based on the specific configuration of an instance of the equipment;
• When you want to register ECVs without changing the EPJ file.

In these cases, dynamically generating the ECVs from the source code easily addresses these challenges.

The rest of this posting briefly shows you how to accomplish this, and how to change and monitor the values of ECVs.

How to generate ECVs programmatically 

After calling ecs.Start() inside Supervisor's Run(), the code sample below generates an ECV.

What you need to be most careful about here is that the ecid and ECV’s name should not be duplicated with other VIDs.

Then you can see the newly generated ECV  in the Equipment Constants screen of the OperatorInterface.

How to change the value of an ECV

The ECV’s value can be updated  through FactoryAutomationServer using the code below.

You can then see a message that the ECV’s value has been changed.

How to detect the ECV’s value change

If you want to detect changes to the ECV’s value, you can receive a callback  by registering ValueChangedHandler as shown in the code sample below.

To Summarize:

• You can dynamically generate an ECV by calling CreateVariable of CIMConnect;
• You can change the value of an ECV by calling SetEquipmentConstants of FactoryAutomationServer;
• You can detect changes in the value of the ECV by calling RegisterValueChangeHandler of CIMConnect.

All are helpful solutions for CCF developers who need to generate ECVs dynamically.

To learn more about this solution and other CCF programming best practices, please schedule a time to talk with a Cimetrix representative.

Background

At SEMI in North America, the Information & Control Committee meets three times per year; spring summer and fall. This year the summer meetings were held on July 10, 11 and 13 in conjunction with SEMICON West is San Francisco, CA. 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 which was held on Thursday instead of the typical Wednesday. This is a summary of what happened in the task forces I am highly involved in including GEM 300, ABFI and DDA as well as some updates from SEMI.

Note that all ballots that pass are still subject to a final review by the global SEMI Audit & Review committee, where a ballot can still fail when proper SEMI procedures and regulations were not strictly followed.

SEMI

A few changes are happening at SEMI. SEMI is planning to start publishing ‘red-line’ versions of the SEMI standards. Today, when a new version of a SEMI standard is published, it includes change bars on the side to indicate where changes have occurred. The changed section can then be compared with the previous publication to see what changed. While this is helpful to readers, the planned ‘red-line’ versions will identify precise changes using redline strikethrough and underlining to identify the changes. This is a big benefit to the standards community. I look forward to seeing this new feature.

SEMI is planning to add additional digital enforcement to the SEMI standard documents to help enforce SEMI’s copyright to the standards. This should help curb some of the copyright abuse. Every company implementing or using the SEMI standards should have at least one subscription to SEMIViews, https://www.semiviews.org/.

SEMI has hired another technical writer to help keep SEMI standard publication up to date. Recently, the growing queue of standards awaiting publication has affected SEMI standards development. For example, this has caused delays in the DDA task force developing EDA Freeze 3. In the last 9 months, SEMI has already reduced the publication queue substantially and is committed to catching up early in 2024.

GEM 300 Task Force

A lot is going on the GEM 300 task force.

Ballot 7065, an update to the SEMI E172 passed nearly super-clean. SEMI E172, SPECIFICATION FOR SECS EQUIPMENT DATA DICTIONARY (SEDD) defines the XML schema for documenting a GEM interface. Recently the GEM standard was updated to allow transfer of a SEDD file through the GEM interface using Stream 21 messages. Ballot 7065 adds a few new features and changes to the schema files. The most important changes are names for alarms and a ‘well-known’ element to all collection events, variables, and alarms. This ‘well-known’ element is meant to contain a standardized alias so that end users can automatically map an implementation to required items in the SEMI standards. To capitalize on the new E172 ‘well-known’ feature, new ballots were approved to modify E5/E30, E40, E87, E90, E94, E116 and E157 to include standardized ‘well known’ names. These ballots are expected to be completed in time for cycle 7 voting this year.

Ballot 7066 proposed changes to the SEMI E87 Carrier Management Services (CMS) standard. This included a significant change to the new Carrier Ready to Unload Prediction feature. The primary driver for this change is to accommodate internal buffer equipment where the READY TO UNLOAD state depends on when the host sends a CarrierOut message and can be drastically impacted by the carrier-out queue. The ballot proposes to use CARRIER COMPLETE prediction instead, which can be universally applied both fixed buffer and internal buffer equipment. The change has little impact on fixed buffer equipment, where the time between CARRIER COMPLETE and READY TO UNLOAD is typically short and a fixed time. Unfortunately, this line item in the ballot needs some rework before it is ready for acceptance.

The other line items in ballot 7066 passed including a clarification to the ContentMap behavior and an update to the CMS compliance statement. Two requirements related to the ContentMap were in contradiction to each other affecting the ContentMap value when a carrier object is instantiated. The clarification allows the ContentMap to either be an empty list or a structured list of empty lot and substrate ID information. The change only affects the initial value. The compliance statement change adds the missing “Access Mode State Model” to the compliance statement so implementers can declare whether this feature is implemented and compliant.

Ballot 6991 also passed as super-clean (no negative votes) to update SEMI E4 SEMI Equipment Communications Standard 1 Message Transfer (SECS-I). The update removes biased terminology to be compliant with recently updated SEMI regulations. No technical changes were made.

ABFI (Advanced Backend Factory Integration) Task Force

New proposed standards for Consumables and Durables (ballots 6924A and 6925A) both will require Ratification ballots. This means that a few technical changes need to be made for the new standards to be accepted. Ratification ballots R6924A and R6925A will be submitted in the next voting cycle with those technical changes. If this passes, then the new standards will be published. If it fails, then the ballots will be reworked for another voting cycle.

DDA (Diagnostics Data Acquisition) Task Force

The DDA task force meeting was relatively quiet and uneventful for the first time in years while the task force waits for accepted ballots to be published including updates to E125/E125.2, E134/E134.2, and E120.2. No ballots were adjudicated. Ratification ballot R7002 for SEMI standards E132 and E132.2 passed in the voting cycle 4. Meanwhile new versions of E121 and E179 were published by SEMI in April and June, respectively.

Next steps for the DDA task force include updating E164 and planning a ‘vendor test session’. The E164 update is tied to the GEM 300 ‘well-known’ feature mentioned above, where the E164 names and IDs will be synchronized with the aliases added to the GEM 300 standards. The vendor test session is planned to occur during Spring 2024. Any company wishing to participate to validate EDA client or server software against other implementations is welcome. Participants will run through a small set of E132 scenarios, E125 scenarios and E134 scenarios to validate the current standards. Any issues found during this testing will be quickly resolved so that an EDA freeze 3 version can finally be declared. The task force leaders plan to share a test plan before Fall meetings to help everyone prepare.

Richard Howard, Director of Technical Operations, Cimetrix Connectivity Group (a part of PDF Solutions), along with other leaders of the SEMI Fab & Equipment Computing Device Security (CDS) Task Force, were awarded the SEMI International Standards Excellence Award, along with his co-leaders on the SEMI Fab & Equipment Computing Device Security (CDS) Task Force  (Leon Chang of TSMC, Ares Cho from ITRI and Ryan Bond of Intel). The award was announced at SEMICON West.

This award recognizes years of involvement and leadership by Richard Howard and the team in the development of new Semiconductor industry standards, in particular in the area of cybersecurity. Recognizing the urgent need for robust cybersecurity measures, SEMI's International Standards Information & Control Committees in Taiwan, Japan, and North America formed task forces in the fall of 2018 to investigate the feasibility and implementation of standards to address these threats. Over the years, the task forces worked diligently through regular meetings to coordinate efforts and eliminate redundancies.  As a direct result of this work, SEMI recently published its first two Cybersecurity Standards.

"I am very honored to be recognized with the other co-leaders of their respective task forces." said Richard Howard.  "I believe this award also truly recognizes the collaborative, international effort of the many task force members who have worked diligently to develop these initial standards. Our work is just beginning."

"We are extremely proud of the work of Richard Howard," said John Kibarian, PDF Solutions’ President and Chief Executive Officer. "These standards are a critical step toward safeguarding the semiconductor manufacturing infrastructure from the growing threat landscape. Through the dedicated efforts of the leadership of these task forces, and SEMI Standards members, there is a robust framework designed to enhance cybersecurity practices across the industry."

PDF Solutions and Cimetrix by PDF Solutions are exhibiting at SEMICON West 2023 in less than a week and we hope to see you there!

SEMI is the principal industry association that represents the global electronics manufacturing supply chain, and regularly brings industry leaders together to drive the future of electronics and advanced semiconductor manufacturing. SEMICON West is one of its premier annual industry events, and this year’s gathering will take place July 11-13, 2023 at the Moscone Center in San Francisco, California with the theme “Building a Path Forward.”

At SEMICON West 2023, The Cimetrix Connectivity Group (CCG) of PDF Solutions will exhibit our latest software solutions that are designed to improve manufacturing quality and productivity. You can find us at booth #344 as well as a variety of other places during the exhibition. Be sure to stop by any of the following activities:

• John Kibarian (CEO, PDF Solutions) will participate In DAC Research Panel "Why Is Curvy Design an Opportunity Now?" (July 11 at 1:30 pm)
• Greg Prewitt (Director, PDF Solutions) will speak at the Test Vision Symposium on "Enhanced Parametric Test Insights Through Dynamic Data-Driven Test Flow Execution" (July 12, 11:15 am)
• Ranjan Chatterjee (VP, Cimetrix Connectivity Group) will chair the AI/ML Enabled Manufacturing Operations Panel (July 12 at 2:00 pm @ Smart Manufacturing Theater)
• Alan Weber (VP, Cimetrix Connectivity Group) will present "Connecting the Dots: From KPIs to Smart Manufacturing Applications to Industry Standards" (July 13 at 10:35 am @ Meet the Experts Theater)
• Ming Zhang (VP, PDF Solutions ) will participate In a panel discussion "From Assembly Line to Field: The Future Semiconductor Testing" (July 13 at 3:40 pm @ Test Vision Symposium)
• PDF Solutions presentation at AWS booth #1841
• Exensio and proteanTecs daily demos - DAC booth #2449 at 2:30 pm and SEMICON booth #1834 at 11:30 am

At our booth (#344) we will showcase the latest versions of all our industry-leading solutions, as well as our Smart Factory platform, Cimetrix Sapience. Stop by to speak with an industry expert, or contact us by clicking the button below and let us answer all your questions!

Have you experienced a lack of storage space on your equipment?

There can be many reasons for this, and one of them is a lack of space for saving logs.  

One of our Cimetrix CIMConnect customers had this issue and asked if there is a way to add storage to their tool. The engineer commented that there are no available USB slots on their equipment computer. Therefore, he got permission to add a network drive to their system.

How to configure an external network drive for CIMConnect logging

1. Connect an external storage device to the network and you may see it in your File Explorer.
2. Run CIMConnect Control Panel
   1. Go to the equipment tab (“Equipment1” in this view)
   2. Go to “Logging Configuration” under “Equipment” menu.
   3. Click on the folder icon next to the “Directory” text box. 
   4. In the “Browse For Folder” window, find your network drive. 
      
      Here’s tricky part: you may find one under your network, not a mapped one.  It will give an absolute path name, such as “\\RT-AX56U-83E8\Cimetrix_Ian\CIMConnect Logs”
3. If you still cannot see any log files created in that network drive directory. 
   In this case, please follow the steps below to register EMService as a COM Local Server. 
   
   1. Open Windows Command Prompt as an Administrator.
   2. Type “EMService.exe /RegServer” (without quotation marks) and hit Enter.
   3. Restart your EMService: go to Windows “Services” and select EMService then click “Restart”.
      

These steps set a network drive as your extended CIMConnect storage.

To Summarize:

1. Connect an external drive to your network.
2. Use CIMConnect Control Panel to find and set up the added drive. Don’t forget to configure one in the network, not a mapped drive.
3. Register CIMConnect’s EMService as your COM local server.
4. Restart EMService and enjoy the extra storage.

As I mentioned at the beginning, this is a good solution for those who do not have sufficient storage in their existing equipment control system. It is usually difficult to replace the entire PC on your equipment, but external storage can be as simple as I described in this posting.

To learn more about CIMConnect, logging or other products,  please feel free to reach out by clicking the button below.

In the semiconductor industry, the fabrication process is a complex process and involves multiple steps to achieve the desired result. Each process step uses different types of equipment. Semiconductor industry equipment uses a specific type of communication protocol called SECS/GEM (SEMI equipment communication standard and Generic equipment model).

High-level architecture of a fabrication factory

• MES: Manufacturing Execution System is the central part of the production process. It connects with multiple equipment and monitors the progress of material in individual equipment and the entire factory at the same time. It integrates the ERP system (Enterprise Resource Planning) and individual machines.
• MES DB: It is a MES database system that will store the MES related information including recipe information.
• FDC: Fault Detection and Classification is used to continuously monitor the sensor data coming from the equipment and analyze and detect fault to prevent it from reoccurrence.
• APC: Advanced Process Control uses R2R (Run to Run) method that adjust the process parameters based on the incoming and outgoing data from an equipment for a material in combination with process model.
• Host: This is an application that connects with the equipment via SECS/GEM. This application instructs the equipment to process the materials and retrieve the related information.
• Equipment: This is a tool that performs and process the incoming materials based on the instruction given by the host.
• DB: This is an equipment database that can store the material processing information as a raw data form. (Example Metrology tool data).

Some of the SECS/GEM standards we will highlight are E4, E37, E5 and E30.

Communication Layer

There are two different types of GEM communication models.

• SEMI E4 standard which is SECS-I a serial communication model that uses RS-232.
• SEMI E37 standard which is HSMS communication model that uses TCP/IP. (There is a subset of E37 standard is called E37.1 HSMS-SS).

Message Structure Layer

The Message Structure Layer is also called the SEMI E5 standard. A typical SECS/GEM message contains a header and a body. The Header contains Stream and Function, and a Body contains a list of one or more data items. Each data items may contain another list of data items. Refer the below example.

GEM Layer

Messages can be categorized into two types, the primary message and secondary message.

Primary messages are usually the request message that will be initiated by one party (Host/equipment). The secondary message will be the response that will be acknowledged by the other party (host/equipment).

Some common GEM messages include:

• Collection Events – these messages are raised when the equipment processes the substrates using S6F11.
• Alarms – these messages are raised when any problem occurs at the equipment using S5F1.
• Remote Commands – these messages are sent by the host to command the equipment using S2F41.
• Recipe Management – these messages manage the recipes and can sent by either party. Example: S7F3 is the recipe download command.

A typical process flow between a host and the GEM based equipment is explained below.

Conclusion

This blog post has summarized how the factory host communicates with equipment using SECS/GEM protocol. At the Cimetrix Connectivity Group of PDF Solutions, we have products for the factory hosts that can easily be integrated with any existing systems with minimal configuration settings. To learn more about our products for the factory host click on the below button.

If you’ve ever wondered how to implement the SEMI E30 GEM (Generic Equipment Model) communications standard in a PLC-based equipment control system, read on – this posting is for you!

What problem does the GEM OPC Connector Application solve?

The Cimetrix CIMConnect product provides a software library that equipment suppliers in a wide range of manufacturing industries use to integrate the GEM standard into their equipment control systems and associated applications. These applications are typically written in C#, VB.NET, or C++, which must run on a Microsoft Windows operating system.

This solution works great for equipment controllers that run on Windows, but what about equipment that does not use a Windows-based control system? In particular, some equipment controllers are PLC based and therefore cannot use the CIMConnect libraries directly. What then? The GEM OPC Connector application very effectively addresses this specific situation.

GEM OPC Connector Application Description

The screenshot below shows the GEM State Settings and current status of a GEM interface implemented by the GEM OPC Connector application. 

The GEM OPC Connector is provided as a CIMConnect sample application. Several of our customers have used it to implement a GEM interface for their PLC-based equipment applications. Since it runs on the same computer as CIMConnect, it requires a Windows operating system, but thankfully, most equipment types that have PLC-based controllers also have a Windows computer somewhere in the overall control system. For example, the HMIs (Human-Machine Interfaces) on much of this equipment run on Windows computers and use OPC UA (or OPC Classic) to share data between the HMI and PLC controllers. In this configuration, CIMConnect and the GEM OPC Connector application can be installed on the HMI Windows computer and connect to the same OPC UA server that the HMI uses (see the block diagram below). Of course, if the equipment controller does not already have a Windows computer, one would have to be added to the controller to use this solution.

How Does it Work?

The GEM OPC Connector application is both a CIMConnect application and an OPC client. GEM features are supported by CIMConnect and variables defined in the OPC server can be used to invoke method calls in CIMConnect or to receive notifications from CIMConnect. OPC variables can be used to:

1. Update status variables (SVIDs) and equipment constants (ECIDs)
2. Trigger collection events (CEIDs)
3. Set or Clear alarms.
4. Receive notification of remote commands from the host.
5. Invoke custom methods. For example, there are pre-defined methods to:
   1. Set the Offline/Online switch,
   2. Set the Local/Remote switch,
   3. Enable/Disable GEM communication with the host,
   4. Change the GEM communication settings.

As OPC UA tags  are updated by the PLCs or the HMI, the GEM OPC Connector monitors these tag value changes and calls the appropriate methods in CIMConnect depending on the function of each OPC UA tag.

Data updates and control signals can go in the opposite direction as well. For example, when the host sends a remote command to the equipment, the GEM OPC Connector handles the remote command by updating the OPC UA tags associated with that remote command’s parameters and setting a Boolean OPC UA tag value to “True” to notify the PLC-based control application that a remote command has been invoked by the host.

An XML configuration file defines the various types of links between OPC UA tags and GEM artifacts. Each link describes a specific function and provides the additional information needed to perform that function. The following sections give examples for several common link types.

Variable Links

Variable links are used to keep GEM variables and OPC UA variables in sync.  The links look like this in the XML file:

This example links the GEM EstablishCommTimeout equipment constant (VID = 4000) to an OPC UA tag = “Channel1.Device1.Standard ECs.EstablishCommTimeout”. Since equipment constants can be updated by the operator or by the host, the Direction attribute is “Both”.

Alarm Links

Alarm links are used to Set and Clear GEM alarms. Alarm links look like this in the XML file:

This example links a GEM alarm (ALID = 20045) to a Boolean OPC UA tag = “Channel1.Device1.Alarms.PMTempTooHigh”.  The PLC software sets this value when an alarm state changes. The GEM OPC Connector monitors this tag for any value changes, and calls the SetAlarm() or ClearAlarm() methods in CIMConnect to update the associated alarm state accordingly.

Event Links

Event links are used to trigger GEM collection events. Event links look like this in the XML file:

This example links a GEM collection event (CEID = 5000) to a Boolean OPC UA tag = “Channel1.Device1.Events.LoadLockDoorOpened”. The GEM OPC Connector monitors this tag for any value changes, and when the value changes from 0 to 1, it calls a method in CIMConnect to trigger the associated event.

Remote Command Links

Remote command links are used to notify the PLC equipment application of a remote command initiated by the host. Remote command links look like this in the XML file:

This example links the GEM “PP-SELECT” remote command to the Boolean OPC UA Tag = “Channel1.Device1.RemoteCommands.PP-SELECT”. Parameter values are optional. In this case there is a single parameter linked to OPC UA tag = “Channel1.Device1.RemoteCommands.PP-SELECT_PPID”. When the host sends the PP-SELECT remote command using S2F41 “Host Command Send”, the GEM OPC Connector handles the message as follows: if the value of the Processing State is such that the equipment can accept this remote command, the parameter value will be updated first, and then the PP-SELECT value will be set to ”True” to notify the PLC application that the remote command was invoked.

Method Links

Method links are used to invoke custom methods in the GEM OPC Connector itself. Several pre-defined methods are available, and custom methods can be added, but the latter requires source code changes to the GEM OPC Connector application. Method links look like this in the XML file:

This example links the method named “PPChange” to the Boolean OPC UA tag = “Channel1.Device1.Methods.PPChange”. Methods may have parameters, and in this case, there are two parameters linked to OPC UA tags: one for the Process Program name that has changed, and another to describe the type of change that was made (Create, Edit, or Delete). To invoke this method, the PLC should first update the parameter values and then change the PPChange OPC UA tag value from 0 to 1 to notify the GEM OPC Connector that the method has been invoked. The GEM OPC Connector then looks for the method by name and executes the code.  In this example, it would update the GEM data variables PPChangeName and PPChangeStatus and trigger the PPChange collection event.

Conclusion

This quick overview of the GEM OPC Connector application is intended to pique your interest in this capability and prompt you to contact us to find out how much more there is to be learned. If you think the GEM OPC Connector might be right for you, reach out to us by clicking the button below for a demo !

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.