Industry News, Trends and Technology, and Standards Updates

Thinking Ahead: Why would I want to buy EDA client libraries for my equipment?

Posted by Alan Weber: Vice President, New Product Innovations on Nov 11, 2020 11:30:00 AM

Background and Audience

Over the past several years, I have written numerous blog postings heralding the benefits of the SEMI Equipment Data Acquisition (EDA, also known as Interface A) standards, promoting their adoption by 300mm wafer fabs around the world, explaining how to develop robust purchase specs to ensure the interfaces delivered by the equipment suppliers meet the fab customers’ expectations, describing how the various components of the standards work together and the importance of the embedded equipment model, and finally explaining how to run compliance and performance tests on an EDA interface to validate its fitness for production use. The target audience for most of these postings has been the factory users, for they are the ones who increasingly depend on detailed equipment and process data to profitably run their enterprises.

By contrast, this posting is aimed at the equipment suppliers who are looking to increase the value of their product families by augmenting their hardware offerings with software capabilities that only they are uniquely qualified to provide.

This is not a new idea. Several major equipment suppliers have offered so-called “Equipment Engineering Systems (EES)” products as companions for their equipment over the years, providing applications like Fault Detection and Classification (FDC), production monitoring, maintenance management, local repositories for diagnostics and field support, and other capabilities that leveraged deep domain knowledge of the equipment. However, these systems necessarily relied on private interfaces to the equipment for their data, such as an additional network connection, direct access to the file system, or other mechanisms. And from the fab’s perspective, these constituted yet another piece of infrastructure to maintain.

Now there’s EDA: a key enabler for value-added equipment applications

Since the SEMI EDA standards are inherently multi-client, a single EDA interface can support not only the factory information and control systems that depend on equipment data, it can also provide whatever information a supplier-specific application may need as long this data is represented in the equipment metadata model. Since that model is designed by the equipment suppliers as a fundamental component of the EDA interface, they can choose to put as much information in these model as they want, possibly well beyond that required by the fab customers’ purchase specifications. In fact, these models could be used to implement the diagnostic logging capability that suppliers usually build into their equipment for their own use, but without requiring custom software to read and interpret that information. See the figure below for an example of such a configuration.

EDA-Equipment-1The EDA standards also include a provision for “built-in DCPs” (DCP = Data Collection Plan) which can be shipped with the equipment and protected from accidental deletion at the factory site. These DCPs could be crafted by the equipment supplier to directly feed whatever value-added applications the supplier chose to develop, whether these resided on a computer local to the equipment in the fab, on portable computers used by field service engineers to diagnose problems, or on remote cloud-based systems allowed to connect via secure EDA-defined URLs. This flexibility opens up a wide range of application types, from those that embed equipment-specific algorithms to generic Machine Learning frameworks… the possibilities are endless.

What all these approaches have in common is a standard EDA client capability that can establish a session with the equipment, activate Data Collection Plans, and receive the ensuing Data Reports. The Cimetrix EDAConnect product provides all these features and more in a lightweight set of .NET libraries which can be deployed wherever they are needed to consume EDA data.


More and more semiconductor factories are requiring EDA interfaces with their new equipment purchases with highly prescribed equipment models and demanding performance criteria. From the equipment supplier’s perspective, these requirements have been viewed as a source of additional cost, with all the benefit accruing to the factory customers. But it doesn’t have to be that way…

Why not take advantage of this interface to offer additional value using a standards-based approach? This just might be an idea whose time has finally come. If you agree, give us a call – we can help you make it happen!

Topics: Industry Highlights, Semiconductor Industry, EDA/Interface A, Doing Business with Cimetrix, Standards

Best Practices in EDA Metadata Model Design: EDA Exception Consolidation

Posted by Derek Lindsey: Product Manager on Mar 31, 2020 11:45:00 AM

You may be familiar with the brain teaser that starts, “As I was going to St. Ives, I met a man with seven wives.” As the poem continues, each wife has seven sacks, each sack has seven cats, etc. Eventually the question comes out, “How many were going to St. Ives?” The common misconception of this brain teaser is that to answer the question you must multiply all of the items together, resulting in a huge number.

Cimetrix has extensive experience in helping application developers integrate the Equipment Data Acquisition (EDA) / Interface A standards into their equipment control applications. Occasionally we encounter an equipment type that has a very large number of process modules and each process module has a very large number of exceptions. An exception in EDA Freeze II is represented by both an exception definition and an exception instance. What are the options for creating a model with a large number of exceptions?


The most direct approach is to have one exception definition per exception instance as shown in the following EDA equipment model:exception-consolidation1However, with this approach, if each module has 5000 exceptions, 200 modules would result in 1 million exception instances with a corresponding 1 million exception definitions. The system resources required to deploy and maintain this model are very large.


EDA allows multiple exception instances to refer to a single exception definition. The following model shows this approach:exception-consolidation2In this example, we can see that the process module has ten exception instances, but now there is only one set exception definition. Using this approach, if each module has 5000 exception instances, 200 modules would still result in 1 million exception instances, but we would now only have 200 exception definitions (one for each module). This is a significant reduction, but still quite large.


The best approach for equipment with many process modules each with a large number of exceptions is to define only a few distinct exceptions per module, and then use a transient parameter (or data variable) to indicate the actual cause of the problem. The following model shows how this might look:exception-consolidation3The process module in the model above only has one exception. The transient parameter AlarmCode would contain the information about what caused the exception to be triggered. It is possible to have multiple exception parameters if additional information is necessary (sub error code, description, etc.)

The EDA standards reference four exception severity levels – Information, Warning, Error, and Fatal. If we create one exception definition for each of these severities and no more than four exception instances per module, we see that a model with 200 modules would have four exception definitions and an upper limit of 800 exception instances.

This approach to exception consolidation benefits equipment makers and factories alike by reducing model complexity and model size.

The answer to the brain teaser above is that only one person was going to St. Ives – me. You don’t have to spend a lot of time and effort trying to figure out how many people, cats, etc. were in the other party, because they were travelling in the opposite direction! Similarly, if you consolidate your exception handling in EDA, you don’t have to spend a lot of time and system resources trying to handle too many exceptions.

Topics: Industry Highlights, EDA/Interface A, Doing Business with Cimetrix, EDA Best Practices

Are you now required to work from home? Don’t let it cripple your EDA-related activities!

Posted by Alan Weber: Vice President, New Product Innovations on Mar 25, 2020 1:15:00 PM

WFHEDA1The COVID-19 pandemic is impacting businesses worldwide, and in many regions, working from home is now mandatory or at least strongly encouraged.

While this doesn’t pose a major disruption for many types of jobs, it can be problematic for people working with the automation features of advanced manufacturing equipment. The network connections to production equipment are normally part of a secure factory system infrastructure, which makes them almost impossible to reach from outside the company’s intranet. Luckily, for those responsible for testing and characterizing the SEMI EDA (Equipment Data Acquisition, also known as Interface A) interfaces on new 300mm equipment, this should only be a minor inconvenience. And why is that?

The choice of internet technologies (Web Services, SOAP/XML) as the foundation for the EDA standards makes it easy to connect to a piece of equipment over the internet as long as the user’s client computer can “reach” the connection URLs of the equipment (and vice versa). What this probably means in practice is setting up a VPN (Virtual Private Network) connection from your client computer (say, the laptop you normally use) to the company’s network. This is something that road warriors and remote employees must often do as a matter of course to access internal file systems, in-house applications, and other private information.

Once this is done, you can connect to the various service URLs for that equipment by including the remote computer name in the session connection strings. Note that you may have to modify the firewall settings of your client machine so the E134 NewData messages can find their way back to you. This is necessary because these are NOT request/reply messages like many of the EDA services; rather, they are initiated from the equipment, so your application has to be listening for them on the Consumer URL. This address is passed to the equipment when the connection session is first defined and established.

Using the Cimetrix ECCE Plus client product as an example, here is how I would set up a remote (from home!) session with an EDA-enabled 300mm equipment simulator running in our office on a machine named “edasimulator.” The first screenshot shows the choice of connections defined for my instance of the ECCE Plus; note that last one in the list that is highlighted.WFHEDA2png

Clicking on the “Edit Session Definition” button and then the “More >” checkbox yields the screen below. You can see that the equipment IP address is “edasimulator” (the remote computer name referenced above) and each of the Freeze II service URLs (E132 Location, E125 Location, and E134 Location) for the session are defined on that machine.WFHEDA3

Note that the client ID (From/Client Name), which is “MyHomeTestClient,” must also be defined in the equipment’s Access Control List (ACL). For me to be effective, this client must have sufficient privileges for the kinds of work I need to do, which may include using existing DCPs (Data Collection Plans), creating additional DCPs, viewing interface configuration parameters (e.g., Max Sessions) and ACL entries, browsing the metadata model, and looking at the SOAP logs. Results of some of these tasks using the ECCE Plus are shown below.WFHEDA4WFHEDA5pngWFHEDA6WFHEDA7png

This may sound like a lot of trouble, but with a little help from your company’s IT support team, you can follow the “shelter in place” guidelines and STILL work effectively on your EDA-related tasks. And when the current crisis has passed, you’ll know how to be even more effective when you’re on the road!

We hope the posting is useful for you, and most importantly, that you and your loved ones stay safe and calm.

Topics: Industry Highlights, EDA/Interface A, Customer Support, Partners, Doing Business with Cimetrix

Cached Data: A New Feature in EDA Freeze 3

Posted by Brian Rubow: Director of Solutions Engineering on Jan 22, 2020 11:15:00 AM


Several years ago, I was working with a client implementing EDA who wanted to collect data at higher than typical rates using the EDA trace data collection feature (essentially periodic data polling). The typical EDA data collection rate I was used to was 10 Hz, with a couple of clients implementing 20 Hz or even 40 Hz. This client, however, wanted to collect data at about 1000 Hz. This was a lot faster than we normally could accomplish, especially since the software timers and clock functionality in Windows are really designed for about 15 ms intervals. Therefore, the normal means of implementing the data collection was not going to work very well.

With a little creative thinking, I came up with a solution. Instead of using trace data collection, I decided to try event data collection. Every 1 second, I triggered an event notification and provided 1000 data samples with the event that had been collected at 1 ms intervals and stored. The 1000 samples were presented to the EDA client as an array of data, which EDA supports directly, and this solution worked very well. I also found that this approach used surprisingly few resources to implement and transmit, largely because the data is so compact. It was also very reliable.

Although this event with array data solution worked in this very specific situation, there were a few drawbacks. First of all, the client could not choose the data collection interval. Normally with trace data collection the client chooses the data collection rate to meet the needs of a specific data collection application. Secondly, the client receiving the data had to know what the data meant. The client application software had to be programmed to understand that each value in the 1000 sample array represented data collected every 1 ms. Finally, I could not use the trace start trigger and stop trigger to automatically enable and disable the reporting of the data collected. Normally, trace data collection can be started and stopped automatically to collect data between specific equipment events, which is a nice feature to focus data collection between specific processing steps or other meaningful activities.

EDA Freeze 3

A couple of years ago, the SEMI North America DDA (Diagnostics and Data Acquisition) task force, which I co-lead, decided to begin work on the next version of the EDA standards suite, commonly referred to as EDA Freeze 3. As part of this work, I raised an issue that I wanted our task force to address. That is, I wanted to be able to collect data using the EDA standard at higher frequencies than the typical 10 Hz available using today’s trace data collection. In particular, I wanted to leverage what I had learned using the event data array solution to report data collection at 1000 Hz and faster, and make this an integral part of the EDA standard without the limitations of my current solution. This new feature is now called Cached Data.

Cached Data Features

The basic principle behind this new feature is simple. First, allow the EDA client to define a Cached Data Request and specify the reporting frequency, data collection frequency, and other attributes like the number of samples, a start trigger, a stop trigger, and whether or not the triggers are cyclical. Then have the EDA server report the data for each parameter as a compact data array.

For example, an EDA client might ask for a parameter at a collection interval of 0.1 ms (10 KHz) and a reporting interval of 1 second. The result would be a set of Cached Data Reports that look like this:


The equipment would collect the data every 0.1 ms and store the values for 1 second, and then send the Cached Data Report with the collected values in a tightly packed array. The EDA client would receive the data once per second and would know the data collection frequency.


There are some limitations to the Cached Data proposal. For example, this type of data array reporting is only practical for some data types like integers, floats, Booleans and bytes. This type of data reporting is not practical for structured data or strings. Moreover, not all data can or should be collected at such high rates. Collecting data at these high rates requires robust software specifically designed for high-speed data collection. Therefore, the EDA proposal includes a way for parameter metadata to specify where the cached data feature can be used, and includes the specific minimum and maximum data collection frequencies. Therefore, the Cached Data feature is expected to be used for a limited subset of the available parameters for which the EDA server is specifically designed to provide such high-speed data collection.

gRPC & Protocol Buffers

The proposed EDA Freeze 3 standards also include the use of gRPC and Protocol Buffer technology, thereby moving EDA away from SOAP/XML over HTTP. gRPC with Protocol Buffers is a solution for a binary interface. Prelimiary test results reported to the DDA task force show dramatic throughput improvements and reduced bandwidth requirements for EDA. Additionally, the testing confirmed that reporting data in compact arrays is far more efficient for transmitting large amounts of data. In other words, the Cached Data feature is expected be even more effective due to this EDA protocol change.

SEMI Voting

Soon a new voting cycle for SEMI standards will begin where we vote on new versions of the standard. The Cached Data feature is included in two SEMI ballots: ballot 6553, a major revision of the SEMI E134 SPECIFICATION FOR DATA COLLECTION MANAGEMENT, and ballot 6527, a major revision of the SEMI E125 SPECIFICATION FOR EQUIPMENT SELF DESCRIPTION. Both are planned for voting in SEMI voting cycle 2 in 2020. Task force members are currently reviewing the latest revision of the proposed ballots.
Studies have already shown vast improvements in factory applications when collecting data at 10 Hz instead of 1 Hz. The increased performance of EDA Freeze 3 will allow the industry to dramatically improve manufacturing processes even more when data can be collected and reported at rates of 1000 Hz, 10 KHz, and beyond.

Topics: Industry Highlights, Semiconductor Industry, EDA/Interface A, EDA Best Practices

Cimetrix Korea presents the 5th Annual EDA/Interface A Seminar in Seoul - Registration is open now!

Posted by Hwal Song on Dec 26, 2019 5:45:00 PM

Cimetrix Korea is happy to announce that the 5th EDA (Equipment Data Acquisition) Seminar will be held on January 15th, 2020. It will be co-hosted with Linkgenesis, the regional distributor of CIMPortal Plus, the EDA suite from Cimetrix.

As EDA has expanded its footprint as the preferred industry standard among leading IDMs in the world of big data, AI, Machine Learning, and Industry 4.0, equipment makers face the challenges of delivering the new requirements of EDA without fully understanding its fundamental objectives, technologies, and benefits.

This seminar is designed with highly practical sessions where speakers will share their personal experiences and insights as developers to help software engineers at the equipment suppliers understand the most efficient ways to implement robust EDA interrfaces.

For registration and questions, please email Ian Ryu (

Topics include the following:

  1. Global and domestic EDA trends, including Freeze III, that will introduce major performance improvements.
  2. EDA spec review – A summary of key contents from the newest and most demanding EDA specifications that a developer must know.
  3. EDA modeling methodology and important lessons learning that Cimetrix engineers have gained while supporting many new EDA customers.
  4. Testing methodology used during development and needed for EDA acceptance to ensure that standards compliance and interface performance expectations are met.
  5. Other general topics
    a-Software roadmap for equipment makers
    b-Smart factory

We look forward to seeing you at the seminar!

씨메트릭스 코리아는 파트너사인 링크제니시스와 공동으로 제5회 EDA 세미나를 2020년 1월 15일에 개최하게 되었음을 기쁘게 생각합니다. 최근 몇년 간 EDA가 국내뿐 아니라 해외 반도체 제조사에서 빅데이터, AI, 인더스트리 4.0에 부응하기 위해 업계 표준으로 자리를 잡아감에 따라, 여러 장비회사들은, 복잡한 EDA 요구사항을 충분히 이해하지 못한 상황에서 관련된 요구사항을 개발해야하는 도전에 처해 있는 상황입니다.

한국에서 개최되는 금번 세미나는 실용적인 방법론을 최대한 강조한 세션들로 구성되어, 발표자들이 지난 수년 동안 쌓은 개발자로서의 경험과 통찰력을 최대한 공유함으로 참가한 개발자분들이 각자의 회사로 돌아가 EDA 인터페이스를 개발할 때, 최선의 개발 및 디자인 선택을 할 수 있도록 하였습니다.

참석하시는 분들에게 실전에 도움이 되는 유익한 시간이 되시리라 생각됩니다.

세미나 등록이나 기타 질문은 유종하 팀장 (에게 연락 주시기 바랍니다.

세션은 아래와 같이 진행됩니다.

  1. EDA의 국내외 동향(FREEZE III 포함) EDA 관련 업계 현황과 큰 성능개선을 기대하는 Freeze III 소개
  2. EDA Spec Review : 개발자로서 알아야 할 새롭고 복잡한 EDA  스펙의 키포인트 정리
  3. EDA 모델링 개발 지원 경험 공유 – EDA를 신규 개발하는 여러 회사를 지원하며 축적된 경험 공유 및 방향성 제시
  4. 개발 및 납품 시 테스트 방법론 – 개발과 검수 효율성을 향상
  5. 일반 주제
    1. 장비회사에서 가져야 할 소프트웨어 로드맵
    2. 스마트팩토리 솔루션


Topics: Industry Highlights, Semiconductor Industry, EDA/Interface A, Doing Business with Cimetrix, Events

EDA Programmatic Model Building

Posted by Derek Lindsey: Product Manager on Nov 27, 2019 11:00:00 AM

The Cimetrix CIMPortalTM Plus software product allows users to achieve compliance with the SEMI Interface A standards. This includes E120, E125, E132, E134 and E164. A key element in enabling the data collection provided by Interface A is the equipment model, which has three main purposes:

  1. It defines the structure and relationships of the components that make up equipment (E120)
  2. It defines the data (parameters, events and exceptions) that are available to be used in data collection (E125)
  3. It defines the supporting structures (state machines, parameter type definitions, logical elements, etc.) for creating objects throughout the life of the running equipment (E125)eda-programmatic-model-building-pic-1

Part of the CIMPortal Plus Software Development Kit (SDK) is an application called Equipment Model Developer (EMDeveloper for short) that uses a simple drag and drop interface to allow CIMPortal Plus users to create a fully EDA-compliant equipment model. This includes making the model compliant with the E164 (Specification for EDA Common Metadata) standard which incorporates best practices from many production EDA implementations by defining common structures and other important conventions for the equipment metadata.

While EMDeveloper makes it simple to create, validate and deploy a fully compliant equipment model, there are times when equipment manufacturers want to provide a more flexible way of creating the equipment model. For example, an equipment manufacturer may offer multiple configurations of a unit of equipment with different arrangements of load ports and/or process module combinations. It is possible for the equipment supplier to save multiple equipment models that are shipped with each equipment, but this opens the door for possible human error in deploying an incorrect model file. It is also possible to create a “master model” that has all possible components defined. When the model is deployed, the equipment developer can use DisableModelNode functionality to disable the components that are not present. However, this approach may also result in errors, and is in the “gray” area of the standards (i.e., it is possible, but not encouraged).

Wouldn’t it be convenient if there was a way to create a model that exactly matched the equipment configuration?

We wouldn’t have a blog post if we didn’t already a positive answer to this question! EMDeveloper uses an API provided by the CIMPortal Plus CxModelLibrary. It does not use any sleight of hand or backdoors to create the equipment model. If a CIMPortal Plus user had the desire to do it, they could recreate EMDeveloper on their own. The API provided by CxModelLibrary allows users to programmatically create an EDA-compliant equipment model that exactly matches the desired equipment configuration.

When using programmatic model building, Cimetrix recommends first becoming familiar with the available API and determining the model building approach that works best for your equipment. The Solutions Engineering team at Cimetrix provides a sample application (including source code) that shows how to programmatically build an equipment model. This sample builds an E164-compliant model. In other words, all the expected parameters, events and exceptions and associated structures required by the standards are included as part of the resulting model.eda-programmatic-model-building-2

The EDA standards – and specifically E164 – define the types of data that are required for various components in the equipment. For example, each substrate location in the model is required to implement a SubstrateLocation state model. Moreover, this state model must appear within the equipment node in the model hierarchy that matches the physical structure of the equipment. This sample illustrates best practices in constructing model objects that can be reused based on the type of component. Programmatic model building may take a little more investment up front, but in the end, it can pay big dividends to those equipment providers that may need to change their equipment model on the fly depending on its configuration.

Once a model has been programmatically created/modified, Cimetrix also provides an API for validating the model, deploying the model to be used by an EDA client and creating an Access Control List (ACL) entry to allow a client to securely connect to the interface and gather data.

There is also a provision in the standard for addressing the concern that if the model is updated dynamically, an EDA client may have data collection plans (DCPs) that become out of sync with the modified model. In this case, the client is notified of model changes, and can also be designed to dynamically update the data collection plans based on the changes.

The Cimetrix CIMControlFramework (CCF) product makes use of this programmatic model building functionality. CCF dynamic model building is described in a blog post that you can find here.

To learn more about the EDA/Interface A standards, CIMPortal Plus or programmatic model building, click below and a Cimetrix expert will contact you. 

Topics: Industry Highlights, Semiconductor Industry, EDA/Interface A, Smart Manufacturing/Industry 4.0, EDA Best Practices

Resources Round-up: Presentations

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

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

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


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

EDA Best Practices Series: Choose to Provide E164-Compliant Models

Posted by Derek Lindsey: Product Manager on Aug 28, 2019 11:42:00 AM

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.eda-best-practice-e164-1

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.


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.

Contact Us

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

Resources Round-up: Videos

Posted by Kimberly Daich; Director of Marketing on Aug 3, 2019 1:28:00 PM

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

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


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

EDA Best Practices Series: Specifying and Measuring Performance and Data Quality

Posted by Alan Weber: Vice President, New Product Innovations on Aug 1, 2019 12:14:00 PM

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.edabest-measure-1
  • 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.

Contact Us

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