Semiconductor Industry News, Trends, and Technology, and SEMI Standards Updates


Equipment Data-Driven Continuous Improvement for 200mm Fabs

Posted by Alan Weber: Vice President, New Product Innovations

Feb 23, 2016 1:03:00 PM


The focus of the most recent SYSTEMA Expert Day, held during a snowy week in Dresden in late January 2016 in conjunction with the 13th annual innovationsforum, was “200mm Fab Enhancement” and featured a number of presentations from Systema GmbH customers and partner companies.

By way of background, there are a number of reasons for the emphasis on 200mm fab enhancement, most notably that many of these factories are enjoying a renaissance of business to meet the growing demands for IoT (Internet of Things) devices. Moreover, since the drivers for this market segment include cost, variety, and volume, the automation and operations people in these factories are faced with a new combination of challenges not seen in earlier markets.

Cimetrix’ contribution to the event was a presentation titled “Equipment Data-Driven Continuous Improvement for 200mm Fabs,” which outlined a model-based, ROI-driven approach for adding equipment data collection capabilities to existing factories. Our basic premise is that such an approach helps meet some of the automation challenges in an incremental, cost-effective way without requiring major redesign of the factory or equipment control systems.


Since the term “model” is used in many different contexts, we first clarified what this term means in the context of SEMI equipment communications standards, and how this evolved over the past three decades. This was accomplished using a natural language analogy, which is shown in the figure below. Note that the culmination of this process to date is the EDA (Equipment Data Acquisition) metadata model called for in the latest generation of standards, which is very prescriptive in terms of structure, content, and naming conventions for the elements of a semiconductor manufacturing equipment. And even thought the specifics of this model were designed with 300mm wafer fab equipment in mind, the principles well apply to all substrate sizes, and even to the types of material, processes, and equipment found in back end assembly and test factories.

After establishing the value of explicit models for representing equipment, sensors, and other key items in a manufacturing environment, we next introduced concept of an ROI-driven strategy for evaluating the relative benefit of various data collection projects. This strategy first identifies and ranks the key manufacturing objectives that must be addressed, then poses the questions that must be answered to meet those objectives. It then identifies the data sources for the information required to answer those questions, and the data collection techniques (including software) applicable to those sources. Finally, since the original objectives can change with time and additional knowledge, they should be re-examined periodically, giving the strategy an iterative aspect as well.

In order provide specific examples for the uses of equipment data in a continuous improvement program, the presentation listed a number of application use cases that have been successfully deployed in 200mm facilities. These included (in general increasing order of complexity) substrate tracking, process execution tracking, product time measurement (aka wait time waste analysis), external sensor integration, component fingerprinting, and product traceability.


A couple of these were then explained in more detail, showing how a basic tracking application could start by using a small subset of the equipment data, and then evolve over time to provide more advanced functions (and benefit!) as more detailed information was made available.

For those who want to understand this process in more depth, you are welcome to download the entire presentation using the link below, or call us to discuss how we can apply these ideas to your company!

“Equipment Data-Driven Continuous Improvement for 200mm Fabs"

Watch the Video

Topics: Semiconductor Industry, Market Trends, EDA, SYSTEMA GmbH, Data Collection

New Features in CIMControlFramework™ 3.0

Posted by Cimetrix

Jul 1, 2011 1:41:00 PM

By David Francis

Product Manager

The creation of a new software product is an exciting process. Often, as was the case with the Cimetrix CIMControlFramework™ (CCF) software, this process begins with a partner that will become the first customer of the product. Cimetrix teamed with Axcelis Technologies to develop a new tool control framework for one of their process tools. A following project with Rorze Automation further developed the framework and produced CCF 2.0. Upon completion of that project, Cimetrix continued the development of the tool control framework to become a standard product that any OEM could use, resulting in the release of CCF 3.0.

The development effort for CCF v3.0 focused on four main areas that improve both the product development capability and the user experience:

  • Tighter integration with Cimetrix connectivity products
  • Faster data analysis
  • Reduced installation time
  • Improved training material

1)      Tighter integration of CIMControlFramework with factory automation components to implement Interface A and SECS/GEM connectivity

We simplified the data configuration so that parameters, events, and alarms are registered at start up and automatically coordinated with the configuration files for the factory automation products.

In the previous versions, CCF was configured to work with a CIM300 or CIMConnect product that was previously installed and configured for the equipment. The problem was that if someone needed to change the connectivity functionality, that change was not reflected in the tool control portion of CCF, or vice versa.  This meant that the required changes had to be implemented twice, resulting in duplication of effort.

Since we wanted to develop the product for a broad range of customers, we wanted to make sure that during tool initialization, OEMs would be able set up alarms, variable definitions, collection events, etc. one time for both tool control by CIMControlFramework and for the connectivity products.

With the tighter integration in CCF 3.0 to coordinate the tool control and the connectivity, initial deployment is now much easier and faster.

Below is an example that shows how alarms, events, and variables are tied together.  OEMs create the initial model using EM Developer, and then all of the configured alarms, events, variables are dynamically added to the model after startup. You don’t have to create all the details of the model, just the basic configuration and CCF fills in the data.

 Data Model resized 600

2)      Improved User Experience Through Faster Data Analysis
We learned from the initial deployments that tool operators need quick access to process data in order to improve productivity and lower costs. For CCF 3.0, Cimetrix implemented dedicated history tables to improve performance of queries on historical data.  The new history tables allow for much faster queries for wafer, EPT and Alarm history information.

All logged information is written to log files.  Any log information related to wafer, EPT, or alarm history is also written to the respective table in the on-tool database.

The benefit is fast and easy visualization of the equipment process data that is 20-30 times faster than the previous CIMControlFramework product.

The following graph shows the frequency of alarms reported by the equipment, which can be used to identify problem areas.  This type of data now comes back within a few seconds.

 Alarm History resized 600

3)      Reduce the time and effort of software installation and initial setup

The new installer allows the user to select the specific CCF modules needed and any other embedded Cimetrix products – such as CIMPortal™ or CIM300™ they want to install and configure. The installation is done in 2 phases. The first phase installs all files related to the products selected, including the source code. The second phase installs and pre-configures CCF and any pre-requisite packages. With the installation package, the time to time to install is dramatically reduced.

4)      Improved training material and code samples

To help a project team get started faster and get them more productive sooner, the Cimetrix created new labs that offer hands-on exercises.  One example is a lab to show the process for customizing user screens.  Both the problem case and the completed solution for each lab ship with CCF.  The real benefit is customers can use the labs as a starting point for their project or as reference material to help them create their own implementation.

Below is a screen shot from a lab that walks students through the process of creating a custom screen to visualize data for their specific tool, such as visualizing pressures, load locks, robots, load ports, processing chambers, etc.

UI Training resized 600

Cimetrix is a software company dedicated to continual product enhancement.  This release delivers improved functionality and performance that will benefit our customers.  With CIMControlFramework, OEMs have a great solution for tool control that allows them to spend more time and effort on delivering their unique value to the market, and far less time on tool control and connectivity—and it just keeps getting better.  This is another example of what Cimetrix does to support our customers to speed them through the development phase and into production.

Topics: Equipment Control-Software Products, Data Collection, Equipment Automation Framework, Data

Cimetrix at SEMICON Japan 2010

Posted by Cimetrix

Dec 14, 2010 11:35:00 AM

By Dave Faulkner

Executive VP, Sales and Marketing, Cimetrix

We had a strong showing at SEMICON Japan at the Makuhari Messe December 1 - 3.  Attendance was brisk, and Cimetrix products were on display at both the Meiden and the Rorze booths.  This event was a great opportunity for us, since we have just started Cimetrix Japan K.K. effective November 25, 2010.  The new Cimetrix company will provide both new market development and customer support for the Japan marketplace.

In the Meiden booth, Cimetrix EDA/Interface A products were on display.  In addition, Meiden highlighted the partnership between Meiden, DSD, and Cimetrix, which allows DSD and Meiden to offer complete EDA solutions using Cimetrix technology.  These solutions are available to both equipment suppliers and IC manufacturers, and Meiden listed the benefits and sample architectures for each group. 

 Meiden Booth resized 600

 Meiden Booth Signs resized 600

Cimetrix CIMControlFramework (CCF) was on display at the Rorze booth running a complete 450mm vacuum platform.  Many visitors stopped to watch this powerful demonstration.  Cimetrix products were also highlighted, along with Rorze’s unique ability to deliver a complete hardware/software platform solution for equipment suppliers using Rorze and Cimetrix technology. 

 Rorze Booth resized 600

 Rorze Booth 2 resized 600

One other highlight of the show was visiting the Axcelis booth where they highlighted their Integra plasma dry strip cleaning system that uses the Cimetrix CIMControlFramework.

 Axcelis Booth Integra Tool using CCF resized 600

We also learned at the show that a new top 20 OEM in Japan would adopt Cimetrix connectivity products.  It is great to see how companies are using our solutions to get to their products up and running in wafer fabs around the world.

Thanks to all those people who stopped by the booths.  Please let us know if you need more information about Cimetrix connectivity or tool control solutions.

Topics: Equipment Data Acquisition, Semiconductor Industry, Interface A, CIMPortal, SEMICON Japan, CIMControlFramework, EDAConnect, Data Collection, Japan, Equipment Automation Framework, Rorze

So Much Data, So Little Time

Posted by Cimetrix

Jun 24, 2010 6:00:00 AM

by Dave Faulkner,
EVP, Sales & Marketing

Engineers love data. Business people love information. But it all starts with high-quality, real-time data. The possibilities are endless with good data.

As an equipment supplier, history probably has you living with a tool architecture from the early 300mm days. The focus was on implementing AMHS systems and meeting the GEM300 standards. A data driven architecture wasn't on the radar screen. And it wasn't a business priority. Times have changed. Fabs started asking for more data by creating the SEMI Interface A standards - and equipment suppliers are learning they can produce more productive equipment by leveraging the right data.

Interface A was an interesting concept when it started in the early 2000s. Discoverable data available to the fabs in real time would seem to be the answer to many problems. But the adoption has been less than stellar - even with strong endorsement and technical support by ISMI. Lack of fab side applications plumbed to use the Interface A data and "ownership" issues of the data haven't helped. These are real business problems that must be solved and will be solved with the next wave of fab purchases.

But what have we learned as equipment suppliers and software providers? Tool data models are helpful. Self description is great. We can create high performance data gathering applications that integrate with existing tool control architectures to make data available and controllable by the equipment supplier. Look at the performance of CIMPortal, our comprehensive equipment data acquisition (EDA) solution. We also learned that given the opportunity to "start over", we can create new tool control architectures that are data driven and prepared for the future. Look at CIMControlFramework. So the data is available - or you can make it available with an existing or new tool control architecture.

Let's put this data to work. Either to benefit you as the tool supplier or to help your customer. How is your tool accepted at the fabs? Do you have contingencies on your customer's payments? Does tool uptime have an impact on the tool price? Are your warranty costs too high? You get the point. With high-quality, real-time data at our fingertips, we can solve some of these business issues. We are at the beginning of a phase where the tool supplier makes use of this data and it directly impacts business results. Tool side fault detection, preventative maintenance, whatever is needed. The important point is we are finally starting from a strong foundation with the right data at the right time - and it can lead to increased margins or higher levels of customer satisfaction. Bring us your business problem and let's build something together to put this data to good use. Let's do it now!

You might also be interested in:

Topics: Equipment Data Acquisition, SEMI Standards, Interface A, CIMPortal, CIMControlFramework, Equipment Control-Software Products, Data Collection, Data Management, Data

Selecting or Designing a Yield Management System

Posted by Cimetrix

Jan 27, 2010 9:43:00 AM

by Sheethong Ho,
Solutions Architect

It is a natural tendency to think that Yield MaYield Managementnagement Integration is simply a data integration job that gathers related manufacturing and test data into a Yield Management System (such as dataPOWER, PDF), and thereafter the engineers and their Yield Management System live happy ever after.

For the fact that a production environment is never static and is evolving constantly makes the maintenance aspects of the Yield Management System a formidable challenge. It is fairly common to see a facility struggling to have its newly implemented Yield Management System keep up with new production needs. Any intentional or unintentional change in manufacturing data may break the loading of a data feed causing its yield analysis capabilities render useless.

The following are some of the key considerations when designing or selecting a solution for the implementation of a Yield Management System.

  1. How flexible is the solution in adapting to changing needs in the manufacturing environment? For instance, a new foundry plant is providing the assembly testing that feeds an existing data source for the Yield Management System. However, its test data does not comply with the expected format and could not be processed and loaded. What will be the cost and effort associated with fixing the assembly test data feed?
  2. How easy is it to manage and administrate the system? Anyone tasked to manage and maintain the data processing and data feed for the Yield Management System will experience a substantial amount of time investigating why a certain data failed to load. Hence, the question: does the solution provide good error reporting and handling? When the system administrator is approached by the yield engineer on a certain high priority lot not appearing in the Yield Management System – what tools are available to help diagnose the problem or to track down the missing lot? Will the system provide any further means to answer these questions:
    • Did the test data for the lot make it to the Yield Management system? Perhaps the lot has not even been tested or data was not made available to the system.
    • What is the cause for the failure? A typical failure is the missing Meta (e.g. Wafer Map Configuration) data that is required for the loading. (Usually the Process Engineers are responsible in keeping the Meta data updated)
    • How the error could be eradicated and the data loading be resumed. What tools are provided to facilitate such activities?
  3. Does the system provide critical alarms and warnings ahead of time such that problems are not identified only when data are discovered to be missing or incorrect during yield analysis? These alarms and warning could also include system resources such as storage space and CPU usage that could affect the processing and loading of yield related data.

In considering a solution for Yield Management System integration, perhaps more than simply concerning about getting the data accurately into the system, the ease of system maintenance is equally important.

Contact Cimetrix Global Services to discover Cimetrix can help with your Yield Management System implementation and integration.

You might also be interested in:

Topics: Data Collection, Global Services, Yield Data Management, Data Management

Data... and more Data

Posted by Cimetrix

Oct 21, 2009 8:02:00 AM

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.


You might also be interested in:

Topics: Equipment Data Acquisition, CIMControlFramework, Events, Data Collection

Interface A vs. SECS/GEM for Data Collection

Posted by Cimetrix

Oct 6, 2009 8:11:00 AM

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….

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

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.

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.

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:

Topics: SEMI Standards, SECS/GEM, Interface A, Data Collection

Receive Email Updates

Follow Us

Learn More About the
SEMI Standards


GEM 300

Interface A/EDA