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


Build vs. Buy?

Posted by David Warren: Director of Software Engineering

Feb 18, 2016 1:06:00 PM

Every company that needs software must make a build versus buy decision at some point. Some choices are easy—it makes little sense to build your own office software for word processing, spreadsheets, or presentations. But what if you need software to control specialized physical equipment?

Classic advantages of building your own software are:

  • Canned software is generally targeted to meet many needs for most problems. Custom software is better suited to meet specific and uncommon needs.

  • Canned software has a fixed set of features and it may be difficult to add or remove specific features, which may lead to software that contains unneeded features or is missing features that you do need. Custom software can be built to meet the specifications of a projects and include all the features that are needed and never any that aren’t.

  • The process of developing software builds in-house technical expertise. This expertise can be used to create competitive advantage through higher performance and faster reaction time in meeting the changing needs of the marketplace.

Classic advantages of using standardized software are:

  • Standardized software is generally less expensive than custom software because its cost can be spread across many customers and/or tools.

  • Standardized software can require less time depending on the degree of customization required.

  • Standardized software can be more reliable since it has been tested and used in many different applications.

  • Standardized software may provide more features than would otherwise be available.

Why Not Combine the Best of Both Options?


Buying a tool control framework can help you build your own tool control software and still get the benefits of using standardized software. The framework can take care of common problems while you focus on items unique to your specific tool. As a framework, features can be removed, replaced, or even modified as needed. You reduce your costs as well as your time-to-market by using a selection of reliable, field-proven features and including only those that are relevant and add value to your control system. You still retain and build your in-house technical expertise to create competitive advantages in controlling your equipment instead of treating tool control expertise as a commodity.

Using a tool control framework can be a smart way to improve your processes by using standardized software that is easy to customize. So why not consider it as an option for your next project?

If you are interested in downloading the data sheet on Cimetrix’ tool control framework software, CIMControlFramework, click here.

Topics: CIMControlFramework, Equipment Control-Software Products, Equipment Automation Framework, Software

Cimetrix at SEMICON West 2012 - Equipment Control

Posted by Cimetrix

Jun 29, 2012 1:30:00 PM

If you are going to attend SEMICON West in San Francisco, July 10-12, 2012, at the Moscone Center – please visit us at booth #1241 and let us tell you how we can support your next equipment control project using our CIMControlFramework™ equipment automation software.

CIMControlFramework dashboard

As more and more customers use CIMControlFramework software on different tool types (strip tools, MOCVD, defect inspection, chemical deposition, and a host of others), we have also generated training material in the form of labs our customers can use to help them get up to speed faster and learn how to implement designs easier and more effectively.

Come to our booth and take a look. When we demonstrate CIMControlFramework, we will show you the labs we supply with the software. Those labs include not only topics such as installation and fundamentals, but also sections such as scheduling and material movement, user interface development, and I/O and communications.

We can also discuss our product support and training classes that will help get your team up and running on SEMI factory connectivity standards, and their implementation, equipment control, and C# and Agile software development.

We look forward to seeing you at our booth at SEMICON West.

Topics: SEMICON West, CIMControlFramework, Equipment Control-Software Products

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

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

CIMControlFramework Logging Benefits

Posted by Cimetrix

Jun 2, 2010 5:00:00 AM

by David Warren,
Senior Software Engineer, CIMControlFramework Solution Architect

Part 2 - Read Part 1

Would it surprise you to find out there are still people who pan for gold? Some are serious prospectors working for a payoff. Others are recreational prospectors who enjoy the outdoor activity and the actual finding of gold is of secondary importance. Regardless of their motivation, most prospectors must sift a great deal of material in order to find a few flakes of gold. Having the right equipment helps the serious prospector to sift more material and find gold more quickly than someone just looking for a good time.

What does panning for gold have to do with Cimetrix? In a previous blog, we talked about the importance of having log data when problems occur. Log data can be like panning for gold—most of the log data has little to do with the problem you are currently trying to solve, but a few of the messages will be pure gold. Having the right tools to find the gold log messages quickly can make all the difference in the world in resolving problems in a timely manner.

Analyzing tens of megabytes of text data with a text editor and a pair of Mark I eyeballs is difficult at best. Yes, text editors do have the ability to search for words or phrases, but that only helps if you already know what you’re looking for. Jumping into the middle of a log file lets you look at the messages in that part of the file, but gives you no context into what has happened before or after the log messages you are looking at.

CIMControlFramework, our tool control solution, contains a Log Viewer application to help analyze CIMControlFramework log files. It has standard text analysis features such as text search and bookmarking, but because it understands CIMControlFramework log messages, it has more powerful features as well. It adds features like time deltas, finding matching messages for function entry and exits, and tracing a single thread’s log messages. But its most powerful feature is being extensible through plug-ins. These plug-ins have the ability to analyze all the log messages and graphically display information to give context to the current log messages.

timing charts screen shotOne such plug-in is the Timing Chart. The Timing Chart looks at all the function entry/exit log messages and creates a timing chart centered on the current log message. This allows you to look at all the functions that are currently being executed and how long each function took to complete. It also shows which functions just finished and which functions are about to start. It just wouldn’t be feasible to keep track of all that information manually. Another plug-in tracks wafers as they move through tool. A third plug-in keeps track of GEM300 job data. And you are not limited to our ideas for plug-ins, you can develop your own to display the log data however you want.

Having the CIMControlFramework Log Viewer and its plug-ins helps you to sift through the log data and find the gold log messages quickly and efficiently. Finding the right log messages will enable you to resolve problems in a timely manner.

You might also be interested in:

Topics: CIMControlFramework, Equipment Control-Software Products, Product Information, Logging

WCF and CIMControlFramework

Posted by Cimetrix

Feb 1, 2010 7:08:00 AM

by Derek Lindsey,
Principal Software Engineer

When creating new tools for use in the semiconductor industry, most original equipment manufacturers (OEMs) prefer to concentrate on their area of expertise – the processing of wafers. The bother for them is that they have to conform to material handling standards to get the wafers delivered to the correct process module before they can perform process on the wafers. They also have other overhead that takes time and resources away from what they do best. This overhead includes operator interfaces, recipe management, error handling and the list goes on.

With CIMControlFramework™ we set out to create a flexible equipment automation framework that handles much of the overhead associated with wafer processing. This allows OEMs to spend more time on perfecting their processing while still creating a first class application to drive the tool. The framework includes packages for performing recipe management, alarm management, user management, configuration management, message logging, scheduling, factory automation, user interface and material handling.

Data generated at any point on the tool from any of these packages can be quickly and easily accessed by any other module or external application. This is where Windows Communication Foundation (WCF) enters the picture. To paraphrase Reggie Jackson, WCF is the straw that stirs the drink. It allows access to all of the functionality provided in these packages. Cimetrix chose to use WCF for distributing the functionality contained in each of these packages. WCF is as easy as ABC. In order to use WCF services, we need three pieces of information: an Address, a Binding and a Contract (A, B, C).

Each of the packages listed above provides a service with functionality for clients to access. The functionality provided by the service is the contract. An address is where the service is located. A binding is how the client talks to the service (what protocol is used.) These three pieces of information are called an Endpoint. Once a client application knows the endpoint, it can access the vast array of functionality provided by the CIMControlFramework service packages.

Once an OEM taps into CIMControlFramework, they can focus their resources on process technology and product differentiation.

An excellent blog on WCF can be found here:

You might also be interested in:

Topics: CIMControlFramework, Equipment Control-Software Products, Product Information, Equipment Automation Framework, Programming Tools, WCF

Logging - enabling passionate support

Posted by Cimetrix

Jan 19, 2010 9:06:00 AM

by David Warren,
Senior Software Engineer, CCF Solution Architect

Logging ScreenshotIn today’s world, having great software is not enough. To be successful, software must also be supportable. Keeping a record of what the software is doing and has done enables after-the-fact diagnosis and makes remote support much more efficient. As an additional benefit, this information can also be displayed live to the GUI, giving the operator additional insight into what is happening. Having a record makes it possible to determine if the software is working correctly or incorrectly. In Cimetrix’s new tool control software, CIMControlFramework™, this functionality is provided by the Logging package.

The CIMControlFramework Logging package provides an MxN information delivery system—the logging package receives information from multiple sources and delivers it to multiple destinations. These sources may be different software components or instances within the same process. They may even be in other processes on the same or different computers. Likewise, the destinations may also be distributed. Some destinations may store the information for a few seconds or minutes, like printing to a console or displaying on a GUI. Other destinations may store information for many days or indefinitely in a database or file.

Logging is a two-edged sword however. There is a balance between information and performance. Storing too much information can adversely affect performance. Storing too little information boosts performance, but limits the benefits of logging. Too often the mindset is to turn logging off most of the time, and only turn it on when trying to solve a problem. I think it is more effective to turn on as much logging as possible—and then leave it on all the time. It may be necessary to limit the information flow to CPU intensive destinations to maintain acceptable performance, but it is worth it. By leaving logging on all the time, it is possible to find those problems whose descriptions start with “This only happened once, but…”

Logging enables passionate support. Just as surveillance cameras can provide more information than an eyewitness, a log record can provide more information than a customer incident report. The additional information is usually crucial in finding root causes and resolving customer issues quickly. And that’s something we are all interested in.

You might also be interested in:

Topics: CIMControlFramework, Equipment Control-Software Products, Product Information, Logging

What is a Software Framework? And why should you like 'em?

Posted by Cimetrix

Oct 2, 2009 8:59:00 AM

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:

<Window x:Class="WpfApplication1.Window1"

xmlns="" xmlns:x=

Title="Window1" Height="300" Width="300">


<Button Name="button1" Click="button1_Click">Button</Button>



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:

namespace WpfApplication1


/// <summary>

/// Interaction logic for Window1.xaml

/// </summary>

public partial class Window1 : Window


public Window1()




private void button1_Click(object sender, RoutedEventArgs e)


MessageBox.Show("Hello world.");




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.


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


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

Topics: CIMControlFramework, Equipment Control-Software Products, Equipment Automation Framework, Programming Tools

Receive Email Updates

Follow Us

Learn More About the
SEMI Standards


GEM 300

Interface A/EDA