Industry News, Trends and Technology, and Standards Updates

What is a GEM Interface? What are some of the key features of the GEM SEMI Standard? What does the GEM standard have to do with Smart Manufacturing? Brian Rubow, the Cimetrix Director of Solutions Engineering, conducts a five-part video series that covers the complete GEM standard. In this Part One of the series, he covers some of the main questions that are often asked of manufacturing industries looking into GEM for the first time. 

Brian begins the video by answering the question, "What is a GEM Interface". He follows up by addressing the related SEMI standards, including SECS-II and HSMS. 

The GEM standard is feature complete.and includes the following:

• Event Notification
• Alarm Notification
• Data variable collection
• Recipe Management
• Remote Control
• Adjustment Settings
• Operator Interface

GEM is the proven and mature equipment communication standard used by the front-end semiconductor industry for a number of years and has been adopted by a number of other industries because of it's effectiveness. 

View the entire series today!

 

What is GEM Control State?

The GEM Control State is one of the fundamental E30 GEM requirements. It defines the level of cooperation between the host and equipment and specifies how the operator may interact at the different levels of host control.

In a semiconductor factory, the host or operator may be in control of equipment processing. Having both sides in control of the equipment at the same time poses problems. When one side is in control of the equipment, the other side should be limited in the operations it can perform. For example, if an operator pauses processing, the host should not be allowed to send commands to resume processing or to start a new job. The GEM Control State is provided to prevent these types of issues from occurring.

Figure 1: SEMI E30 GEM Control State Model

How does the Control State work?

The Control State provides three basic levels of control. Each level describes which operations may be performed by the host and equipment sides.

Remote

• The host may control the equipment to the fullest extent possible.
• The equipment may impose limits on the local operator’s ability to control the equipment, but this is not a requirement of the standard. The host must be capable of handling unexpected commands invoked by the operator at the equipment.
• GEM Remote Commands are used by the host to invoke commands on the equipment.

Local

• The operator may control the equipment to the full extent possible.
• The host has full access to information. The host can collect data using other GEM features such as collection events, traces, and status data collection.
• Limits are placed on how the host can affect equipment operations:
  • Remote commands that initiate processing (e.g. START) or cause physical movement are prohibited. During processing, remote commands that affect processing (STOP, ABORT, PAUSE, RESUME) are also prohibited.
  • Other remote commands that do not initiate processing, cause physical movement, or affect processing may be allowed.
  • During processing, the host is prohibited from modifying any equipment constants that affect that process.
  • Equipment constants that do not affect the currently running process may be changed.
  • All equipment constants are changeable when not processing.

Offline

• The operator has complete control of the equipment.
• The host has no control over equipment operations and very limited information gathering capabilities.
• The only messages that the equipment will accept from the host are:
  • Messages used to establish GEM communication (S1F13/F14).
  • Requests to activate Online Control State (S1F17), but only if the currently active state is Host Offline (transition #11 on the Control State Model).
  • S1F2 “Are You There Response” while the attempting to go Online.
• The only primary messages that the equipment may send to the host are:
  • Messages used to establish communications (S1F13).
  • S9Fx messages, but only in response to the messages to which the equipment will normally respond to while Offline (i.e., S1F13 and S1F17).
  • S1F1 “Are You There Request” is sent to the host when the “Attempt ON-LINE” sub-state is entered. This message is used to get permission from the host to transition into an Online state (transition #5).
• No messages are spooled while Offline.

The Control State Model was designed in a way to give the equipment operator more control over the state machine than the host.  This protects the operator from unexpected state changes initiated from the host.

• The equipment operator can choose which Online sub-state is active through the operator interface. The host side cannot choose which Online sub-state is active.
• The equipment side can put the Control State Model into an Equipment Offline state (transition #6). When in this state, the host cannot request to go Online.
• The host side can put the Control State into a Host Offline state (transition #10), but the equipment side could reject this request. When in the Host Offline state, the equipment side can always attempt to go Online by first transitioning into the Equipment Offline state (transition #12) followed by an attempt to go Online (transition #3).

Operator Interface Requirements

The equipment must provide a way of displaying the current Control State to let the operator know who is in control of the equipment.

The equipment must provide a momentary switch to initiate the transition to the Equipment Offline state, and another switch to attempt to go Online from the Equipment Offline state. This may be a hardware switch on the front panel, but is often implemented in software using button controls.

The equipment must provide a discrete two-position switch which the operator may use to indicate the desired Online sub-state (Local or Remote). This may be a hardware switch on the front panel, but is often implemented in software using button controls. If implemented in software, the setting must be saved in non-volatile storage.

Conditional State Transitions

In the Control State Model, transitions #1, #2, #4, and #7 are conditional state transitions. The equipment application must provide a way of configuring which state to transition into. Equipment constants may be used for these configuration settings.

Conditional transitions #1 and #2 determine the initial state of the Control State Model during startup. The configuration that controls these transitions can be set for one of the following states:

• Online
• Equipment Offline
• Attempt Online
• Host Offline

Conditional transition #4 is used to determine which state to transition into after an equipment attempt to go Online fails. The configuration can be set to one of the following states:

• Equipment Offline
• Host Offline

Conditional transition #7 is used to determine which Online sub-state (Local or Remote) should be active when the Control State becomes Online. The configuration can be set to one of the following Online sub-states:

• Local
• Remote

Which Messages are used for Control State?

Message ID	Direction	Description
S1F1	Host <- Equipment	This message is sent to the host when the equipment attempts to go Online (in the “Attempt ON-LINE” state). The host grants permission by sending the S1F2 reply message. The host can deny permission by sending S1F0 or allowing the message transaction to time out.
S1F15	Host -> Equipment	The host sends this message to request a transition from “Host Offline” to Online (transition #11).
S1F17	Host -> Equipment	The host sends this message to request a transition from Online to “Host Offline” (transition #10).

 

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

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

Even for someone who has been in this industry since the days of the TI Datamath 4-function calculator and the TMS1100 4-bit microcontroller (yes, that’s been a LONG time – the movie Grease premiered the same year!), it is sometimes hard to grasp the scope and complexity of what happens in today’s leading-edge semiconductor gigafabs. In fact, the only way to comprehend the enormous volume of transactions that occur is to consider what happens in a single minute – this is illustrated in the infographic we have labeled “The Gigafab Minute.”* 

In 1977, the classic movie "Close Encounters of the Third Kind" was released.  Towards the end of the movie, there is a dramatic "conversation" between the space aliens and the humans. One of the scientists makes the statement, "I hope someone is taking all this down."

What they really wanted was message logging!

Just like software logging is important for troubleshooting an application, logging the detailed message traffic between a factory host and the manufacturing equipment is just as important for troubleshooting.

For example, a host sends a command, and the equipment behaves based upon the message, but something does not work as expected.  It would be very helpful to see the message that was sent and the reply from the equipment, in conjunction with any other logs from the equipment to determine where the problem is located.

The format used to display/represent the logged messages is also very important. The latest industry standard for SECS message formatting is SEMI E173, the Specification for XML SECS-II Message Notation (SMN).

Here is an example:

<?xml version="1.0" encoding="utf-8"?>
<SECSMessageScenario xmlns="urn:semi-org:xsd.SMN">
                <Comment time="2018-02-05T18:19:20.365Z">State Change NotConnected</Comment>
                <Comment time="2018-02-05T18:19:20.400Z">State Change NotSelected</Comment>
                <HSMSMessage time="2018-02-05T18:19:20.394Z" sType="Select.req" direction="H to E" txid="1">
                                <Header>FFFF0000000100000001</Header>
                </HSMSMessage>
                <HSMSMessage time="2018-02-05T18:19:20.417Z" sType="Select.rsp" direction="E to H" txid="1">
                                <Header>FFFF0000000200000001</Header>
                                <Description>Communication Established</Description>
                </HSMSMessage>

Here is an S5,F5 example:

<SECSMessage s="5" f="5" direction="H to E" replyBit="true" txid="7" time="2018-02-05T18:19:20.507Z">
    <SECSData>
        <UI4 />
    </SECSData>
</SECSMessage>
<SECSMessage s="5" f="6" direction="E to H" replyBit="false" txid="7" time="2018-02-05T18:19:20.507Z">
    <SECSData>
        <LST>
            <LST>
                <BIN>0</BIN>
                <UI4>1</UI4>
                <ASC>Alarm 1 Text</ASC>
            </LST>
        </LST>
    </SECSData>
</SECSMessage> 

The SMN format is ideally suited for:

• Capturing the HSMS header information in a clear way
• Logging messages in an exact, binary format
• Reading the logs using software
• Creating a host or equipment emulator, since it is easy to read the logging from a software application and play it back.
• Extracting data from the SMN logs

The logs can be captured by the Equipment, Host, or even a "network sniffer" like Cimetrix's CIMSniffer utility.

Cimetrix’s Logviewer utility supports SMN logs as well:

With these standards and tools available, there's no reason to be like the scientist in Close Encounters, hoping that the messages were being logged.  Turn on logging!

Cimetrix's CIMConnect, HostConnect and SECSConnect all provide message logging in the SMN format.

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

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

Purpose of the Protocol Layer

The protocol layer packages data and reliably transfers it between the factory host and the equipment GEM interface.

Protocol Layer Definition

The protocol layer implements the transport technology and data packing algorithms used to send messages across a wire between a factory host and an equipment GEM interface.  

The SEMI E5 standard, SEMI Equipment Communications Standard 2 Message Content (SECS-II), defines  SECS messages that are used as the data and defines how they are packed into binary buffers for transport.

The SEMI E37 and E37.1 standards, High-Speed SECS Message Services (HSMS), define a protocol for exchanging SECS messages over a TCP/IP connection. This is the most used transport technology in SECS/GEM.

HSMS Protocol Stack

The SEMI E4 standard, SEMI Equipment Communications Standard 1 Message transfer (SECS-I), defines a mechanism for exchanging SECS messages over RS-232. This is normally used for older equipment or for some hardware inside an equipment such as an EFEM controller.

The rest of the document will focus on SECS messages over HSMS.

Protocol Layer Benefits

The protocol layer in GEM maintains the connection and detects a loss of connection so either party may take appropriate action such as activating Spooling. 

The protocol layer defines handshaking mechanisms to ensure delivery of messages if desired. 

The protocol layer connection is point-to-point between the factory host and equipment. It is a dedicated connection with no broadcast capabilities. This makes it easier to predict network loading.

Data Density

SECS/GEM transmits data with little overhead and high density. This means less network bandwidth usage for a given data set.  

For illustrative purposes, let us look at a typical example of an event report and compare SECS/GEM messaging to a somewhat equivalent XML and JSON message.

Take a typical GEM interface that uses unsigned 4-byte integers for IDs and an event report containing 8-byte floating point numbers and 4-byte integers. An example of this message is shown in the table below in a SECS/GEM format per E5 and in equivalent JSON and XML formats.

 

The binary SECS/GEM message will take 58 bytes over the wire, the JSON around 206 bytes and XML 175.  The JSON and XML numbers can change a bit based on key/element names and the above is just one of many possible representations.

A chart showing the data density comparison for the example message is shown below.  The Actual Data size is 2 4-byte integers + 2 8-byte floating point numbers + 1 4-byte event id + 1 4-byte report id = 32 bytes of actual data.  The overhead is calculated by subtracting the actual data size from the total number of bytes for the message.

For the example message the data density for SECS the data density percentages are shown in the graph below.  Data density percentage is calculated by the (actual data) / overhead *100.

Now if we change the example message to have 100 8-byte floating point numbers in it, the Data Density % graph changes to the chart below. Notice the JSON and XML are relatively the same, but the SECS/GEM data density increases to 78%.

SECS/GEM encoding has very little overhead.  The overhead for a message is 10 bytes for a header describing the message, plus 1 to 4 bytes for the size of the message body.  For any 4-byte integer or floating-point number in a SECS message, 6 bytes will be sent across the wire, 4 bytes for the integer value + 1 for the type + 1 for the length in bytes of the data.  Likewise, for any 8-byte integer or floating-point number, 10 bytes will be sent. For a string value, the length will be the number of characters plus 2 to 4 bytes. Any time a List (L in the readable example above) appears in a SECS message, 2 to 4 bytes will be added to the message.  

Arrays of numbers are brutally efficient in SECS/GEM. The overhead for an array is 1 byte for the type plus 1 to 4 bytes for the length of the array, plus the data in its native size. For example: an array of 10 4-byte integers would take 42 bytes, that is a data density of 95%! 

In the JSON example, a 4-byte integer requires 16 bytes + the number of characters needed to represent the integer, so 17 to 28 bytes. Floating point numbers are the same overhead, but probably requiring more characters to represent the value.

In XML, the overhead is based on the sizes of the XML element names.  Using the element names in the example above, for any 4 -byte integer the number of bytes across the wire will be 9 + number of characters needed to represent the integer, so 10 to 21 bytes. Floating point numbers are at the mercy of the string formatting used to represent the values. 

In summary, looking at the per-item byte size across the wire, SECS/GEM is very dense.  Take the 4-byte integer example where SECS/GEM is 6 bytes across the wire, the JSON example is 17 to 28 and the XML example is 10 to 21 bytes and you see as you scale the number of parameters the overhead really matters.  300mm Semiconductor equipment are expected to transfer 1000 parameters per second per process module to the host.  For a 2-module equipment, this results in the following number of bytes just for the data: 12K bytes/ over SECS/GEM, 34K-56K for JSON, and 20K-42K for the XML example. These numbers do not account for size of the rest of the message, just the actual parts related to parameter values. If that data is transferred in lots of messages with few values per message, then the network load is even worse. Fewer, larger messages are always better in all cases.

XML and JSON may also add to the overhead depending on the transmission protocol used.  For example, XML is often transmitted over HTTP using SOAP, this adds two additional layers of overhead and more bytes going across the wire for each message.The numbers of bytes shown for SECS/GEM are what is transmitted across the wire on top of TCP/IP. 

No Data Translation

Numeric data is transmitted with no translation in SECS/GEM.  Numbers are transmitted in their native format.  For example: an 8-byte floating point number is transmitted in its 8-byte representation without any conversion, truncation, or rounding. 

Any protocol such as JSON or XML must convert those 8-byte floating point numbers into a text representation.  This takes computing resources for the encoding and decoding and significantly more bytes across the wire. IEEE754 requires 17 decimal digits to accurately represent an 8-byte floating point number as a string. Adding in characters for sign, decimal point, exponent and exponent sign leads to 21 characters. That is over twice what SECS/GEM sends across the wire.

Circuit Assurance

HSMS defines a circuit assurance mechanism called Link Test.  The protocol layer has a timer that is started if there are no active message exchanges. Every time the timer expires, a protocol message is exchanged to ensure the connection is still open.  

Security

HSMS defines no security.  There is no validation of the connecting party, no credentials or certificate is required to connect. The data is not encrypted by any normal encryption algorithms; however, data is obfuscated through the data packaging process and is not generally human readable. 

Security is not normally seen as an issue since factory networks are isolated from the outside world.

Conclusion

The SECS/GEM Protocol Layer using HSMS provides a very efficient means of exchanging accurate data between the factory host and equipment. 

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

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

Purpose of Spooling Messages

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:

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:

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，E5，E30，E37，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 Framework^TM (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标准。

采用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 CIMControlFramework^TM (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.

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.

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.

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:

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: