Industry News, Trends and Technology, and Standards Updates

What do the factories DO with all that data?

Unlike the other postings in this series which deal with specific features and capabilities of the SEMI E30 GEM (Generic Equipment Model) standard, this blog identifies a number of the factory applications that depend on collecting data from the equipment.

Moreover, since we often hear the question “How do the factories actually use the different types of equipment information we’re expected to provide?” this posting will summarize the specific data required to support a number of these applications. This list is by no means exhaustive, but should give you an idea of the range of factory stakeholders whose objectives are supported by GEM data collection.The figure below illustrates the relationship between the Key Performance Indicators (KPIs), the factory stakeholders responsible for optimizing them, the applications used to achieve this, and data required by these applications.

The most effective way to share this kind of information is in tabular form. Within a group of related applications (e.g., scheduling, preventive maintenance), the applications are listed in generally increasing order of complexity, which is also the likely order of implementation by the factory applications development staff.

To the extent that some of the application data described in the table above can be standardized across equipment types, there is an opportunity to create generic factory applications that would only require a mapping from the supplier-specific GEM IDs (collection event IDs, status/data variables, equipment constants, etc.) to their generic counterparts. But this is a topic for another posting on the concepts of “plug-and-play” in a GEM context.

We hope this explanation helps you appreciate how valuable equipment information is for the factories that consume it, and therefore how important it is to provide a rich set of events, variables, and other detailed information in the GEM interfaces you design in the future. 

Click here to read the other articles in our SECS/GEM Features and Benefits series. 

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

GEM is an industry standard, which defines standard methods to communicate between process equipment and factory host software for monitoring and controlling purposes. By connecting GEM equipment, factories can immediately experience operational benefits. Factory hosts can collect data in multiple ways. A previous blog post discussed collecting data by using collection event reports where data is pushed to the host based state transitions performed by the equipment. In addition to event reports, the factory host often has a need to poll the equipment for current data values. Data values can be directly requested by the host, or can be sampled on a periodic basis in a trace report. This is called Data Polling and is the topic for today's discussion.

Types of Data

There are three types of data in a GEM interface:

• Data Variable (DV) – data items that can be gathered when an equipment event occurs. This data is only guaranteed to be valid in the context of the event. For example, the GEM interface may provide an event called PPChanged (triggered when a recipe changes). The interface may also provide a data variable called changed recipe. The value of this DV is only valid in the context of the PPChanged event. Polling the value at a different time may have invalid or unexpected data.
• Status Variable (SV) – data items that contain information about the equipment. This data is guaranteed to be valid at any time. For example, the equipment may have a temperature sensor in a process module. The GEM interface may provide a ModuleTemperature status variable. The host can request the value of this SV at any time and expect the value to be accurate.
• Equipment Constant (EC) – data items that contain equipment settings. Equipment Constants determine how equipment will behave. For example, a GEM interface may have an equipment constant called MaxSimultaneousTraces which specifies the maximum number of traces that can be requested simultaneously from the host. The value of equipment constants is always guaranteed to be valid and up to date.

Data Properties

Each of the three data types listed above have similar properties that help define the data. The equipment supplier is responsible for providing these properties in a GEM manual so that the factory host will be able to interact with the data. Some of the important data properties are:

• ID – a numeric ID that must be unique in the GEM interface. These IDs can be grouped by data type and are referred to as SVIDs (Status Variable IDs), DVIDs (Data Variable IDs) and ECIDs (Collection Event IDs).
• Name – a human-readable name for the data item
• Format – the data type of the item. 
  • Data formats can be simple (numeric, ASCII, Boolean) or complex (arrays, lists, structures). For example, numeric types can be I1, I2, I4, I8 (signed integer types of different byte length), U1, U2, U4, U8 (unsigned integer types) and F4 or F8 (floating point types). 
  • List and array types contain multiple values in the data item. For example, image data would be formatted as a byte array. 
  • Structure types contain a specific type of data. For example, a variable may represent a slot map which contains carrier information as well as a list of slots and their wafer placement status.
    
• Value – the actual value of the data item. Data values are in an accurate, efficient, self-describing binary format so that the host will know how to interpret the data. The data format allows for collection of more data more efficiently.

Collection Events (CE) and Alarms also have IDs and names. These items are discussed in other blog posts, but it is important to know about some of the properties for this post because these properties can be queried as well.

Data Polling

As mentioned, the factory host will often get data on a regular basis through trace reports and event reports that it defines. GEM also provides a method for the factory host to poll data based on its needs.

Status Variables

The host can query the value of status variables at any time by sending an S1F3 message containing a list of SVIDs for which to obtain the value. If the list has a length of one, only the value of the single SV will be returned. If the list has a length of zero, the values of all SVs defined in the interface will be returned. The values are returned in a list in an S1F4 message from the equipment.

The host can also request a list of SV names from the equipment by sending an S1F11 message to the equipment. The list rules mentioned above apply to this message as well. The return message will contain an entry for each SV that displays its SVID, Name and Unit.

Equipment Constants

Similar to the way SVs work, the host can also query the values of equipment constants defined in the GEM interface by sending an S2F13 message. The values will be returned from the equipment using an S2F14 message.

Also similar to SVs, the names of ECs can be queried using an S2F29 message.

Data Variables

Since data variables are only valid in the context of a collection event, there is not a method for polling values of data variables. The value of a Data Variable can only be reported in a collection event report.

Other

In addition to the methods for polling data discussed above, the following items can also be obtained from a GEM host by polling the equipment:

• Collection Events (CE) – The host can query what Collection Events are available on the GEM interface along with what DVs are associated with each CE. These are requested using the S1F23 message.
• Alarms – The host can query what Alarms are available on the system by sending an S5F5 message listing the ALIDs of the desired alarms. The return message lists the alarm code and alarm text associated with the ALID. Two status variables are required to be present in every GEM interface. AlarmsEnabled contains a list of IDs of all enabled alarms on the equipment. AlarmsSet contains the list of ID for alarms on the equipment that are currently in the Set state. Since these values are status variables, they can be queried at any time.
• MDLN and SOFTREV – The response to an S1F1 (Are you there?) message will contain the equipment model type (MDLN) and software revision (SOFTREV) for the equipment.
• DateTime – The date and time for the equipment can be requested using an S2F17 message. The host can synchronize the equipment’s time using the S2F31 message. GEM requires the equipment to maintain a Clock SV containing the current time. Allowing the host to query and synchronize time provides the capability to order nearly simultaneous events on the system.

Trace Data Collection

Trace data collection provides a method of sampling data on a periodic basis. The time-based approach to data collection is useful in tracking trends or repeated applications within a time window, or monitoring of continuous data.

When creating a trace definition, the host provides the following:

• Sample period – the time between samples. The resolution is in centiseconds, so it is possible to gather data very quickly using a trace. It is common for equipment so support as fast as a 10 Hz trace interval.
• Group size – number of samples included in a trace report
• SVIDs – List of status data to be included in the trace
• Total samples – number of samples to be taken over the life of the trace
• Trace request id – identifier of the trace request (GEM only allows trace IDs of type integer)

The host defines a trace request by using the S2F23 message. Trace reports are sent from the equipment to the host using the S6F1 message.

Trace Sample

Let’s suppose that a piece of equipment is processing a wafer and the processing takes 5 minutes. It is important to keep the chuck temperature within a certain acceptable range and to make sure that the chamber pressure stays below a specified level. It is sufficient to monitor the values at 15 second intervals, but we can create groups of data to only receive reports once a minute. The host could send an S2F23 message with the following trace configuration:

Trace ID: 100 (ID must be an integer)
Sample Period: 00001500 (take a sample every 15 seconds)
Total Samples: 75 (Samples every 15 seconds for 5 minutes)
Group Size: 4
SVID List:
   300 (ID of the status variable that contains information about chuck temperature)
   301 (ID of the status variable that contains information about chamber pressure)

After one minute, the first trace report will be delivered using an S6F1 message from the equipment. The message will contain the following information:

100 (Trace ID)
4 (last sample number)
2018-01-22T14:20:34.8 (date format depending on TimeFormat equipment constant)
Status Value List: (Length is 8: 2 SVs with a group size of 4)
   219.96 (chuck temperature for first sample)
    0.0112 (pressure for first sample)
   219.97 (chuck temperature for second sample)
   0.0122 (pressure for second sample)
   219.97 (chuck temperature for third sample)
   0.0120 (pressure for third sample)
   219.96 (chuck temperature for fourth sample)
   0.0119 (pressure for fourth sample)

After another minute the trace report may look like the following:

100 (Trace ID)
8 (last sample number)
2018-01-22T14:21:34.8 (date time shows one minute later than the first trace)
Status Value List: (Length is 8: 2 SVs with a group size of 4)
   219.96 (chuck temperature for fifth sample)
   0.0112 (pressure for fifth sample)
   219.97
   0.0122
   220.01
   0.0120
   220.00
   0.0119

Three more reports will be received at one-minute intervals. The host can check returned values in the report and react accordingly if values are out of the expected range.

Conclusion

The host could poll status data using S1F3 if it wanted to check a value at a given point in time. It can set up a trace if it wants to continuously collect data over a given period of time.

Using the data sampling methods outlined in this blog will allow host applications to poll the data they need when they need it. GEM provides flexibility in requesting data from the equipment either by allowing the host to query values at a given point in time or to be sampled on a periodic basis using a trace.

Click here to read the other articles in our SECS/GEM Features and Benefits series. 

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

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:

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.

HSMS or High-Speed SECS Message Services is a messaging protocol used in semiconductor and other industries as means for connecting to, controlling and gathering data from equipment inside the factory. HSMS provides means for independent manufacturers to produce implementations which can be connected and interoperate without requiring specific knowledge of one another.

HSMS was defined by SEMI in the mid 1990’s as an alternative to aging SECS-I protocol that uses much slower and otherwise more limited RS-232 hardware.

HSMS vs. SECS-I:

• Throughput – HSMS uses TCP/IP and Ethernet which allow speeds up to 1000Mb/s (and higher as technology advances) where SECS-I is limited to 9600b/s or even slower when length of connection between devices increases.
• Distance – lengths of RS-232 cables is usually limited to somewhere less than 1000 feet where Ethernet, with the use of additional devices such as network hubs, has no limits.
• Connectivity – RS-232 is a point-to-point connection where each device has to have an available hardware port. In the factory, a GEM Host has to connect hundreds of equipments and has to have a separate dedicated RS-232 port for each one. With HSMS, a computer with single network interface card can connect to hundreds of equipment.

HSMS is used in all modern semiconductor factories as means for the factory host system to connect to, monitor and control individual equipments.

You might also be interested in:

Read more about High-Speed SECS Message Services
Download the white paper on the SECS/GEM Standards

SEMICON West 2017 has come and gone! The trade show and technical conference was held this year at the Moscone Center in San Francisco and turned out to be a very busy show for the Cimetrix team. While the show was only two halls strong, we had many meetings with current clients, met with new potential clients and even made a few new friends along the way.

A major highlight of the event for all of Cimetrix took place Tuesday evening at the SEMI Standards Awards reception where our own Brian Rubow, Director of Client Training and Support at Cimetrix, took home the prestigious SEMI Leadership Award. Brian, who has over 20 years of experience in the industry, has been a long-time leader and key contributor to the SEMI Standards programs throughout his career.  We were very proud of his work and so glad he was able to receive recognition from the SEMI organization. 

The sales team was hard at work during the entire show and it wasn’t often the Cimetrix booth was empty! Meeting with many new companies made the show very exciting. Our team was especially pleased to meet for several hours with the CEO of our newest client from China! The relationships we establish and cultivate while at these tradeshows make them an invaluable part of our sales, marketing and support efforts. 

The Cimetrix team members that attended were Bob Reback (President and CEO), Dave Faulkner (EVP Sales and Marketing), Ranjan Chatterjee (V.P. Emerging Business & Technology Office), Stu Benger (Director of Sales, North America), Brian Rubow (Director of Client Training and Support), David Francis (Director of Product Management), Alan Weber (V.P. New Product Innovations) and Kimberly Daich (Marketing Manager). Several team members were able to attend for just a day including some of our newest engineers. It was a great chance for them to get to know the show, meet some clients and see some of the machines our software powers in action.

The Moscone Center is undergoing major renovations in preparation for SEMICON West 2018; and we were able to secure a premium spot for next year’s show. SEMICON West is always a great show and we were pleased to be able to attend this year, and as always we’re already looking forward to SEMICON West 2018!

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.

In a recent blog posting we introduced the topic of EDA (Equipment Data Acquisition) standards testing and sub-divided the domain into three parts:

• Compliance testing – does the equipment adhere to the specifications described in the SEMI Standards?

• Performance and stability testing – does the equipment meet the end users’ performance and availability specifications?

• Equipment metadata model conformance testing – does the equipment model delivered with the interface represent the tool structure and content anticipated by the end customer?

Today’s post deals with the equipment metadata model conformance testing in greater detail.

The impetus for the metadata conformance requirement is SEMI Standard E164 – Specification for EDA Common Metadata. Although this standard is not part of the original core suite of EDA standards, it is now being required by GLOBALFOUNDRIES and a number of other major semiconductor manufacturers on EDA-enabled equipment.

The purpose of the standard “is to promote commonality among implementations by defining common representations and conventions of equipment metadata based on SEMI E125.” (Section 1.1 of E164)

In other words, conformance to E164 requires a consistent implementation of E125. All state machines required by the GEM300 standards must be implemented and use the same names for required events, parameters, state names and transitions. It requires that all process modules implement the E157 Module Processing state machine using specified names. As a result, E164 ensures a high level of implementation commonality across all equipment types. This commonality enables better automation of data collection processes across the fab, driving major increases in engineering efficiency. In summary, E164 is to EDA what GEM was to SECS-II.

Currently, the only E164 conformance tester is Metadata Conformance Analyzer (MCA) that was commissioned by Sematech and implemented by NIST (National Institute of Standards and Technology). In our discussions with potential users of an EDA test tool, most clients agree that the sooner a replacement can be created for MCA, the happier they will be.

In a previous post, we mentioned that Cimetrix has automated the EDA compliance evaluation procedures. We are also in the process of designing the performance testing components of this tester. The plan is to also create an E164 conformance tester that will replace MCA.

If you want to know more about EDA testing and/or discuss your specific needs or provide input on what you would like to see included for E164 conformance testing, contact Cimetrix for a demonstration of this exciting new capability!

Update: Cimetrix EDATester Datasheet available now!

In a recent blog posting we introduced the topic of EDA (Equipment Data Acquisition) standards testing and sub-divided the domain into three parts:

• Compliance testing – does the equipment adhere to the specifications described in the SEMI Standards?

• Performance and stability testing – does the equipment meet the end users’ performance and availability specifications?

• Equipment metadata model conformance testing – does the equipment model delivered with the interface represent the tool structure and content anticipated by the end customer?

Today's post deals with the performance and stability testing in greater detail.

In our discussions with EDA users (both OEM implementers and fab end users) about EDA testing, they all acknowledge the need for compliance testing. However, the vast majority have said, “If you can help me automate my performance testing, I would be able to save a huge amount of time.” Most thought they could reduce testing time from several weeks to just a couple of days.

Everyone has different ideas about what should be included in performance testing of their EDA software. Everyone can agree that generally they need to test if the equipment meets the end users’ performance and availability specifications in terms of data sampling intervals, overall data volume transmitted, size and number of DCPs (data collection plans) supported, demands on the computing/network resources, and up-time. They also need to know if the software will support the range of application clients expect in a production environment.

Data Volume

EDA users want to know the sheer volume of data that can be collected.

ISMI has reported in public forums that IC makers expect EDA to achieve data rates of 50+ variables per chamber at rates up to 10 Hz. In EDA specifications, IC makers have requested the ability to gather 1,000 to 2,000 parameters using data collection rates from 5 to 20 Hz, which translates to 40,000 values per second.

These rates are easily achievable with today’s computing platform technology, but users also want to know the upper limit. In other words, at what point does the ability to collect data break down?

Data Quality

EDA users want to know that the data comes in at the specified rates and that the values and timestamps that are received at those rates are accurate.

Resource Usage

EDA users want to know how different data collection rates and volumes will affect the system resources. Will memory usage be too high? How will different collection rates affect CPU usage? Is the network bandwidth sufficient for gathering the required data at the required speeds and still maintain high data quality?

In a previous post, we mentioned that Cimetrix has automated the EDA compliance evaluation procedures. The newly released Cimetrix EDATester^TM is the integrated solution that supports the broadest range of use cases in SEMI Equipment Data Acquisition (EDA/Interface A) standards compliance testing in the industry. The Cimetrix EDATester automates the execution of the ISMI EDA Evaluation Method and features performance testing that characterizes the capabilities and limitations of a tool’s EDA interface. Download the data sheet and see how the Cimetrix EDATester supports your objectives. 

If you want to know more about EDA testing and/or discuss your specific needs, contact Cimetrix for a demonstration of this exciting new capability!