Industry News, Trends and Technology, and Standards Updates

Do you need to develop complex drivers for the components in your equipment? Let’s see how the CIMControlFramework^TM Communicator Framework helps you accomplish this.

What is the CCF Communicator Framework?

The Communicator Framework simplifies the low-level message handling to and from the hardware by encapsulating the connection between CCF and the device.

As an example, consider how the connection is made between control software and hardware devices. An ASCII serial connection needs a socket connection using TCP, a multi-threaded mechanism to handle multiple messages to/from the devices, logic to synchronize the commands and their respective responses, and several other functions. This is a lot of work when developed from scratch.

As an alternative, CCF provides a built-in ASCII serial connection class to achieve all these quickly. You can simply use this class to create an ASCII serial connection to the component.

What is the specific role of the Communicator Framework?

Each component or device in an equipment provides a set of commands and responses to perform its designated function. The Communicator Framework includes a Transaction class that handles these commands; each command to a particular device is implemented as a transaction.

Consider the case of the Clamp activity for a loadport—the associated command could be “LOCK.” Now let’s see what are our tasks are to implement this command in a loadport driver as a CCF developer.

The first step is to create a Transaction class for the loadport which must be inherited from the base CCF Transaction class. See below for an example that creates the “Clamp” transaction.

In this example, the ClampTransaction class accepts the command Clamp as an attribute. The command which is passed as the attribute to its base class will be sent to the device through the ACSII serial connection.

The next step is to implement a Communicator class to send the command and receive responses from the device. See the sample code below.

The CCF product includes a LoadPort class. Here we initialize the Communicator class with the ASCII serial connection to perform the transaction.

When a clamp activity is needed, CCF calls the Clamp function of the LoadPort to do the clamping. We use the Communicator object just initialized to send the command to the hardware. Note that we did NOT write any code for sending the command or receiving its response because this is the job of the Communicator.  You send the command to the hardware by calling the PerformTransaction function of the Communicator base class as shown below.

Believe it or not… that’s it! We sent a command to the device with very few lines of code in the driver. Now, how do you handle responses from the device? Let’s have a look.

Each device implements different responses to the command set, depending on the manufacturer of that device. This may include acknowledgments, data items, events of various types, and so on. So, whenever the Communicator receives a response from the device, it calls an abstract method on a child class to parse the response. As a CCF developer you must decide what type of response it is, whether or not it successfully completes the transaction, and how to respond to the Communicator as a result.

The example below shows how to parse a response from the device.

Finally, how can we deal with the events from the hardware? From the code above you can see how to indicate that the type of response is an Event, and in this case, it will invoke another abstract method on its child class to handle the event. The CCF developer can then handle it in their code as shown below.

That’s all there is to it. The code segments above provide an example of a basic loadport driver that includes a Clamp transaction.  To implement additional commands for your device, simply add more transactions and call them from the equipment controller. The Communicator Framework will handle the rest of the communication with your device.

To learn more about CCF or other Cimetrix products, click the link below:

Background

The China summer SEMI Standards meeting was convened on August 8, 2023 in Shanghai. Two task forces met; the ABFI (Advanced Backend Factory Integration) and GEM300 Task force in the TC China Chapter. I actively participated in both task forces to closely monitor and comprehend all activities discussed during the meeting.

ABFI (Advanced Backend Factory Integration) Task Force

Ballot 7018, one Line Item revision to the SEMI E87-0921, Specification For Carrier Management(CMS) and E87.1-0921, Specification for SECS-II Protocol for Carrier Management(CMS).

It provides a means for the host or equipment to provide the slot map, which contains information regarding the correct and incorrect placement of substrates within a carrier. Additionally, it supports configuration settings that indicate the slot map is not read and will not be verified against host-provided information.  Furthermore, new related roundtrip scenarios are added to Related Information 1 – Carrier Object ID when the equipment lack the hardware for scanning a carrier’s slot map. This ballot was submitted for cycle-2 voting in February 2023 but received three rejections with a total of five negatives. During the ABFI Task Force meeting, we thoroughly reviewed and addressed these negative items.  Consequently, we will revise this ballot accordingly and submit it to the A&R committee for review. 

1. Line Item #1, Reject from Miyamoto Motoki (Yokogawa)
   • Negative 1 to Line Item #1 :  Accepted and do modification according to negative comments.
   • Negative 2 to Line Item #1-g : Accept and do modification according to negative comments.
2. Line Item #1 Reject from Matsuda Mitsuhiro (KKR)
   • Negative 1 to Document 7018 Line Item #1:  Negatives is not related with this ballot. This negative was not accepted by Task Force.
   • Negative 2 to Document 7018 Line Item #1:  Negatives is related but not persuasive. This negative was not accepted by Task Force.
3. Line Item #5 Reject No.1 from Mochizuki Tadashi (TEL)
   • After communication, voter withdrew the reject.

GEM 300 Task Force

In this task force we proposed two SNARFs, one for a line item revision to E40-1218, Specification For Processing Management, and another for E40.1-1218, Specification For SECS-II Protocol For Processing Management, and another for a line item revision to E94-0819R, Specification For Control Job Management and the E94.1-0819R, Specification For SECS-II Protocol For Control Job Management (CJM).
 
Some background information is useful here. In the semiconductor industry, the E90 Specification for Substrate Tracking, E40 and E94 are used together to monitor the substrate and job status in most 300mm frontend and advanced backend factories. Typically, after completing a job, it is the responsibility of the factory host to check the state of all materials to determine if the job has been successfully finished. However, some factories do not track E90 substrate events, and/or certain equipment types lack the capability to report such events. Additionally, some factories believe that the calculation of processed materials, failed materials and  unprocessed materials in a job should be performed on the equipment side, which then provides the final processed results. These factors make it challenging for the factory host to check the process status (processed, failed or unprocessed) of all materials in a job. As more straightforward data reporting requirements have accumulated from various factories, many equipment suppliers have developed their own means for delivering the processed substrate lists and counts. However, due to a lack of reference standards for these requirements and implementations, many variations exist in the data formats used to serve this single purpose.
 
These two SNARFs include revisions as follows to cover the above requirements and gaps:
1. Add new definitions for the Processed, Failed and Unprocessed state of materials.
2. Add a state matrix to better explain the E90 substrate processing states
3. Add new material processing result-related variables for job (process job and control job) events.
4. Add new object attributes for material processing result of job a (process job and control job) objects.
 

Note that these two SNARFs have undergone formal review, and ballots 7139 and 7140 were created as a result.

This blog provides a summary of the deliberations that took place during both task force meetings. For more information about these standards meetings, or questions about Cimetrix, please contact us by clicking the button below.

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.