Industry News, Trends and Technology, and Standards Updates

I remember as a new Boy Scout, we planned a hiking trip up into a primitive area in the mountains near my home. One of the first things we learned about reading a map was where to find the legend. The map legend contains important information needed to read a map, like indicating which direction is north. Now that we knew where to find the legend, we could orient the map so it made sense as we were planning our hike.

Most equipment in a typical semiconductor or electronics assembly factory has a user interface that contains a lot of information about the equipment. Most equipment also contains many screens that are used for controlling or operating the equipment. With the use of GEM, a factory host system can control the equipment and collect important data generated during processing.

Like a map, there is a lot of information available on the user interface of a piece of equipment. It can sometimes be difficult to know where to find the important information the host system needs to properly control and communicate with the equipment. The GEM standards provide guidelines on how critical items on the equipment user interface should be presented and controlled. For example, if the host sends information to the equipment operator about tasks they need to perform, the GEM terminal message guidelines state that the information must remain on the user interface of the equipment until the operator acknowledges that they have read it.

The SEMI E30 standard defines the Specification for the Generic Model for Communications and Control of Manufacturing Equipment (GEM). In addition to providing the definition of the common set of equipment behavior and communication capabilities required for manufacturing automation, the standard also provides requirements on which items must be present on an equipment user interface and how they should be represented. User interface requirements spelled out by the standard address communication state, terminal service new message indicator, terminal services message recognition button, communications state default and communications state selector.

This may seem like a small thing, but just like knowing where to find the legend on a map enabled understanding of the lines and symbols on the map, so too the GEM standards can help provide an understanding of information presented on an equipment interface that is essential for communication with a factory host system.

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:

In the third article of this EDA Applications and Benefits in Smart Manufacturing series, we highlighted the first of a series of manufacturing applications that leverage the capabilities of the EDA / Interface A suite of standards in leading semiconductor manufacturers. In this fourth article, we’ll highlight the application that has been the principal driver for the adoption of EDA across the industry thus far, namely Fault Detection and Classification (FDC).

Problem Statement

The problem that FDC addresses is the prevention of scrap that may result from processing material by an equipment that has drifted out of its acceptable operating window for whatever reason. The prevalent technique used by today’s leading FDC systems is to develop “reduced dimension” statistical fault models for the various production operating points based on training sets of “good” and “bad” runs. These models are then evaluated in real time with key parameters (usually trace data) collected from the equipment during processing to detect process deviation and predict impending tool failure. In the most advanced fabs, the FDC software is deeply integrated with the systems that manage process flow, and can even interdict equipment operation in mid-run to prevent/reduce scrap production. 

Of course, the challenge with this type of algorithm is developing models that are “tight” enough to catch all sources of potential faults (i.e., eliminating false negatives) while leaving enough wiggle room to minimize the number of false positives (also known as false alarms, or crying “Wolf!”). This in turn requires high quality data from the equipment, and lots of process engineering and statistical analysis expertise to develop and update the fault models for the range of production cases that must be handled. High-mix foundry environments exacerbate this situation.

Solution Components

The core of modern FDC systems is a robust multivariate statistics analysis toolbox, capable of handling large amounts of time series data. By “large,” we mean both the number of distinct equipment parameters and the number of samples for each parameter. These software tools collapse potentially hundreds of parameters into a small set of “principal components” that can be calculated on-the-fly using a limited set (say, 20-30) of equipment parameters. Some number of these principal components in aggregate represent the actual state of the process accurately enough to detect deviations from the norm, and since they can be realistically calculated in real time, the application serves as an on-line equipment health monitor.

The other major solution component for a production FDC system is a fault model library management capability that can handle large numbers of models. This is necessary because the multivariate approach includes little or no awareness of the physical meaning of the principal components (i.e., they are not “first principles” based), so different operating points for the equipment must have their own sets of fault models. The proper models for a given operating point are selected by matching the values of the “context parameters” for a specific run to those used to store the models. Even if some models can be shared across a range of operating points, the number of distinct models for a foundry megafab will still number in the thousands.

EDA (Equipment Data Acquisition) Standards Leverage

In an advanced fab, there is a spectrum of data collection alternative available for a given application, from basic lot-level summary information to detailed real-time data that can used at the substrate level or even on a die/site basis. For FDC, this spectrum of possibilities is shown in the table below.

SEMI Standard Level	Functionality	Benefit
GEM/GEM300	Fault models difficult to change after initial development if data collection requirements change	Baseline
EDA Freeze I (1105)	Easy to change equipment data collection plans as fault models evolve and require new data; Model development environment can be separate from production system	Engineering labor reduction; improved fault models and lower false alarm rate
EDA Freeze II (0710)	Use conditional triggers to precisely “frame” trace data while reducing overall data collection needs; Incorporate sub-fab component/subsystem data into fault models	Even better fault models; reduced MTTD (mean time to detect) of fault or process excursion; little or no data post-processing required
EDA Common Metadata (E164)	Include standard recipe step-level transition events for highly targeted trace data collection; Automate initial equipment characterization process by using metadata model to generate required data collection plans	Faster tool characterization and fault model development time
Factory-Specific EDA Requirements	Incorporate previously unavailable equipment signals in fault models; Update data collection plans and fault models automatically after process and recipe changes; Include recipe setpoints in the equipment metadata models	TBD (Not yet applicable)

 

The left column refers to the level of SEMI standards used to provide the necessary equipment data. The “Functionality” column describes how that data is used in an FDC context, and the “Benefit” column highlights the potential impact these functions can have. 

Let’s say that a fab implemented the capability described on rows 3 and 4 of the table (EDA Freeze II (0710) and E164-compliant EDA Common Metadata). In this case, the process equipment will be able to provide detailed process parameters at recipe step-specific sampling rates sufficient to evaluate “feature extraction” algorithms of even the most demanding FDC models…with context data to select the precise set of models for a given process condition. And even though the specific equipment parameters are necessarily process dependent, much of the software that monitors recipe execution events, generates the data collection plans (DCPs) that provide the trace data, and assembles the context data used by the model management library can be truly generic because of the fab-wide consistency of the equipment interfaces dictated by the E164 standards.

Another aspect of the EDA standards that FDC teams can leverage is the system architecture flexibility enabled by the multi-client capability. Even while a piece of equipment is connected to a production data management infrastructure, the process engineers and statisticians who develop and refine the fault models can use an independent data collection system tailored for process behavior analysis, experimentation, and continuous improvement. When the new fault models are ready for production, the production DCPs can be updated with these new requirements.

KPIs Affected

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. 

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

As 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:

SEMICON 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.

As 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.

Alarms

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.

SMN and SEDD

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:

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

美国矽美科股份有限公司上海代表处成立于2017年8月，地址位于称为中国硅谷的上海张江高科技园区。公司总部（矽美科股份有限公司）创建于1987年，地址位于美国犹他州盐湖城。矽美科公司是一家为半导体行业、SMT行业、PCB行业、光伏行业、LED行业及相关行业的设备制造商和生产工厂提供产品和服务的软件公司。

矽美科公司有着非常良好的客户评价，公司不仅将自己视为客户的重要供应商，更加将自己视为客户值得信赖的合作伙伴。我们坚信有能力为客户提供全球最先进的基于SEMI标准的软件解决方案。

矽美科上海代表处为中国、台湾等亚太地区客户提供售前产品咨询，客户培训，售后技术支持服务。我很荣幸在今年8月份加入到矽美科上海代表处，在过去的几个月内我们不断收到老客户给予的好评和新客户的合作意向。感谢新老客户对公司的支持，我们将一如既往的为客户提供最优质的、高效的服务，希望我们的产品和服务能让您满足，并为您带来巨大的帮助。

 

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.

Just 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 alarm 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:

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.

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:

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.

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.