Industry News, Trends and Technology, and Standards Updates

The SEMI North American standards meetings for the Information and Control Committee were held recently and the following is a summary of some of the highlights and action items. 

In the GEM 300 task force, a revision to GEM officially removed E139 as a recipe management option. A planned revision to GEM should be much more exciting and progressive, but this work cannot begin until E30 is published with the current changes. In the meantime, future near-term plans include defining new SECS-II messages to improve host access to data collection setup and some terminology clarification. Brian Rubow from Cimetrix continues to co-lead this task force with Chris Maloney of Intel.

In the DDA (Diagnostics Data Acquisition) task force, which Brian Rubow from Cimetrix continues to co-lead, the standard that establishes gRPC and Protocol Buffers for EDA freeze 3 was approved. However proposed changes to the other core standards E125, E132 and E134 all failed, as well as the gRPC adoption for E132. The failures were expected. Additionally the North America DDA task force leaders continue to actively collaborate with the co-leaders of the DDA task force in South Korea. It is a great example of competitors working together at SEMI to create common solutions that satisfy everyone’s requirements.

Tami Tracy, a Cimetrix Solutions Engineering Manager, was officially voted in as a GUI task force co-leader for 2020, co-leading with Frank Summers. Congratulations and thanks to Tami for volunteering for this position. This will accelerate the task force's plans to modernize the SEMI E95 standard.

The Computer and Device Security (CDS) task force announced a vastly improved collaboration with its sister organization in Taiwan which has officially agreed to "divide and conquer" rather than attempting to address the entire scope of this domain with a single standard. A few months ago, the two groups seemed to be at odds with each other...The Taiwan task force proposed to include all factory and equipment security issues in one effort, while the North American task force wanted to focus initially on the equipment issues. The Taiwan, Japan and North America Task Force Leadership have now agreed to convert the Specification for Malware Free Equipment Integration (SNARF) 6506 into an overarching standard. The CDS task force is moving forward on SNARF 6566, and received authorization for a ballot on this proposed new standard for Cycle 2-2020.

The Advanced Factory Factory Integration (ABFI) task force, headed by Brian Rubow (Director of Solutions Engineering, Cimetrix) and Dave Huntley (PDF Solutions), held its first task force meeting. One order of business is to update E142 substrate mapping. The task force intends to map equipment features to SEMI standards including GEM and GEM 300. This effort could facilitate adoption of the GEM standard on equipment that previously had little interface standardization. It should also encourage further advance the goals of Smart Manufacturing and Industry 4.0 in related industries, encouraging more factories and equipment to adopt the standards that have been so successfully applied in semiconductor manufacturing for decades.

To find out more, you can speak with an industry standards expert today by clicking the link below.

In the early 1990’s I worked with companies like Motorola, Wacker Siltronics, and AT&T to characterize the SEMI Equipment Communication Standards (SECS) interface on the equipment. It was early in the process of connecting process and metrology equipment to a factory control system (Manufacturing Execution System – MES), in the days before the leading chip makers at that time got together to define the Generic Equipment Model (GEM), which was eventually balloted as SEMI E30.

It was a fun and exciting time as process owners began to see the power and benefit of having an automated interface to the equipment. The first project I worked on was collecting critical dimension (CD) data from a microscope following a lithography process step. Previously the operators would manually enter 6 measurement data points to 8-digit precision. This was a very error-prone process, and each time a mistake was made, lots were put on hold until the problem was diagnosed. This affected not only the throughput of the lithography area, but also the overall fab, since the litho tools are invariably the bottleneck. The automated interface eliminated this problem because process engineers knew that any lot holds were due to real process errors rather than operator input errors.

Moving the automated interface to the process equipment was a little more difficult. An automated interface on a metrology tool cannot cause misprocessing, but an automated interface on a process tool was a little riskier. We decided that the first step would be to simply verify that the correct recipe was selected, and not allow processing to proceed until it was reviewed by the process Engineer assigned to that equipment. Within a few minutes of going live with the first automated interface for a process equipment, a mismatch was detected between the operator-selected recipe and the recipe specified in the MES. A quick check by the process engineer verified that the technician had indeed selected the wrong recipe—this simple check alone saved misprocessing the entire carrier of material.

From these humble beginnings, full factory automation in front end 300mm fabs was adopted quickly and revolutionized semiconductor manufacturing. The level of automation in other areas of the semiconductor and electronics assembly industries is now increasing dramatically, motivated by the prospect of improved factory throughput and higher yields. Moreover, the experience gained through implementation of automated interfaces using SEMI communication standards will be a great benefit to semiconductor backend and electronics assembly markets. Some of the standards used in 300mm automation have already been modified for this purpose, and new standards are in work to better serve these industries.

In September 2019, SEMI published the PCBECI (Printed Circuit Board Equipment Communications Interface) standard, officially designated SEMI A3. This standard is a simplification of the reliable and much-used GEM equipment communication standard.

Early in 2019 the SMT-ELS (Surface Mount Technology Equipment Link Standard) suite, designated SEMI A1, A1.1, and A2, was also published. These standards address the need for machine-to-machine (M2M) communications to support flow manufacturing processes. The adoption process for these new standards has just begun, but like the early adoption of the SECS and GEM standards, it is exciting times and good things are happening. 

Visit us as Productronica (Hall A3 Booth 421) or SEMICON Europa (Hall B1 Booth 525) to hear more about these new standards and the products Cimetrix has developed to support their implementation and validation in equipment and factories. Or you can get in touch with a standards expert any time by clicking the link below. 

The 31^st annual APC Conference is now in the history books, and the diversity of topics, presenters, and local distractions made it well worth the visit to San Antonio! This year’s agenda featured half-day tutorials on the basics of APC and cyber-security, keynotes from chip makers and leading suppliers on automotive industry requirements, smart equipment, and smart manufacturing, and a series of packed technical sessions covering sensors and equipment control, fault detection and feedforward/feedback control, advanced analytics, and standards.

One of the presentations in the standards session provided detailed information about the new SEMI SMT-ELS (Surface Mount Technology Equipment Link Standards) M2M (machine-to-machine) communications standard. Alan Weber made the presentation titled “SEMI Standards to Support APC for Post-Fab Operations” to an interested audience, which triggered a number of discussions about the automation roadmap for the semiconductor assembly and test segment. This was especially relevant, since some of the leaders of the newly formed SEMI Advanced Backend Factory Integration Task Force (ABFI TF) were also present.

The SMT-ELS standard has come a long way in a short time, and the ambitious, integrated demonstration created by 4 major SMT suppliers (Fuji, Juki, Panasonic, Yamaha) that was exhibited in June (Japan) and August (China) will again be shown in productronica (Munich, 13-15 November). The basic functions of SMT-ELS (officially designated at SEMI A1, A1.1, and A2) appear in the figure below.

Cimetrix will likewise demonstrate this new standard at productronica, showing not only an equipment-level implementation of the M2M features but also the host-based configuration process and a plug-in for doing protocol validation tests.

Smart Manufacturing was a common theme this year, with an entire session dedicated to this global initiative. The Factory Integration section of the IRDS (International Roadmap for Devices and Systems) will be reorganized around the tenets of Smart Manufacturing, and a two-volume multi-industry book on this body of technology is scheduled for publication early next year. Another of Alan Weber’s presentations was dedicated to this topic, as he wrote the chapter chronicling the semiconductor industry’s development and use of these technologies.

If you would like any further information, you can speak with a Cimetrix expert, or you can stop by our booth at productronica this week (Hall A3 booth 451). 

Recently, I had the opportunity to participate in the development, testing, and integration of the Cimetrix ELS library that encompasses the SEMI A1, A1.1, and A2 (SMT-ELS) standards. It’s been exciting to see how ELS has increasingly been embraced as a connectivity solution for electronic manufacturing equipment.

I was first introduced to the SMT-ELS standard in June 2019 by Alan Weber (VP, New Product Innovations, Cimetrix). To begin, I obtained a functioning ELS implementation from Siemens Japan as well as the needed hardware. To make sure I fully understood ELS, I attended a 2-day class presented by Siemens and began studying the ELS standard and the Siemens ELS implementation.

It took a significant amount of time to get familiar with Siemens Implementation and gain an understanding of what they did to support the ELS standard. Siemens Japan has done a great job with their SEMI SMT-ELS implementation, and their assistance with my efforts is greatly appreciated. Once I felt familiar enough with ELS, I built a SMEMA interface driver to simulate the conveyor signals.

Using the SMT-ELS communications library, the Cimetrix development team designed a sample equipment application which I was able to use for initial connectivity testing. At first, it was fairly difficult to get the two libraries to communicate. However, when I used the Cimetrix EquipmentTest^TM software, I was able to find defects in our library, which were quickly and easily resolved by our development team. 

While it was beneficial to have a known ELS implementation to test against, it is now clear how valuable using a testing tool would be for anyone creating or validating their own SEMI SMT-ELS implementation.

Even though the SEMI A1, A1.1 and A2 standards are not long, they are dense. As adoption of these standards increases, it becomes paramount that equipment manufactures can test their SMT-ELS implementations during development. It is not effective or efficient for equipment manufacturers to test against other equipment as their primary form of testing. This is why the Cimetrix EquipmentTest SMT-ELS plug-in is so valuable.

I am currently working on test are written in C# and the code is easy to follow. The tests are split into two categories; one for horizontal communication between equipment ,and vertical communication to a factory system.

Horizontal Tests

For Panel Transfer verification, EquipmentTest connects to the first and last equipment in the line. This allows EquipmentTest to send messages to the first equipment and validate the format and content of the message from the last equipment. 

For this test, the user defines the panel parameters. The panel is sent to the first equipment. Once the last equipment in the line sends the panel to EquipmentTest, the Material Data Content is verified. 

In addition to actual tests, EquipmentTest can be used to send user defined atomic messages such as SetMDMode.

Vertical Tests

EquipmentTest Connects directly to the vertical port of the equipment. Using EquipmentTest, I can set and validate the Net Configuration.

The EquipmentTest software has been pivotal in developing and test our SMT-ELS Implementation. A demonstration of EquipmentTest SMT-ELS and the Cimetrix EquipmentConnect^TM SMT-ELS software will be given at Productronica from November 12-15, 2019 in Munich, Germany. Please drop by our booth any time, or feel free to set up an appointment in advance. We look forward to meeting with you and discussing your ELS needs!

 

The Cimetrix Resource Center is a great way to familiarize yourself with standards within the industry as well as find out about new and exciting technologies. 

Our resource center features information about 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 the electronics assembly, semiconductor, SMT and other 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 many presentations featured in our resource center provide in-depth coverage from Cimetrix expert's presentations at many different conferences and expos around the world. Some of our most popular presentations are below.

• Getting the Most from the GEM Standard
• Addressing Connectivity Challenges of Disparate Data Sources in Smart Manufacturing
• Standards-based Multi-Source Data Collection in the Smart Manufacturing Era
• Smarter Manufacturing through Equipment Data-Driven Application Design

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

In the EDA Best Practices blog series, we have discussed choosing a commercial software platform, using that package to differentiate your data collection capabilities and how to choose what types of data to publish. In this post we will review why you should choose to provide an E164-compliant equipment model.

What is E164?

Equipment Data Acquisition (EDA) - also referred to as Interface A - offers semiconductor manufacturers the ability to collect a significant amount of data that is crucial to the manufacturing process. This data is represented on the equipment as a model, which is communicated to EDA clients as metadata sets. The metadata, based upon the SEMI E125 Specification for Equipment Self-Description, includes the equipment components, events, and exceptions, along with all the available data parameters.

Since the advent of the SEMI EDA standards, developers and fabs have recognized that equipment models, and the resulting metadata sets, can vary greatly. It is possible to create vastly different models for similar pieces of equipment and have both models be compliant with the EDA standards. This makes it difficult for the factories to know where to find the data they are interested in from one type of equipment to another.

Recognizing this issue, the early adopters of the EDA standards launched an initiative in to make the transition to EDA easier and ensure consistency of equipment models and metadata from equipment to equipment. This effort resulted in the E164 EDA Common Metadata standard, approved in July 2012. Another part of this initiative was the development of the Metadata Conformance Analyzer (MCA), which is a utility that tests conformance to this standard. With this specification, equipment modeling is more clearly defined and provides more consistent models between equipment suppliers. This makes it easier for EDA/Interface A users to navigate models and find the data they need.

Power of E164

The E164 standard requires strict name enforcement for events called out in the GEM300 SEMI standards. It also requires that all state machines contain all of the transitions and in the right order as those called out in the GEM300 standards. This includes state machines in E90 for substrate locations and in E157 for process management. The states and transition names in these state machines must match the names specified in the GEM300 standards.

These requirements may seem unnecessarily strict, but implementing the common metadata standard results in:

• Consistent implementations of GEM300
• Commonality across equipment types
• Automation of many data collection processes
• Less work to interpret collected data
• Ability for true “plug and play” applications
• Major increases in application software engineering efficiency

Knowing that a model is E164 compliant allows EDA client applications to easily and programmatically define data collection plans knowing that the compliant models must provide all of the specified data with the specified names. For example, the following application is able to track carrier arrival and slotmap information as well as movement of material through a piece of equipment and process data for that equipment.

This application will work for any GEM300 equipment that is E164 compliant. The client application developer can confidently create data collection plans for these state machines, knowing that an E164-compliant model must provide the needed state machines and data with the proscribed names.

Decide to be E164 compliant

A number of leading semiconductor manufacturers around the globe have seen the power of requiring their equipment suppliers to provide EDA/E164 on their equipment, and now require it in their purchase specifications.

If you are a semiconductor manufacturer, you should seriously consider doing the same because it will greatly simplify data collection from the equipment (and most of your candidate suppliers probably have an implementation available or underway.

If you are an equipment supplier and your factory customers have not required that your EDA models be E164 compliant, you should still seriously consider providing this capability anyway as a way to differentiate your equipment. Moveover, E164-compliant models are fully compliant with all other EDA standards. Finally, it is much easier and more cost effective to create E164-compliant models from the outset than it is to create non-compliant models and then convert to E164 when the factory requires it.

Conclusion

The purpose of the E164 specification is to encourage companies developing EDA/Interface A connections to implement a more common representation of equipment metadata. By following the E164 standard, equipment suppliers and factories can establish greater consistency from equipment to equipment and from factory to factory. That consistency will make it easier and faster for equipment suppliers to provide a consistent EDA interface, and for factories to develop EDA client applications.

For the last couple of years, we have published a number of beneficial series in this forum to help contribute to the understanding of many of the standards in the manufacturing industry. In case you missed some of them, we are going to re-cap and link to the most popular today.

GEM Features and Benefits

This series features 15 separate posts with videos and information on some of the most important aspects of the GEM (SECS/GEM) standard. This series is one of our most popular ever and was written by a number of the Cimetrix engineering team who have studied and practiced GEM for many years.

EDA Application and Benefits in Smart Manufacturing

With the adoption of the latest SEMI EDA (Equipment Data Acquisition, also known as Interface A) standards accelerating significantly over the past 2 years, we felt it was time to highlight the applications across the industry that make the best use of these standards, and the specific manufacturing benefits that result. 

Models in Smart Manufacturing

In this series, we highlighted the importance of explicit and standardized models in the context of equipment communications interfaces and some of the “smart” factory applications they support. 

EDA Testing

Since the EDA/Interface A adoption process has now clearly reached critical mass, we must seriously address the question “How are we going to test the equipment and systems that incorporate these standards?” This is an excellent question, and one that has a multi-part answer, which is addressed in this 6-part series.

These, and many others including a the Cimetrix Book Club and Meet-the-Team series are some of what you can find on our blog. Be sure to subscribe today!

The Cimetrix Resource Center is a great way to familiarize yourself with standards within the industry as well as find out about new and exciting technologies.

Our resource center features information about 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 the electronics assembly, semiconductor, SMT and other 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 videos and video series featured in our resource center provide in-depth coverage of some of these concepts.  Some of our featured videos are below.

• Smart Manufacturing Series by Ranjan Chatterjee
• What Happens in a Gigafactory Minute
• Cimetrix at IPC Apex 2019
• The Big Picture: EDA Overview and Mechanics

Be sure to stop by our Resource Center any time or watch the videos directly from the links in this posting.

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.

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.