Industry News, Trends and Technology, and Standards Updates

by Allyn Sullivan,
Software Engineer

I have recently worked with several customers who were in the process of building CIMPortal equipment models for their tools. Some were using the Equipment Model Developer (EMD) which ships with CIMPortal while others were programmatically building their models using the CxModel API. Working with both sets of customers, I saw a very real need for customers to develop programming tools to create equipment models instead of relying on the EMD alone.

Every model has a unique equipment configuration. Building an equipment model through the EMD is a laborious process. Each node of the equipment is added individually with a minimal amount of automation. Although suitable for those new to CIMPortal and initial model development, the EMD is not practical for building the many unique equipment models required for every tool configuration that a manufacturer makes.

Most manufacturers use a base tool to which they can add components to meet their customer's specification. Equipment configuration data can then be imported from the bill of materials (BoM), parts inventory, or other data from the manufacturing system of record. The model builder application can import this data (from a database or spreadsheet, for example) and use the CxModel API to generate several unique equipment models automatically. The application should be able to easily generate equipment models for any tool in the manufacturer's inventory.

Developing the proper tools that meet your individual needs is the most efficient way of creating equipment models for CIMPortal. You'll save time over using the EMD and have more consistent equipment models across tools.

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

by Mike Baker
Cluster Tool Control Practice Manager

The purpose of a framework is to improve the efficiency of creating new software.  Frameworks can improve developer productivity and improve the quality, reliability and robustness of new software.  Developer productivity is improved by allowing developers to focus on the unique requirements of their application instead of spending time on application infrastructure (“plumbing”).

Many people equate the term software framework with an object-oriented software library, or set of libraries, intended to provide reuse.  However, there is an important difference between a framework and a library, that difference is often called “inversion of control.”  If you’re using a library, the objects and methods implemented by the library are instantiated and invoked by your custom application.  You need to know which objects to instantiate and which methods to call in order to achieve your goals.  On the other hand, if you’re using a framework, you implement the objects and methods that are custom to your application and they are instantiated and invoked by the framework.  A framework defines the flow of control for the application.

A common way to customize framework behavior is to override framework-implemented features. The abstract or virtual methods defined by framework classes can be overridden in user-defined code. New objects can be created that implement framework-defined interfaces. These approaches leverage polymorphism to allow one software system, the framework, to interact with software developed by another group.

To emphasize the point, let’s look at a grossly oversimplified example. The Windows Presentation Foundation (WPF) is a framework for building Windows applications. To create a new Windows application with WPF there are two essential elements. The first is a XAML file. The XAML file describes the configurable attributes of the application including: which classes to instantiate, values for object properties, and which methods to invoke in response to user activity. The following is a very simple example of a XAML file:

This sample describes a Window that can be instantiated by the application. Application-specific logic for this window is found in a class named WpfApplication1.Window1. The sample describes how to label the window and the initial size of the window. The window contains a Grid control which in turn contains a Button control. The attributes of the Button control tell WPF to invoke the WpfApplication.Window1 method named button1_Click when the button is clicked by a user.

The second essential element of a WPF application is code. The following is a simple example:

This snippet is sufficient to implement a Windows application. The framework’s "inversion of control" is represented by the button1_Click method. This method is invoked by the framework when the user clicks on the button. The framework defines practically everything that happens when this application is executed; the Window1 class defines only the application-specific behavior. No coding is needed to display the window, process user input, or handle any common window operations (e.g. move, resize, minimize, maximize, close). Compare this sample with the amount of code that would be needed to develop even a simple application like this one without a framework. Many organizations develop Windows applications; few do it from scratch.

Now extend the framework concept from the general-purpose to a specific application domain (e.g. equipment automation). A domain-specific framework permits new domain applications to be developed more quickly, with high quality, and allows developers to focus their attention on the unique requirements of their application or system. Imagine configuring a new equipment control solution using framework-implemented building blocks and implementing only the overrides that are unique to your system. Those overrides could include elements of process control, human machine interface, data collection and analysis, recipe management, material handling, etc. Today there are many organizations that develop individual equipment automation solutions from scratch. A team using an equipment automation framework, such as CIMControlFramework™, could (for example) focus their time on how to execute a process recipe instead of worrying about how recipes are stored, retrieved, organized, protected, uploaded, downloaded, or communicated to the process equipment.

Advantages

• Reuse code that has been pre-built and pre-tested. Increase the reliability of the new application and reduce the programming and testing effort, and time to market.
• A framework can help establish better programming practices and appropriate use of design patterns and new programming tools. A framework upgrade can provide new functionality, improved performance, or improved quality without additional programming by the framework user.
• By definition, a framework provides you with the means to extend its behavior.

Disadvantages

• Creating a framework is difficult and time-consuming (i.e. expensive).
• The learning curve for a new framework can be steep.
• Over time, a framework can become increasingly complex.

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. 

by Dave Faulkner
Executive Vice President, Sales & Marketing

It is starting to feel like a recovery in the semiconductor industry.  Wall Street is saying to keep on eye on semiconductor stocks and even semiconductor equipment stocks.  SEMI just reported that worldwide semiconductor equipment bookings for Q2 2009 were 83% greater than Q1 2009.  Capacity utilization is likely to reach 88% in Q3 2009 according to IC Insights, up from 57% in Q1 2009.   And the SEMI World Fab Forecast is now calling for a 64% increase in fab spending in 2010.  The fear is starting to subside.   Q1/Q2 2009 appear to be the low point for equipment suppliers and we appear to be heading up the hill, but starting from a very low elevation.  I think we are finally in the recovery.

We have a very unique look at the semiconductor industry.  Our customers report tool shipments based on license orders.  And our customer base is very broad including all tool types in the frontend and backend.  We see who is booming and who is busting.  While we would never, never, never discuss individual company progress, I can say that shipments (via way of license revenues) have hit their bottom and are on the way back up.  And we are seeing this in all areas of the semiconductor industry.  It is like seeing a bit of blue sky during the storm, it gives us hope for all.  We just need to give the rest of the storm clouds time to move on…..

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. 

Forbes magazine declared Utah the 2nd best state in America for business in 2008. The State New Economy Index - performed by the Ewing Marion Kaufman Foundation - gave Utah the number one spot in "economic dynamism" that same year.

2008 was a good year for Utah.  And Cimetrix received a very nice honor when compared to other companies in Utah.  Utah Business magazine recently published their "Top 40 Public Companies in Utah" for 2008 and Cimetrix was included in that list at #32. Being named one of Utah's top companies is an honor in itself, but the fact that we made the list in one of the stronger economies in the nation... makes it even sweeter.

Cimetrix was also included in the magazine's annual "Book of Lists" in 2008 which includes comprehensive information and rankings about the state's businesses and industries. We were ranked as one of the top 25 software developers for 2007.

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?

At Cimetrix, we thrive on customer interaction, continous improvement, and a passionate dedication to providing an elevated level of quality in both our products and services.  In an effort to solicit more feedback from our customers and colleagues, we will be launching a blog in the coming weeks. 

Readers can expect to see posts regarding industry trends and updates, product  & company announcements, tips for smooth implementation of the SEMI standards (SECS/GEM, GEM300, and EDA), and common incidents and how to avoid them.

Check back soon!