Industry News, Trends and Technology, and Standards Updates

Today, Cimetrix held its 2nd annual soup cook-off. With the our first big storm of the season right around the corner, a good bowl of soup seems very fitting for this time of year.

We had some excellent contenders with entries ranging from Elk Chili to Mexican Chicken Soup. Each member of the Cimetrix team takes the tasting process very seriously. There are sample cups - so that you can try just a little of each before getting a bowl of your favorite. However, I think most of us were full after just the tasters!

After a thorough tallying process, the winner was announced... Mark Bennett!  Not just a member of our experienced engineering staff, but also a remarkable cook.  His Zuppa Toscana won by a landslide. Congratulations Mark!

Download a copy of Mark's recipe here. 

by Bob Reback,
President and CEO

Running a company during an industry downturn presents quite a challenge. I have always thought I would someday be the president of a company. However, during this severe semiconductor down cycle, the thought that you should “be careful what you wish for” certainly came to mind a few times. Even though Cimetrix is a small company, successfully navigating a business through a severe downturn that hit the semiconductor industry requires a combination of critical thinking, tough decisions and a durable stomach.

The decision making process must consider the perspectives of all stakeholders - including investors, customers, employees and suppliers. The primary objective is clearly to make sure the business survives through the downturn. The secondary objectives relate to how to best satisfy customers, investors, employees and suppliers while making sure objective number one is met.

More than ever, this requires extensive communication with all parties. Not every party will be happy with your decisions. However, having sound analysis for your decisions, along with open and honest communications can ensure that all parties understand and, most importantly, accept the decisions.

Like almost all companies that serve the semiconductor industry, Cimetrix’s revenues suffered severe declines in the first half of 2009. The dramatic decline in revenues was the root cause of the crisis, as revenue brings in the necessary cash flow to pay employees and other business obligations. In addition, the severity of this down cycle caused more customers than anticipated to cease operations as a result of either bankruptcy or a parent company shutting down a division. Even though our primary competitor filed for bankruptcy and ultimately sold off its assets, there is no joy as you empathize for all of the affected employees without a job.

Fortunately, Cimetrix has a great team and everyone pitched in to help ensure the company successfully navigated through this down cycle. This includes our customers, employees, suppliers and investors. We are now seeing evidence that our customer’s businesses are starting to improve and the industry is on the mend, which is leading to increased revenues for Cimetrix. By retaining all of our key customers and a solid team of employees, we are well prepared and positioned for growing the business going forward.

There has been an underlying theme emerging in the semiconductor industry over the last couple of years. Do you know what it is? DATA. Give me more DATA.

Equipment suppliers today are required to support more than a dozen SEMI^® standards related to factory automation and a host of commonly used substrate-handling components such as robots and vacuum system hardware. More DATA.

They also need to support a new suite of “Equipment Engineering Capabilities” (EEC) including: e-Diagnostics, data collection, recipe management, data quality, fault detection and classification, run-to-run control and predictive maintenance. The key underlying factor for most of these features is... DATA.

Initiatives by other industry organizations, such as the International SEMATECH Manufacturing Initiative’s (ISMI) 300mm NGF, also focus on... you guessed it, DATA. Increasing the accessibility of high-quality data, and then, using the data to improve efficiency and productivity. In addition, factories are also requiring DATA storage and access on and off the tool for future performance analysis.

Attend this week's FREE WEBINAR on "Using Data to Improve Equipment Efficiency and Performance" to learn about the significant manufacturing benefits gained from improved access to higher quality and quantity of data.

The webinar will take place on Thursday, October 22
at 8:00 am MT/ 4:00 pm UTC.

by Stu Benger,
Director of Sales, North America

I’d like to draw your attention to two recent articles by Tom Friedman, a renowned columnist for the NY Times and one of my favorite authors. Tom is far greener than I; however, as an old economics major, I agree with him that it is the economics of the conservation energy that is most critical to our nation generally and the fledging Solar industry specifically. In the first article Tom discusses the growth in Applied’s Solar business and laments that the factories are being built in China. 

In the second article Tom goes on to say that the efforts by the Chinese in PV and their focus on Green Energy should be seen as an event similar to the Russian launch of Sputnik back in the 60’s an event that should be a clear call for action to spur the American people. Sputnik led to the “Space Race” and innovation in every phase of American life from Tang to the internet, but mostly it led to a huge interest in technology. And by the end of the Space Race, America was the technology leader in about every facet of industry one could imagine. However, over the past thirty years, we have turned our interest from making things to making money. We have allowed our best engineers to turn from tweaking hardware for best performance to tweaking trading algorithms that produce a bit more for the hedge funds. I think we need to take a hard look at what Mr. Friedman is saying and call on our Politicians to do the same.

Solar Power is an industry poised for huge growth. The economics of the industry, the high degree of automation that can be used makes this an ideal industry that might just allow the American Manufacturing Sector a chance to crawl back from the dead. If we don’t, I’m afraid it will be a long time before the next opportunity presents itself and when it does it will only be because our children are the new low cost manufacturing site for a dominant Chinese economy.

Cimetrix is dedicated to improving the efficiency of solar cell production and actively seeking avenues for assisting the US solar industry to achieve this goal. We have been involved in the PV-EIS Task Force since its inception. A world-wide factory automation software supplier to the semiconductor industry, Cimetrix is an expert in the SEMI connectivity standards and has already been working with members of the solar industry to implement the new PV2 standard. We offer a complete set of proven and efficient equipment communication software solutions for PV manufacturing.

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. 

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.