Industry News, Trends and Technology, and Standards Updates

SECS/GEM Series: GEM Message Spooling Capabilities

Posted by Jesse Lopez: Software Engineer on Jun 6, 2018 10:49:00 AM

Purpose of Spooling Messagesphone-cut-cord

Even the most robust computer networks experience communication failure. Regardless of the cause, a small outage could be responsible for a significant amount of mission critical data loss. GEM mediates this loss of data by providing the message spooling capability.

Spooling Definition

“Spooling is a capability whereby the equipment can queue messages intended for the host during times of communication failure and subsequently deliver these messages when communication is restored" SEMI E30-0717 7.12.

Spooling Benefits

Automated factories are data-driven. Data is extracted and analyzed to make decisions that influence how engineering and management teams react to ensure product yield is high and scrap is low.

Gaps in this data could lead to erroneous judgement or even guessing. Spooling is a backup system that ensures this data will be preserved and restored reducing the risk of losing valuable data.

GEM Capability Requirements

Spooling is not a GEM requirement however, if this additional capability is implemented it must be done so properly. Here are a few requirements for implementing a compliant spooling interface.

The equipment must provide the host with the ability to enable and disable spooling via the equipment constant “EnableSpooling”. This EC is published by the equipment and the host can select the desired state.

When Spooling is implemented, it must be functional for all relevant primary messages and accessible using an S2, F43/F44 transaction. This excludes stream 1 messages which must be rejected if they attempt to “set spool”. 

Non-Volatile Storage

The equipment is responsible for allocating enough non-volatile-storage to store all messages that have been spooled for at least one processing cycle of the equipment. The NVS will also house all spooling-related status variables. NVS is used for this data so that if a power outage occurs the data is persisted.

Loss of Power

All messages that were spooled prior to the equipment’s power loss will be available since they are persisted in non-volatile storage. All spooling context is restored from NVS if spooling was active at the time of the power loss occurred. This includes the spooled data as well as all spooling related status variables persisted in NVS.

Host responsibility for implementation of Spooling

Message spooling requires hosts to participate to successfully recover after a loss of communication. It is Ideal to leave spooling in the disabled state until the host has been programmed to properly handle all conditions that may occur in the entirety of this state machine. Disabled spooling is better than improperly managed spooling. 

Once communication is re-established, the host must manage requesting the spooled messages. The host also has the option of purging the files from the equipment when necessary.

Conclusion

Though spooling is not a fundamental GEM requirement, if implemented it must be done so properly. Both host and equipment software have a responsibility to ensure GEM compliance when spooling is enabled. GEM spooling protects the potential loss of valuable data and provides a standard for both equipment and host software to adhere to with ease.

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

SECS/GEM Series: User Interface

Posted by David Francis: Director of Product Management on May 23, 2018 11:04:00 AM

secs/gem user interfaceI 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:

SECS/GEM White Paper

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

CCF为实施工厂自动化提供了一条捷径: CCF Gives an Easy Way to Implement Factory Automation

Posted by Yufeng Huang; Software Engineer China on May 10, 2018 11:37:00 AM

Yufeng Huang of Cimetrix China, talks about Equipment Control in the factory. Read now in Chinese or below in English.

在和半导体设备制造公司的接触中我们遇到这么一个尴尬的问题,很多懂得设备控制的优秀软件工程师对于GEM,GEM300和EDA标准不是很有经验。这些公司往往是在设备在实验室研发成功,准备产业化送入客户工厂时发现设备没有实现或只有部分实现GEM/GEM300标准,尤其是当客户工厂要求EDA(Interface A)通信接口的时候,这些设备制造商的软件工程师往往一脸茫然,不知道如何在短时间内开发出完全遵循GEM/GEM300/EDA标准的软件。

对于大多数设备公司而言,限制于有限的人力、财力资源,公司很难聘请到足够多富有经验的工厂自动化软件工程师开发自己的GEM/GEM300,甚至EDA软件模块。另外一个棘手的问题是我们发现很多软件工程师不是特别有意愿加入到半导体行业,而是选择比较热门的互联网、游戏,手机App等软件行业。纵观半导体工厂自动化软件市场,虽然已有多家公司提供GEM/GEM300/EDA的软件开发包(SDK),但软件工程师仍旧需要掌握一定的工厂自动化基础知识才能着手编写软件集成代码。工厂自动化涉及大量SEMI标准,譬如GEM标准大概有450页文档,包括E4,E5E30E37,E37.1,E172,E173,GEM300标准大概有280页文档,包括E39,E40,E87,E90,E94,E116,E157,E148,而更为复杂的EDA标准大概480有页文档,包括E120,E125,E128,E132,E134,E138,E164,对于大多数非专业的工厂自动化软件工程师而言,工厂自动化软件的集成工作是一件极其繁琐而艰难的任务。


Cimetrix Control FrameworkTM (CCF)
是基于微软.Net技术的设备自动化控制软件框架,该软件不仅为设备制造厂商提供了监督控制和生产控制框架代码,而且完全实现了GEM/GEM300/EDA标准。借助CCF软件平台,软件工程师无需深刻掌握工厂自动化的所有SEMI标准,就能轻松变身为工厂自动化开发专家。CCF软件框架内的工厂自动化模块基于Cimetrix公司的CIMConnect,CIM300,CIMPortal Plus三个独立的软件开发套件(SDK)实现,分别对于实现GEM,GEM300,和EDA标准。全球任意一家300mm的芯片制造工厂都有安装了CIM300软件的设备运行,在支持EDA数据采集的工厂都有安装了CIMPortal Plus软件的设备运行。CCF软件框架将所有工厂自动化的开发工作交给Cimetrix公司来完成,设备软件工程师可以把更多的时间花费在如何设计自己的设备控制软件上。

在CCF框架下,CIMConnect/CIM300/CIMPortal Plus的底层API函数都被很好作了封装,软件工程师只需通过CCF框架提供的函数或接口就能轻松实现和工厂主机程序的所有GEM/GEM300标准。实现EDA标准的一个重要任务是创建一个支持分层次结构的设备模型,以及按照标准生成XML数据,此外生成的模型还需满足E164标准。在CCF软件初始化运行时会动态生成设备模型,软件工程师几乎不需要书写EDA代码,设备即可很好的遵循EDA标准。lego brick building is like CCF

采用CCF软件框架降低设备控制程序和工厂自动化程序的开发难度和开发周期,但并不意味着我们的客户一定得推翻自己已有的软件平台或已经测试过的稳定代码。CCF是一个提供源代码的完全开放的自动化控制程序框架,你可以将CCF理解成一个已经拼好的乐高玩具,用户既可以将自己的代码模块集成到CCF中,也可以挑选部分CCF功能模块并将其转移到用户自己的框架中。我们用户将CCF中工厂自动化模块(包括GEM/GEM300/EDA)搬迁到自己的程序框架中,在保证完全遵循工厂自动化诸多SEMI标准的同时,对用户已有程序的影响非常小。

得益于CCF框架的完全开放性,像玩乐高积木一样,软件工程师可以轻松享受自由裁剪自己想要的控制系统框架带来的乐趣,这是其他任何一家提供设备控制软件框架程序的公司都很难做到的一件事情。

在未来几年,越来越多的工厂往智能生产制造的方向发展,由此对数据的需要越来越高,EDA标准越来越成为工厂主流的数据采集方法,CCF无疑成为了设备制造商更快更好实现各种工厂自动化标准的最佳武器。 


We encountered an interesting issue when working with semiconductor equipment manufacturing companies. Many excellent software engineers who know equipment control are not very experienced with the GEM, GEM300, and EDA standards. Sometimes after equipment is successfully developed in the laboratory and before the equipment is shipped to the factory, we discover that the equipment did not implement or only partially implemented the required GEM/GEM300/EDA standard. This is especially prevalent when the factory requires the EDA (Interface A) communication interface. Equipment software engineers sometimes do not know how to develop software that fully complies with GEM/GEM300/EDA standards in a short period of time.

For most equipment companies with limited human and financial resources, it is difficult for the company to have the resources to develop their own GEM/GEM300/EDA software. Another issue is that we have found many of the more experienced software engineers are more interested in high-profile  internet, gaming, mobile phone apps and other software industries rather than the lower profile semiconductor industry.  Although many companies in the semiconductor factory automation software market have provided GEM/GEM300/EDA software development kits (SDKs), software engineers still need to master certain basic knowledge of factory automation to start writing software integration code. Factory automation involves a large number of SEMI standards. For example, the GEM standard has about 450 pages of documents, including E4, E5, E30, E37, E37.1, E172, E173. GEM300 standards have about 280 pages of documents, including E39, E40, E87, E90, E94, E116, E157, E148. The more complex EDA standard has about 480 pages, including E120, E125, E128, E132, E134, E138, E164. For less experienced factory automation software engineers, the integration of automation software can be an extremely tedious and difficult task.

Cimetrix CIMControlFrameworkTM (CCF) is an equipment automation control software framework based on Microsoft .Net technology. This software not only provides equipment manufacturers with supervisory control and equipment control framework code, but also fully implements the GEM, GEM300 and EDA standards. With the help of the CCF software platform, software engineers can easily turn into factory automation development experts without having to master all the factory automation SEMI standards. The factory automation components within the framework of the CCF software are based on CIMConnect, CIM300, and CIMPortal Plus, three independent software development kits (SDKs) from Cimetrix for the implementation of the GEM, GEM300, and EDA standards, respectively. All 300mm chip manufacturing factories in the world have equipment installed which uses CIM300 software. Any factory requiring EDA data collection has equipment installed that uses CIMPortal Plus software. With the CCF software framework, Cimetrix has already done the work of integrating all factory automation into the framework. The equipment software engineer can spend more time on how to develop their own equipment control software.

Under the CCF framework, the underlying API functions of CIMConnect/CIM300/CIMPortal Plus are well encapsulated. Software engineers can easily implement all the GEM/GEM300/EDA standards of the factory host program through the functions or interfaces provided by the CCF framework. An important task in implementing the EDA standard is to create an equipment model that supports hierarchical structures and generate XML data in accordance with standards. In addition, the generated model must also meet the SEMI E164 standard. The equipment model is dynamically generated when the CCF software is initialized. The software engineer needs to do very little to have an equipment control application that is fully compliant with the EDA standard.lego brick building is like CCF

The use of the CCF software framework to reduce the difficulty and development cycle of equipment control programs and factory automation programs does not mean that our clients must replace their existing software platforms or stable code that has been tested. CCF is a fully open automation control program framework that provides source code. You can think of CCF as a LEGO toy that has been put together. Users can either integrate their own code modules into CCF or select some of the CCF functional modules and transfer them to their own framework. Our clients can reuse the factory automation modules (including GEM/GEM300/EDA) in CCF in their own program frameworks. While ensuring that all SEMI standards for factory automation are fully complied with. The impact on the user's existing programs is minimal.

Thanks to the complete openness of the CCF framework, like LEGO bricks, software engineers can easily enjoy the freedom of tailoring the control system framework that they want. It is hard for any company that provides an equipment control software framework program to implement such a rich library of functions. 

In the next few years, more and more factories will move in the direction of smart manufacturing. As a result, the demand for data is getting higher and higher. EDA standards are increasingly becoming the factory's mainstream data collection method. CCF will undoubtedly become the best weapon for equipment manufacturers to quickly and completely implement the various factory automation standards.

Topics: SEMI Standards, SECS/GEM, Semiconductor Industry, Equipment Control-Software Products, Equipment Automation Framework, Cimetrix Products

SECS/GEM series: Equipment Terminal Services

Posted by Derek Lindsey: Product Manager on Apr 19, 2018 10:27:00 AM

After several articles in the series discussing data collection, events, alarms, recipe management and documentation, this post focuses on the Twitter of the GEM standard – Equipment Terminal Services. We will examine what terminal services are, why they are needed and the mechanics of how they work.

What are Terminal Services?

Equipment Terminal Services allows the factory operators to exchange information with the host from their equipment workstations. The host can display information on the equipment’s display device. It also allows the operator of the equipment to send information to the host. The equipment must be capable of displaying information passed to it by the host for the operator’s attention. 

Why Do You Need This Feature?

An example of when terminal services might be used is as follows:

  1. The host gets notified by the FDC software that the process module had an excursion that needs to be addressed.
  2. The host turns on an operator notification light on the light tower. The notification light needs to be accompanied by a reason that the light was illuminated.
  3. The host sends a terminal message saying that the FDC software detected an excursion and that the operator should address the issue.
  4. Along with the signal tower light, the terminal services notification is active on the tool.
  5. The operator sees and acknowledges the message.
  6. Optional: There are different ways to recover, but the operator could send a terminal message to the host after the issue is resolved.

secsgem-terminalservices-1

How Does Terminal Services Functionality Work?

When the host sends a terminal message to the equipment, the equipment is required to display the message to the operator. The display must be able to show up to 160 characters (even more than can be sent in a single tweet using Twitter) but may display more than that. The equipment’s display device must have a mechanism for notifying the operator that a message was received and not yet recognized by the operator. The message continues to be displayed until the operator recognizes the message. The equipment must provide a method, such as a push button, for the operator to acknowledge the message. Message recognition by the operator results in a collection event that informs the host that the operator has received the information. The equipment application is not required to interpret the data sent from the host. It is solely information meant for the operator.

If the host sends a new message is sent before the operator acknowledges a previous message, the new message overwrites the previous message.

The host may clear unrecognized messages (including the indicator) by sending a zero-length message. The zero-length message is not considered an unrecognized message.

The equipment must also allow the operator to send information entered from the operator’s equipment console to the host. 

Which messages are used?

Message ID Direction Description
S10F3 H->E Host sends textual information to equipment for display to the operator on a terminal
S10F1 H<-E Operator sends text message to host
S10F5 H->E (Optional) Host sends multi-block display message. If multi-block is not supported, the equipment responds with an S10F7 message that multi-block is not allowed.
S6F11 H<-E Equipment sends collection event to the host notifying the host that it has recognized the message

 

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, SECS/GEM Series

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.

secsgem-documentation-1.png

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.

secsgem-documentation-2.png

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

secsgem-documentation-3.png

Collection Events

secsgem-documentation-4.png

Status Variables

secsgem-documentation-5.png

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.

secsgem-documentation-6.png

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:

SECS/GEM White Paper

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

SECS/GEM series: Recipe Management

Posted by Bill Grey: Distinguished Software Engineer on Feb 20, 2018 10:54:00 AM

recipe management SECS/GEMFollowing several SECS/GEM series blog posts, including Collection Events, Data Polling and Alarms, we now get into the features and merit of the GEM feature called Recipe Management. We will cover the definition of recipes, what recipe management means and why you need this feature!

What are recipes?

Recipes are sets of instructions describing how the equipment should process its material.  The Recipe content is defined by the equipment supplier.

What is recipe management?

Recipe management allows the factory host to transfer recipes to and from the equipment.   It also requires the equipment to notify the factory host when recipes are changed on the equipment.

Why do you need this feature?

Almost all semiconductor factories require this feature to ensure recipe integrity and to support traceability.   The host will upload approved recipes from the equipment and save them for later use to ensure that the recipe does not change.   For traceability, the recipe is usually saved with the process data.

How does recipe management work?

Recipes are passed between the host and equipment via SECS messages.   There are several sets of SECS messages to enable this.  E30 GEM specifies formatted, unformatted, and large recipe message sets.  The large recipe message set will not be discussed here. 

The equipment is also required to notify the host whenever recipes are changed by an operator at the equipment.  A PPChange collection event is generated with two data variables PPChangeName containing the PPID of the recipe that changed and PPChangeStatus containing the type of change (created, deleted, edited).

Once a recipe has been transferred to the equipment, the equipment should verify the content.  If the recipe is invalid, then a PPVerificationFailed collection event should be generated with a  PPError data variable containing the validation failure information to notify the host of the problem.  The recipe should not be used if it fails verification.

Identification

Each recipe is identified by an ASCII name called a process program ID or PPID.  The factory host and the equipment GEM interface use the name in recipe operations.

Persistence

Recipes are persisted in a GEM interface. If the host disconnects and reconnects, or if the equipment is restarted, the GEM interface will remember the recipes.   In addition, most factory hosts will save recipes on the factory side.

Which messages are used?

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

All Recipes

Message ID

Direction

Description

S7F17

Host -> Equipment

Delete a recipe from the equipment.  

An empty list will delete all recipes from the equipment.

S7F19

Host->Equipment

Request a list of available recipes from the equipment

 

Unformatted Recipes

Message ID

Direction

Description

S7F1

Host<-Equipment

Equipment requests to upload a recipe

S7F3

Host<-Equipment

Equipment uploads a recipe to the host

S7F5

Host<-Equipment

Equipment requests a recipe from the host

S7F1

Host->Equipment

Host requests to download a recipe

S7F3

Host->Equipment

Host downloads a recipe to the equipment

S7F5

Host->Equipment

Host requests a recipe from the equipment

 

Formatted Recipes

Message ID

Direction

Description

S7F1

Host<-Equipment

Equipment requests to upload a recipe

S7F23

Host<-Equipment

Equipment uploads a recipe to the host

S7F25

Host<-Equipment

Equipment requests a recipe from the host

S7F1

Host->Equipment

Host requests to download a recipe

S7F23

Host->Equipment

Host downloads a recipe to the equipment

S7F25

Host->Equipment

Host requests a recipe from the equipment

S7F29

Host<-Equipment

Equipment requests to verify a recipe

S7F27

Host<-Equipment

Equipment sends recipe verification results


Frequently Asked Questions about Recipe Management

How large a recipe can be transferred?

For unformatted recipe messages, the recipe is either a single ASCII string or a binary array value.  A single array value is limited to 16.777215 MB.

Formatted recipe messages, the recipe is split up into a list of items. A single array value is limited to 16.777215 MB.  Total message size is limited to 4.294967295 GB.

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, SECS/GEM Series

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:

on-off-switch.jpg

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

SECS/GEM series: GEM Factory Application Support

Posted by Alan Weber: Vice President, New Product Innovations on Jan 31, 2018 11:30:00 AM

What do the factories DO with all that data?

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

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

App_Support_1.png

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

 Factory Application  Equipment Data Required
OEE (Overall Equipment Effectiveness) Transition events and status codes sufficient to classify equipment states for all time periods
Intra-equipment material flow Material tracking events; material location state indicators and state change events
Process execution tracking Start/stop events for all processing modules; recipe step indicators and step change events for all processing modules that support multi-step recipes
WTW (wait time waste) analysis The combination of events required for the intra-equipment material flow and process execution tracking applications (see above) and context data required to classify material states for all time periods (see the SEMI E168 Product Time Management standard for a deeper explanation)
Time-based PM (Preventive Maintenance) Run timers at the FRU (field replaceable unit) level
Usage-based PM Usage parameters and accumulators appropriate for each FRU, such as time-in-state, execution cycles, fluid flow rates, consumables flow rates, power consumption, etc.
Condition-based PM  Meaningful “health indicators” for each FRU
FDC (Fault Detection and Classification) Equipment/process parameters required by specific fault models and associated context information (this is difficult to do completely because most FDC models are “trained” with knowledge of “good” and “bad” runs, which is not known to the equipment supplier a priori)
Automated equipment interdiction Remote stop command (e.g., issued by an FDC application sensing an existing or imminent fault)
Equipment configuration monitoring Vector of important equipment constants with expected values and acceptable ranges; may need to support multiple sets, if the values are setup-dependent. Designed to catch human errors resulting from operator manual adjustments
Component fingerprinting Performance parameters for key equipment mechanisms, including command/response signals at the sensor/actuator level
Static job scheduling Setup and execution times per product/recipe combination and current setup information
Real-time job dispatching Estimate of current job completion time; estimate of completion time for all material queued at the equipment
Factory cycle time optimization Material buffer contents, job queue information
Operator notification Notification codes for frequent operator actions in a non-/semi-automated environment, such as load/unload material, select/confirm recipe, provide manual “assist” if the equipment is stuck, etc.
Real-time dashboard Equipment/component production status indicators
Equipment failure analysis Meaningful alarm/fault codes and perhaps recent history/statistics
Run-to-run process control Identification of recipe adjustable parameters and commands to remotely update them 

 

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

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

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

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

SECS/GEM White Paper

Topics: SEMI Standards, SECS/GEM, SECS/GEM 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.

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:

SECS/GEM White Paper

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

SECS/GEM series: GEM Collection Events

Posted by Brian Rubow: Director of Solutions Engineering on Jan 10, 2018 11:12:00 AM

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

What are collection events? 

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

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

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

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

A little analogy

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

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

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

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

Why do you need this feature? 

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

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

How does the collection event notification work?

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

Basic Publish/Subscribe Notification

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

Event Report Publish/Subscribe Data Collection

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

Identification

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

Broker

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

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

Collection_Events1.png

Persistence

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

Which messages are used?

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

Message ID Direction Description
S2F37 Host -> Equipment Enable or disable reporting for a set of collection events.

An empty list will enable or disable the reporting for all collection events. Enabling all collection event reporting is useful when characterizing a GEM interface. Disabling all collection events is useful before enabling the reporting of desired collection events.
S2F33 Host -> Equipment Define one or more reports.

An empty list will delete all reports as well as the report links to collection events. Deleting all reports is a useful when resetting the subscriptions, or when connecting to a GEM interface for the first time to override default subscriptions.
S2F35 Host -> Equipment Link one or more reports to a set of collection events.

If reports are already linked to a collection event, you have to remove them and then link all collection events in one message. An empty list will remove report links from the collection event.
S1F23 Host -> Equipment Request the list of available collection events and the available data for each collection event. 
S6F11 Equipment -> Host The collection event message.

If no reports are linked, the message will only include the collection event ID number. If one or more reports are linked to the collection event, then the report data for each linked report will be included in the message.

 

Frequently Asked Questions about Collection Events

How much bandwidth do collection events require?

This depends on several factors. 

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

How fast can collection events be triggered?

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

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

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

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

Why aren’t I receiving the collection event messages? 

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

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

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

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

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

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

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

SECS/GEM White Paper

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