Industry News, Trends and Technology, and Standards Updates

Derek Lindsey: Product Manager

Derek Lindsey has been an employee of Cimetrix for over 22 years. For 21 of those years, Derek was a member of the product development team and was involved in the development of several of Cimetrix products. He also has extensive experience working with Cimetrix customers in implementing their tool control solutions using our products. He recently joined the product management team to help add some technical expertise to product development. Derek has a bachelor’s in computer science from Brigham Young University.
Find me on:

Recent Posts

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 Standards, EDA/Interface A, Doing Business with Cimetrix, EDA Best Practices

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 Standards, Semiconductor Industry, EDA/Interface A, Smart Manufacturing/Industry 4.0, EDA Best Practices

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 Standards, EDA/Interface A, Doing Business with Cimetrix, Smart Manufacturing/Industry 4.0, Cimetrix Products, EDA Best Practices

EDA Implementation Insights: What Data Should I Publish?

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

Previous blog posts have discussed the merits of choosing a commercial software platform for implementing the equipment side of EDA (Equipment Data Acquisition) and how you would use that package to differentiate your equipment data collection capabilities from your competitors.

In this post, we discuss how to design the equipment model to contain enough information to make it useful without publishing so much data that it becomes cumbersome for your factory customers to find the data that is most important to them.

Data to Publish

The automation requirements for the most advanced fabs call for the latest versions (Freeze II) of all the standards in the EDA suite, including the EDA Common Metadata (SEMI E164) standard. In addition to providing an excellent foundation for a new equipment model, E164 enables consistent implementation of GEM300, commonality across equipment types, automation of many data collection processes, less work to interpret collected data, and true plug-and-play client applications—all of which contribute to major increases in engineering efficiency. These capabilities benefit both the equipment suppliers and their factory customers alike. Therefore, equipment models should make all E164-compliant data available.

To summarize, those who remember the complexity of implementing SECS-II before GEM came along (pre-1992) will understand this analogy: E164 is to EDA what GEM was to SECS-II.

  • Fab-specified Data

The second blog post made the following statement:

“In effect, the metadata model IS the data collection 'contract' between the equipment supplier and the fab customer."

“This is why the most advanced fabs have been far more explicit in their automation purchase specifications with respect to equipment model content, going so far as to specify the level of detailed information they want to collect about process performance, equipment behavior, internal control parameters, setpoints and real-time response of common mechanisms.”

You only have to read the latest requirements specs for these fabs to get more specifics. Pick the one from your customer base that sets the bar highest and let that be your target.

Data to Avoid in the Model

It is easy to fall into the mindset that if publishing some data through the EDA interface is desirable, the more data we can publish, the better. This is not always the case. In his fascinating book, The Paradox of Choice, Barry Schwartz makes the case that freedom is defined by one’s ability to choose, but more choice doesn’t mean more freedom. In fact, too many choices actually cripple one’s ability to choose. The same can be said of data published in an EDA interface. Making too much data available actually hinders the creation of EDA client applications.information-overload-1-1

We were recently working with a fab to perform a proof-of-concept where we connected an EDA client to a piece of equipment with an EDA interface. We were able to connect to the equipment in a matter of minutes, but finding suitable data to collect for our proof-of-concept took almost an hour because there was so much superfluous data published from the equipment.

Publishing everything including the kitchen sink reduces the ability to create an efficient EDA client application.

Some examples of data to avoid publishing in the model include:

  • Parameters that have no value – If a parameter is available in the model, but the value is not published by the equipment control application, that parameter is just extra noise in the interface. Consider not adding it to the model.
  • Parameters with values that do not change – If a parameter value does not change during the life of the application, it does not make sense to collect that parameter’s data. For example, if an application uses an equipment constant, it may not be necessary to publish that constant through the EDA model.
  • Irrelevant data – If a parameter contains data that is irrelevant to data publication, it should not be added to the model. For example, having parameters in the model that contain the IP address or port number for connection are not very useful in the equipment model. This information is necessary in connecting with an EDA client, but is not relevant for data collection in the model.

The takeaway: Publish data required by E164 and additional fab-specified data, but carefully evaluate other data to be published to make sure it is relevant and useful for data collection.

If you have questions about Equipment Data Acquisition or would like a demo of the functionality described above, please contact Cimetrix to schedule a discussion

You can download an introduction to EDA White Paper any time.

Read the White Paper

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

SECS/GEM series: Equipment Terminal Services

Posted by Derek Lindsey: Product Manager on Apr 19, 2018 10:27:00 AM

After several articles in the series discussing data collection, events, alarms, recipe management and documentation, this post focuses on the Twitter of the GEM standard – Equipment Terminal Services. We will examine what terminal services are, why they are needed and the mechanics of how they work.

What are Terminal Services?

Equipment Terminal Services allows the factory operators to exchange information with the host from their equipment workstations. The host can display information on the equipment’s display device. It also allows the operator of the equipment to send information to the host. The equipment must be capable of displaying information passed to it by the host for the operator’s attention. 

Why Do You Need This Feature?

An example of when terminal services might be used is as follows:

  1. The host gets notified by the FDC software that the process module had an excursion that needs to be addressed.
  2. The host turns on an operator notification light on the light tower. The notification light needs to be accompanied by a reason that the light was illuminated.
  3. The host sends a terminal message saying that the FDC software detected an excursion and that the operator should address the issue.
  4. Along with the signal tower light, the terminal services notification is active on the tool.
  5. The operator sees and acknowledges the message.
  6. Optional: There are different ways to recover, but the operator could send a terminal message to the host after the issue is resolved.

secsgem-terminalservices-1

How Does Terminal Services Functionality Work?

When the host sends a terminal message to the equipment, the equipment is required to display the message to the operator. The display must be able to show up to 160 characters (even more than can be sent in a single tweet using Twitter) but may display more than that. The equipment’s display device must have a mechanism for notifying the operator that a message was received and not yet recognized by the operator. The message continues to be displayed until the operator recognizes the message. The equipment must provide a method, such as a push button, for the operator to acknowledge the message. Message recognition by the operator results in a collection event that informs the host that the operator has received the information. The equipment application is not required to interpret the data sent from the host. It is solely information meant for the operator.

If the host sends a new message is sent before the operator acknowledges a previous message, the new message overwrites the previous message.

The host may clear unrecognized messages (including the indicator) by sending a zero-length message. The zero-length message is not considered an unrecognized message.

The equipment must also allow the operator to send information entered from the operator’s equipment console to the host. 

Which messages are used?

Message ID Direction Description
S10F3 H->E Host sends textual information to equipment for display to the operator on a terminal
S10F1 H<-E Operator sends text message to host
S10F5 H->E (Optional) Host sends multi-block display message. If multi-block is not supported, the equipment responds with an S10F7 message that multi-block is not allowed.
S6F11 H<-E Equipment sends collection event to the host notifying the host that it has recognized the message

 

Click here to read the other articles in our SECS/GEM Features and Benefits series. 

To download a white paper on an introduction to SECS/GEM, Click below:

SECS/GEM White Paper

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

Equipment Control Logging Benefits

Posted by Derek Lindsey: Product Manager on Mar 8, 2018 11:02:00 AM

markets-timber-logging.jpg

Equipment control applications are highly complex and have many moving parts that require a high level of coordination. Because of the high degree of difficulty, problems are bound to crop up. Sometimes the problems are related to a hardware issue. Sometimes the problems are caused by operator error. Sometimes problems are timing related. Sometimes problems happen infrequently. Regardless of the frequency or the cause of the errors, how do you go about debugging issues that happen in the field if you are unable to attach a debugger to the application?
 
The answer is logging.

As part of the CIMControlFramework (CCF) product for creating equipment control applications, Cimetrix developed a logging package. Our logging package has two parts – collecting the log messages and analysis of the messages.

The logging package allows you to assign a source and a type for each log message. The source specifies where the log message originated. The type is a category that can be used to route the log 

messages to specific output locations called log sinks. We have found the most useful log sink to be a text-based log file. The logging package can be configured for the types of messages to log. It can also be configured for how long to keep log files and how many to keep. This helps keep hard drives from getting too full.

logging.bmp

The temptation for many users is to enable all log messages while developing the equipment control application and then turn all the logging off when the equipment ships to the factory. Cimetrix recommends leaving as much logging enabled as possible. This will help you avoid trips to the fab when a problem arises that can be solved via the logging package. Some clients worry about resource usage by the logging package. We have found that the impact of the logging package is light enough that it is advantageous to leave it on all the time.

The Cimetrix logging package was such a success in CCF, that we have started using the logging package in all Cimetrix products. The logging package has earned rave reviews from Cimetrix product users. Here are a few quick examples that show how valuable logging is:

1. An OEM customer called in a panic because because an end user was withholding payment due to a timing/throughput issue in the application. Together Cimetrix and the OEM reviewed the log file. Using some of the LogViewer analysis tools we were able to isolate and identify the problem within 30 minutes. The OEM was able to confidently tell the end user that they had found the problem and a fix would be available within the next software release. Because the OEM was able to support them so quickly remotely, the end user had confidence in the OEM and released the payment.

2. At Cimetrix, we often hear, “This only happened once, but…” With logging always enabled, it is possible to diagnose problems after the fact. This is especially important for problems which occur infrequently. Users of the Cimetrix logging package are able to resolve issues that happen only rarely.

3. Occasionally an equipment control application will deadlock – two different modules are waiting on each other and neither is free to proceed. Using the LogViewer’s Callstacks plug-in, in conjunction with the Timing Chart plug-in, make the process of diagnosing the deadlock much easier.

logging-1.png

4. An end user called up their OEM equipment provider because the software stopped unexpectedly. They wanted to OEM to put someone on a plane immediately to come diagnose the problem. The OEM was able to view the log file to see that an operator had stopped the tool without the supervisor realizing it. When asked, the operator confirmed he had stopped the tool. Crisis averted. No plane ride required by the OEM to satisfy their customer!

5. A client came to Cimetrix for a training class. This client brought in a contractor to attend the class as well. Part of the Cimetrix training was used to review the logging package. During a break in the training, the contractor approached the instructor and asked if he could purchase the logging package separately for use in his other contracts because he could see several applications that would benefit from the power of the logging package.

6. Cimetrix is continuing to add useful plug-ins to the LogViewer. We recently added an E84 (automated material handling system) plug-in to assist in implementing and debugging material transfer. LogViewer allows users to implement their own custom plug-ins for analyzing data important to them.

logging-2.png

These are just some of the success stories we have heard about in relation to the logging package. With equipment control applications and factory automation, there will always be issues to be addressed and opportunities to root cause unexpected behavior. Having a powerful logging package makes that process much easier.

 

Topics: Equipment Control-Software Products, Customer Support, Cimetrix Products

SECS/GEM series: Data Polling

Posted by Derek Lindsey: Product Manager on Jan 24, 2018 11:30:00 AM

GEM is an industry standard, which defines standard methods to communicate between process equipment and factory host software for monitoring and controlling purposes. By connecting GEM equipment, factories can immediately experience operational benefits. Factory hosts can collect data in multiple ways. A previous blog post discussed collecting data by using collection event reports where data is pushed to the host based state transitions performed by the equipment. In addition to event reports, the factory host often has a need to poll the equipment for current data values. Data values can be directly requested by the host, or can be sampled on a periodic basis in a trace report. This is called Data Polling and is the topic for today's discussion.

datapolling_281485322-.jpgTypes of Data

There are three types of data in a GEM interface:

  • Data Variable (DV) – data items that can be gathered when an equipment event occurs. This data is only guaranteed to be valid in the context of the event. For example, the GEM interface may provide an event called PPChanged (triggered when a recipe changes). The interface may also provide a data variable called changed recipe. The value of this DV is only valid in the context of the PPChanged event. Polling the value at a different time may have invalid or unexpected data.
  • Status Variable (SV) – data items that contain information about the equipment. This data is guaranteed to be valid at any time. For example, the equipment may have a temperature sensor in a process module. The GEM interface may provide a ModuleTemperature status variable. The host can request the value of this SV at any time and expect the value to be accurate.
  • Equipment Constant (EC) – data items that contain equipment settings. Equipment Constants determine how equipment will behave. For example, a GEM interface may have an equipment constant called MaxSimultaneousTraces which specifies the maximum number of traces that can be requested simultaneously from the host. The value of equipment constants is always guaranteed to be valid and up to date.

Data Properties

Each of the three data types listed above have similar properties that help define the data. The equipment supplier is responsible for providing these properties in a GEM manual so that the factory host will be able to interact with the data. Some of the important data properties are:

  • ID – a numeric ID that must be unique in the GEM interface. These IDs can be grouped by data type and are referred to as SVIDs (Status Variable IDs), DVIDs (Data Variable IDs) and ECIDs (Collection Event IDs).
  • Name – a human-readable name for the data item
  • Format – the data type of the item. 
    • Data formats can be simple (numeric, ASCII, Boolean) or complex (arrays, lists, structures). For example, numeric types can be I1, I2, I4, I8 (signed integer types of different byte length), U1, U2, U4, U8 (unsigned integer types) and F4 or F8 (floating point types). 
    • List and array types contain multiple values in the data item. For example, image data would be formatted as a byte array. 
    • Structure types contain a specific type of data. For example, a variable may represent a slot map which contains carrier information as well as a list of slots and their wafer placement status.
  • Value – the actual value of the data item. Data values are in an accurate, efficient, self-describing binary format so that the host will know how to interpret the data. The data format allows for collection of more data more efficiently.

Collection Events (CE) and Alarms also have IDs and names. These items are discussed in other blog posts, but it is important to know about some of the properties for this post because these properties can be queried as well.

Data Polling

As mentioned, the factory host will often get data on a regular basis through trace reports and event reports that it defines. GEM also provides a method for the factory host to poll data based on its needs.

Status Variables

The host can query the value of status variables at any time by sending an S1F3 message containing a list of SVIDs for which to obtain the value. If the list has a length of one, only the value of the single SV will be returned. If the list has a length of zero, the values of all SVs defined in the interface will be returned. The values are returned in a list in an S1F4 message from the equipment.

The host can also request a list of SV names from the equipment by sending an S1F11 message to the equipment. The list rules mentioned above apply to this message as well. The return message will contain an entry for each SV that displays its SVID, Name and Unit.

Equipment Constants

Similar to the way SVs work, the host can also query the values of equipment constants defined in the GEM interface by sending an S2F13 message. The values will be returned from the equipment using an S2F14 message.

Also similar to SVs, the names of ECs can be queried using an S2F29 message.

Data Variables

Since data variables are only valid in the context of a collection event, there is not a method for polling values of data variables. The value of a Data Variable can only be reported in a collection event report.

Other

In addition to the methods for polling data discussed above, the following items can also be obtained from a GEM host by polling the equipment:

  • Collection Events (CE) – The host can query what Collection Events are available on the GEM interface along with what DVs are associated with each CE. These are requested using the S1F23 message.
  • Alarms – The host can query what Alarms are available on the system by sending an S5F5 message listing the ALIDs of the desired alarms. The return message lists the alarm code and alarm text associated with the ALID. Two status variables are required to be present in every GEM interface. AlarmsEnabled contains a list of IDs of all enabled alarms on the equipment. AlarmsSet contains the list of ID for alarms on the equipment that are currently in the Set state. Since these values are status variables, they can be queried at any time.
  • MDLN and SOFTREV – The response to an S1F1 (Are you there?) message will contain the equipment model type (MDLN) and software revision (SOFTREV) for the equipment.
  • DateTime – The date and time for the equipment can be requested using an S2F17 message. The host can synchronize the equipment’s time using the S2F31 message. GEM requires the equipment to maintain a Clock SV containing the current time. Allowing the host to query and synchronize time provides the capability to order nearly simultaneous events on the system.

Trace Data Collection

Trace data collection provides a method of sampling data on a periodic basis. The time-based approach to data collection is useful in tracking trends or repeated applications within a time window, or monitoring of continuous data.

When creating a trace definition, the host provides the following:

  • Sample period – the time between samples. The resolution is in centiseconds, so it is possible to gather data very quickly using a trace. It is common for equipment so support as fast as a 10 Hz trace interval.
  • Group size – number of samples included in a trace report
  • SVIDs – List of status data to be included in the trace
  • Total samples – number of samples to be taken over the life of the trace
  • Trace request id – identifier of the trace request (GEM only allows trace IDs of type integer)

The host defines a trace request by using the S2F23 message. Trace reports are sent from the equipment to the host using the S6F1 message.

Trace Sample

Let’s suppose that a piece of equipment is processing a wafer and the processing takes 5 minutes. It is important to keep the chuck temperature within a certain acceptable range and to make sure that the chamber pressure stays below a specified level. It is sufficient to monitor the values at 15 second intervals, but we can create groups of data to only receive reports once a minute. The host could send an S2F23 message with the following trace configuration:

Trace ID: 100 (ID must be an integer)
Sample Period: 00001500 (take a sample every 15 seconds)
Total Samples: 75 (Samples every 15 seconds for 5 minutes)
Group Size: 4
SVID List:
   300 (ID of the status variable that contains information about chuck temperature)
   301 (ID of the status variable that contains information about chamber pressure)

After one minute, the first trace report will be delivered using an S6F1 message from the equipment. The message will contain the following information:

100 (Trace ID)
4 (last sample number)
2018-01-22T14:20:34.8 (date format depending on TimeFormat equipment constant)
Status Value List: (Length is 8: 2 SVs with a group size of 4)
   219.96 (chuck temperature for first sample)
    0.0112 (pressure for first sample)
   219.97 (chuck temperature for second sample)
   0.0122 (pressure for second sample)
   219.97 (chuck temperature for third sample)
   0.0120 (pressure for third sample)
   219.96 (chuck temperature for fourth sample)
   0.0119 (pressure for fourth sample)

After another minute the trace report may look like the following:

100 (Trace ID)
8 (last sample number)
2018-01-22T14:21:34.8 (date time shows one minute later than the first trace)
Status Value List: (Length is 8: 2 SVs with a group size of 4)
   219.96 (chuck temperature for fifth sample)
   0.0112 (pressure for fifth sample)
   219.97
   0.0122
   220.01
   0.0120
   220.00
   0.0119

Three more reports will be received at one-minute intervals. The host can check returned values in the report and react accordingly if values are out of the expected range.

Conclusion

The host could poll status data using S1F3 if it wanted to check a value at a given point in time. It can set up a trace if it wants to continuously collect data over a given period of time.

Using the data sampling methods outlined in this blog will allow host applications to poll the data they need when they need it. GEM provides flexibility in requesting data from the equipment either by allowing the host to query values at a given point in time or to be sampled on a periodic basis using a trace.

Click here to read the other articles in our SECS/GEM Features and Benefits series. 

To download a white paper on an introduction to SECS/GEM, Click below:

SECS/GEM White Paper

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

Sending data in chunks to optimize network performance

Posted by Derek Lindsey: Product Manager on Oct 19, 2017 10:11:00 AM

The Interface A / EDA standards define powerful methods for collecting data from an equipment control application. The data collection can be as simple as querying values of a parameter or two, or as complex as gathering thousands of parameter values across multiple reports. EDA specifies the use of internet standard messaging protocols like HTTP, XML and SOAP messages for collecting this data.

It is possible to define so many data collection plans gathering so much data that the sheer amount of data causes network performance to degrade. To remedy this situation, the EDA standards provide ways of sending the data in “chunks,” which dramatically improves the performance of XML over HTTP.

Two methods for sending data in chunks are grouping and buffering.

Grouping

Grouping only applies to individual Trace Requests within a Data Collection Plan (DCP).  If I have a trace request with an interval of one second, a group size of 1 would generate a report every second and send it across the wire. If I change my group size to 10, a report would still be generated every second, but the report would not be sent across the wire until 10 reports have accumulated. Each report has its own timestamp and they are arranged in the order they occur. The following diagram shows a trace data collection report with a group size of 3.

EDAdatachungs-1.pngBuffering

Buffering is different from grouping in that the buffer interval (in minutes) applies to an entire DCP rather than individual trace requests within that plan. For example, if I have a DCP with three trace requests and two event requests defined with a buffer interval of 1 (meaning one minute), the trace reports would still be generated at the specified trace interval. Event reports would be generated as the events are triggered. The reports are not sent to the EDA client until the buffer interval expires. At that point, all the data reports that were generated within that buffer interval time are packaged and sent to the EDA client.EDADatachunks-2.png

Combining Grouping and Buffering

Grouping and buffering can be combined as well. Groups are still defined on a per trace basis. If a group size has not been met when the buffer interval expires, the group report will be in the next buffer report that is sent.

Summary

With the provision for transmitting data in blocks, using grouping for trace data reports and/or buffering for all data reports, EDA is well suited for collecting large amounts of data without having a negative effect on network performance.  

Topics: EDA/Interface A, Data Collection/Management

Implementing CIMPortal Plus

Posted by Derek Lindsey: Product Manager on Jul 7, 2017 12:07:00 PM

Toolkit.jpg

Generally, when I do a DIY (do-it-yourself) project around the house, I spend the majority of the time searching for my tools. The other day I was helping a friend with a project. He had a well-organized tool box and it seemed that the perfect tool was always at his fingertips. I was amazed at how fast the project went and how easy it was when the right tools were handy.

In April of 2016, we published a blog called OEM EDA Implementation Best Practices that outlined ten things to consider when designing an equipment-side EDA / Interface A solution to fit your needs. This blog post analyzes a few of those recommendations and looks at how using the Cimetrix EDA products CIMPortal Plus, ECCE Plus and EDATester (a well-stocked and organized tool box) makes it very easy to follow those recommendations.

The basic steps in creating a useful EDA implementation are:

  1. Determine which data will be published
  2. Build an equipment model
  3. Deploy the model
  4. Publish the data from the equipment control application
  5. Set up a data collection application
  6. Test the interface

The blog post mentioned above states, “Since the content of the equipment metadata model is effectively the data collection contract between the equipment supplier and the factory users, your customer’s ultimate satisfaction with the EDA interface depends on the content and structure of this model.” Before building your model, you need to determine what data the equipment will make available for collection. CIMPortal Plus has the concept of a Data Collection Interface Module (DCIM) that publishes this data to the EDA server. The engineer building the model will map the data from the DCIM into the equipment model.

Once the mapping of the data is complete, the engineer will need to put this data in a format understood by the server. CIMPortal Plus provides a utility called Equipment Model Developer (EMDeveloper – pictured below) that makes it easy to create the hierarchy of your equipment (SEMI E120) and embed the data from the DCIM into that model (SEMI E125). If you use the tools and best practices provided in EMDeveloper, your equipment model will conform to the SEMI E164 (EDA Common Metadata) standard as well. This can be very useful when writing data collection applications so conformance to E164 is being required by more and more fabs. The E164 standard was developed to encourage companies using Interface A connections to provide a more common representation of equipment metadata based upon the SEMI E125 Specification for Equipment Self-Description. This makes data collection more uniform across these pieces of equipment.

CIMPortalPlus_Blogimage1.png

Once the model is created and validated, it is deployed to the CIMPortal Plus server. The server is the component that manages and tracks all data collection plans, reports, tasks, access control and timing. 

With the DCIM information embedded in the model (described above), it is easy for the equipment control application to push the data to be published to the EDA server for collection. This is done by using a simple API available on the DCIM interface.

In addition to CIMPortal Plus server capabilities, Cimetrix has other products available to help with client-side data collection. ECCE Plus is an industry approved method for manually testing EDA implementations. For users who need to create client-side data collection applications, Cimetrix also provides EDAConnect - a powerful library that handles all the connection details and allows developers to concentrate on the specific data collection and analysis tasks.

Fabs receive a wide variety of equipment with EDA implementations from numerous vendors. They want to use a single verification application to make sure that all EDA implementations are compliant to the EDA standards. That’s where EDATester comes in. EDATester is a new product that allows users to quickly and accurately verify EDA standards compliance by automating the test procedures ISMI EDA Evaluation Method that were defined specifically for this purpose. If you use Cimetrix products to implement your EDA interface, you are guaranteed to be compliant with the SEMI EDA standards. But whether you use Cimetrix products to implement your EDA interface or not, you (and your fab customer) want to rest assured that your implementation is fully compliant. Moreover, you’ll want to know that you’ve met the fab’s performance criteria for your equipment interface. To support this use case, the EDATester also allows users to quickly profile the performance of EDA data collection on a piece of equipment so that fabs and those using the data will know the boundaries within which they can successfully collect equipment data.

With the well-stocked EDA tool box provided by Cimetrix, following the EDA best practices in creating an efficient, standards-compliant EDA interface becomes a snap.

Topics: EDA/Interface A, Cimetrix Products

CCF Series Wrap-up

Posted by Derek Lindsey: Product Manager on Apr 12, 2017 11:00:00 AM

One of the habits outlined in Stephen R. Covey's book, The 7 Habits of Highly Effective People, is to "Begin with the End in Mind." He goes on to explain that beginning with the end in mind means to "begin each day, task, or project with a clear vision of your desired direction and destination, and then continue by flexing your proactive muscles to make things happen.”

Beginning an equipment control project with a clear vision of your desired destination makes it much more likely that you will have a successful project. A blog post titled CIMControlFramework Work Breakdown dated March 15, 2016 outlined the tasks necessary to create a first-class equipment control application using CIMControlFramework (CCF). Since that initial blog post, Cimetrix has explored each of the tasks labeled in the work breakdown structure in greater depth in their own blog posts as follows:

Looking back from the successful completion of a CCF equipment control application makes it clear that the work breakdown vision from the beginning helped gain that success.

You can also reference the following blog posts related to CimControlFramework:

CIMControlFramework Dynamic Model Creation

Learning from Others

Build vs. Buy

WCF and CIMControlFramework

To learn more about CCF, visit the CIMControlFramework page on our website!

Topics: Equipment Control-Software Products, Cimetrix Products