Support Login
Taiwan translated pages

Semiconductor Industry News, Trends, and Technology, and SEMI Standards Updates

Implementing GEM on your Manufacturing Equipment

Fuji SMT machine 3.jpgAs an OEM, implementing GEM on your equipment can seem like a daunting task. However, as GEM gains popularity in your industry, your customers may start requiring your equipment to be “GEM Compliant”.

So, what does it take to implement GEM on your equipment and become “GEM Compliant”? To answer this question, let’s first understand GEM.

Officially titled the “Generic Model for Communication and Control of Manufacturing Equipment,” GEM is a SEMI standard (E30), which defines standard methods to communicate with host software for monitoring and/or controlling purposes. Essentially, GEM provides a common language for a host system to communicate with the various equipment in a factory. 

Next, let’s understand why customers are demanding your equipment to be GEM Compliant.

As industry trends such as Industry 4.0, Smart Factory, and Big Data drive data exchange and process automation in manufacturing, factories desire to connect each machine to their network for data collection and control. Essentially, factory equipment is added to the “Internet of Things” – also called IIOT - Industrial Internet of Things.  

GEM is a powerful enabler for factories to implement these industry trends. A factory no longer needs to develop disparate/custom interfaces to communicate with different equipment types. A factory can develop common applications to communicate to all equipment via a single common GEM protocol. Originally, GEM was widely adopted in the Semiconductor Front End industry followed later by the Photovoltaic and LED industries. Recently the PCB industry selected GEM as their standard. And GEM is quickly gaining adoption in other electronics industries such as Semiconductor Back End, Flat Panel Display, and Surface Mount Technology.

By connecting GEM equipment, factories can immediately experience operational benefits. Examples of such benefits are:…

  • Ensure recipe (aka process program) correctness and track when recipes are changed/revised
  • Monitor equipment performance to calculate Overall Equipment Effectiveness (OEE) metrics
  • Gather real-time data variables to implement Statistical Process Control (SPC) for key processes
  • Broadcast equipment alarms to immediately notify personnel when equipment requires assistance
  • Collect equipment parameters to drive preventative maintenance plans

Now that we understand GEM, we can explain the term “GEM Compliance”.

GEM Compliance is defined in the SEMI E30 GEM standard. To be “GEM Compliant” means your equipment implements a specific set of capabilities called “Fundamental GEM Requirements”. Your equipment may also implement optional features called “Additional Capabilities”. The SEMI E30 standard provides a list of all GEM features, as listed below.

gem compliance.png
Per Table 11 Section 8.4.3. of the document "SEMI E30-0307E2"

So, how do you become “GEM Compliant”?

As mentioned above, to be GEM compliant, the equipment must implement the eight capabilities listed under Fundamental GEM Requirements. If one of the fundamental capabilities is not implemented, then you cannot say the equipment is GEM compliant.  However, each capability listed under Additional Capabilities is optional. Implementing GEM also means implementing the other SEMI standards that GEM is based on including: E4 (SECS-I), E5 (SECS-II)E37(HSMS), E37.1 (HSMS-SS). In addition, depending on your industry, there may be additional standard to adhere to.

All-in-all, there are 100’s of standards pages filled with requirements and implementation information. Reading and implementing all the requirements defined in those standards may require extensive time. However, toolkits such as our CIMConnectTM product greatly reduce the number of people and time needed to implement a fully GEM compliant interface.

A simple GEM interface that only implements the Fundamental capabilities can be completed relatively quickly. However, a toolkit like CIMConnect enables a small team of one or two people to implement a fundamental interface in even less time. CIMConnect reduces time by implementing the GEM features that are common to all equipment, and providing API to implement the capabilities unique to your equipment. Toolkits also provide several utilities to help become GEM compliant. For example, one of the fundamental GEM requirements is to provide a GEM interface manual with each equipment. CIMConnect provides a template and a documentation builder to help create your manual. These tools reduce the time to create a GEM interface manual from weeks to hours. With products like CIMConnect, a more complex GEM interface can be implemented in just a couple weeks.

Whether you use CIMConnect or an in-house solution, the process for developing a GEM interface is roughly the same:

  • Define and Document GEM interface
  • Implement GEM interface
  • Test GEM interface
  • Customer accepts GEM interface

Defining and documenting the GEM interface of the equipment should be first because it helps to reduce feature creep, keep the project on course, and ensure the project is completed on time. Implementing the GEM interface is often the largest part of the process. Since no two equipment are alike, programming is required to customize the GEM interface for your equipment. It is common to test the GEM interface as each feature is implemented. Testing ensures your GEM implementation is compliant with the GEM standard and is defect free. Some use a completely manual testing process that can take weeks, but we recommend creating automated tests that can be built with our Cimetrix HostConnectTM product. Automated testing allows defects to be detected and fixed quickly; preventing unexpected development costs down the line. Once you believe your interface is free of defects, it’s time to get acceptance from your customer.

To ensure continued success, it is important for your GEM product supplier to provide training and on-going product support. Proper training and support from your GEM supplier allows you to provide continuous support to your customers.

Congratulations – you are on your way to being able to make your equipment “GEM Compliant”.  You can successfully meet your customers’ requirements while keeping your team’s resources on their core competency. 

Topics: SECS/GEM, GEM Interface

CCF Provides Fully Implemented GEM300 and EDA Interfaces

Posted by Bill Grey: Distinguished Software Engineer on Feb 15, 2017 1:00:00 PM

What does this mean and why should I care?

The SEMI standards for 300mm Semiconductor Manufacturing Equipment can be an overwhelming burden of information to understand, let alone implement.

The GEM standards comprise over 450 pages of documentation: E4, E5, E30, E37, E37.1, E172, E173.

The 300mm standards add another 280 pages: E39, E40, E87, E90, E94, E116, E157, E148.

And the EDA standards pile on an additional 480 pages: E120, E125, E128, E132, E134, E138, E164.

That’s over 1200 pages of standards documents filled with requirements and implementation information. 

On top of that GEM and EDA collect data differently from the equipment.  See a post we did on data collection for more information on those differences.

Implementing the requirements defined in those standards without an SDK would be a very brave undertaking.  Even with SDKs for the standards, it would be a fair amount of work, when all you really want to do is get your equipment automated.

In addition, it is very important that those standards be implemented correctly in order for your equipment to be smoothly integrated and accepted into each fab.  Different fabs use the standards slightly differently or have additional requirements.   This requires experience.

GEM300 and EDA standards implementation is a very large burden.

semi standards difficult burden

So what does this mean?

One of the large tasks for the EDA standards is defining a hierarchical model of the equipment and what data it can produce in XML per the schemas defined in the standards.   Creating the initial model and keeping it up to date as the equipment evolves is a tedious task.  In addition, that model must be conformant to the E164 standard (which has over 10 pages of requirements on its own).   See our blog post on conformance testing. CCF does this for you, producing an E164 compliant EDA model in the background based on your CCF programming. See our blog post on CCF dynamic model creation further details.  CCF also builds the GEM interface model for you at the same time.

Further, CCF is completely GEM compliant and 300mm compliant, using the Cimetrix CIMConnect and CIM300 products which have been successfully deployed in every 300mm fab around the world on many different equipment types.

Twelve hundred pages of standards, compliantly implemented, at no additional effort.  That is what this means.

Turn that donkey into a goat and use CCF.



Topics: SECS/GEM, EDA, CIMControlFramework, GEM Interface

Leveraging GEM

Posted by David Francis: Director of Product Management on Nov 28, 2016 11:30:00 AM

One of my favorite gifts when I was a kid was an erector set. I could build all kinds of machines and robots. The set I had even included a simple motor, so I could make things move. I spent a lot of hours building machines and robots and dreaming of doing that on a bigger scale.

When I graduated from college I worked for a small company that did warehouse automation and automated transport control systems. It took me back to when I was a boy building robots with my erector set. Except these robots could actually move things and had a full set of commands to control them, not just on or off. The company I worked for had a small group that did firmware programming for the robotic controllers. I worked in the software group that wrote the software systems for controlling the whole automated warehouse. I soon learned that each type of automated equipment had its unique set of commands and that just because two pieces of equipment might perform the same function, didn’t mean they used the same commands.

Along the way I had the opportunity to work with Motorola to develop cell controllers for one of their new, state-of-the-art fabrication facilities in Austin, Texas. This opened up a new world of automation for me. The SEMI Equipment Communication Standards (SECS) were fairly new and still trying to gain wide acceptance. There were a lot of similarities to the automated material handling equipment I had been working with. Each piece of equipment had a defined set of SECS messages it supported, but each tool had to be carefully characterized in order to know how to create the cell control application that would interface with it. It was exciting to bring new tools on line and see the benefits in reduced scrap and improved throughput. But it took a lot of time to develop the cell controllers and there wasn’t much code that could be reused from one to the next.

During this time, I had the opportunity to attend some SEMI standards meetings and participate in discussions about the development of a Generic Equipment Model (GEM) to achieve more consistency across different companies’ SECS interface implementations. It made so much sense! I had built a good business doing equipment characterizations for semiconductor manufacturing companies, but it seemed like there should be a better way of interfacing with the equipment – a more standard way. As the adoption of GEM grew in the semiconductor manufacturing industry, the cost of developing equipment cell control applications decreased. Much of the code could be used across different pieces of equipment, because there was a standard for interfacing with all equipment.

While GEM was developed by and for the semiconductor industry, it could also benefit many other industries. GEM provides a standard way to control a factory and gather equipment and process data that can be used to measure and monitor Overall Equipment Effectiveness (OEE), implement Statistical Process Control (SPC), manage material queues and WIP levels, and a wide range of additional factory applications. Several parallel markets (PV, LED) have adopted the GEM standard to take advantage of commonality required by the standard. Other markets would also benefit by adopting the GEM standard to help increase software reuse and productivity


Topics: SECS/GEM

News You Can Use in SEMI Command and Control Standards, Part 2

Posted by Brian Rubow and Alan Weber on May 31, 2016 1:00:00 PM

 172SEMI.pngIn a previous blog we mentioned that two new SEMI standards, E172 and E173, demonstrated that the GEM standard was alive and well and even gaining new momentum by evolving to adopt new technology. The earlier blog focused on E172 with its SEDD files that use an XML schema to describe what is in a GEM interface. Today’s blog is about the E173 Specification for XML SECS-II Message Notation: a new way to log and document GEM/SECS messages, again using an XML schema.

A few years ago Cimetrix was involved in a project prototyping Wait Time Waste concepts and implementation alternatives. This work required Cimetrix engineers to review and extract data from many different SECS-II message log files from a variety of sources, and in the process, exposed a serious weakness in the industry. Because there was no standardized notation for logging SECS-II messages, everyone represented them differently, using different nuances and variations in their notation based loosely on SML (SECS Message Language, which is mentioned in the GEM standard). Additionally, SML itself was designed primarily for human readability, and certainly not for consumption by software programs; moreover, you can’t analyze a long message log without software to do the parsing for you. As a consequence, writing software to review the log files and to extract meaningful data from the log files was far more difficult than it should have been – SML and SML-like notations are simply not suitable for today’s needs. But now there is a suitable, industry-standard alternative. 

At Cimetrix we have utilized various notations for logging SECS-II messages for many years. In order for any notation to be useful it must meet certain criteria. First of all, it has to be easy for software to write (serialize). Secondly, it also needs to be easy for software to read (deserialize). And finally, it should be easy for humans to read and understand.

The original technique we used many years ago was based on the scripting language Tcl (pronounced “tickle”), which uses curly braces as structural delimiters. When programming within the Tcl language, this works very well. In other programming languages, however, it is easy to serialize, but not so easy to deserialize. Another technique Cimetrix had used for a few years was based on XML, which is well supported by all modern programming languages and an integral part of most internet activity. It is very easy to serialize and deserialize. And when formatted with carriage returns and indentation, it is quite easy to read for most humans (at least the ones who are software programmers or web page gurus).

Here is a subjective comparison between the notation alternatives using a scale of 1 to 5 where 5 is excellent and 1 is very poor or difficult.


At Cimetrix we decided to leverage our experience with XML, SECS/GEM standards and the SEMI Standards organization and related communities to develop a notation that everyone in the industry could benefit from. The result was this new standard: SMN. It is comprised of two parts: an XML schema defined specifically for GEM/SECS messaging; and a specification document describing how to use it (although many details of the specification are embedded as annotations within the XML schema file itself). It looks like this:


The schema is found on the SEMI website:

SMN brings the representation of SECS messages into the Internet era by defining an open, standard, XML-based notation for these messages. So what can you do with this? Here are some ideas:

  • Document individual SECS/GEM messages (the SEMI E172 SEDD file uses SMN for this). You can also document entire message scenarios.

  • Log individual SECS/GEM messages or scenarios in XML format. These can include only the messages, or might also include protocol messages (like the HSMS separate message).

  • Share message logs with others. If their software supports SMN, they can immediately make use of it. This should increase collaboration in the manufacturing community, particularly between equipment suppliers and their customers.

  • Embellish log files with comments and meaningful metadata, like data item names, variable names, collection event names, etc.

  • Analyze and extract information from log files offline for projects like Wait Time Waste, where you don’t need to process a live data stream.

  • Log messages in a raw binary format to save disk space, yet encapsulated in XML for convenience.

  • Many of the numerous XML tools in the software development community can now be used by SECS/GEM software developers. This opens up a world of opportunities.

  • Products like our CIMConnect and CIM300 can make use of SMN to make it easier to implement GEM and GEM300 interfaces on the equipment by using the SECSData element from SMN to pass data from the equipment supplier’s software into our product.

It is exciting to see the GEM standard evolve and embrace new technologies like XML to make integrating manufacturing equipment into the factories easier and easier.

For more information about these latest standards, and how you can incorporate them into your interface implementation, please contact us.

Topics: SEMI Standards, SECS/GEM, SEMI

CIMConnect: Making GEM Implementation Simple for Any Industry Using Automated Manufacturing Equipment

Posted by Brian Rubow: Director of Client Training and Support on May 26, 2016 1:00:00 PM


Interest in SEMI standard E30, known as the GEM standard has grown in recent years. That interest has increased in various manufacturing industries has matured in which factories are seeking to increase automation and carefully monitor equipment activity in order to increase production and product quality. Initially, the GEM standard targeted just the semiconductor industry, but then expanded to include any industry that used manufacturing equipment. In fact, a number of years ago the name of the GEM Standard changed from the “Generic Model for Communication and Control of Semiconductor Equipment” to “Generic Model for Communication and Control of Manufacturing Equipment.” Adoption by other industries is possible because the GEM standard defines generic features to control and monitor any manufacturing equipment. The GEM standard technology is not limited to semiconductor manufacturing. Over time, other industries have taken notice, especially as they try to develop increased control over their equipment.

CIMConnect™ is the best software product on the market for implementing the GEM standard. Of course CIMConnect supports all of the required GEM features as well as additional capabilities. This even includes excellent support of the Spooling feature, which saves messages that are otherwise dropped during a loss of communication. Early implementations of the GEM standard by others gave the GEM standard’s Spooling feature a bad reputation. This reputation is undeserved when Spooling is implemented by a robust product like CIMConnect. In CIMConnect, not only does Spooling work; it works well. It has been proven by customers that CIMConnect’s Spooling implementation does not lose any messages—even while under high-stress conditions. This means that when using CIMConnect, the Spooling feature can be used to effectively preserve critical data from the equipment.

Another feature that makes CIMConnect the best GEM software product is the CIMConnect Control Panel. In the new CIMConnect release, this application was completely rewritten, redesigned in .NET,  giving it a modern look and feel while adding lots of new convenient functionality. With other GEM products, the GEM interface is essentially a black box. With CIMConnect, however, the Control Panel application gives full visibility into the GEM interface. And you can run it at any time during GEM interface development and also during production. This means that you can see what reports and traces are defined, the link between reports and events, the status of all state machines, the state of each alarm, the enable status of every event, the history of occurring collection events, the history of alarm state changes and the current values of all data variables, and status variables and equipment constants. You can also view and capture the SECS-II message logging at any time for scenario diagnostics. Additionally, the CIMConnect Control Panel provides features to simulate the occurrence of collection events, collection event data, alarms, and variable data; thereby making it a built-in simulator included requiring no additional effort. And when you are ready to update your GEM documentation appendix with the list of defined collection events, alarms, status variables, data variables, and equipment constants, use the documentation builder feature.

CIMConnect has also already adopted use of new SEMI standard E173 Specification for XML SECS-II Message Notation (SMN). CIMConnect allows software applications to use SMN notation both when providing variable values to CIMConnect, as well as when getting variable values from CIMConnect. This means that you can pass data around in XML, retaining the data type and data structure information; bringing the convenience of XML into the SECS/GEM technology. You can log the GEM communication messages using SMN format making log messages much more useful, and they are able to be easily deserialized by any software applications that has XML libraries.

For additional detailed information about CIMConnect or to request a product demonstration, please contact us.

Topics: SECS/GEM, SEMI, CIMConnect

News You Can Use in SEMI Command and Control Standards

Posted by Brian Rubow and Alan Weber on May 24, 2016 1:00:00 PM


As the SEMI GEM standard celebrates its 25th birthday, you may have thought its evolution had just about run its course — but you’d be wrong. Last year, the Information and Control Committee of SEMI Standards passed two new standards that enhance the usability of the entire SECS/GEM suite of standards for equipment suppliers and semiconductor manufacturers alike: E172 SEDD and E173 SMN.

Let us talk about the first of these, the E172 Specification for the SECS Equipment Data Dictionary (SEDD) and postpone E173 Specification for XML SECS-II Message Notation (SMN) discussion for another blog. SEDD standardizes the approach for documenting an equipment’s GEM interface in a way that is both human- and computer-readable. All factories in every industry that use GEM require their equipment suppliers to provide GEM interface documentation in some electronic form for each type of equipment. This is because the GEM interface on every equipment type is unique, supporting unique features and publishing a unique set of data. Of course, the GEM standard itself requires documentation and what has to be in the documentation but does not specify how this is to be accomplished. Until now there has been no common approach or format. This has always left the equipment suppliers to come up with their own format. At best this might be in a multiple-tabbed Excel spreadsheet or a PDF file; and at worst a text document that might or might not have been accurate or even complete. And every equipment supplier completes the documentation in a different structure and style so that no two GEM documents look the same. In summary, everyone is trying to complete this GEM and factory requirement by providing documentation, but in the end what factories are receiving has to be consumed and digested differently based on the equipment supplier, and sometimes even based on the specific equipment type from the same equipment supplier. It is a lot of work for the factory just to understand exactly what is in each GEM interface.

SEDD was created to solve this problem by defining a standard XML schema for documenting a GEM interface. Equipment suppliers create an XML file that complies with the SEDD XML schema to document the GEM interface and then deliver this XML file (called an SEDD file) to the factory.

Why XML? Because XML is the perfect technology for organizing data into a uniform structure that is well supported by modern programming languages. This means that equipment suppliers can use a software program to generate the SEDD file. It also means that factories can write software to read and view the SEDD file. Moreover, they can create intelligent host applications that automatically configure themselves and adapt to a specific GEM interface.

So what’s in an SEDD file? Below is a visual representation of the SEDD file schema, identifying the major elements of the SEDD file.

172Picture1.pngSo essentially the SEDD file includes a list of the data available for collection by a host, some general information about the equipment (in the header), and the format of the data variables, status variables and equipment constants. As an example of what details are included, here are the details for collection events.

As an example, for a collection event, the SEDD file includes a list of all collection events available, and the ID, name, description, related SEMI standard, and the list of related data variables and other variables for that collection event. This is everything you need to use a collection event.


So far this is a summary of what is available today in a SEDD file. Cimetrix is leading the GEM300 task to extend the SEDD file to include additional information. This work is in SEMI ballot 5872 that proposes to extend the SEDD file to also include:

  • A list of supported SECS-II messages and the acceptable format for each message (using E172 SMN)

  • A list of support remote commands and available parameters for each remote command

  • A list compliance tables for supported SEMI standards

  • The list of predefined event reports

This is all work that was postponed from the original SEDD standard development. Hopefully ballot 5872 will pass and make SEDD files even more useful. With this additional information an SEDD file would empower GEM host software to configure itself to fully communicate with a GEM interface and make all of the features in the GEM interface available.

This is one example of how GEM technology just keeps getting better. It is not surprising that GEM is getting used in more and more industries.

For more information about this latest standard, and how you can incorporate it into your interface implementation, please contact us.

Topics: SEMI Standards, SECS/GEM, SEMI

Connecting GEM-Based Equipment to PLCs

Posted by Cimetrix on Nov 10, 2014 4:17:00 PM

The Cimetrix open source GEMBridge solution is now updated to use with Kepware Technologies KEPServerEX OPC platform. Cimetrix customers using CIMConnect and CIM300 can use GEMBridge to connect their PLC-controlled equipment to SECS/GEM and GEM 300 interfaces using an OPC-compliant interface.

Cimetrix announced this solution last week in a press release. With this solution, OEMs can send messages to and from programmable logic controllers to enable complete equipment control throughout the system. 

Kepware’s KEPServerEX is a flexible and scalable solution for connecting, managing, monitoring, and controlling diverse automation devices and software applications. Communications is managed through a robust platform that supports an array of open standards such as OPC, propriety communication protocols, API's, and various automation systems' interfaces. KEPServerEX enables improved operations and decision making throughout all levels of an organization.

Kepware CIMConnect resized 600

KEPServerEX provides the ability to consolidate data and information from various sources. This not only ensures consistency and reliability, but also reduces the number of Third-Party communication servers from which the end application must gather data. Furthermore, having a single source gather data for client applications reduces network traffic, device and system resource usage, and data inconsistencies. Instead, it provides a manageable and scalable platform for automation communications.

For more information, contact Cimetrix at

Topics: SECS/GEM, CIM300, CIMConnect

New SEMI Standards Automation Technology Committee Formed

Posted by Cimetrix on Oct 15, 2014 11:36:00 AM

James Amano of SEMI, in the October 2014 SEMI Standards Watch, announced a new Automation Technology Committee whose mission is to bring together automation standards for the semiconductor, PV, HB-LED, and other related industries. The first chapters will be in Europe and Japan.

The new committee replaces the PV Automation Committee. That committee developed standards based upon the SECS/GEM standards were used by the photovoltaic equipment industry. Interestingly enough, programmable logic controller (PLC) manufacturers are now considering using those standards because they are general enough to support flow-oriented manufacturing in other industries.

Fab System Host 1 resized 600

Previously, different industry segments such as PV, FPD, and HB-LED addressed their automation requirements in separate committees. Now, the new committee will combine interests and resources into a single group.

To read the article by James Amano, go to:

Topics: SEMI Standards, PV2 Standard, SECS/GEM

EDA/Interface A versus SECS/GEM SEMI Standards

Posted by Cimetrix on Oct 13, 2014 4:11:00 PM

With the growing interest in the use of SEMI EDA/Interface A standards, we have been getting a great deal of requests for the difference between Interface A and SECS/GEM. As a result, we thought we would re-post the blog written by Bill Grey back in 2009. You can read that entry here: Take a look at Bill's excellent blog post and download the whitepapers if you would like more information.

For a quick comparison, here is a table to showing some of the differences between Interface A and SECS/GEM:

EDA/Interface A versus SECS/GEM 

EDA/Interface A






Can be configured for SSL-secured communications

HSMS is not secure

Equipment Model

You can upload a description of the logical structure of the equipment which includes parameters, events, and exceptions assigned to modules, subsystems, and I/O devices

Equipment information is found in a manual provided with the equipment, but often without the necessary context


Start & stop triggers that may include one or more events and/or exceptions  Traces begin via a SECS message and end when a specified number of samples are collected

Event Reports

Specify an event and an optional set of parameters to be collected when that event occurs

GEM host defines collections of parameters called reports, then links one or more reports to one or more events. The same report may be linked to multiple events if needed.

Data Collection Reports

E134 allows data collection to be throttled if data collection is reducing equipment performance below a specified level

GEM does not throttle back data collection


Additional Resources:

Topics: Equipment Data Acquisition, SEMI Standards, SECS/GEM, Interface A

Implementing GEM and PV2 – what you should know

Posted by Cimetrix on May 4, 2012 10:08:00 AM

by Rob Schreck
Marketing Manager

As we gear up for SEMICON West, we are encouraged by some good news in the industry after enduring the bleak news of autumn and winter. SEMI reports the North American semiconductor capital equipment industry book-to-bill was over 1.0 in February and March of this year (see Semiconductor Equipment Industry Book-to-Bill), and the PV equipment book-to-bill ratio is starting back up (see PV Manufacturing Equipment Book-to-Bill Increases from Record Low). With the good news comes more companies developing new equipment, drawing more attention to SEMI standards such as SECS/GEM and PV2 (PVECI).

Understanding the SEMI SECS/GEM and PV2 standards, and the impact to their product roadmaps, might seem a little daunting for many equipment suppliers. We have updated a white paper to provide some background, called Introduction to the SEMI Standards: Implementing GEM and PV2.

This paper highlights key elements and issues associated with GEM software projects to help guide users toward a successful implementation.

A GEM (E30) interface is implemented by the equipment manufacturer to enable the equipment and factory software (a.k.a. “host”) to communicate using SECS-II (E5) messages via Ethernet.

 GEM Factory Host Interface resized 600

GEM standard compliance consists of fundamental requirements and additional capabilities, and compliance is only required for the equipment interface, not for the factory host software. Companies scale the GEM standard implementations to match the complexity of the equipment and the needs of the factory host software.

The GEM fundamental requirements include establishing communication with the factory host software, implementing a processing state machine, event notification, protocol error messages, and a GEM implementation document. Here is an example of such a document, and you can find a GEM compliance check list at Are You GEM Compliant?





State Models

□ Yes         □ No

□ Yes (see #1)

□ No

Equipment Processing States

□ Yes         □No

Host-Initiated S1,F13/F14 Scenario

□Yes          □No

Event Notification

□ Yes         □No

On-Line Identification

□ Yes         □ No

Error Messages

□ Yes         □ No


□ Yes         □ No

Control (Operator Initiated)

□ Yes         □ No




Establish Communications

□ Yes         □ No

□ Yes         □ No

Dynamic Event Report Configuration

□ Yes         □ No

□ Yes         □ No

Variable Data Collection

□ Yes         □ No

□ Yes         □ No

Trace Data Collection

□ Yes         □ No

□ Yes         □ No

Status Data Collection

□ Yes         □ No

□ Yes         □ No

Alarm Management

□ Yes         □ No

□ Yes         □ No

Remote Control

□ Yes         □ No

□ Yes         □ No

Equipment Constants

□ Yes         □ No

□ Yes         □ No

Process Recipe Management

□ Yes         □ No

Process Programs:  □ Yes         □ No

E42 Recipes:            □ Yes          □ No

E139 Recipes:          □ Yes          □ No

Material Movement

□ Yes         □ No

□ Yes         □ No

Equipment Terminal Services

□ Yes         □ No

□ Yes         □ No


□ Yes         □ No

□ Yes         □ No

Limits Monitoring

□ Yes         □ No

□ Yes         □ No


□ Yes         □ No

□ Yes         □ No

Control (Host-Initiated)

□ Yes         □ No

□ Yes         □ No

GEM Compliance Statement

Much like how the GEM standard is a subset of the SECS-II standard with additional required features, the PV2 standard is a subset of the GEM standard with additional required features, which include:

  • The required format to use for data items in the SECS-II messages
  • A specific list of variables, equipment constants, and collection events
  • A subset of SECS-II messages
  • An implementation of SEMI E10 to report equipment states related to reliability, availability, and maintainability (RAM)
  • An implementation of the Network Time Protocol (NTP)
  • A statement of PV2 compliance

These PV2 requirements should make PV2-compliant equipment even easier than GEM to integrate with the factory host software.

Download the paper and let us know what you think.

Topics: SEMI Standards, PV2 Standard, SECS/GEM

Subscribe to Email Updates

Follow Me

Learn More About the
SEMI Standards


GEM 300

Interface A/EDA