Industry News, Trends and Technology, and Standards Updates

Standards Activity Report SEMI NA Spring 2021

Posted by Brian Rubow: Director of Solutions Engineering on May 12, 2021 11:45:00 AM

Stcked_Standards_logoFor the first time since the Fall of 2019, the SEMI North America Information & Control Committee (I&CC) was finally able to meet and conduct business online. Throughout all of 2020, the I&CC was not able to meet because SEMI regulations did not at that time allow voting in online meetings. Instead, only the task forces have been meeting. As a result, any passing ballots, unless super clean, had to wait for adjudication in the North America I&CC.

This year, prior to the I&CC meeting on April 1 and 2, all of the associated task forces also met as usual, including the GEM 300, Diagnostic Data Acquisition (DDA), and Advanced Backend Factory Integration (ABFI) task forces. Moreover, the I&CC was able to conduct all the unresolved business that had accumulated over the last year. During the committee meeting, the I&CC successfully used the SEMI Virtual Meeting (SVM) software which runs in an internet browser, allows each committee member to log in, and allows for official voting to take place during the meeting. The North America I&CC will meet again during the summer.

GEM 300 Task Force

In the GEM 300 task force, the primary activity was to officially redefine its charter and scope to match what it has already been doing for the last 20 years. Each SEMI task force defines a “Task Force Organization Force” document (aka TFOF) to establish its charter and scope. Somehow, the GEM 300 task force charter and scope were severely out of date.

In addition to this update, some changes to the E5 standard finally passed voting, pending some final approval. The E5 changes include several new messages and establish definitions for commonly used data collection terminology. The new messages complement the existing set of messages by allowing the host to query information about the current data collection setup. Currently, it is common for a host program to reset and redefine all data collection after first connecting to an equipment because there has been no way to query this information. With these new messages, the host will be able to query the setup and confirm that no data collection has changed while disconnected. Finally, it will be easier to test GEM interfaces with these new messages.

The task force already approved tasks to consider some major work to the GEM standard. The task force is also considering changes to the E116 standard, but there is some resistance to these changes. Here is a summary table of the GEM-related standards activity from across the globe.

Region

Ballot

Standard(s)

Status

Topic

South Korea

5832

New

Cycle 5, 2020

Generic Counter

South Korea

6695

E87

Adjudication

Ready to unload prediction changes.

North America

6572

E30

Development

Add Stream 21, more stream 2, Cleanup Process Program Management.

North America

6552

E5

Adjudicated Spring 2021

Data collection setup, terminology. Ratification ballot proposed.

2 line-items pending since Summer 2020

North America

6598

E37, E37.1

Cycle 7, 2020

Standardize TCP/IP port numbers

North America

6597

E173

Adjudicated Spring 2021

Minor updates, clarification

Pending since Spring 2020.

North America

6647

E116

SNARF Revision

Recommendations from the ABFI task force

North America

6683

E148

Development

Line item revision

 

DDA Task Force

In the Diagnostic Data Acquisition (DDA) task force (responsible for the EDA standards, aka Interface A), freeze 3 development is moving forward. All of the ballots still failed as expected. The number of remaining technical issues nevertheless has dwindled to just a handful. E132, E125, and especially E164 need the most work.

Following is a summary of the previously completed work.

Standard (Ballot)

Ballot Status

Lead

E132 (6337)

Published - 04/29/2019

Brian Rubow (Cimetrix)

E138 (6336)

Published - 03/15/2019

Brian Rubow (Cimetrix)

E134 (6335)

Published – 03/29/2019

Inhyeok Paek (Link Genesis)

E120 (6434)

Published – 05/30/2019

Inna Skvortsova (SEMI)

E145 (6436)

Published – 05/31/2019

Inna Skvortsova (SEMI)

E178 (6300)

Published – 01/10/2020

Mitch Sakamoto (ZAMA)

E179 (6344A)

Published – 03/27/2020

Albert Fuchigami (PEER)


And here is a summary of the work in progress.

Standard (Ballot)

Ballot Status

Lead

E125 (6718)

Development

Brian Rubow (Cimetrix)

Hyungsu Kim (Doople)

E132 (6719)

Development

Mitch Sakamoto (ZAMA)
Albert Fuchigami (PEER)

E134 (6720)

Development

Brian Rubow (Cimetrix)

E164

 

Alan Weber (Cimetrix)

E125.2 (6345)

Development

Albert Fuchigami (PEER)

E132.2 (6346E)

Development

Albert Fuchigami (PEER)

E134.2 (6347)

Development

Albert Fuchigami (PEER)

E125 (6527C)

To Abolish

Replaced by 6718

E132 (6571C)

To Abolish

Replaced by 6719

E134 (6553C)

To Abolish

Replaced by 6720

 

All of the failed ballots will be reworked and resubmitted for voting. For many of these ballots, it will be the sixth time to go through the SEMI ballot procedure. Consensus is very nearly achieved, and the defects in the ballots have been identified and corrected. Additionally, there are plans to modify SEMI E179, the standard that defines how gRPC will be utilized. While testing EDA freeze 3, Cimetrix has identified two simple ways to modify the E179 protocol buffer files in order to reduce overhead. These and a few other changes will be proposed in a new ballot.

One of the last changes to the freeze 3 standards will be the introduction of passwords. In the current freeze 1 and freeze 2 versions, there are no passwords. Any client that knows a valid, unused Access Control List entry (ACL, the equivalent of a user name) can connect; therefore, there really isn’t any authentication unless using the SSL protocol with certificates. Passwords will enhance EDA security and facilitate EDA interface setup by allowing client applications to use the same ACL entry while defining a unique password to block other clients from using the same entry. The final E132 ballot will finalize the password feature.

The task force leaders are asking the voting members to raise any final issues before these ballots are submitted to SEMI to the next voting cycle so that we can approve these standards, give implementers a chance to experiment with EDA freeze 3, raise any serious issues that impede the implementation, and then propose the final changes which incorporate that feedback. Until a version of these standards is formally approved, it will be difficult to get concrete and widespread feedback on the new technology, which is a necessary precursor to its adoption and use.

ABFI Task Force

The Advanced Factory Integration task force passed more changes in E142 without controversy. The task force plans to create E142.4, another GEM implementation of E142, designed for larger wafer maps to allow for increased traceability possibilities. Additionally, the task force continues to make plans to develop an adoption matrix as a new standard to describe when GEM and GEM 300 standards should be adopted in backend equipment based on equipment features.

Topics: Industry Highlights, SECS/GEM, Semiconductor Industry, EDA/Interface A, Doing Business with Cimetrix, Smart Manufacturing/Industry 4.0, GEM300, Standards

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.

Conclusion

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?

Good

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.

Better

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.

Best

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

Background

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:

EDA-Freeze-3-1-1

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.

Limitations

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 (ian.ryu@cimetrix.com).

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 인터페이스를 개발할 때, 최선의 개발 및 디자인 선택을 할 수 있도록 하였습니다.

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

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

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

  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.

Resources

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.

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.

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.

Resources

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