Industry News, Trends and Technology, and Standards Updates

To start off our SECS/GEM series, let's begin with an explanation of one of the GEM standard’s key features called Collection Events. We'll start with an explanation as to how they work, then move to why they are so effective for collecting data from manufacturing equipment. 

What are collection events? 

The two words in the name “collection event” are descriptive. 

As denoted by the word “event” a collection event is a notification. Its purpose is to notify the host when something of interest happens at the equipment. The “host” is the factory client software that connects to the equipment’s GEM interface. For example, collection events can report when material arrived, a consumable is running low, a hardware problem occurred, a camera inspected the material, the material is ready to be removed, a chamber reached the target vacuum pressure, processing completion, etc. The equipment can use the collection event feature to report when anything of interest happens. Whoever makes the GEM interface determines exactly what collection events are available to the host; therefore the set of available collection events is different from equipment type to equipment type.

As denoted by the word “collection”, collection events are also capable of publishing data along with the collection event message. It is a very efficient form of data collection, asynchronously providing information as it becomes available. For example, a collection event that reports when material arrives might also report the arriving material’s barcode and location. There are three types of data in a GEM interface; information about the collection event (called data variables), status information (called status variables) and equipment settings (called equipment constants). Whoever makes the GEM interface determines exactly what information will be available for each collection event. So the set of available information for collection events is different from equipment type to equipment type. And the available data is only sent if the host sets up the reports. 

So in summary, a collection event can not only tell the host when something happens but it can also provide more detailed information about what happened and about the status of the equipment. 

A little analogy

As an analogy, think of the factory as a boss and the equipment they purchase as employees. There are many different styles of managing, just like there are different types of factories and styles for running a factory. You don’t want to be forced to run your factory just like someone else’s factory. You want to run it your way.

Additionally, each employee is unique and needs unique level of attention. And each employee is doing unique things. Generally speaking, all managers want to know basic information about employees and what their employees are doing. They want to know when the employee starts a project and when they finish a project. Some employees are very productive even with minimal oversight and reporting. Some employees need extensive oversight and reporting. GEM allow the factory to deal with each equipment uniquely. Specifically, GEM collection events give the equipment a way to report on what it is doing. 

The host has to set up the rules for the reporting and adapt the rules appropriately. For example, sometimes a manager does not care when the employee goes to the bathroom. For certain employees, the manager might want to know. In a GEM interface, the host can choose which notifications occur and which do not. 

Sometimes a manager just needs to be told when the employee does things like when employee arrives, departs, goes on break, and come off break.  Sometimes a manager needs more details, like what project did you finish, how long did it take, the key results of the project. Similarly, GEM allows the host to track not when things happen, but to also provide details about the activity. GEM reports meet this need very effectively. 

Why do you need this feature? 

The short answer is that collection events allow you to track what the equipment is doing in real time. If a factory wants to any degree of Smart Manufacturing or just wants to improve productivity, then one of the first things needed is the ability to track what the equipment is doing. Collection events provide this. You can track equipment utilization, material movement, processing milestones, count cycles of activity for predictive maintenance, consumable usage, and anything else related to the published collection events. The applications for such information are endless.

Sometimes collection events are also used to implement scenarios where the equipment needs information from the host before proceeding or permission to proceed. A collection event tells the host when the equipment is ready for the host instructions or permission.

How does the collection event notification work?

An equipment’s GEM interface can publish many different collection events. The host will not typically want to be notified of all of them at once and it does not have to. Collection events use a publish/subscribe design pattern in two ways.

Basic Publish/Subscribe Notification

The host subscribes to specific collection events to receive notification when they occur. The subscription allows a host to enable or disable the reporting of each collection event available in the GEM interface. The equipment publishes the collection events as they happen.

Event Report Publish/Subscribe Data Collection

By default, a collection event message will not include any data. A subscription also allows the host to decide what data to include in each enabled collection event’s message. The host defines reports and links the reports to collection events; thereby subscribing to the data. Each collection event can have a different report. Reports can also be shared across multiple collection events. A report can include any data variables associated with the collection event, any status variables and any equipment constants. The equipment publishes the collection event with the requested data.

Identification

Each collection event published by the equipment has a unique ID number for identification. The host software uses the ID number when enabling or disabling a collection event. The equipment uses the ID number when the collection event message is sent. Each available data variable, status variable and equipment constant also has a unique ID number. When the host defines a report, it assigned the report a unique ID number.

Broker

The broker to handle all collection event publication/subscription is built into the equipment’s GEM interface. It is part of the equipment system. Communication between the host (a client) and GEM interface is standardized using SECS/GEM communication. Communication between the GEM interface and the rest of the equipment hardware and software (the source of the equipment collection events and data) can be any appropriate technology and does not matter as long as the GEM interface functions properly and performs sufficiently well.

This means that messages are only sent from the equipment to the host when the host has subscribed. Having the broker as part of the equipment and GEM interface makes the GEM interface very efficient and use much less bandwidth than protocols that use an external broker where all messages and data have to be sent to a broker all the time.

Persistence

The collection event subscriptions are persisted in a GEM interface. So if the host disconnects and reconnects, or if the equipment is restarted, the GEM interface will remember the setup of all subscriptions.

Which messages are used?

Here is a summary of each of the primary messages related to collection events. Note that the “S” identifies the “stream” and “F” identifies the “function”. Together, a stream and function number uniquely identify a message. 

Frequently Asked Questions about Collection Events

How much bandwidth do collection events require?

This depends on several factors. 

1. The number of collection events that are enabled by the host. 
2. The size of the data reports linked to the collection events. 
3. The frequency at which the enabled collection events are triggered by the equipment. This depends on the meaning of the collection event. 

How fast can collection events be triggered?

The GEM standard does not limit collection event frequency and uses standard communication hardware. In other words, by improving the hardware you can allow for faster collection events.

GEM allows for two protocols: SECS-I and HSMS. SECS-I is based on RS-232 serial communication and therefore little used today. Such implementations are not able to trigger collection events very quickly.

HSMS is based on network communication. Because serial communication is slow, by far most GEM implementations use HSMS. GEM uses TCP/IP very efficiently. The possible frequency of collection events depends on the speed of the network hardware, equipment computer performance, and host computer performance. Like most protocols, it usually takes more computer resources to consume messages than it does to produce them.

The speed at which collection events can be generated also depends on the data reports linked to the collection events. For example, if a data report is large, like 10 MB, this will impact performance.

Why aren’t I receiving the collection event messages? 

There are a few reasons why a host might not receive collection event messages. 

1. Host and equipment must have established GEM communication using a successful S1F13/S1F14 exchange.
2. GEM control state must be on-line. It cannot be in a host-offline or equipment-offline state. 
3. GEM spooling must be inactive. To disable spooling while it is active will not make spooling go inactive. If the spooled messages are not wanted, then purge spooling using message S6F23. If the spooled messages are wanted, then request them iteratively using S6F23 until the spooling state becomes inactive.
4. The collection event must be enabled. Use S1F3 to check the “EventsEnabled” status variable to confirm that the collection event is enabled. Use message S2F37 to enable the collection event. 
5. The collection event activity needs to occur. For example, a collection event reporting when material arrives will never occur if material does not actually arrive. If the activity happens and the above conditions are satisfied, then the equipment’s GEM interface has a defect. 

What if an equipment’s GEM interface does not publish the collection event I need?

Ask the equipment supplier to add the desired collection event. It is difficult for an equipment supplier to accurately predict all collection events that the factories will want. The equipment supplier will need to upgrade their GEM interface software at the factory.

How large of data reports can be when linked to a collection event?

GEM allows a single data variable value or status variable value to be an array or structure of any data type including a floating point, string or integer. A single array is limited to 16.777215 MB. Total message size is limited to 4.294967295 GB.

To download a white paper on an introduction to SECS/GEM, Click below:

After the Taiwan Printed Circuit Board Association (TPCA) chose the Generic Model for Communication and Control of Manufacturing Equipment (GEM) standard for equipment connectivity, they asked Cimetrix to present at a TCPA technical conference explaining some of the most important features and benefits of GEM.  After Brian Rubow (Cimetrix Director of Client Training and Support) presented they asked him to write a summarizing article which was published by TPCA during the October 2017 TPCA show. Today, we are re-publishing the article as we launch an extensive features/benefits blog series coming up in 2018. 

SECS/GEM refers to a set of SEMI standards that govern the communication between manufacturing equipment and factory host computer systems. The Message layer standard, SEMI E5 SECS-II, defines a generic message structure and a library consisting of many standardized messages. The Protocol layer standard, SEMI E37 High-Speed Message Service (HSMS), defines a binary structure to transfer SECS-II messages using TCP/IP. SEMI E30 GEM, defines a minimum set of requirements, additional (optional) capabilities, use cases and user scenarios for a subset of SECS-II messages. 

SECS/GEM is implemented on an equipment, and is used by the factory to implement command and control functions. Since it is an industry standard, any SECS/GEM-compliant host software can communicate with any SECS/GEM-compliant equipment. When fully implemented on the equipment, the standards enable factory software to completely control and monitor the equipment by means of its SECS/GEM interface. These standards provide numerous benefits to both equipment manufacturers and factories. Several of these benefits are highlighted in this article.

SECS/GEM Reduces Equipment Integration Costs

Factories are typically owned and operated by multinational enterprises which purchase equipment from a variety of equipment manufacturers. Even though the control software is different on every equipment, the factory is required to integrate the equipment to operate in harmony. While it is possible to independently integrate each equipment with custom software, this is not cost or time effective. 

The situation is similar for equipment manufacturers, who sell their products to diverse factories across the globe. Data collection and application software at every factory are different. The equipment manufacturer is required to help the factory integrate the purchased equipment. While it is possible to develop a custom integration solution for each factory, this is again not cost effective. Every time a factory asks for custom integration features, these costs get passed on to the factory itself.

Custom software, whether developed by the equipment manufacturer or the factory, is expensive to create and maintain, and tends to be of lower quality than desired. By contrast, the SECS/GEM standards define how to create a standardized interface on any manufacturing equipment. Equipment manufacturers benefit by developing one interface for all of their customers. Factories benefit by reusing the same integration software for all of their purchased equipment. Reuse of this software and technology both by the factory and equipment manufacturer raises the software quality, reduces costs and allows for more functionality. The equipment manufacturer and factory alike can invest not only in the minimum features required, they can also implement advanced functionality that is otherwise unaffordable. If they only have to support SECS/GEM, then equipment manufacturers can publish more data and support more advanced control. In turn, factories can then use the additional data to improve product quality and productivity. 

SECS/GEM Is Applicable to All Manufacturing Equipment 

Because SECS/GEM is divided into Fundamental Requirements and Additional Capabilities, it can be implemented on any manufacturing equipment, regardless of size and complexity. Additional Capabilities are optional because they are not always needed. For example, some equipment do not have recipes and therefore do not need to implement the Recipe Management Additional Capability. 

SECS/GEM also scales well with the magnitude of an equipment’s data. For example, a very simple equipment or device might publish 10 different collection events, whereas a complex equipment might publish 5000 different collection events; yet both can use the same SECS/GEM technology. 

Innumerable Applications Can Be Supported Using a SECS/GEM Interface

Everything that happens on an equipment can be tracked. Any remote control features and system configuration can be supported. The more data that is published by an equipment, the more software applications a factory can implement. A SECS/GEM interface makes it possible to implement applications for statistical process control, troubleshooting, predictive maintenance, feedforward/feedback process control, equipment utilization, material tracking, recipe validation and many more. Such applications often reduce the need for an operator interface on the equipment, thereby reducing the number of operators in the factory. Recipe management allows factories to minimize scrap. For example, use the SECS/GEM interface to store golden recipes in a central location and also to ensure that the correct recipe is used on the material. 

SECS/GEM Uses Network Bandwidth Very Efficiently

There are several features that make SECS/GEM naturally efficient. First of all, every SECS/GEM interface acts as a message broker. Because the broker runs on the equipment, unsubscribed data is not published on the network. For host software to receive alarm, collection event, or trace data messages, it must first subscribe. Since subscriptions for each alarm, collection event, and trace data are managed separately, the equipment can implement a single SECS/GEM interface that publishes all alarms, collection events and trace data requested by all factory applications without wasting network bandwidth with unnecessary data. Moreover, when the host subscribes for trace data, it specifies the data collection rate, making SECS/GEM much more efficient and useful than protocols that publish data at a hard-coded rate. 

Additionally, all SECS/GEM messages are always transmitted in an efficient binary format. This uses much less bandwidth than protocols that transmit in ASCII format. Despite using a binary format, SECS/GEM messages are also easily converted to and from a standardized XML notation. 

SECS/GEM Enjoys Enormous Industry Support 

SECS/GEM has been the backbone of factory/equipment communication and control systems for years in the semiconductor industry. This means that all semiconductor manufacturing today completely relies on SECS/GEM communication. 300mm semiconductor factories have been running with full automation based on SECS/GEM communication since the late 90s—large companies like TSMC, Samsung, Micron, Intel, Toshiba and many others utilize SECS/GEM 24/7 in every factory. Other industries like Flat Panel Display, High-Brightness LED and Photovoltaic have also officially adopted SECS/GEM because they recognized how SECS/GEM features can be applied to any manufacturing equipment to support mission-critical applications.

SECS/GEM Is Self-Describing

Although the standard requires GEM documentation to be provided with the equipment, SECS/GEM supports multiple approaches for host software to automatically adapt to an equipment’s SECS/GEM interface. There are messages for the host software to ask for the list of available alarms, status variables, equipment constants, and, for newer implementations, a list of available collection events and data variables. These messages make SECS/GEM plug-and-play. Additionally, the equipment manufacturer can provide a standardized XML file that provides a full description of the SECS/GEM interface and its features. 

Summary

These are just some of the many benefits of using SECS/GEM technology, both for factories and equipment manufacturers. SECS/GEM is proven technology that is available today. 

The SEMI North American Information & Control Committee meetings were held in Milpitas, CA at SEMI headquarters. The following activities might be important for Cimetrix customers and employees.

By far, the longest discussion was surrounding the biggest decision of all. Currently, the EDA standards are using HTTP/1.1 for message transfer and SOAP/XML for message body. This means that the EDA standards are text based. At the time of EDA development, this seemed to be the best internet technology for data collection. Today, HTTP/1.1 is out of date. More recently, advances have been made in internet technology for sharing data in a binary format. The biggest advantage of transferring data in a binary message format is message efficiency. A binary message generally will be about 15 to 20 times smaller than text based messaging. This means less load on the equipment that publishes EDA data, much less load on the network and less load on the subscribing EDA clients. Many alternatives were discussed including WebSockets, HTTP/2, and even HSMS. It was discussed whether to stick with a text based protocol and use compression or move to a binary protocol. Data was presented from a DDA Task Force member regarding a performance comparison between HTTP/1.1 with text messages (like EDA today), HTTP with binary messages, HTTP/2 with SSL, WebSockets with binary messages and WebSockets with SSL. The test results showed binary messaging to be allow 25 times more data collection than the current HTTP/1.1 technology. Ultimately, it was decided that moving to a binary protocol was the right strategic direction.

Another point of discussion was how to implement binary messaging. Google has developed the Protocol Buffer technology. Specifically, we looked at version 3 called “proto3” which defines a notation for establishing binary messages. They have also published open source code gRPC in various software programming languages that implement the binary encoding and decoding for the Protocol Buffer technology and HTTP/2. This seems to be today’s best technology for binary web services. The DDA Task Force is in the process of developing a ballot to propose the adoption of this technology for the EDA messages. If approved, this would be the foundation of freeze 3 communication and a vast improvement.

In Japan, the Information & Control Committee recently created a DDA task force. The leader, Mitch Sakamoto from company ZAMA is coordinating with the North American DDA task force. Similarly, the DDA task force leaders in Korea are also working closely with North America. The Freeze 3 EDA development really is emerging as a worldwide coordinated development. The world-wide cooperation and coordination is much stronger and cohesive than the development was for Freeze 1 and Freeze 2.

The GEM 300 task force passed a ballot approving the use of SECS Message Notation (SMN) for GEM implementations. SMN could already be used anyway, but adding this to the GEM standard makes its use more official. This means that messages can be logged and documented using SMN.

The GUI task force continues to move along with planned improvements for the E95 standard. This including modernizing the graphics in the standard, updating the text and most importantly having the standard include the adoption of small screen devices as an equipment HMI. The new E95 standard will be a major revision standard.

In Korea, several ballots continue to be developed and reworked. This includes an update to the E87 carrier management services standard to allow more precise reporting when carrier approach the completion state. This includes an update to the E142 wafer map handling standard with new features in the schema file. Additionally, they are working on an equipment generic counter standard, which establish standardized methods for equipment to “count” things that happen on the equipment. This proposed specification is a favorite of mine personally. It is a clever way to recognize that it is important to count things on every equipment such as the number of times a vacuum has a been cycled, the number of times a nozzle has been used, the number of times a user has logged in, the number of times a robot has moved a substrate, the number of times an equipment has been restarted. It could be anything and it could be very different on two types of equipment. Collecting such data in a generic, natural way facilitates predictive maintenance; a key to minimizing factory equipment downtime.

SEMI held the spring 2017 North American standards meetings during the week of April 3 at the new SEMI facility in Milpitas, CA. The new facility had only been occupied for a few weeks prior, yet SEMI was able to hold the meetings with few technical difficulties. The new facility is quite attractive with improved accommodations for standards meetings.

There is a lot of activity currently, in the two task forces that I lead; namely the GEM 300 task force and DDA task force.

Every five years SEMI re-approves every active standard. Without renewal, the standards become “inactive”. During the Information & Control Committee (I&CC) meeting a few standards were re-approved this cycle with a few editorial changes including:

• Ballot 6066A: E130 (Specification for Prober Specific Equipment Model for 300 mm Environment) and E130.1 (Specification for SECS-II Protocol for Prober Specific Equipment Model for 300 mm Environment) 
• Ballot 6068A: E116 (Specification for Equipment Performance Tracking) and E116.1 (Specification for SECS-II Protocol for Equipment Performance Tracking)
• Ballot 6064A: E121 (Guide for Style and Usage of XML for Semiconductor Manufacturing Applications)

Additionally, during the Information & Control Committee (I&CC) meeting, the following ballots were passed which make changes to standard:

• Ballot 5549A: E30 (Generic Model for Communications and Control of Manufacturing Equipment) with the following changes to the GEM standard
  • The title was changed to “Specification for the Generic Model for Communications and Control of Manufacturing Equipment”
  • The initial sections were reorganized to have sections Purpose, Scope, and Limitations which results in renumbering all following sections
  • The Application Notes were renamed Related Information
  • Equipment Constant “EnableSpooling” was added to the Variable Item List.
• Ballot 5738: E87.1 (Specification for SECS-II Protocol for Carrier Management)
  • Title was changed to remove the provisional status. All other references to provisional status were removed.
  • Numerous editorial changes were made for clarity, misspellings, incorrect references
  • Format codes were clarified for consistency
  • The only “technical” change was to allow for up to 255 slots in a carrier for attribute “Capacity”. This makes E87.1 more consistent with E87 which does not restrict carrier capacity and with known existing implementations that have more than 25 slots in a carrier. 

Ballot 5872B, an update to the E172 Specification for SECS Equipment Data Dictionary (SEDD), failed to pass. This update adds numerous optional features to the SEDD file for documenting GEM interfaces in an XML file. With this update, GEM interfaces can be documented almost entirely in an XML file; virtually eliminating the need for the traditional GEM documentation. The most valuable addition is the list of supported SECS-II messages and the expected format for each message. By documenting GEM interfaces in an XML file, factories can write software to parse the SEDD file and automatically configure host software to adapt to an equipment’s GEM implementation. The GEM 300 task force expects this ballot to pass later this year after making a few small changes.

In the next SEMI voting cycle for North America, called “Cycle 5”, the GEM 300 task force plans to resubmit ballot 5872C to update the E172 SEDD.

Additionally, a new ballot 6114 will be submitted for vote. Ballot 6114 introduces a new set of SECS-II messages for transfer of large strings or binary data. The new messages are initially intended for transfer of large Recipe files to/from the host system. Currently, the typical stream 7 SECS-II messages are limited to 16.7 MB. With these new messages, recipes could theoretically be allowed up to about 4 GB. Additionally, the new messages could be used to transfer other types of large strings or binary streams. The new messages include a “type” field to indicate the type of object being transferred. For recipes, field will most likely be “SEMI:RECIPE”, but other types could be defined in other standards like “ProductionRecipe” for E170 or “SEDD” for E172.

In the DDA Task Force, more plans were discussed for the EDA Freeze 3. The Korea DDA Task Force leaders have committed to working with North America DDA Task Force in this effort and presented several ideas for changes. The most dramatic change they presented was to consider using WebSocket technology instead of HTTP in order to make the SOAP/XML messages perform much better by maintaining a socket connection.

The GUI task force has begun its work to revise the E95 standard. It is still a great time for new task force members to join and contribute.

The Japan GEM 300 task force have previously made some announcements concerning a GEM300A initiative to expand the traditional GEM 300 standards (E30, E37, E39, E40, E87, E90, E94) to also include newer standards developed in the Japan GEM 300 task force. Namely E170, E171 and E174. E174 has been very controversial. During the North American GEM 300 task force meeting, it was requested that if there be any initiatives to declare a GEM300A set, that this be a collaborative effort between the various GEM 300 task forces and also consider including E116, E148, E157, E172 and E173.

During the GEM 300 task force, a representative from the Japan GEM 300 task force presented some possible future ideas to have a separate GEM connection for recipe management, to ensure that data collection reporting is not hindered by the transfer of large recipes files.

 SEMI North America Information & Control Task Force and Committee fall meetings were last held at SEMI headquarters November 7 through 9, 2016. During these meetings, SEMI announced that they are relocating their headquarters to Milpitas, CA. That move is currently underway. In the GEM 300 task force, all of the ballots failed to pass. This include ballot 5872A, 5549, 6026, 6066, and 6068. In the DDA task force, ballot 6064 also failed.

Ballot 5872A is work driven by Cimetrix to complete to work initially proposed for the E172 standard SEDD files, a feature to enable an electronic format for GEM documentation. Ballot 5872A failed due to some minor issues. SEDD files already provide partial GEM interface documentation in an XML file by listing the data variables, status variables, equipment constants, collection events and alarms. The ballot proposes to enhance SEDD files by adding a list of supported SECS-II messages, remote commands, SEMI standards (with compliance tables), and default event reports. The ballot will be reworked and resubmitted as ballot 5872B.

 Ballot 5549A is a title change and organizational change to the GEM E30 standard. Several years ago, SEMI required all standards to have an official designation, such as Guide or Specification. E30 currently has a title that fails to establish an official standard designation. Additionally, the standard currently fails to have the mandatory sections “Purpose”, “Scope”, “Limitations” like other standards. The ballot was delayed several years due to the SML copyright claim by Peer Group and the ensuing legal confrontation with SEMI. The ballot was finally submitted in 2016 and failed because it renamed the Application Notes as an Appendix instead of “Related Information”. Additionally, there was some confusion because the ballot was based on the 0611 version of E30 rather than the 0416 version which had just been published. This ballot will be reworked and resubmitted as ballot 5549B.

 Ballots 6026, 6066, 6068 and 6024 are reapproval ballots for standards E109, E130/E130.1, E116/E116.1 and E121. SEMI automatically submits all standards for re-approval every five years if a standard has not been revised. These standards all failed due to outdated references. They will all be resubmitted in 2017 with minor changes to correct the outdated references.

 The new GUI task force was approved to create a new major revision of the E95 standard. In particular, the new revision will accommodate new software and hardware technology when laying out equipment user interfaces.

 Cimetrix proposed a new activity to define new SECS-II messages for transferring recipes. The activity will result in a new ballot 6614. Currently, the GEM standard defines two ways to transfer unformatted recipes. Using simple Stream 7 messages S7F3 and S7F6, the entire recipe is part of a single message. This makes is really easy to implement in the host and equipment GEM software, but recipes are limited to about 16.7 MB (the maximum size of a single data item in any SECS-II message). The second way is using the large recipe scenarios which involve using a sequence of messages S7F43/F44, S13F1/S13F2, S13F3/F4, S13F5/F6 (repeated iteratively until there is an error), S6F11/F12 and finally S13F7/F8. Even for an expert, this is very complicated. Ballot 6614 will propose simple new messages for transferring a large recipe using a single message where the recipe can be broken up into multiple parts where each part is up to 16.7 MB in size. If approved, another ballot will attempt to add this to GEM standard. This will open the door for the GEM standard to be used more effectively and in more application where the 16.7 MB limitation posed an issue.

 Japan Information & Control committee (I&CC) announced the official withdrawal of OBEM standards E98 and E98.1. Japan also announced a GEM300A initiative which includes standards E170 and E171 and E174. E170 is the Production Recipe Standard which allows equipment to designate production and non-production recipes; where production recipes are given change protection. E171 defines predictive carrier logistics. Ballot 5601 defines Wafer Job Management. It is not clear whether or not there any IC makers will demand any of these newer standards. Of the three, E170 seems to be most useful and interesting. Predictive carrier logistics seems to be useful only for equipment that have carrier internal buffers. It attempts to help the equipment report when carriers will be ready for removal. It is not clear how E171 will compete with the upcoming E87 ballot 4946 to be submitted by the Korean Information & Control Committee in 2017. Ballot 4946 modified the E87 standard to predict when carriers will be ready to unload. Wafer Job Management is a controversial standard. Japan I&CC announced the passing of ballot 5601 (now E174) despite the strong opposition by multiple knowledgeable voters in other regions, and despite very underwhelming support from regional leaders in North America, Korea, Europe and Taiwan.

 Korean Information & Control committee announced plans to submit ballot 5832, a proposal for a new Generic Counter standard which is built upon the GEM standard. The standard would allow an equipment to define various types of generic “counters” that can be reset by the host. The counters could be used a wide variety of applications; particularly predictive maintenance. The standard as defined in the current ballot defines digital counters, analog counters and collection event counters. Voting period for this ballot just ended recently.

 Next North American I&CC meetings will be held first week in April, 2017.

Interest in SEMI standard E30, known as the GEM standard has grown in recent years. That interest has increased in various manufacturing industries has matured in which factories are seeking to increase automation and carefully monitor equipment activity in order to increase production and product quality. Initially, the GEM standard targeted just the semiconductor industry, but then expanded to include any industry that used manufacturing equipment. In fact, a number of years ago the name of the GEM Standard changed from the “Generic Model for Communication and Control of Semiconductor Equipment” to “Generic Model for Communication and Control of Manufacturing Equipment.” Adoption by other industries is possible because the GEM standard defines generic features to control and monitor any manufacturing equipment. The GEM standard technology is not limited to semiconductor manufacturing. Over time, other industries have taken notice, especially as they try to develop increased control over their equipment.

CIMConnect™ is the best software product on the market for implementing the GEM standard. Of course CIMConnect supports all of the required GEM features as well as additional capabilities. This even includes excellent support of the Spooling feature, which saves messages that are otherwise dropped during a loss of communication. Early implementations of the GEM standard by others gave the GEM standard’s Spooling feature a bad reputation. This reputation is undeserved when Spooling is implemented by a robust product like CIMConnect. In CIMConnect, not only does Spooling work; it works well. It has been proven by customers that CIMConnect’s Spooling implementation does not lose any messages—even while under high-stress conditions. This means that when using CIMConnect, the Spooling feature can be used to effectively preserve critical data from the equipment.

Another feature that makes CIMConnect the best GEM software product is the CIMConnect Control Panel. In the new CIMConnect release, this application was completely rewritten, redesigned in .NET,  giving it a modern look and feel while adding lots of new convenient functionality. With other GEM products, the GEM interface is essentially a black box. With CIMConnect, however, the Control Panel application gives full visibility into the GEM interface. And you can run it at any time during GEM interface development and also during production. This means that you can see what reports and traces are defined, the link between reports and events, the status of all state machines, the state of each alarm, the enable status of every event, the history of occurring collection events, the history of alarm state changes and the current values of all data variables, and status variables and equipment constants. You can also view and capture the SECS-II message logging at any time for scenario diagnostics. Additionally, the CIMConnect Control Panel provides features to simulate the occurrence of collection events, collection event data, alarms, and variable data; thereby making it a built-in simulator included requiring no additional effort. And when you are ready to update your GEM documentation appendix with the list of defined collection events, alarms, status variables, data variables, and equipment constants, use the documentation builder feature.

CIMConnect has also already adopted use of new SEMI standard E173 Specification for XML SECS-II Message Notation (SMN). CIMConnect allows software applications to use SMN notation both when providing variable values to CIMConnect, as well as when getting variable values from CIMConnect. This means that you can pass data around in XML, retaining the data type and data structure information; bringing the convenience of XML into the SECS/GEM technology. You can log the GEM communication messages using SMN format making log messages much more useful, and they are able to be easily deserialized by any software applications that has XML libraries.

For additional detailed information about CIMConnect or to request a product demonstration, please contact us.♦

During the week of SEMICON West in San Francisco this past July, the North American Information & Control Committee met to discuss and consider new and pending standards within the industry. SEMATECH was noticeably absent from the sessions. For many years, SEMATECH has been a leader in developing and promoting the GEM 300 and EDA standards.

Here are the highlights from those meetings and how they will effect you.

The DDA Task Force is in the early stages of planning a Freeze 3 version of the EDA (Interface A) standards. This may cause some concern—especially with OEMs—as some are just now getting their Freeze 1 interfaces accepted in Fabs. Freeze 2 was a big step forward in making the standards clearer and easier to adopt, but it required a lot of work to move from Freeze 1 to Freeze 2. The hope is that the transition from Freeze 2 to Freeze 3 will be easier, but there will be doubt and concern among many OEMs.

One of the changes proposed for Freeze 3 is replacing the usage of SSL (HTTP) with WS-Security, an extension to SOAP and a member of the web services specifications published by OASIS. This extension allows for secure data within a SOAP message, while still using HTTP for data transfer. This is really an underlying issue and should not affect the applications that would interface with our CIMPortal Plus product. It would allow for a secure connection between CIMPortal and the Fab client so that the data transmitted is protected from theft. There would be configuration changes required to allow the secure connection to be defined, but—once it is—the actual interaction between the OEM’s application and CIMPortal Plus should not change.

Another change being considered is the implementation of WS-ReliableMessaging, another extension to SOAP and also a member of the web services specifications published by OASIS. WS-ReliableMessaging describes a protocol that allows SOAP messages to be reliably delivered between distributed applications in the presence of software component, system, or network failures. Just as the WS-Security item above, this would be at the protocol level, an “under-the-hood” change. It should not affect the way applications interact with our product, but should provide for a more reliable connection to the host EDA client. Use of this extension could also allow EDA to be used in more factory applications, where guaranteed data acquisition is required.

The final issue that was discussed relating to Freeze 3 was a new high-frequency trace for collecting data at very high speeds triggered for short periods of time where the collected data is sent at the end of the collection period. For example, a 1 ms trace for 5 seconds where the 5,000 collected samples for each parameter would be sent at the end of the 5 second period. This change might require alterations in our products. This will help the data reporting be more efficient. Rather than reporting small individual pieces of data to the EDA client, this will allow many data samples to be sent together making for more efficient use of the network.

The GEM 300 Task Force had three ballots on hold due to the ongoing SML copyright legal trial between SEMI and The PEER Group. However, work on other pending ballots continued. The first, Ballot 5872, proposes to add new features to the E172 SEDD standard. E172 is a new standard that provides an XML schema for documenting a GEM/GEM 300 interface. Eventually, E172 can completely replace the current GEM documentation requirements.

Recipe Integrity ballot 5618 has an uncertain future since ISMI failed to pursue its development; unfortunately, the ballot had seemed very close to completion. This standard says that it will not require changes to SECS II messages, but simply clarifies what parameters are defined and how the existing pieces work together. So, essentially, it would be a standard that tells you how to use other existing standards.

Finally, the Task Force discussed enhancing the GEM 300 standards to handle equipment that bond substrates and divide substrates. This will affect E90 and could affect E40, E87, and E94 as well. These changes would likely require updates to CIM300. Right now the standards just address how to treat equipment where the same material (substrates or wafers) go in and out. Traditional material tracking assumes one wafer in, get processed, then return to an output carrier. In the proposed case, either two wafers go in and one unit comes out, or one substrate goes in and two come out

The committee is scheduled to next meet in November, so you can plan on seeing another post from me on the outcome of those meetings afterwards. Subscribe to our blog in the upper right corner of this page to be sure not to miss that or any of my future updates on the North American Information & Control Committee.