Industry News, Trends and Technology, and Standards Updates

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!

In the first blog of this series, Clare Liu of Cimetrix China made the compelling case for choosing a commercial software platform for implementing the equipment side of the EDA (Equipment Data Acquisition) standards interface rather than developing the entire solution in-house. 

Whenever this “make vs. buy” decision is discussed, however, the following question inevitably arises: “If we choose a standard product for this, how can we differentiate the capabilities of our equipment and its data collection capability from our competitors?” It’s a great question which deserves a well-reasoned answer.

Platform Choice and System Architecture

Most advanced fabs use EDA to feed their on-line FDC (Fault Detection and Classification) applications, which are now considered “mission-critical.” This means if the FDC application is down for any reason, the equipment is considered down as well. It is therefore important to choose a computing platform for the EDA interface that is highly reliable and has enough processing “headroom” to support the high bandwidth requirements of these demanding, on-line production applications. Moreover, this platform should not be shared by other equipment communications, control, or support functions, since these may adversely impact the processing power available for the EDA interface. 

Surprisingly, this approach is not universally adopted, and has been a source of problems for some suppliers, so it is an area of potential differentiation. 

Adherence to Latest Standards 

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 (E164) standard. Dealing with older versions of the standard in the factory systems creates unnecessary work and complexity for the fab’s automation staff, so it is best to implement the latest versions from the outset. The Cimetrix CIMPortal Plus product makes this a straightforward process using the model development and configuration tools in its SDK (Software Development Kit), so there is absolutely no cost penalty for providing the latest generation of standards in your interface.

It takes time and effort for equipment suppliers with older versions of the standards to upgrade their existing implementations, so this, too, is an opportunity for differentiation.

Equipment Metadata Model Content

This is probably the area with the largest potential for competitive differentiation, because it dictates what a factory customer will ultimately be able to do with the interface. If an equipment component, parameter, event, or exception condition is not represented in the equipment model as implemented in the E120 (Common Equipment Model) and E125 (Equipment Self-Description), and E164 (EDA Common Metadata) standards, the data related to that element cannot be collected. 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 like material handling, vacuum system performance, power generation, consumables usage, and the like. This level of visibility into equipment operation is becoming increasingly important to achieve the required yield and productivity KPIs (Key Performance Indicators) for fab at all technology nodes.

The argument about “who owns this level of information about equipment behavior” notwithstanding, providing the detailed information the fabs want in a structure that makes it easy to find and access is a true source of differentiation.

Self-Monitoring Capability

If you really want to set your equipment apart from your competitors, consider going well beyond simply providing access to the level of information needed to monitor equipment and process behavior and include “built-in” Data Collection Plans (DCPs) that save your customers the effort of figuring out what data should be collected and analyzed to accomplish this. Your product and reliability engineering teams probably already know what the most prevalent failure mechanisms are and how to catch them before they cause a problem… why not provide this knowledge in a form that makes it easy to deploy?

A few visionary suppliers are starting to talk about “self-diagnosing” and “self-healing" equipment… but it will be a small and exclusive group for a while – join them.

Readiness for Factory Acceptance

Before the fab’s automation team can fully integrate a new piece of equipment, it must follow a rigorous acceptance process that includes a comprehensive set of interface tests for standards compliance, performance, and reliability. This process is vital because solid data collection capability is fundamental for rapid process qualification and yield ramp that shorten a new factory’s “time to money.” If you know what acceptance tests and related software tools the fab will use (which is now explicit in the latest EDA purchase specifications), you can purchase the same software tools, perform and document the results of these same tests before shipping the equipment. 

This will undoubtedly speed up the acceptance process, and your customers will thank you for the effort you took to put yourself in their shoes. Incidentally, this usually means the final invoice for the equipment will be paid sooner, which is always a good thing.

In Conclusion

In this posting, we have only scratched the surface regarding the sources of competitive differentiation. As you can see, choosing a commercial platform enables this far more readily than the in-house alternative, because it allows your development team to focus on the topics above rather than worrying about compliance to the standards. If you’d like to know more, please give us a call or click below to talk schedule a meeting. 

Join Brian Rubow for the third video in our five-part video series which covers another of the core features of GEM.

One of the core features for monitoring equipment is the GEM Collection Event Notification. Every equipment will publish a set of collection events. These report in real-time when things are happening at the equipment level that a factory may want to monitor. The equipment will document a set of events that are aviable at the factory level, and the host can choose which ones they want to subscribe to.

View the entire series today!

The second video in our Overview of the GEM Standard video series goes into a little more detail on the GEM standard functionality. 

The GEM standard is broken down into two sets of functionality. One is the fundamental requirements.  These are the things that everyone that uses GEM should implement. It gives some of the basic funtionality you want in every equipment and every device that has a GEM interface. Then there are a number of additional capabilities, meaning you can be GEM compliant without using them, but they are available when needed. 

The GEM standard is extremely efficient, with messages that are always transmitted in a binary format, which is much smaller than ASCII based protocols. Among the benefits of this is that the network bandwidth is not wasted. 

To find out even more, be sure to see the second part of our series today! 

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!

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.”* 

During the SEMICON West exhibition in San Francisco this past week (July 9-10), the North American Information & Control Committee and its Task Forces met to continue SEMI standards development. Here is a brief summary of the proceedings.

The GEM 300 task force, in addition to reapproving E90, also approved minor title changes to the E39, E39.1, E40 and E40.1 standards. Each SEMI standard must be revised or reapproved to avoid becoming inactive. A few years ago, SEMI changed regulations that mandate that each standard declare its classification, such as a “guide” or “specification”. Since then the task force has been slowly correcting the titles. The E37.1 standard is in the middle of such classification, but has been riddled with reapproval complications due to minor concerns and some needed corrections in the standard. The ballot to make these corrections, 6349, failed for the second time at SEMICON West. The ballot will be slightly reworked and resubmitted for another round of voting. Another ballot, 6348 proposed to clean up the GEM E30 standard, to improve its readability and to bring the standard in conformance with current SEMI regulations and its current style guide. The forefront of the discussions was surrounding the confusing use of acronyms DVNAME, DVVAL, SVV and other such acronyms where the meaning and use of the acronyms was confusing to new readers. The 6348 ballot also failed, but hopefully the task force is progressing towards reaching an agreement. One major challenge is that ballot 6348 is a major revision ballot, where the entire specification is opened up for review and scrutiny, as opposed to line item ballots where only specific sections of a standard are modified.

Finally, and most exciting is ballot 6114B; a revision to the SECS-II E5 standard. The ballot proposed a set of new messages for transferring any large items between a host and equipment. Typically, one item in a message is limited to about 16.7 MB. The new messages are specifically targeting the transfer of equipment recipes, but the messages are written generic enough so that anything else can be transferred, too. The new messages support two styles of item transfer. Either the item can be transmitted in a single message, or broken into parts for transfer with the expectation to be concatenated by the recipient. Or the item can be transmitted in multiple messages, broken into parts with each part sent in a separate message and the same expectation to be concatenated by the recipient. An item is identified by its “type”, “id” and “version”. The messages are intended to resolve current issues with recipes where some equipment suppliers are using recipes that surpass 16.7 MB. And the messages open the door to be used by other SEMI standards and to be customized for specific applications. After passing this ballot, the task force intends to make the messages part of the GEM standard. Even though the ballot 6348 failed, the task force seems to have finally reached consensus on the message formats and continues to work out minor details.

The DDA Task Force continues to work on the next version of the Equipment Data Acquisition (EDA) standards. In the latest cycle of voting, changes were proposed to E138 (ballot 6336), E134 (ballot 6335) and E132 (ballot 6337). Although one part of E134 passed, most of E134 failed and the other ballots failed. All of the failed ballots will be reworked and resubmitted for voting. Additionally, during the task force meeting additional proposed changes were reviewed and discussed. The task force continues to make plans to move from HTTP 1.1 and SOAP/XML to HTTP 2.0 and Protocol Buffers. Specifically, the plan is to recommend using gRPC. Testing done to date indicated an 18 times performance improvement and significant bandwidth reduction. The task force also discussed changes to simplify the equipment model metadata handling. Finally, Cimetrix proposed the implementation of a new method of data sampling designed for higher data collection frequencies. The current trace data collection messages, while very effective for speeds up to maybe 80 Hz, become inefficient when trying to collect data at even faster rates. The concept is called a “cached data sample” where the equipment collects the data at a specified frequency and then reports the data in an array syntax. When using HTTP 2.0 and Protocol Buffers, this will be an especially efficient format expected to allow much higher frequencies.

The client specifies the data collection frequency as well as the reporting frequency. For example, a client might specify a frequency of 10 kHz and a reporting frequency of 1 s, where 10,000 data samples would be reported each second. Such proposal if accepted, combined with the faster Protocol Buffer, will open the door for a number of new data collection applications.

A lot of people are wondering when EDA freeze III will be done. Probably not until late next year. How soon this happens mostly depends on how efficiently task force members provide feedback on the ballot drafts.

Subscribe to our blog in the upper right corner of this page to be sure not to miss that or any of my future updates on the North American Information & Control Committee.

Cimetrix is here at SEMICON West 2018 and we're excited to be a part of the first Smart Manufacturing Pavilion in the South Hall. We hope you've been able to drop by and hear some of the great speeches including our own experts Alan Weber, VP New Product Innovations and our VP & GM Smart Factory Business Ranjan Chatterjee with Dan Gamota (VP Digital Engineering Services) at Jabil.

Alan Weber's presentation is now available online. The topic he chose is "Making Smart Manufacturing Work: The Stakeholder-driven Requirements Development Process".

An important maxim of performance management is “You get what you measure.” This is largely true whether you are talking about employees, organizations, processes, time management, sports teams, or – to highlight a current global industry topic – Smart Manufacturing.

The question now becomes “How DO the industry’s leading manufacturers ensure the equipment they buy will support their Smart Manufacturing objectives?” This presentation explains how the careabouts of key stakeholder groups are “translated” into specific equipment automation and communications interface requirements which can then be directly included in the equipment purchasing specifications. As more semiconductor manufacturing companies take this approach, effectively “raising the bar” for the entire industry, the collective capability of the equipment suppliers will increase in response, to everyone’s benefit.

Through several interviews with leading manufacturers over the past 18 months, we discovered that the best way to accomplish this is through a focused, interactive questionnaire process. By asking very specific questions about people’s daily tasks, problem areas, expectations, success criteria, and other items of constant concern, we can take a generic automation purchase specification outline and generate a complete, factory-specific set of automation and communications interface purchase specifications in a matter of days. This is time well-spent when you consider the value and volume of equipment potentially affected… and the opportunity cost of not having these requirements clearly expressed.

If the above discussion triggers the question “I wonder if our equipment automation purchase specs are sufficient to address the Smart Manufacturing challenges we’ll face in the next few years?” this presentation will interest you. Taking its lessons to heart may be the most important next step you take in formulating you own company’s Smart Manufacturing implementation roadmap.

Get Alan Weber's SEMICON West presentation now!