Industry News, Trends and Technology, and Standards Updates

by Matt Mayer,
Principal Software Engineer, Global Services

1. Establishing Communication- A standardized communications mechanism ensures both equipment and host have agreed, and all requirements necessary for properly collaborating data (between tool and host) based on the SEMI® SECS messaging standards (E5) are compatible during the connected status and after connection could have been disrupted.

2. Spooling- Spooling is an essential part of keeping synchronization with the tool. Communications (connect status) can be disrupted. In the event of communication disruption, the tool can be configured to spool collection event (S6F11) messages after communications has been restored and the host requests the last know transactions for the lost time span.

   Spooling can be configured to retain a SECS message pooled history of almost any stream and function (SEMI E5 standard). With this enriched functional capability, any condition of the tool can be relayed at anytime after communication has been re-established (e.g.: alarms, events, processing state changes, etc…).

   With that said about spooling, the host is required to take special care of the data received and re-act to the latest available data (spooled messages) in the most appropriate manner. In many cases, this behavior of the host takes special care at documentation and tool manufacturer collaboration.

3. Alarm Handling- The alarm handling capability provides for host with notifications and management of alarm conditions occurring on the equipment. Typically an alarm is associated with abnormal conditions of the equipment.

   With each alarm a correlating set/clear event notification will be issued to the host. As with each event definition, a report can be defined and linked in order to associate variable data specific to the alarm (see Event Handling).

4. Event Handling- Event handling provides a dynamic and flexible method for the tool manufacturer to customize the equipment to meet needs specified by the fabrication facilities with respect to data representation and presentation to the host. The event based approach to data collection provides automatic notification to the host and its activities which are useful in monitoring the equipment and in maintaining synchronization with the equipment.

   Reports can be configured by the host application and attached to event report messages (S6F11). These reports are linked to the desired event and are typically associated with variable data relating to the event generated by the equipment.

5. Variable Handling- The variable handling capability provide both the tool and equipment the ability to share details. Variables are categorized in three groups.

   Groups:

   • Equipment Constants, provides the capability for the host to read and change the value of selected variables of type EC which allow the host to reconfigure the variety of equipment functionality.
   • Status data, the values of a status variable will be current.
   • Discrete data, the values of DVs are only guaranteed to be valid at the occurrence of a collection event.

6. Process State Model Handling- The processing state model is dependent on the equipment process and technology. However, there are expected common aspects to these models. Many of these equipments use the GEM proposed state model with some variations. An ERROR and MANUAL state can be utilized during initialization and when the state is idle.

   Based on the SEMI E30 standard, the equipment must generate collection events for each processing state transition, as well as provide status variables (ProcessState, PreviousProcessState) which values represent the current processing state and the previous processing state. Other collection event reports can be defined and linked to event triggers.

7. Remote Command Handling- The capability which provides the host with control over the equipment and its operations. A remote command consists of parameter name/value pair with a particular host command (S2F41). The equipment manufacturer will provide unique names for any supported command parameters. The command parameters are defined by fabrication facilities and equipment manufacturers.

   A typical set of remote commands are listed below. However, the list is not a constraint and any set of remote commands can be specified and used.

   • PPSELECT
   • START
   • STOP
   • PAUSE
   • ABORT

8. Recipe Upload/Download Handling- Recipe handling provides the means for transferring process (recipe) information between the host and the equipment. The specifications for equipment processing (e.g. recipes) are managed through SECS messages (E5). Recipe uploading and downloading will be accomplished using several formats and combination thereof.

   Formats:

   • Unformatted recipe content
   • Formatted recipe content
   • Value based content transfer
   • File based content transfer

In addition to the above mentioned considerations, Cimetrix's CIMConnect, an object-oriented software development kit for equipment suppliers to quickly develop a GEM interface, also allows for multi-host connections.

by Vladimir Chumakov,
Software Engineer

HSMS or High-Speed SECS Message Services is a messaging protocol used in semiconductor and other industries as means for connecting to, controlling and gathering data from equipment inside the factory. HSMS provides means for independent manufacturers to produce implementations which can be connected and interoperate without requiring specific knowledge of one another.

Industry organizations, such as SEMI and ISMI, have been touting the benefits of the Interface A, also known as EDA, standards for years. This year, SEMI approved an important revision to these standards to incorporate many of the lessons learned from early implementations. In addition, SEMATECH member companies (which make up 50 percent of the worldwide chip market) wanted ISMI to focus on a smaller number of projects with short-term benefits for 2009. Interface A (EDA) is on this short list.

Want to learn more?

Cimetrix is hosting a FREE webinar outlining the features and benefits of the Interface A standards. The material will be presented by Doug Rust, Director of Quality Customer Support and co-chair of the SEMI North America GEM300 Task Force.

FREE WEBINAR: Interface A Features & Benefits
Date: Thursday, November 12, 2009
Time: 8:00 am MST/ 7:00 am PST/ 10:00 am EST/ 3:00 pm GMT
Duration: 1 hour

• The key features & benefits of Interface A
• Data & reporting features available through Interface A
• The role of Interface A in manufacturing

by Bill Grey,
Director of Research & Development

Engineers often ask, “What are the differences between Interface A and SECS/GEM for data collection.” This is a high-level comparison of Interface A and SECS/GEM/HSMS-SS data collection features. We are working on some tools to help demonstrate Interface A data collection. More on that later….

Clients
Interface A supports multiple clients where SECS/GEM is usually a single client.

Security
Interface A can be configured for SSL secured communications. Only clients with a valid certificate can use the interface and all data across the wire is encrypted.

HSMS is not secured. In HSMS, any host that has the device ID can connect and data across the wire is binary encoded, but not encrypted.

Additionally, Interface A client features are gated by privileges where GEM features are not privileged.

Equipment Model
Interface A E125 provides methods for its client to upload a description of the logical structure of the equipment which includes parameters, events, and exceptions assigned to modules, subsystems, and IO devices. In this manner, each parameter, event, and exception has the context of the owning component.

In GEM, similar information is found in a manual provided with the equipment. Unfortunately, in most equipment manuals, the relationship of which component on the equipment produces the parameter, event, or exception is not available. Context is missing.

Traces
Interface A traces have features that GEM traces do not. Interface A traces have start and stop triggers. These triggers may include one or more events and/or exceptions. The trace would begin collecting data when any of the start triggers occurs and stop collecting data when one of the stop triggers occurs. This is useful as a trace for a processing module may be defined to start when a processing started event occurs and to stop when a processing completed event occurs for that module. In this manner, the Interface A client defines the trace once and collects the data only when processing is active. Between the triggers, data is collected at the specified rate. The rate is specified with a floating point number designating the number of seconds between samples. The resolution is limited by the equipment.

In GEM, traces begin when defined through a SECS message and end when the specified number of samples is collected. To achieve the same effect as Interface A, a host would have to define event reports for the processing module processing started and processing completed events. When the processing started event is received, the host would have to define the trace by sending a SECS message. When the processing completed event is received, the host would have to terminate the trace with a SECS message. The host would have to do this every time, unlike Interface A. There is a delay between the processing started event and when the trace starts because of the SECS messaging that isn’t there with Interface A. GEM traces are limited to centisecond resolution by the E5 standard even if the equipment could support faster traces. Some older GEM implementations are limited second resolution.

Event Reports
Interface A event reports specify an event and an optional set of parameters to be collected when that event occurs. The Interface A client activates the event report to begin monitoring the event and deactivates the report to stop monitoring the event.

GEM event reports are a little different. A GEM host defines collections of parameters called reports. Then it links one or more reports to one or more events. The same report may be linked to multiple events if needed. Then the host enables the event to begin monitoring the event and disables the event to stop monitoring the event.

Alarm Reporting
Interface A exception reporting is very different than GEM Alarm reporting. Interface A exception reports are defined using a source ID, exception ID, and severity. Any of the fields may be empty or filled in. Source ID identifies which component provides the alarm, for example a processing module or load port. If source ID is the only non-empty field, then all exceptions for that component will be monitored and reported. Exception ID identifies a specific exception name, if this is the only non-empty field, then all exceptions matching this name regardless of source will be monitored and reported. If severity is the only non-empty field, then all exceptions matching this severity will be monitored and reported regardless of source ID or exception ID. If more than one of these fields is non-empty, then reporting will be determined by applying Boolean AND logic to the fields. In addition, exception reports in Interface A may contain parameter data; however, which parameters are supplied with each exception is specified by the equipment manufacturer and not selectable by the Interface A Client.

GEM alarm reporting has two forms. For notification of an alarm being set or cleared, the host may enable alarms and receive a SECS message containing no other data. In GEM, each alarm has one set and one clear event that may be used for event reports. Using these events, the host may be notified of alarm set and clear transitions with reports that contain data chosen by the host.

Reports
Neither Interface A nor GEM provide annotated reports.

Data Collection Impact
Interface A E134 defines a mechanism for the equipment to limit the impact of client defined data collection on material processing. If data collection hinders processing, the equipment may issue a Performance Warning to all clients and deactivate their data collection. The equipment may resume data collection at a later time and issue a Performance Restored.

GEM defines no such throttling or notification mechanism.

You may also be interested in:

• Download the complete SECS/ GEM Overview
• Download the complete Interface A Overview
• View Cimetrix SECS/GEM Software Products
• View Cimetrix's Interface A Software Products

Cimetrix was among those recognized for their work on the PV2 Standard last week. On Tuesday, the PV-EIS task force was awarded the SEMI Europe Standards Merit Award 2009. This was the first time that a team has received the award since it was established in 2001. Our own Bruce Febvret was there to receive the honor on behalf of Cimetrix. He and Brian Rubow have served on the task force since its inception in September 2007.

Bruce is the one on the left =)

Brian Rubow, principal engineer,will discuss common quality issues and performance challenges for PV 2 Standard implementation. The paper that we presented at the European PV SEC event last week will also be made available to all webinar registrants. 

In June of this year, the SEMI PV 2 Standard - Guide for PV Equipment Communication Interfaces (PVECI) was approved for publication by the global Audits and Reviews Subcommittee.

Curious about the new PV standards? Planning on being in Hamburg, Germany this week? 

Cimetrix will be participating in the Visual Presentations at the European Photovoltaic Solar Energy Conference (PV SEC) in Hamburg, Germany next week.  Bruce Febvret will be representing Cimetrix at the conference and available to answer questions regarding our paper "Maintaining Quality and Performance in your Implementation of PVECI and GEM Standards." He will be near our poster (#2CV.1.77) on Wednesday, September 23 from 8:30 am - 10:10 am. The poster presentations will be on display in the Congress Center Hamburg (CCH) in the POSTER AREA in Halls D, E, F, G and Foyer D-G (2nd Floor). Click here to view a map of the venue.

Won't be in Germany? No problem.  We will be hosting a webinar on the same topic on Thursday, October 1. For your convenience, we will be presenting at 2 different times: 8:00 am MT/ 2:00 pm UTC as well as 5:00 pm MT/ 11:00 pm UTC. Brian Rubow, principal engineer,will discuss common quality issues and performance challenges for PV 2 Standard implementation. The paper being presented at PV SEC will be made available to all webinar registrants. 

by Doug Rust,
Director, Quality Customer Support & co-chair of the SEMI North America GEM300 Task Force

In April, the suite of SEMI software standards commonly referred to as "Interface A" turned 5 years old.

Coincidentally, also in April, the SEMI standards North America Information and Control Committee approved an important revision to these standards to incorporate many of the lessons learned from early implementations.

SEMATECH, through its subsidiary ISMI, for years has been consistent in communicating how important Interface A (a.k.a. - Equipment Data Acquisition - EDA) is to the current and future manufacturing automation needs of its member companies. This message was repeated again at an ISMI workshop I attended this last Spring. ISMI had explained that the SEMATECH member companies (which make up 50 percent of the worldwide chip market) wanted ISMI to focus on a smaller number of projects with short-term benefits for 2009. Interface A (EDA) is on this short list.

In support of the ISMI members' vision for a better quality data communication interface, Cimetrix has been actively developing Interface A software since before the standards were published with early prototypes based on draft documents back in 2002-2003. We have had a continuous product improvement program in place since 2004 for our CIMPortal product which implements the Equipment Data Acquisition standards on the server side. We had previews of our EDAConnect factory-side EDA product at SEMICONWest 2007 and launched the product later that year.

So, as I was sitting in the workshop listening to the speaker from ISMI say once again what an important enabling technology Interface A was for current and Next Generation Factories (NGF), I thought to myself, "I keep hearing ‘we need it, we need it'. I wonder why more companies aren't using it"?

Why do you think companies have been slow to deliver Interface A (EDA) solutions on their equipment and using it in their fabs?