Industry News, Trends and Technology, and Standards Updates

The old adage “You get what you pay for” doesn’t fully apply to equipment automation interfaces… more accurately, you get what you require, and then what you pay for!

This is especially true when considering the range of capability that may be provided with an equipment supplier’s implementation of the EDA (Equipment Data Acquisition, also known as Interface A) standards. Not only is it possible to be fully compliant with the standard while delivering an equipment metadata model that contains very little useful information, the standards themselves are also silent on the topics of Performance and Data Quality.  So you must take extra care to state these requirements and expectations in your purchase specifications if you expect the resulting interface to support the demands of your factory’s data analysis and control applications. Moreover, to the extent these requirements can be tested, you should describe the test methods and tools that you will use in the acceptance process to minimize the chance of ugly surprises when the equipment is delivered.

We have covered the importance of and process for creating robust purchase specifications in a previous posting. This post will focus specifically on aspects of Performance and Data Quality within that context.

Scope of Performance and Data Quality Requirements

From a scope standpoint, Performance and Data Quality requirements are found in a number of sections in an automation specification. The list below is just a starting point suitable for any advanced wafer fab – your needs may extend and exceed these significantly.

Here are some sample requirements that pertain to the computing platform for the EDA interface software:

• The interface computer should have the capability of a 4-core Intel i5 or i7 or better, with processing speed of 2+ GHz, 8 GB of RAM, and 500 GB of persistent storage with at least 50% available at all times.
• The equipment must monitor key performance parameters of the EDA computing platform such as CPU utilization (%), memory utilization (GB, %), disk utilization (GB, %) and access rate, etc. using system utilities such as Perfmon (for Windows systems) and store this history either in a log file or in some part of the equipment metadata model.
• The network interface card must support 1 GB per second (or faster) communications.

In the area of equipment model content, the following requirements are directly related to interface performance and data quality:

• The equipment should make the EDA computing platform performance parameters available as parameters of an E120 logical element that represents the EDA interface software itself.
• The supplier must provide a written description of the update rates, recommended sampling intervals, normal operating ranges and behaviors, and high/low/rate-of-change limits for all key process parameters. These will be used to design data quality filters in the data path between the equipment and the consuming applications/users.
• Equipment parameters provided through the EDA interface must exhibit a number of data quality characteristics, including, but not limited to: an internal sampling/update rate sufficient to represent the underlying signal accurately; timing of trace reports that is consistent with the sampling interval within +/- 1.0%; values in adjacent trace reports must contain then-current values at the specified sampling interval; and rejection of obvious outliers.

Advanced users of the EDA standards are now raising their expectations for the equipment to provide self-monitoring and diagnosis capability in the form of built-in data collection plans (DCPs), as expressed in some of the following requirements:

• The supplier must provide built-in DCPs to support common equipment performance monitoring, diagnostic, and maintenance processes that are well known to the supplier. Documentation for these DCPs must define their purpose, activation conditions, interface bandwidth consumed, and the types of analysis the collected data enables.
• The supplier must describe the operating conditions that can lead to a PerformanceWarning situation for the EDA interface.
• The supplier must describe the algorithms used to deactivate DCPs under PerformanceWarning conditions. These might include LIFO (i.e., the last DCP activated is the first to be deactivated), decreasing order of bandwidth consumed or “size” (in terms of total # of parameters and # of trace/event requests), etc.

Because of the power and complexity of the DCP structure defined in the EDA standards, it is not sufficient to specify the raw communications performance requirement as a small number of isolated criteria, such as total bandwidth (in parameters per second) or minimum sampling interval. Rather, since the EDA interface must support a variety of data collection client demands for a wide range of production equipment, these requirements should be expressed as combinations of sampling interval, # parameters per DCP, # of simultaneously active DCPs, group size, buffering interval, response time for ad hoc “one-shot” DCPs, maximum latency of event generation after the related equipment condition occurred, consistency of timestamps in trace reports with the specified sampling interval, and perhaps others.

Moreover, some equipment types may have more stringent performance requirements than others, depending on the criticality of timely data for the consuming applications… so there may be process-specific performance requirements as well.

Measurement and Testing

Methods for measuring and testing the above requirements should also be described in the purchase specifications so the equipment suppliers can know they are being successfully addressed during the development process and can demonstrate compliance before and after shipping the equipment. Clarity at this phase saves time and expense later on.

Examples of such requirements include:

• The supplier must test the EDA interface across the full range of performance criteria specified above and provide reports documenting the results.
• An earlier requirement states that the EDA interface must be capable of reporting at least 2000 parameters at a sampling interval of 0.1 seconds (10Hz) with a group size of 1, for a total data collection capacity (bandwidth) of 20,000 parameters per second. In addition to this overall bandwidth capability, the supplier must demonstrate that this performance is possible over a range of specific data collection deployment strategies, meaning different #s and sizes of DCPs, different sampling intervals, group sizes, etc. without causing the EDA interface to reach one of its “Performance Warning” states or overstress its computing platform. To this end, all combinations of the following data collection configuration settings must be run for at least 15 seconds each; assuming the equipment has n processing modules:
  • Trace intervals (in seconds): 1, 0.5, 0.2, 0.1 (and 0.05 if possible)
  • # of parameters per DCP: 10, 50, 100, 250, 500, 1000 (and 2000 if possible)
  • # of DCPs: 1, 2, 3, … to n
  • Group size: 10, 5, 2, 1
• The test client should be run on a separate computing platform with sufficient computing power to “stay ahead” of the EDA interface computer; in other words, the EDA interface should never have to wait on the client system.
• Test reports should indicate the start and stop time of each iteration (i.e., one combination of the above settings), and verify that the timestamps of the data collection reports sent by the EDA interface are within +/- 1% of the value expected if the samples were collected exactly at the specified trace interval.

Performance parameters of the EDA interface platform should also be monitored during the tests and included in the report. These parameters should include memory usage, CPU processing load, and disk access rate (and perhaps others) for all processes that constitute the EDA interface software.

This approach is shown in tabular form for a 2-chamber tool (see below); since Group Size does not (or should not) impact the effective parameters per second rate, it is not shown in the table.

• A summary report for all performance tests that show acceptable message generation and transmission timing across the full range of data collection test criteria must be available.
• Detailed SOAP logs for specific performance tests must be available on request.

In Conclusion

We hope you now have some appreciation for the importance of solid requirements in this area, and can accurately assess how well your current purchase specifications express your actual needs. If you want to know more about a well-defined process for improving your specifications, or have any other questions regarding the status and outlook of the EDA standards, and how they can be implemented, please contact us.

In this our first standard overview, we look at GEM. At its history, its application and its suitability for use in the smart factories of today and the future.

Overview

The GEM standard defines a software interface that runs on manufacturing equipment. Factories use the GEM interface to remotely monitor and control equipment. The GEM interface serves as a broker between the factory host software (host) and the manufacturing equipment’s software. Because the GEM standard is an open standard, anyone can develop GEM capable host or equipment software.

The GEM standard is published and maintained by the international standards organization SEMI based in Milpitas, CA, USA. SEMI uses the standard designation “E30” to identify the GEM standard with the publication month and year appended as four numbers to designate a specific version. For example, E30-0418 identifies the version of the GEM standard published in April of 2018.

The GEM/SECS-II standards are protocol independent. Today, there are two protocols defined by SEMI: SECS-I (E4) for serial communication and HSMS (E37) for network communication. SECS stands for ‘SEMI Equipment Communications Standard’ and HSMS stands for ‘High-Speed SECS Message Services’.

Not surprisingly, most systems today are using the HSMS. HSMS does not specify the Physical Layer. Any physical layer supported by TCP/IP can be used, but typically everyone uses an Ethernet network interface controller (NIC) with an RJ45 port. When using the SECS-I standard, the messages size is limited to 7,995,148 bytes (about 8MB).

The GEM standard is built on top of SEMI standard SECS-II (E5). The SECS-II standard defines a generic message layer to transmit any data structure and defines a set of standard messages each with a specific ID, purpose and format.

History and Adoption

GEM was developed by the semiconductor industry to allow fabricators to connect and manage multiple machines in billion dollar facilities all around the world.

GEM is the adopted technology by factories worldwide because it is mature and supports all the features required now and expected in the future. GEM allows the same technology and software to be used to integrate multiple equipment and process types, independent of supplier.

The GEM standard is used in numerous manufacturing industries across the world, including semiconductor front end, semiconductor back end, photovoltaic, electronics assembly, surface mount technology (SMT), high brightness LED, flat panel display (FPD), printed circuit board (PCB) and small parts assembly. The adaptability of the GEM standard allows it to be applied to just about any manufacturing industry.

All semiconductor manufacturing companies including Intel, IBM, TSMC, UMC, Samsung, Global Foundries, Qualcomm, Micron, etc., currently use the GEM standard on all manufacturing equipment and have for many years. This includes 300mm, 200mm and 150mm wafer production.

GEM was successful enough early on that SEMI developed and currently uses several additional factory automation standards based on GEM technology. These additional standards are referred to as the GEM 300 standards, named because of their widespread adoption by the factories dedicated to the manufacturing of 300mm wafers.

In 2008, the photovoltaic (solar cell) industry officially adopted GEM with SEMI standard PV2 (Guide for PV Equipment Communication Interfaces) which directly references and requires an implementation of the GEM standard. In 2013, high-brightness LED industry created a similar SEMI standard HB4 (Specification of Communication Interfaces for High Brightness LED Manufacturing Equipment). Recently, the printed circuit board association has followed in the same path with ballot 6263 (Specification for Printed Circuit Board Equipment Communication Interfaces). All three standards similarly define implementations of the SEMI standard that increase GEM’s plug-and-play and mandate only a subset of GEM functionality to facilitate GEM development on both the equipment and host-side.

Several additional SEMI standards have been created over the years to enhance GEM implementations and are applicable to any industry and equipment. E116, Specification for Equipment Performance Tracking, defines a method to measure equipment utilization as well as the major components within the equipment. E157, Specification for Module Process Tracking, allows an equipment to report the progress of recipe steps while processing. E172, Specification for SECS Equipment Data Dictionary, defines an XML schema for documenting the features implementing a GEM interface. E173, Specification for XML SECS-II Message Notation, defines an XML schema for logging and documenting messages.

Flexibility and Scalability

GEM requirements are divided into two groups; Fundamental Requirements and Additional Capabilities. Any equipment that implements GEM is expected to support all the Fundamental Requirements. Additional Capabilities are optional and therefore are only implemented when applicable. This makes the GEM standard inherently flexible so that both a simple device and a complex equipment can implement GEM.

GEM easily and inherently scales to the complexity of any system. A simple device need only implement the minimum functionality to serve its purpose. Whereas complex equipment can implement a fully featured GEM interface to allow the factory to fully monitor and control its complex functionality. GEM also allows multiple host applications to connect to an equipment.

The requirements in that the GEM standard only apply to the equipment and not the host. This means that equipment behavior is predictable, but the host can be creative and selective choosing to use whichever features from the equipment’s GEM interface to attain it goals.

Our Seven Point Checklist

Remember our simple seven-point checklist for connectivity from our original article:

• Event Notification – real-time notification of activity & events
• Alarm Notification – real-time notification of alarms & faults
• Data Variable Collection – real-time data, parameters, variables & settings
• Recipe Management – process program download, upload, change
• Remote Control – start, stop, cycle stop, custom commands
• Adjust Settings – change equipment settings & parameters
• Operator Interface – send & receive messages to/from operator

Put simply GEM succeeds in each of these areas and you can find more detail by downloading our white paper or watching the videos on our website.

Conclusion

If you’re looking for a tried and tested standard that can be applied to any smart manufacturing ecosystem, no matter how large, it’s hard to beat GEM. The semiconductor industry is one of the most demanding and expensive industries in the world and they have done the work for everyone else at great cost and over many years. Industries like PCB fabrication are adopting this standard rather than developing their own for good reason, they need something that can be applied quickly, reliably, economically and at scale.

Forgive the pun but, we believe GEM is the gold standard for standards. We’ve been working with it successfully for decades in the semiconductors industry and more recently in PCB and SMT facilities. In some cases, we have deployed GEM at the request of OEM customers to drive greater control and traceability in their supply chain.

This blog was first posted on EMSNow.com.

Cimetrix attended the recent JISSO PROTEC exhibition (June 5-7, 2019) at the Tokyo Big Sight International Exhibition Center to see the latest developments in SMT (Surface Mount Technology) manufacturing… and witnessed a truly compelling demonstration of the new SEMI Flow Manufacturing communications standards in action.

The new suite of standards is named SMT-ELS (Surface Mount Technology-Equipment Link Standards), and includes SEMI A1/1.1 as a lower-level messaging standard with SEMI A2 SMASH (Surface Mount Assembler Smart Hookup) defining the content of the messages required to configure an SMT manufacturing line and automate the material and information transfer among all equipment in that line. This is depicted in the figure below.

The demonstration itself included placement equipment from 4 large equipment suppliers—Fuji, JUKI, Panasonic, and Yamaha—as well as load/unload stations and a bar code reader at the beginning of the line (see picture below). Each of these companies had implemented the “horizontal” (machine-to-machine) communications according to the SMT-ELS standards. The demonstration consisted of an operator scanning one of the stack of input boards with the barcode reader, placing it on the loader conveyor, and then watching as each piece of equipment automatically adjusted its internal conveyor to accept the board, run through its part placement recipe, and pass the board to the next equipment in the line, finally arriving at the unload station conveyor after a minute or so.

The Cimetrix Resource Center is a great tool for anyone who wants to learn more about industry standards including Equipment Connectivity and Control, data gathering, GEM (SECS/GEM), EDA/Interface A, and more. These standards are among the key enabling technologies for the Smart Manufacturing and Industry 4.0 global initiatives that are having a major impact on many industries. Manufacturers and their equipment suppliers must be able to connect equipment and other data sources, gather and analyze data in real time, and optimize production through a wide variety of applications. The free eBooks listed below provide in-depth coverage of the some of these concepts.  They have been written by technical experts who have participated in and led the standards development processes for more than two decades.

• Features and Benefits of GEM
• Implementing Equipment Control Applications using CCF
• EDA Applications and Benefits for Smart Manufacturing
• Models in Smart Manufacturing

Be sure to stop by our Resource Center any time or download the white papers directly from the links in this posting.

A few years ago, I went through the process of building a new house. It was exciting to work with the architect to design the house and imagine what the finished product was going to be like. The architect created a 40-page set of drawings detailing all the components that would go into the house, like the electrical, plumbing and flooring. I thought everything was covered. I was a little surprised when things didn’t go exactly as detailed in the drawings. There were exceptions! However, having the detailed drawings made it easier to identify where things went wrong and helped clarify what needed to be done to correct the problems.

Communication standards like GEM are like a set of architectural drawings for how to connect equipment to factory control systems. They define what needs to be communicated, how the communication needs to take place and provide a great roadmap for getting there. But like building a new house, there are usually a few surprises along the way. A standard, consistent way of testing the interface that can be used by both the factory and equipment manufacturer, greatly reduces the unknown and simplifies the process.

The new Cimetrix EquipmentTest™ product is the fastest way to achieve GEM Compliance for factory acceptance testing of new equipment. Whether you are an equipment manufacturer or factory, making sure the equipment interface is GEM compliant is critical. Having an easy-to-use testing solution to determine if the equipment is GEM compliant is critical.

There are two versions of EquipmentTest depending on your needs. The EqupmentTest Basic version is ideal for both Smart factories and equipment manufacturers to quickly and easily test the basic capabilities of an equipment’s GEM interface. EquipmentTest Basic includes a simple testing scenario, called a plugin, to evaluate the equipment’s ability to connect to a GEM host and communicate events, data and alarms. This version also includes the ability to send/receive individual messages to/from the equipment for discovery or diagnostic purposes. With the messaging functionality, you can also create macros to send and receive groups of messages.

For more complex testing, there is the EquipmentTest Pro version. In addition to all the features of the EquipmentTest Basic version, EquipmentTest Pro includes a full, rigorous GEM compliance testing plug-in and an operational GEM compliance testing plugin. The Pro version includes development tools to allow you to create your own custom tests/plug-ins using .NET languages. The GEM compliance plugin generates a GEM compliance statement that shows the areas and level of compliance to the GEM standards. There are also other tools only available in the EquipmentTest Pro version that allow you easily test and interact with the GEM functionality on the equipment.

As with all our products, Cimetrix supports the industry connectivity standards so you never have to wonder if your equipment is keeping up with the rest of the industry.

You can purchase either version of EquipmentTest directly from our website and download the software immediately. You will need to provide a valid Mac ID and email address for licensing purposes. You will receive your license agreement no more than 48 hours after purchase. Be sure to learn more and get your EquipmentTest download today!

Cimetrix participated in the recent European Advanced Process Control and Manufacturing (apc|m) Conference, along with over 150 control professionals across the European and global semiconductor manufacturing industry. This site of this year’s conference was Villach, Austria, a picturesque town nestled in the eastern Alps just north of the Italian border in the state of Carinthia. This region is home to a number of high-tech companies and institutions all along the semiconductor manufacturing value chain, and since it was the first time the conference was held in Villach, the local hosts rolled out the red carpet. 

This conference, now in its 19th year and organized by Silicon Saxony, is one of only a few global events dedicated to the domain of semiconductor process control and directly supporting technologies. As usual, the conference was very well organized, and featured a wide range of high-quality presentations, keynote addresses, and tutorial sessions. The supplier exhibits associated with this year’s event were especially numerous, as were the technical posters displayed in the exhibition area just outside the conference rooms.

As in many prior years, Cimetrix was privileged to present at this conference, as Alan Weber delivered a talk entitled “Addressing Connectivity Challenges of Disparate Data Sources in Smart Manufacturing.” The presentation highlighted the need for unifying data collection concepts—like explicit equipment models and generic structures for data collection plans—are increasing necessary for maintaining the fidelity of a factory’s “digital twin” in Smart Manufacturing settings where the number of data source types is growing. This presentation resonated with a number of the key conference themes, so if you want to know more, feel free to download a copy of the entire presentation from our web site.

Other highlights of the conference included:

• An update by Otto Graf on the ambitious vision and progress of the BOSCH 300mm wafer fab now under construction in Dresden. In this talk he emphasized the role that digital technologies will play in bringing up the fab and climbing the yield ramp and other features of a wall-to-wall Industrie 4.0 implementation. 
• “The Role of APC and Smart Manufacturing / Industrie 4.0 in New Reliability-Critical Markets“ by James Moyne (University of Michigan / Applied Materials) – James re-presented a number of the Smart Manufacturing technologies in the context of automotive industry requirements, especially the role that Subject Matter Expertise (i.e., people!) will play alongside other emerging technologies. He also pointed out that the Factory Integration chapter of the International Roadmap for Devices and Systems (IRDS) will be reorganized around the key tenets of Smart Manufacturing.
  
  
• A thought-provoking invited talk from Dr. Roman Kern of the KNOW-CENTER titled “Possibilities and Challenges of Digitalization in the Semiconductor and Other Domains.” His key messages started with “Big Data is the new oil…. AI is the new electricity… and Data Science is the new lingua franca for leading global industries,” and then he went deeper into all of these.
  
  
• Dr. Germar Schneider of Infineon Technologies built on the theme above in a practical setting with his “Chances and Challenges of Digitization in Semiconductor Fabs and Success Factors during the implementation” presentation. This was not only an in-depth look at some of the multi-year efforts at Infineon, but also included a summary of current digitization projects across the European manufacturing R&D community. 
  
  
• Another invited talk from BMW was delivered by Rainer Hohenhoff which covered “Product Data and Product Life Cycle Management in the face of new business models of the automotive industry.” In short, it discussed many of the ways a car company might make money even after people stop buying as many cars as they do today… and what collisions (pun intended) you could expect in the market as service companies like Google, Amazon, UBER, and others converge on the transportation consumer. 

There were poignant moments as well. After 19 years of personal dedication to this event, both Gitta Haupold of Silicon Saxony and Dr. Klaus Kabitzsch, Program Committee Chair from Technical University of Dresden are retiring. They will definitely be missed!

The insights gained from these and the other 30+ presentations are too numerous to list here, but in aggregate, they provided an excellent reminder of how relevant semiconductor technology has become for our comfort, sustenance, safety, and overall quality of life. 

This conference and its sister conference in the US are excellent venues to understand what manufacturers do with all the data they collect, so if this topic piques your interest, be sure to put these events on your calendar in the future. In the meantime, if you have questions about any of the above, or want to know how equipment connectivity and control fit into the overall Smart Manufacturing landscape, please contact us!

The GEM standard is often incorrectly perceived as a single-connection protocol for manufacturing equipment. A single connection means that only one software product can use the GEM interface at one time. Many manufacturing equipment that support the GEM standard only have the ability for one connection. However, this limitation is set only in ignorance, by tradition, and to satisfy the common manufacturing system architecture. 

The truth is that the GEM standard simply does not discuss additional connections--meaning that additional connections are neither required nor prohibited. Not only is it possible for an equipment to support multiple concurrent GEM interfaces, this is becoming more and more common. If each supported GEM connection is point to point and complies with the GEM standard, this is certainly allowed. However, each connection should be completely independent of other GEM connections and still comply with the GEM requirements. Implementing multiple connections raises several questions. 

What does it mean for each GEM connection to be independent?

It means that each GEM host operates completely independently, as if the other GEM host connections were not present. Here is a more specific list of attributes that define “completely independent”:

• The Communication state model is independent. Each can establish and disconnect independently from the other host packages.
• The Control state model is independent. Each can be set up as local or remote as needed. 
• Collection event report dynamic configuration is completely independent. Each host defines a unique set of reports and subscribes to a unique set of collection events. Even so, if two GEM host connections create identical reports and link them to the same collection event, then both should receive identical data. 
• Each host subscribes to a unique set of alarms. 
• Each host can query status information independently of any another.
• Each host can choose to enable or disable Spooling and configure it as desired.
• Each host can set up its own trace data collection.
• Each host only receives messages based on its subscriptions.
• Each host only sees reply messages to its primary messages.

Are you talking about HSMS-GS? 

No. HSMS-GS means implementing SEMI Standard E37.2, High Speed Message Service – General Session, an inactive SEMI standard. This standard, which never gained much industry traction, opens a single port through which any number of clients can connect. In contrast, I am talking about supporting multiple implementations of E37.1, High Speed Message Service – Single Session (HSMS-SS) where each connection uses a unique port number. Nearly all GEM interfaces today use the HSMS-SS protocol. 

What are the advantages of having multiple GEM connections in a single GEM interface? 

This opens the door for many useful applications. Here are three example configurations, and of course, all of them could be accomplished at the same time. 

1. A factory can set up multiple host software packages at the same time to connect to the same equipment’s GEM interface, without any knowledge of or interference with each other. With only a single connection, a factory wanting to do the same thing has to implement some sort of GEM host broker to funnel the different GEM host package communications into a single GEM connection… a technically challenging feat. 
2. If an equipment supplier wants to create an application designed specifically for its equipment running in a factory, they can use one of the GEM connections. They don’t have to replicate functionality into a custom interface. 
3. If one equipment needs to monitor, control, or pass data directly to or from another equipment, this can be done using one of the GEM connections without interference to the factory GEM connection. This is relatively simple to set up. Sometimes this is called horizontal communication. Such communication can also be channeled through a host using the traditional vertical communication use case for a GEM interface. 

What about safety?

Typically, I would expect factories to set up one and only one connection in the GEM interface to be in the online-remote state and allowed to send remote commands. But this is not an absolute requirement. It is not difficult to imagine applications where execution of remote commands is distributed among multiple applications. For example, an equipment supplier might use one GEM connection to manage periodic recalibration of the equipment based the actual measured performance. 

What are the technical complications? 

There are a few. 

• Because each connection uses a separate port number, the GEM interface can only support a finite number of connections when using HSMS-SS. 
• Because multiple connections are not addressed explicitly in the standard, there are not requirements for handling them. For example, GEM requires that operator commands and operator recipe management activity be reported to the host. However, when another connection sends a remote command or downloads a new recipe, there is no requirement to report this. Our CIMConnect product does, but there are no formal requirements to do so. 
• GEM requires the communication status to be displayed in the GUI, but what about multiple connections? It is not clear what needs to be displayed for multiple hosts. Typically I’ve just displayed the first GEM connection status, but it might be useful to show each connection status and give the operator a chance to control all GEM connections. 
• Some collection events (and hence data variables), status variables and equipment constants are targeting the behavior of that single connection. This means that in order to implement multiple connections correctly, these connection-specific features must be unique for that connection. For example, consider status variables EventsEnabled and ControlState. The values reported for these two status variables are unique to that connection. This adds some complexity to implementing the GEM interface with multiple connections. Of course, our CIMConnect product implements and handles this already. 

Does each GEM connection have to be identical? 

No, but generally speaking it should be the same. The same set of collection events/data variables, alarms, status variables, and equipment constants should be reported to all connections. However, there are use cases where it might be useful to have some unique collection events and data on one connection. For example, if an equipment supplier uses one GEM connection as a pipeline for a factory host package dedicated to their equipment, they might want to publish some unique data that is for its eyes only. As mentioned above, if two GEM host connection create an identical report, and link it to the same collection event, then both should receive identical data. On the other hand, trace data reports with the same status variables may not need to report identical data, because the values might be sampled independently and at different time intervals. 

How many GEM connections should an equipment support in its GEM interface?

I recommend supporting five connections. Most GEM implementations are just using one connection today, so this opens the door for up to four more connections. This enables an equipment to handle most situations without the need to be reconfigured later at the factory. In CIMConnect, the overhead for having five connections is quite minimal, and virtually nothing if they are not used. 

What should the communication settings be? 

You should definitely set up the equipment as passive. This puts all of the configuration on the host side. The device ID can be the same for all connections, where 0, 1, or 32767 is best. 

How do I turn on multiple GEM connections in CIMConnect?

Since our CIMConnect product inherently supports multiple GEM connections, Cimetrix customers really only have to configure the setup file. Our CIMConnect GEM product was originally designed with multiple GEM connections in mind; therefore it is native and intuitive, with virtually no extra programming required unless you count the additional work in the operator interface. In the setup file, just create the five [CONNECTIONX] sections initially, and then set up a connection-specific VARIABLES and EVENTS section for each of the five connections. 

Alternative Approaches?

One alternative approach is to look at the SEMI Equipment Data Acquisition (EDA) standards. An EDA interface is inherently only for data collection and has multiple client access built into the standard as a fundamental requirement. The semiconductor front end device manufacturers have successful embraced this technology in addition to the GEM standard. The GEM interface is used by the Manufacturing Execution System for command and control of the equipment, while the EDA interface is used for every other application. 

Final Thoughts

My recommendation is that everyone, especially Cimetrix CIMConnect customers, take a look at their GEM interface and make sure that you are doing a good job implementing multiple host connections. CIMConnect makes this extremely easy. And let your customers know that you have this feature so that they can take advantage of it. 

You can learn more about the GEM standard any time on our website.

The Cimetrix Resource Center is a great tool for anyone who wants to learn more about industry standards including GEM (SECS/GEM), GEM300, EDA/Interface A, and more. These standards are among the key enabling technologies for the Smart Manufacturing and Industry 4.0 global initiatives that are having a major impact on many industries. Manufacturers and their equipment suppliers must be able to connect equipment and other data sources, gather and analyze data in real time, and optimize production through a wide variety of applications. The free white papers listed below provide in-depth coverage of the most broadly used equipment connectivity standards. They have been written by technical experts who have participated in and led the standards development process for more than two decades.

• Introduction to the Standards: GEM (SECS/GEM) – SEMI E5, E30, E37
• Introduction to the Standards: GEM300 – E40, E87, E90, E94, E116, E148, E157
• Introduction to the Standards: EDA/Interface A – E120, E125, E132, E134, E164 (and others)
• Introduction to the Standards: PV2 (PVECI)
• Introduction to the Standards: Implementing GEM and PV2
• SECS Messaging Primer

Be sure to stop by our Resource Center any time or download the white papers directly from the links in this posting.

Previous blog posts have discussed the merits of choosing a commercial software platform for implementing the equipment side of EDA (Equipment Data Acquisition) and how you would use that package to differentiate your equipment data collection capabilities from your competitors.

In this post, we discuss how to design the equipment model to contain enough information to make it useful without publishing so much data that it becomes cumbersome for your factory customers to find the data that is most important to them.

Data to Publish

• E164 (EDA Common Metadata) Values

The automation requirements for the most advanced fabs call for the latest versions (Freeze II) of all the standards in the EDA suite, including the EDA Common Metadata (SEMI E164) standard. In addition to providing an excellent foundation for a new equipment model, E164 enables consistent implementation of GEM300, commonality across equipment types, automation of many data collection processes, less work to interpret collected data, and true plug-and-play client applications—all of which contribute to major increases in engineering efficiency. These capabilities benefit both the equipment suppliers and their factory customers alike. Therefore, equipment models should make all E164-compliant data available.

To summarize, those who remember the complexity of implementing SECS-II before GEM came along (pre-1992) will understand this analogy: E164 is to EDA what GEM was to SECS-II.

• Fab-specified Data

The second blog post made the following statement:

“In effect, the metadata model IS the data collection 'contract' between the equipment supplier and the fab customer."

“This is why the most advanced fabs have been far more explicit in their automation purchase specifications with respect to equipment model content, going so far as to specify the level of detailed information they want to collect about process performance, equipment behavior, internal control parameters, setpoints and real-time response of common mechanisms.”

You only have to read the latest requirements specs for these fabs to get more specifics. Pick the one from your customer base that sets the bar highest and let that be your target.

Data to Avoid in the Model

It is easy to fall into the mindset that if publishing some data through the EDA interface is desirable, the more data we can publish, the better. This is not always the case. In his fascinating book, The Paradox of Choice, Barry Schwartz makes the case that freedom is defined by one’s ability to choose, but more choice doesn’t mean more freedom. In fact, too many choices actually cripple one’s ability to choose. The same can be said of data published in an EDA interface. Making too much data available actually hinders the creation of EDA client applications.

We were recently working with a fab to perform a proof-of-concept where we connected an EDA client to a piece of equipment with an EDA interface. We were able to connect to the equipment in a matter of minutes, but finding suitable data to collect for our proof-of-concept took almost an hour because there was so much superfluous data published from the equipment.

Publishing everything including the kitchen sink reduces the ability to create an efficient EDA client application.

Some examples of data to avoid publishing in the model include:

• Parameters that have no value – If a parameter is available in the model, but the value is not published by the equipment control application, that parameter is just extra noise in the interface. Consider not adding it to the model.
• Parameters with values that do not change – If a parameter value does not change during the life of the application, it does not make sense to collect that parameter’s data. For example, if an application uses an equipment constant, it may not be necessary to publish that constant through the EDA model.
• Irrelevant data – If a parameter contains data that is irrelevant to data publication, it should not be added to the model. For example, having parameters in the model that contain the IP address or port number for connection are not very useful in the equipment model. This information is necessary in connecting with an EDA client, but is not relevant for data collection in the model.

The takeaway: Publish data required by E164 and additional fab-specified data, but carefully evaluate other data to be published to make sure it is relevant and useful for data collection.

If you have questions about Equipment Data Acquisition or would like a demo of the functionality described above, please contact Cimetrix to schedule a discussion. 

You can download an introduction to EDA White Paper any time.

The fourth part of our Overview of the GEM Standard Video series is here! 

In this video, Brian Rubow gives a description and dives a little deeper on some of the most important GEM features including the following:

• Self-Description
• Alarms
• Remote Control
• Equipment Constants
• Recipe Management
• Material Movement
• Terminal Services
• Clock
• Spooling

View the entire series today!