Industry News, Trends and Technology, and Standards Updates

EDA Applications and Benefits for Smart Manufacturing Episode 3: Real-Time Throughput Monitoring

Posted by Alan Weber: Vice President, New Product Innovations on Mar 28, 2018 11:13:00 AM

In the introduction to this series (posted December 19, 2017), we listed some of the manufacturing stakeholders whose work objectives are directly addressed by the applications we’ll highlight in this and subsequent postings. In the second article, we explained the process used to map the careabouts of key stakeholder groups into specific EDA interface requirements which are can then be directly included in the purchasing specifications. semiconductor wafer

In this post, we’ll explain how some of those interface requirements support an important factory application that has general applicability across all equipment types, namely “real-time throughput monitoring.” This application can realistically work with a variety of equipment types with no custom code or configuration depending, of course, on how faithfully the equipment supplier implements the SEMI standards referenced in the requirements specification. This powerful concept greatly improves the software engineering productivity of a fab’s automation team, so we’ll take some time to explain how this is possible.

Problem Statement

This application addresses the problem of monitoring equipment throughput performance in real time, and raising an alarm when it drifts away from “normal” for any reason. This is especially important for bottleneck equipment (e.g., litho tracks and scanners), because any loss of throughput ripples throughout the line, resulting in lost production and its associated revenue and profit. Stated simply, “lost time on a bottleneck tool can never be recovered.” 

Solution Components

This application requires data that includes primarily the equipment events that chronicle the movement of substrates through the equipment and execution of the recipes appropriate for this equipment type (process, metrology, inspection, sorting, etc.). With this information, the application calculates the process time “on the fly” and compares the current value with the expected (“normal”) value. 


This is not as simple as it first may seem, because the expected value will likely depend on the product type, process type, material status, layer, recipe, and several other factors. Taken together, the set of factors that determines “equivalence” of different lots for some processing purpose is called “context.” For this application, the context parameters ensure that you are comparing apples and apples when looking for variations in process time.

EDA (Equipment Data Acquisition) Standards Leverage

By “EDA,” we include not only the standards in the Freeze II / 0710 suite, but also SEMI E164 (EDA Common Metadata), E157 (Module Process Tracking), and by reference, the entire GEM 300 suite. This ensures not only the granularity and breadth of event support necessary to precisely track wafer movement and step-level recipe execution, but also specifies the naming conventions of those events and their associated parameters, regardless of equipment type or vendor.

If the equipment automation purchase specifications include clauses that state “we require that all state machines, states, state transition events, and attributes of the objects defined in the referenced 300mm SEMI standards be implemented and named exactly as specified in the standards,” then all the information you should need to write a truly generic throughput monitoring application will be available on demand.

A robust real-time throughput monitoring algorithm can be implemented with information solely from the following SEMI standards: E90 (Substrate Tracking), E157 (Module Process Tracking), E40 / E94 (Processing / Control Job Management), and E87 (Carrier Management). The Harel state diagrams, events of interest, and EDA metadata model representation* for a couple of these (E90 and E157) are shown in the figures below.



Note that as little or as much of the parameter information required to be available for each event (the rightmost picture in each figure) can be collected via the EDA construct of a “Data Collection Plan” (DCP) with one or more “Event Requests.” For more information about these capabilities, consult the SEMI E134 (Data Collection Management) specifications directly, or review some of the extensive educational material available on our web site.

The other point of leverage for the EDA standards is the multi-client capability. This contributes to the productivity and responsiveness of your automation software team members by allowing them to collect and process the data for this application independently from any other application. Specifically, the throughput monitoring functions can be implemented separately from whatever systems host the GEM command and control capabilities, which are usually managed very carefully because of their potentially negative impact on fab operations.

Key ROI Factors

apc2017_5.pngAs we said in the initial post of this series, this application is not just something you could build and deploy with EDA-enabled equipment… in fact, this has already been done, and is delivering real production manufacturing benefit! Specifically, the ROI factors impacted (and benefit delivered) by this application include productivity excursion mean-time-to-detect (MTTD, 50% reduction), selected equipment throughput improvement (3-5%), and overall cycle time reduction (difficult to quantify precisely because of the staged implementation process). 

Of course, these results will vary depending on the manufacturer’s fab loading, operations strategy, and overall automation capabilities, but are representative for leading edge production wafer fabs running at near capacity. However, since these are very common ROI factors, most companies can easily quantify these improvements in real financial terms.

In Closing...

As always, your feedback is welcome, and we look forward to sharing the Smart Manufacturing journey with you.


*The visualizations of equipment metadata model fragments are those produced by the Cimetrix ECCE Plus product (Equipment Client Connection Emulator).

Let us know if you would like to schedule a meeting to learn more:

Schedule a Meeting

Topics: EDA/Interface A, Smart Manufacturing, EDA in Smart Manufacturing Series

That's a wrap - SEMICON China 2018

Posted by Cimetrix on Mar 22, 2018 10:30:00 AM

semichina1.jpgSEMICON China was held from March 14-16, 2018 in Shanghai at the Shanghai New International Expo Centre. Simultaneously co-located at this huge complex were Productronica China and Laser World of Photonics China. All three shows were very busy this year, and it is clear the electronics manufacturing industry in China is booming.

Cimetrix attendees included Dave Faulkner (VP Sales and Marketing), Ranjan Chatterjee (VP Smart Factory Business Unit), Michael Lee (Country Manager Taiwan), Yufeng Huang (Senior Software Engineer), Alan Weber (VP New Product Innovations), and Kimberly Daich (Marketing Manager); Hwal Song (Country Manager Korea) was also able to attend for one day. The Cimetrix booth was busy throughout the show, and provided a comfortable and convenient setting for the many scheduled and walk-in meetings that took place.

Cimetrix partners Facet and Flagship also attended the show, and participated in several customer/prospect discussions. In conjunction with our partner Facet, Cimetrix software products are now used in more than 25 production factories within the China market segment. Moreover, the relationships we have established throughout the semiconductor and electronics markets are strengthening our global presence and enable Cimetrix to provide local support to current and potential clients. The most recent example is our Shanghai office, opened in 2017.


In addition to the exhibitions, SEMICON China sponsored many forums for expert speakers throughout the show. One of these included the New Technology Release Forum where our own Alan Weber was selected as a speaker. His topic “Integrated Equipment Data Collection and Management for Smart Manufacturing” was well received by those in attendance. Smart Manufacturing has been a topic of keen interest at all SEMICONs over the past 18 months, and China was no exception; a separate forum dedicated to Smart Manufacturing drew a standing-room-only crowd to hear a broad range of speakers across the technology spectrum.

We are currently expanding our Shanghai office in response to the exciting growth opportunities we see for our industry in China, and look forward to many years of collaborative work in this region.

Topics: Events, SEMICON, Smart Manufacturing

SECS/GEM series: Documentation

Posted by Joe Cravotta, Client Support Engineer on Mar 6, 2018 11:27:00 AM

Case_studies.jpgAs the first article in this Features and Benefits of SECS/GEM series points out, the SECS/GEM standards define a standardized interface that may be used on any equipment. A GEM interface exposes an equipment's capabilities through status variables, data variables, collection events, alarms, data formats, error codes, SECS-II messages, and other optional GEM capabilities. The GEM standard requires each equipment to come with documentation; ensuring a factory has the information it needs to use an equipment’s GEM interface. This documentation is commonly referred to as the GEM manual.

The GEM manual may be distributed in many ways. Currently, most GEM manuals are provided digitally in a Word, Excel, or PDF  document. The vast amount of information in a GEM manual is used to make purchasing decisions, develop host software, and test equipment. For a full GEM interface, the GEM manual must include the following topics: State Models, Scenarios, Data Collection, Alarm management, Remote Control, Equipment Constants, Process Recipe Management, Material Movement, Terminal Services, Error Messages, Clock, Spooling, Control, Supported SECS-II messages, GEM Compliance statement, and Data Item Formats. To keep this post a reasonable length, we will only cover a few of the required topics.

GEM Compliance Statement

The compliance statement is one of the first topics to be reviewed. It is a quick and easy way to understand the features of an equipment’s interface. The manufacturer is required to mark which GEM capabilities are implemented on the equipment, and if they are implemented in a way that is compliant with the GEM standard.


State Models

State Models is a fundamental GEM capability, and is therefore implemented on every equipment. This capability defines the Communication, Control, and spooling behavior of the equipment. A processing state model must be provided. However, it is not possible to define a processing state machine that can be used on every equipment. The processing behaviors that should be the same for all equipment are specified by the standard. Each state model must be documented with a state model diagram, a transition table, and a text description of every state. The consistent and detailed information about each state model enables a factory to start writing a host application as soon as they have the GEM manual.


Alarms, Collection Events, Equipment Constants, Data Variables, and Status Variables 

Alarms, Collection Events, and Variables are large components in gathering data from an equipment. It should not be a surprise that these are required to be in the GEM manual. Each alarm on the equipment should have its ID, name, description, and associated Set/Clear events in the GEM manual. The documentation for each collection event should include the ID, name, description, and a list of associated variables. The documentation for all variables will include an ID, name, description, and the data type. Information about a variables default value or value range should also be provided when appropriate. Although not required, it is common to display all this information in five tables that are easy to find. There would be a single table for each of the following: alarms, collection events, equipment constants, data variables, and status variables. See the examples below.



Collection Events


Status Variables


Remote Control

Once a factory can gather data from an equipment they start looking at how to control the equipment. Remote Control is the GEM capability that allows a host application to request an equipment to perform an action. Each remote command should be in the manual with its name, description, and details about each command parameter that may be sent with the command. The details of a command parameter should include the name, the format, and a description. An example is shown below.



GEM manuals rarely come in a format that is easy to parse in software. This often results in duplicating code and making small changes in order to communicate with other equipment. SEMI E172 SECS Equipment Data Dictionary (SEDD) and E173 SECS Message Notation (SMN) are two standards that can drastically increase the flexibility and reusability of a host application. SEDD is an xml file that is easily distributed and parsed in software. SEDD can be considered a modernized GEM manual because it contains much of the same information that is found in a GEM manual. For example, a SEDD file contains details about every variable, collection event, alarm, and supported SECS-II message. A SEDD file uses SMN to represent the data items, variables, and SECS-II messages. SMN is also XML and is the first standard to define a notation for representing data items and SECS-II messages. This means a single application can read a SEDD file, have a short configuration process, and then immediately start using the GEM interface of an equipment. These features allow a single application to be used with multiple equipment instead of creating slightly different variants for each equipment.

Wrap up

The GEM manual is a crucial piece of documentation that is required by the GEM standard to be provided with every equipment. The GEM Manual should be the first place to look for an answer when there is a question about an equipment’s GEM interface. SEMI continues to improve the content and flexibility of a GEM manual by updating existing standards and creating new standards.

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:

SECS/GEM White Paper

Topics: SECS/GEM, Smart Manufacturing, SECS/GEM Series

Cimetrix International, Inc., China; 矽美科国际有限公司,中国

Posted by Yufeng Huang; Software Engineer China on Feb 28, 2018 11:40:00 AM

Yufeng Huang of Cimetrix talks about our China Office Opening. Read now in Chinese or English.





地址:上海市浦东新区盛夏路399弄1号(A座)3楼328室3069单元 (邮政编码201210)

销售联系:Michael Lee

American Cimetrix Incorporated Shanghai Representative Office was established in August 2017. It is located in ZhangJiang High-Tech Park, which is also known as China’s Silicon Valley. The headquarters of Cimetrix, Inc, founded in 1987, is located in Salt Lake City, Utah, USA. Cimetrix is a software company that provides software products and services to OEMs and Fabs in the semiconductor, SMT, PCB, photovoltaic, LED and related industries.

Enjoying excellent customer reputation, Cimetrix considers itself more as customer’s trusted partner than customer’s supplier. We firmly believe that we have the ability to provide customers with the world's most advanced SEMI-based software solutions.

Cimetrix Shanghai Representative Office provides pre-sales consulting, customer training, after-sales technical support services to mainland China, Taiwan and other Asia areas. I am greatly honored to join Cimetrix Shanghai Representative Office in August 2017. In the past few months, we have continuously received favorable comments from existing customers and cooperation intentions from potential customers. Thanks for their trust and support of the company, we will, as always, provide our clients with the best and most efficient services. We believe that our products and services will meet customer satisfaction and greatly enhance your product quality.

American Cimetrix Incorporated Shanghai Representative Office
Address: Unit 3069, Room 328, Floor 3, No. 1 (Block A), Lane 399, Shengxia Road, Pudong New Area, Shanghai (Post Code: 201210)

Technical Contact: Yufeng Huang
Telephone: +86-21-8022-0935

Sales Contact: Michael Lee
Telephone: +886-926395649


Topics: Announcements, Global Services, Smart Manufacturing

SECS/GEM Series: Alarms

Posted by David Francis: Director of Product Management on Feb 14, 2018 10:30:00 AM

Previous posts have talked about functionality that allows data to be collected through the GEM interface so the factory applications described in the most recent post can analyze this data. With this posting, we return to a discussion of specific features and capabilities of the SEMI E30 GEM (Generic Equipment Model) standard, specifically the management of error conditions on the equipment.

In a perfect world everything goes according to plan, but in reality, things always go wrong. The secret to success is being able to know when something goes wrong, and then responding appropriately.

Minion_alarm.pngJust like a home alarm system, semiconductor fabs want to know when something bad has happened. They want to prevent the material being processed from being scrapped. Alarm management enables the equipment to notify the host when something goes wrong, and provide information about what has gone wrong. The GEM standard defines Alarm Management as the capability to provide host notification and management of alarm conditions occurring on the equipment. 

In GEM, an alarm is any abnormal situation on the equipment that may endanger people, equipment, or material being processed. For example, if a technician opens an access panel to replace a component, the equipment should send an alarm notifying the host that it is not safe to operate the equipment in its current condition. Another example might be if an equipment requires a high temperature for processing but a sensor detects a low temperature condition, it should trigger an alarm, since running the process under those conditions could damage the material being processed. It is also the responsibility of the equipment manufacturer to inhibit unsafe activities on the equipment when an alarm condition is present. The equipment manufacturer knows best what specific alarms are required on the equipment to ensure safety for people, equipment and material.

Often it is useful to have more information about the conditions in the equipment at the time an alarmflashing-red-light-1.png condition occurs. Communicating that additional information to the host is valuable, but cannot be done through the normal Alarm Report Send/Acknowledge messages. To provide a way to get this additional information, GEM requires that two collection events be defined for each possible alarm condition on the equipment – one event for when the alarm is set, and another for when the alarm is cleared. These collection events allow the GEM event data collection mechanisms to be used to send the additional related information to the host when an alarm changes state.

In addition to providing the time of an alarm state change, Alarm Management on the equipment must allow the Host to request a list of all alarm IDs and associated alarm text. The host must also be able to enable/disable individual alarms on the equipment, and query the equipment for the list of alarms that are currently enabled for reporting.

The state diagram for an Alarm is not very exciting, but it fills a vital need. The picture below illustrates the Alarm State diagram:


GEM alarms only have 2 states: each alarm is either SET or CLEAR. It’s simple but effective.

Alarm Management isn’t rocket science, but through effective use of Alarm Management, fabs can carefully monitor the health of their process equipment and minimize negative impacts to their production yield. 

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:

SECS/GEM White Paper

Topics: SEMI Standards, SECS/GEM, Smart Manufacturing, SECS/GEM Series

EDA Applications and Benefits for Smart Manufacturing Episode 2: The Stakeholder-Driven Requirements Development Process

Posted by Alan Weber: Vice President, New Product Innovations on Feb 7, 2018 11:19:00 AM

In the introduction to this series posted December 19, 2017, we listed some of the manufacturing stakeholders whose work objectives are directly addressed by the applications we’ll highlight in subsequent postings. Before getting into the specific capabilities and benefits of these applications, however, it seemed appropriate and timely to share a little bit about the process that the leading EDA practitioners use to ensure the equipment they are purchasing will support these applications. “Appropriate” because you may need to review and update your own purchasing specifications to clearly convey your requirements in the areas that are not directly covered by the standards (like model content, performance, and stability); “timely” because we at Cimetrix have recently conducted a number of customer workshops and seminars in which this process was effectively used and refined.


In particular, this article explains how the careabouts of key stakeholder groups are “translated” into specific EDA interface requirements which can then be directly included in the purchasing specifications. As more semiconductor manufacturing companies take this approach, effectively “raising the bar” for the entire industry, the collective capability of our equipment suppliers will increase in response, to everyone’s benefit.  

In the previous post, we suggested that manufacturing stakeholders, KPIs, applications, and equipment data are all interrelated. Since the ultimate beneficiaries in this value chain are the stakeholders themselves, the challenge then becomes how to capture their requirements effectively… because these are busy people whose time is precious. Through a number of interviews with leading manufacturers over the past 18 months, we discovered that the best way to accomplish this is through a focused, interactive questionnaire process. By asking very specific questions about people’s daily tasks, problem areas, expectations, success criteria, and other items of constant concern, we can take a generic EDA purchase specification outline and generate a complete, factory-specific set of EDA purchase specifications in a matter of days. This is time well-spent when you consider the value and volume of equipment potentially affected… and the opportunity cost of not having these requirements clearly expressed. 

The stakeholder answers to the questionnaire serve a broader purpose as well, because in addition to driving the content of the equipment purchase specifications, they also form the basis for a lot of manufacturing technology development within the factory. This overall process is shown in the figure below; documents and related artifacts are shown in red; the affected organizations (of which there are many!) are shown in blue. 


A blog posting can only hope cover a fraction of this overall process, but the sample questions below should give you an idea of how it works.

Sample questions for the Manufacturing Automation and Technology Development stakeholders include:

  • Are you familiar with SEMI E157 (Module Process Tracking)? Is it implemented on any of your current tools, and if so, do you monitor those events?
  • EDA_apps_benefits_3.pngDo you require that all state machines, states, state transition events, and attributes of the objects defined in the referenced 300mm SEMI Standards be implemented? If not, why not?
  • Do you currently use information from sub-fab systems in any of your on-line production applications, like FDC, PHM, R2R control, or others? If so, what range of equipment is supported, and how (pumps, chillers, abatement systems …)?
  • How do you express performance expectations for process variable reporting, such as sampling frequency, # parameters per chamber, report sizes, total bandwidth of all data reported, maximum latency of event generation, etc.? 

Sample questions for Production Operations and Engineering Support people include:

  • How do you schedule carrier pick-up and delivery from/to equipment, respectively? Is this done using algorithms in the AMHS/MCS/OHT system components, or do you get real-time updates from the equipment about pending lot completion and tool availability?EDA_apps_benefits_4.jpg
  • Do you need to have remote access capability for checking basic tool status outside the fab?
  • Do you require your suppliers to provide built-in data collection schemes (pre-defined reports, macros, etc.) to support common monitoring, maintenance, or diagnostic processes?
  • Do you have a list of parameters/events that must be collectable to support your production application portfolio?
  • Do you monitor any of the low-level actuator/sensor signals in the various mechanisms that make up a manufacturing tool?

Sample questions for the Procurement and Supplier Relations organizations include:

  • What compliance tests/reports do you require of the equipment suppliers before they ship equipment to your factories? Do you ever/sometimes/always visit the supplier's site to observe this process? What about after delivery?EDA_apps_benefits_5.png
  • Do you have a standard supplier response sheet or checklist for your automation requirements? If so, are you satisfied with its clarity, completeness, and ease of use for evaluating responses?
  • At what point in the equipment purchasing cycle do you review the capabilities of the interface software (event/parameter lists, model structure/content, projected performance, etc.)? When are these capabilities validated?
  • Do you assign a monetary value (say, some % of the equipment purchase price) to the interface software? 

If the above discussion triggers the question “I wonder if our EDA purchase specs are sufficient to address the manufacturing challenges we’ll face in the next few years?” give us a call. We’ll be happy to talk about how to support your stakeholders and automation team with an effective on-site workshop to address this question once and for all… It could be the most important next step you take in formulating you own company’s EDA implementation roadmap. 


As always, your feedback is welcome, and we look forward to sharing the Smart Manufacturing journey with you.

Click below to learn more about EDA:

EDA/Interface A

Topics: EDA/Interface A, Smart Manufacturing, EDA in Smart Manufacturing Series

SECS/GEM series: Data Polling

Posted by Derek Lindsey: Product Manager on Jan 24, 2018 11:30:00 AM

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.

datapolling_281485322-.jpgTypes 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.


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)

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.


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:

SECS/GEM White Paper

Topics: SEMI Standards, SECS/GEM, Smart Manufacturing, SECS/GEM Series

EDA Applications and Benefits for Smart Manufacturing: Introduction to a New Series

Posted by Alan Weber: Vice President, New Product Innovations on Dec 19, 2017 11:40:00 AM
With the adoption of the latest SEMI EDA (Equipment Data Acquisition, also known as Interface A) standards accelerating significantly over the past 18 months, it is time to highlight the applications across the industry that make the best use of these standards, and the specific manufacturing benefits that result.

The articles in this series are not simply suggestions of what one could do by leveraging the performance, flexibility, and architectural features of these standards. Rather, they are leading edge application-specific mini-case studies derived from actual production experience, and as such, can provide genuine guidance for those companies just now contemplating potential pilot projects or even factory-wide deployments of the EDA standards.
Another important aspect of this series is that the applications described affect a broad range of stakeholders in a semiconductor manufacturing company. These include, of course, the process control engineers and statistical modeling support staff responsible for the Fault Detection and Classification (FDC) implementation strategy in all modern wafer fabs, since this application has consistently been the initial consumer of the high-density, precisely framed equipment/process data and associated context information provided through the EDA interfaces.

However, other direct beneficiaries of EDA-enabled applications extend well beyond this group, and include:
  • Industrial engineers responsible for monitoring equipment and factory throughput in real-time, identifying opportunities to eliminate wait time waste in individual equipment types as well as the overall factory, and addressing bottlenecks as they shift and emerge;
  • Production control staff responsible for determining the material release schedule and managing the factory scheduling/dispatching systems to accommodate changes in customer orders and/or factory status;
  • Equipment engineers responsible for fleet matching and management to minimize or eliminate the need to dedicate certain equipment sets for critical process steps and thereby simplify the overall factory scheduling process;
  • Maintenance engineers responsible for minimizing equipment downtime, MTTR (mean time to repair), and test wafer usage required to bring equipment back to production-ready state;
  • Facilities engineers responsible for collecting and integrating sub-fab data from pumps, chillers, exhaust systems, and other complex subsystems into the production data management infrastructure for use by a growing range of analysis applications;
  • Sensor integration specialists responsible for supplementing the built-in sensing and control capabilities of critical process and measurement equipment to support advanced process development…

… and the list goes on.EDAApplications_1.1.png

Despite their diversity, these application articles all share a common profile, which includes a statement of the manufacturing problem addressed; a description of the major solution components required; a discussion of how the solution leverages specific, unique characteristics of the EDA standards; and finally, identification of the key ROI (return on investment) factors that are impacted by the solution. In addition, where available, example ROI calculations will be provided so that the readers can adapt them to their own company environments to quantify the potential benefit of implementing a comparable application solution.

From the above description, you may be tempted to assume that the series focuses mostly on the careabouts of semiconductor manufacturing companies (IDMs and foundries)… but this is not the case. Since the performance of the highlighted applications depends heavily on the “quality” (for lack of a better term) of the equipment interfaces supplying the data, the equipment suppliers have a major role to play in achieving the promised benefit. Specifically, the metadata models (specified by SEMI E120, E125, and E164) that define the parameters, states, events, exceptions, and other data available from the equipment and structure this information for external access essentially form the data collection “contract” between the equipment suppliers and their factory customers. For this reason, the detailed requirements for this aspect of the EDA implementation must be carefully specified and negotiated. This will not happen overnight, as the implications for future equipment design are significant.

As a number of industry experts have already expressed, it is an exciting time to be in the semiconductor industry, regardless of your position along the value chain. For those involved in the collection and use of equipment data to optimize factory performance, we hope you will find the coming series of articles especially useful in formulating you own company’s EDA implementation roadmap.


To view additional resources on EDA/Interface A or other topics, click on the resources link below.


As always, your feedback is welcome, and we look forward to sharing the Smart Manufacturing journey with you.

Topics: EDA/Interface A, Smart Manufacturing, EDA in Smart Manufacturing Series

Conclusions and Call to Action: 6th and Final Episode in the “Models in Smart Manufacturing” Series

Posted by Alan Weber: Vice President, New Product Innovations on Dec 1, 2017 11:00:00 AM

Over the past several months, we’ve highlighted the importance of explicit and standardized models in the context of equipment communications interfaces and some of the “smart” factory applications they support. The manufacturing stakeholders impacted by these applications run the gamut from process, equipment, maintenance, and industrial engineering to production operations to traceability regulatory compliance… yet these only scratch the surface.


The question you may be asking now is “So what?” or “What should I do with this information?” The answer to these important questions depends on your company and your role. 

For example, if you’re part of a semiconductor manufacturing enterprise in today’s market environment, you know that you can probably sell every good device you make, so there is intense pressure to simultaneously maximize product quality, volume, and [factory and engineering] productivity–a perfect storm. Since lead times for new equipment needed for capacity expansion are at all-time highs, this means getting as much as you can out of your existing facilities while waiting for new deliveries. New applications to monitor and improve these KPIs are being developed continuously, but the one thing they have in common is a reliance on detailed, high quality, easily accessible and interpretable equipment data.


For 300mm equipment with the latest generation of SEMI EDA (Equipment Data Acquisition) interfaces, this means having “good” E120/E125/E164-compliant equipment metadata models as a foundation. On top of this foundation, however, the models must also include the specific parameters, events, state machines, and other items that fully describe the behavior of the equipment according to your unique manufacturing requirements… which can only be achieved by mapping these requirements into specific equipment model elements, and updating your purchase specifications to close whatever gaps you find between what is currently offered by the equipment suppliers and what you really need. Fortunately, we have been through this process a number of times, and can help clarify your manufacturing priorities and translate them directly into updated interface purchase specifications.


Admittedly, this may take some time, but remember that you always only get what you are willing to accept. It brings to mind the old adage: “The best time to plant a tree was 20 years ago; the second 


best time is today.” 

As another example, if you are part of the embedded control system development team of an equipment supplier, you can anticipate not only increasingly explicit model content requirements, but also more stringent performance and testing requirements for the standard EDA communications interface as your customers raise their reliance on this technology to realize manufacturing competitive differentiation. We at Cimetrix have seen this demand build over the past 18 months, and are well prepared to support you throughout the entire equipment development life cycle.

This article is the sixth and final in the series announced earlier this year in the Models in Smart Manufacturing blog series. From here, we’ll soon begin a new series on advanced EDA applications and benefits based on best practices of the industry leaders – be sure to watch for this early next year!

We look forward to your feedback and to sharing the Smart Manufacturing journey with you.


*The visualizations of equipment metadata model fragments are those produced by the Cimetrix ECCE Plus product (EDA Client Connection Emulator).

Topics: EDA/Interface A, Models in Smart Manufacturing series, Smart Manufacturing

SEMICON Taiwan wrap-up

Posted by Alan Weber: Vice President, New Product Innovations on Sep 21, 2017 10:45:00 AM


As predicted, Cimetrix had a very busy and fruitful week (September 11-15) in Taiwan. In addition to hosting numerous customers, prospects, and friends at our booth, Cimetrix made multiple technical presentations focused on Smart Manufacturing, both at the show and at the eMDC Conference in Hsinchu. Two of these were jointly presented with Mark Reath of GLOBALFOUNDRIES. Use the links at the bottom of this post if you’d like a copy of this material.



In addition to our participation in these technical events, Cimetrix demonstrated the new Cimetrix EDATester™ product to a number of factory customers who now need a validated method for verifying incoming equipment compliance to the SEMI Equipment Data Acquisition (EDA) suite of standards. The timing for this product is ideal, based on the increased rate of adoption for these standards we have seen in Taiwan. 

Given the industry’s current momentum and near-term outlook, the mood in Taiwan is overwhelmingly positive, and the trade show almost had a celebratory quality to it. Fittingly, the Leadership Gala Dinner held Wednesday night was a feast for all the senses, from the food to the entertainment to the array of dignitaries who attended. 


For the second year in a row, President Tsai attended and expressed her gratitude for the industry’s role in advancing the quality of life across the nation and her administration’s unwavering support for its continued prosperity. Dr. Nicky Lu, one of Taiwan’s well-known business and technology icons, was honored with the industry’s most prestigious Leadership Award, and shared his personal perspective on some of the exciting semiconductor-enabled products now in the works. 


Dr. Lu went into even more depth about semiconductor technology evolution in his keynote address for the eMDC Conference (Joint Symposium of e-Manufacturing & Design Collaboration Symposium 2017 and ISSM 2017) on Friday, outlining a powerful vision that he’s labelled as “HIDAS: Heterogeneous Integrated Design/Architecture/System for Silicon-Centric Nano-System in Si4.0” – if you want to know more, you’ll want to contact him directly!


All in all, is was a great week to be in Taiwan, especially since Typhoon Talim decided to take a turn to the north without dampening the spirit of SEMICON. Please contact us with any questions, and we look forward to seeing you at future industry events.

Device Scaling vs. Process Control Scaling: Advanced Sensorization Closes the Gap

Smarter Manufacturing through Equipment Data-Driven Application Design

Smart Manufacturing Requirements for Equipment Capability and Control

Topics: Events, SEMICON, Industry 4.0, Smart Manufacturing