Industry News, Trends and Technology, and Standards Updates

The 19th Annual European APC Conference is in the books!

Posted by Alan Weber: Vice President, New Product Innovations on Apr 23, 2019 10:34:00 AM

apcm20191Cimetrix 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. apcm20192-2

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.

apc20193-1Other 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. apcm20194-1
  • “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. 

  • apcm20195-1Another 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!

apcm20196-1The 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!

Contact Us

Topics: Industry Standards, Semiconductor Industry, Doing Business with Cimetrix, Events, Smart Manufacturing/Industry 4.0

Multiple GEM Connections on Manufacturing Equipment

Posted by Brian Rubow: Director of Solutions Engineering on Apr 10, 2019 12:47:00 PM

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. 01_GEMHost_v3
  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. 02_GEMHost_v3
  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. 03_GEMHost_v3

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.

GEM Standard

Topics: Industry Standards, SECS/GEM, Smart Manufacturing/Industry 4.0, Cimetrix Products

Resources Round-up: White Papers

Posted by Kimberly Daich; Director of Marketing on Mar 26, 2019 11:15:00 AM

Resource Center-1The 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.

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

Resources

Topics: Industry Standards, SECS/GEM, EDA/Interface A, Doing Business with Cimetrix, Programming Tools, Photovoltaic/PV Standards, Smart Manufacturing/Industry 4.0

EDA Implementation Insights: What Data Should I Publish?

Posted by Derek Lindsey: Product Manager on Mar 19, 2019 11:30:00 AM

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

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.information-overload-1-1

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.

Read the White Paper

Topics: Industry Standards, EDA/Interface A, Smart Manufacturing/Industry 4.0

Overview of the GEM Standard: Video Series Part Four of Five

Posted by Kimberly Daich; Director of Marketing on Feb 26, 2019 11:32:00 AM

The fourth part of our Overview of the GEM Standard Video series is here! New call-to-action

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!

Topics: Industry Standards, SECS/GEM, SECS/GEM Features & Benefits Series

EDA Implementation Insights: Competitive Differentiation

Posted by Alan Weber: Vice President, New Product Innovations on Feb 13, 2019 11:50:00 AM

people arrowIn 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 

gold-thumbs-upThe 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.

eye-with-maglassThis 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

checklistBefore 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.Red_smart_factory-TW

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. 

Contact Us

Topics: Industry Standards, EDA/Interface A, Doing Business with Cimetrix, Smart Manufacturing/Industry 4.0, Cimetrix Products

Overview of the GEM Standard: Video Series Part Three of Five

Posted by Kimberly Daich; Director of Marketing on Jan 3, 2019 11:22:00 AM

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

New call-to-action

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!

Topics: Industry Standards, SECS/GEM, SECS/GEM Features & Benefits Series

Overview of the GEM Standard: Video Series Part Two of Five

Posted by Kimberly Daich; Director of Marketing on Nov 28, 2018 11:15:00 AM

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

Overview of Gem part 2 of 5

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! 

Topics: Industry Standards, SECS/GEM

Overview of the GEM Standard: Video Series Part One of Five

Posted by Kimberly Daich; Director of Marketing on Oct 31, 2018 12:08:00 PM

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. 

New call-to-action

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!

 

Topics: Industry Standards, SECS/GEM

The Gigafab Minute and SEMI Standards: A Modern Miracle

Posted by Alan Weber: Vice President, New Product Innovations on Oct 4, 2018 11:04:00 AM

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


It’s amazing enough to think that a single factory can start 100,000 wafers every month on their cyclical journey through 1500 process steps… and have 99%+ of them emerge 4 months later to be delivered to packaging houses and then on to waiting customers. It’s quite another to realize that all of this happens continuously (24 x 7) and automatically. TMS1100-TIDatamath-image

“How is this possible?” you ask.

Well, a big part of the solution is the body of SEMI standards which have evolved since the early 80s to keep pace with the ever-changing demands of the industry. From an automation standpoint, many of these standards deal with the communications between manufacturing equipment and the factory information and control systems that are essential for managing these complex, hyper-competitive global enterprises.

A significant characteristic of these standards is that they have been carefully designed to be “additive.” This means that new generations of SEMI’s communications standards do not supplant or obsolete the previous generations, but rather provide new capabilities in an incremental fashion. To appreciate the importance of this in actual practice, consider how the GEM, GEM300, and EDA/Interface A standards support the transactions that occur in a single Gigafab Minute. 

Starting at 1:00 o’clock on the infographic and moving clockwise, you first notice that 2.31 wafers enter the line. Of course, these are actually released in 25-wafer 300mm FOUPs (Front-Opening Unified Pod), but 100K wafers per month translates to 2.31 per minute. Since these factories run continuously, once the line is full, it stays full. And with an average total cycle time of 4 months, this means that there are 400K wafers of WIP (work in process) in the factory at any given time. This number, and the total number of equipment (5000+), drive the rest of the calculations. 

GEM (Generic Equipment Model) – SEMI E30, etc.

The GEM messaging standards were initially defined in the early 90s to support the factory scheduling and dispatching applications that decide what lots should go to what equipment, the automated material handling systems that deliver and pick-up material to/from the equipment accordingly, the recipe management systems that ensure each process step is executed properly, and the MES (Manufacturing Execution System) transactions that maintain the fidelity of the factory system’s “digital twin.” 

Every minute of every day, GEM messages support and chronicle the following activities: 240 process steps are completed (i.e., 240 25-wafer lots are processed), 300 recipes are downloaded along with a set of run-specific adjustable control parameters, and 600 FOUPs are moved from one place to another (equipment, stockers, under-track storage, etc.). For each of these activities, the factory’s MES is notified instantaneously.

GEM300 – SEMI E40, E87, E90, E94, E157

With the advent of 300mm manufacturing in the mid-to-late 90s, a global team of volunteer system engineers from the leading chip makers defined the GEM300 standards to support fully automated manufacturing operations. Starting at 5:00 o’clock on the infographic, the number of transactions per minute jumps almost 3 orders of magnitude, from the monitoring of 900 control jobs across 4000 process tools to the tracking of 360,000 individual recipe step change events. This level of event granularity is essential for the latest generation of FDC (Fault Detection and Classification) applications, because precise data framing is a key prerequisite for minimizing the false alarm rate while still preventing serious process excursions. In this context, more than 6000 recipe-, product- and chamber-specific fault models may be evaluated every minute.

Simultaneously, the applications that monitor instantaneous throughput to prevent “productivity excursions” and identify systemic “wait time waste” situations depend on detailed intra-tool wafer movement events. In a fab with hundreds of multi-chamber, single-wafer processes, 75,000 or more of these events occur every minute. gantt-chart-cycle-time

EDA (Equipment Data Acquisition) – SEMI E120, E125, E132, E134, E164, etc.

Rounding out the SEMI standards in our example gigafab is the suite of EDA standards which complement the command and control functions of GEM/GEM300 with flexible, high-performance, model-based data collection. The EDA standards enable the on-demand collection of the volume and variety of “big data” required from the equipment to support the advanced analysis, machine learning, and other AI (Artificial Intelligence) applications that are becoming increasingly prevalent in leading semiconductor manufacturers. As EUV (Extreme Ultraviolet) lithography moves from pilot production to high-volume manufacturing at the 7nm process node and beyond, the litho process area will become a major source of process data by itself, generating 10 GB of data every minute. This is in addition to the 100 GB of data collected from other process areas. graph-and-equipmentfolder

The End Result

The final wedge (12:00 o’clock) in our infographic highlights the real objective – which is producing the millions of integrated circuits that fuel our global economy and provide the technologies that are an integral part of our modern way of life. Assuming a nominal die size of 50 square mm (typical of an 8 GB DRAM), the 2.31 wafers we started at 1:00 o’clock result in almost 3200 individual chips. But none of this would be possible without the pervasive factory automation technology we now take for granted. So, as you finish reading this posting on whatever device you happen to be using, take a micro-moment to acknowledge and thank the hundreds of standards volunteers whose insights and efforts made this a reality!

Red_smart_factory-TWYou may not be responsible for running a gigafab anytime soon, but the SEMI standards used in this setting are no less applicable to any Smart Manufacturing environment. Give us a call if you’d like to know more about how these technologies can benefit your operations for many years to come. 

 

You can see this infographic and much more in the Cimetrix Resource center.

Resources

 *The Gigafab Minute was inspired by an analogous explication of the scope and impact of today’s Internet from Lori Lewis and Chadd Callahan of Cumulus Media, and published on the Visual Capitalist web site (http://www.visualcapitalist.com/internet-minute-2018/)

Topics: Industry Standards, SECS/GEM, Semiconductor Industry, Smart Manufacturing/Industry 4.0