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.