Industry News, Trends and Technology, and Standards Updates

Background

As one of the North American DDA Task Force co-leaders, I am often asked when EDA Freeze 3 will be ready to implement. The SEMI DDA Task Force has been working on developing an EDA Freeze 3 standard for several years. This is an updated version of the data collection standard for manufacturing equipment. Unfortunately, due to many factors, this work has been slow to develop. For more information on a “freeze version” see SEMI standard E178 where official freeze versions are defined.

Status

To date the following ballots have been completed:

At no point is an EDA client required to include the password or hashed password when establishing a session. To keep passwords secure, administrative EDA clients should use SSL when adding ACL entries. This increase in security is expected to allow for the adoption of EDA standards in a wider spectrum of applications.

Known Future Ballots

• An update to E164.
• Another update to E132, E125, and E134. A proposal was made to redefine the terms “client” and “consumer”. This week, the task force decided to go forward with this proposal.
  • The adoption of gRPC allows EDA clients to receive NewData messages with a bi-directional (full duplex) connection. In EDA freeze 1 and 2, SOAP message over HTTP are only one-directional. This new bi-directional use case muddied the meaning of “client” and “consumer”. The proposal will clarify how a “client” is the entity that initiates communication with the “equipment server”. When configured to do so, an “equipment server” can initiate communication with a “consumer”. So there may or may not be a consumer present.
  • EDA Freeze 3 also introduces three classifications of messages from the equipment server, heartbeat, operational, and notification messages. The heartbeat and operational are sent either to the client (in bi-directional mode), to the consumer or are disabled entirely. Notification messages can be sent to client and/or consumer.
• The task force plans to organize another test session open to anyone interested, where E132, E120, E125 and E134 can all be tested together. This had been planned for early 2023, but dates have not been proposed and these plans may slip. This test is expected to validate whether the published standards are ready. The task force leaders expect that some issues might be revealed and further changes to E125 and E134 may be required. If so, EDA freeze 3 might not be ready until spring 2024.
• An update to E178 Guide for EDA Freeze Version. This is the final step to officially declare the freeze 3 version.
  
  

To summarize, while the EDA Freeze 3 is not getting completed as quickly as most would like, the work is progressing. There aren’t any major hurdles at this time, but it lots of time and effort to complete the work that has already been planned.

Background

The North America Information & Control Committee (I&CC or NA I&CC) is comprised of several task forces including GEM 300, Diagnostic Data Acquisition (DDA), Advanced Backend Factory Integration (ABFI), Fab & Equipment Computer and Device Security (CDS), and Graphical User Interfaces (GUI). These task forces and the committee all met during the week of SEMICON West, July 11-13, 202. Not long ago, SEMI regulations were modified to allow TC Chapter (Committee) voting in virtual meetings; therefore, the standards activities continue to move forward. In-person task force participation was much higher than the last meetings, but remote participation also remains strong. This blog is a summary of the activities in each task force.

GEM 300 Task Force

Here is a summary of worldwide activities related to the GEM 300 task force as of the start of the GEM 300 task force meeting.

Three ballots were adjudicated during the GEM 300 task force meeting. The term “adjudication” means we review the voting and recommend handling of all negative votes and comments received to ultimately accept the ballot for publication or reject the ballot for rework. The recommendations by the task force are then finalized at the committee meeting. Usually, the task force recommendation is accepted by the committee, as was the case in all three ballots.

6916 E5

This ballot proposes to modify the E5 SECS-II standard and included the following minor changes:

• Allow data variable OperatorCommand to be type ASCII.
• Correct various typographical errors
• Remove the dependency between variables MDLN (equipment model number) and EqpSerialNum (equipment serial number).

This ballot passed after the only negative was withdrawn by the voter.

6572B E30

This ballot proposes to modify the GEM (E30) standard. It is a revision ballot, meaning the entire E30 standard is subject to review. This is the third time the ballot has been submitted. It is a major update to the GEM standard and includes the following changes:

• Process Program Management changes
  • The terms “recipe” and “process program” are currently used nearly interchangeably. The proposal is to use the term “process program” exclusively.
  • References to E42, large formatted and large process programs are moved out of the main standard and into the appendix.
  • Stream 21 messages are introduced for process program management, including both the single and multiple message techniques. This provides a simplified way for GEM interfaces to upload and download large process programs.
  • The entire process program management section is vastly reorganized to help implementers understand the available alternatives and the scenarios for each available alternative. New tables were introduced to compare and summarize implementation alternatives.
  • Collection event ‘Process Program Error’ is specifically listed as required, rather than just as an implied requirement.
• A series of new SECS-II messages are introduced including S2F51-S2F64. These are new capabilities to make a GEM interface more transparent.
• S5F7/F8 is added to the alarm management capability for similar reasons.
• Two new GEM documentation features are added and made available through the GEM interface using Stream 21 messages including PDF documentation and SEDD (see SEMI E172) documentation. This should make it easier to distribute GEM documentation and ensure that the right documentation is referenced.
• Two new equipment identification features are added, one to identify the equipment supplier and one to uniquely identify each individual equipment. This should make it easier to identify and track specific equipment on the factory floor.
• Some changes related to terminology are included. SEMI regulations recently were updated with a list of restricted bias terminology which are not allowed in any SEMI standards and a list of terms to avoid when possible.

This ballot failed due to a disagreement regarding a proposed change to the GEM control state model collection on transition 10 related to the host off-line state. The task force remains evenly divided on this issue; therefore, this change will be withdrawn from the next revision of this ballot.

I am optimistic that the 6572C revision of this ballot will pass voting with little controversy. This ballot has already been distributed to the task force for final review. Little controversy remains unless some voter raises a new issue.

6859 E116

Originally ballot 6859 intended to add significant new features to the E116 standard. However, the aggressive changes have been abandoned. Instead, this ballot is focused on making one change to E116. Currently the E116 specification implements collection events in a manner inconsistent with E30, E40, E87, E90, E94, E109, and E157. This E116 ballot failed. After further discussion in the task force, consensus on the proposed changes seems possible in the next voting cycle. The updated ballot 6859A has already been submitted for review by the task force.

DDA Task Force

The DDA task force has been and continues to update the Equipment Data Acquisition (EDA a.k.a. Interface A) standards with the goal to approve an EDA Freeze 3 set of standards based on gRPC technology. To date the following ballots have been completed:

During these meetings, three DDA task force ballots failed adjudication, 6927 (E125, E125.2), 6928 (E132, E132.2) and 6929 (E134, E134.2) due to procedural errors which violated SEMI regulations. This is primarily due to a long backlog of publications on previously approved specifications. Discussions were held in several meetings in an attempt to find ways to help SEMI get caught up on publications. The delay in publication is partly due to the several large ballots that were backlogged when COVID activity prevented the committee from completing adjudication in remote or hybrid meetings.

Test Session #1

The most important activity for the DDA task force was “vender test session #1” held on Thursday, July 14. An open invitation was made to all task force members to participate in an E132 test session. Anyone could submit a client and/or equipment server implemented with the current E132 and E179 specifications. Four companies came together and ran tests against each other’s software. Each participant will provide the task force with a list of issues in E132 and E179. This was a great opportunity to try the gRPC technology together and get a sense of what issues still need to be resolved before EDA Freeze 3 is complete.

DDA Freeze 3 Plans

The DDA Task force plans an update to E125, E132, and E134 including changes from the recently failed ballots as well as topics raised in the test session. Due to the expanded scope, new ballot numbers will be issued. Additionally plans to update E164 are also moving forward. The biggest challenge for E164 will be converting the XML files into JSON files. Either JSON5 or JSONC will likely be used since comments are mandatory in the E164 complementary files which show how to create GEM 300 capable EDA equipment models.

ABFI Task Force

The Advanced Backend Factory Integration task force is actively working on two ballots.
One ballot is a minor update to the E142, the substrate mapping specification which facilitates traceability and other application where substrate, tray, feeder, and other information can be shared between a factory and equipment. The minor update will add additional substrate types so E142 substrate maps can be used in more applications.

Additionally, the task force is working on ballots 6924 and 6925. The 6924 specifications will define the management of Consumable and Durables on manufacturing equipment. Features include allowing the host to accept or reject newly mounted consumables and durables. Additionally, the equipment will be able to report on consumable and durable usage. While technically both can already be done, the specification establishes a standard way for the features to be implemented. The 6925 ballot maps 6924 for usage in a GEM interface. The plan is to submit the ballot for the next voting cycle.

GUI Task Force

The GUI task force continues to work on a major revision of the E95 specification for Human Interfaces for Semiconductor Equipment. In addition to updating the specification with changes in software development, this revision will establish requirements for the usage of human interfaces on equipment using devices with small screens. The task force seems to be gaining consensus of many topics and getting ready to submit the ballot for voting.

Getting Involved

For those interested in participating, it is easy to join SEMI standards activities. Anyone can register at www.semi.org/standardsmembership.

All SEMI task force ballot activities are logged here.

After joining the standards activities, anyone can get involved. The task forces post everything on the connected @ SEMI website https://connect.semi.org/home. Here are the community names for the task forces covered in this blog:

• GEM 300 Task Force - North America
• Diagnostic Data Acquisition Task Force - North America
• Fab & Equipment Computer and Device Security (CDS) Task Force – North America
• Advanced Backend Factory Integration (ABFI) Task Force – North America
• Graphical User Interfaces (GUI) Task Force - North America

In the late 1980s and early 1990’s the Semiconductor Equipment Communication Standard (SECS) was starting to gain traction. Back then it was based on RS232 serial communication defined by the SEMI E4 SECS-I Standard. Later, SECS-I was replaced by the SEMI E37 HSMS standard. The content of the messages was defined by the SEMI E5 SECS-II standard. At the time, that was all that was defined. It was a bit like the Wild West with each equipment vendor implementing SECS-II messages as they saw fit.

While it was cool to be able to connect to process or metrology equipment and collect data, specify the process, and monitor alarms, it was a big task to develop factory systems that interface to the equipment because each SECS-II interface was unique. One of the first tasks required when developing an interface was to perform an equipment characterization to understand and document the details of the SECS messages used by each equipment. The characterization report became the guide for developing the factory side interface to that particular piece of equipment.

Semiconductor factories were buying hundreds of pieces of equipment for their factories, and though there were usually multiple pieces of the same equipment, there were still many unique equipment interfaces in each factory. The factories had to develop unique interfaces for all the equipment they wanted to automate. This issue was a bit like the tail wagging the dog.

To change things so that each equipment interface wasn’t completely unique, semiconductor factories worked with SEMI to better define how the communication between factory control systems and equipment should work in the factory. In 1992 SEMI published the first version of the E30 standard – Specification for the Generic Equipment Model for Communications and Control of Manufacturing Equipment (GEM). This standard provided a stable base for both factories and equipment manufacturers to work from in developing equipment interfaces. Message usage and contents were consistent, state models were defined, and interface capabilities were well-documented.

Since that time, other equipment communication standards have been developed and approved for use in semiconductor manufacturing. The GEM300 standards for factory automation (E39, E40, E87, E90, E94, E116, E148, and E157) have made it possible to enable fully automated manufacturing. The EDA standards (E120, E125, E132, E134, and E164) make it possible to implement consistent, well-defined data collection.

Even though the SEMI standards are quite well-defined, they are only as good as the implementation on the equipment. Compliance testing is essential for both equipment manufacturers and factories to ensure the interfaces are compliant to the standards and function as defined. In the early days of GEM, compliance testing was an essential piece of factory acceptance of the equipment. Initially, there wasn’t a lot of experience with developing or using the equipment interfaces. This meant that we needed some way to test compliance to ensure the interfaces worked as expected. Even though GEM and GEM300 are now quite established, compliance testing is still important to ensure the communication interfaces will support the functionality needed in the factories.

Compliance testing for the EDA standards hasn't been as well-defined as it has been for GEM and GEM300. In 2011 the International SEMATECH Manufacturing Initiative (ISMI) published the ISMI Equipment Data Acquisition (EDA) Evaluation Method document which provided step-by-step instructions for testing and evaluating an EDA interface. Using that document, Cimetrix developed EDATester which automates the instructions defined in the Evaluation Method document. This automation allows testing that would normally take several days to be done in a few hours, or less.

Having standard, well-defined communication interfaces for semiconductor manufacturing equipment is important to automated manufacturing and data collection. The ability to test developed interfaces and assure that they are compliant with the SEMI standards is essential to successfully introducing the equipment into a semiconductor factory.

Cimetrix compliance test tools automate the testing process making the acceptance process smooth.

For 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.

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.

And here is a summary of the work in progress.

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.

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.

The 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 EDAConnecter within the Cimetrix Sapience platform 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 benefits 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!

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:However, 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:In 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:The 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.

The 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.

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.

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.

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.

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:

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.

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. 스마트팩토리 솔루션

감사합니다.

The Cimetrix CIMPortal^TM 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)

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.

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.