Posted on Thu, Jun 24, 2010
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:
Posted on Wed, Jun 02, 2010
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.
One 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:
Posted on Mon, Feb 01, 2010
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: http://blah.winsmarts.com/2008-4-What_is_WCF.aspx
You might also be interested in:
Posted on Tue, Jan 19, 2010
by David Warren,
Senior Software Engineer, CCF Solution Architect
In 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:
Posted on Thu, Dec 17, 2009
by Dave Faulkner,
EVP, Sales & Marketing
At SEMICON Japan 2009, Cimetrix announced a transition in its distribution strategy in Japan. Rorze Corporation has been appointed as the exclusive distributor in Japan for Cimetrix Factory Automation and Tool Control products. Rorze provides innovative robotic and wafer handling solutions to the global semiconductor industry. 
Cimetrix and Rorze have been working together for several years with Rorze transitioning the FA for its Sorter line to Cimetrix CIMConnect and CIM300 products, and working closely with Cimetrix to integrate its EFEM and vacuum platforms with the Cimetrix CIMControlFramework tool control software. This technology exchange led to an investment by Rorze in Cimetrix and the appointment of Rorze as the Cimetrix exclusive distributor in Japan. Rorze’s software department has engineers on staff who are familiar with the SEMI FA standards and have used Cimetrix FA and tool control products on previous projects. Watch for more news as this relationship broadens to add new channels throughout Asia.
At SEMICON Japan, Rorze and Cimetrix demonstrated a new 450mm wafer capable vacuum platform. This platform was controlled by Cimetrix CIMControlFramework and was cycling both 300mm and 450mm wafers. It created quite a stir on the main aisle at SEMICON Japan due to the actual moving demonstration and discussions by ISMI about progress on industry usage of 450mm platforms. Please contact Rorze or Cimetrix for more information.
You might also be interested in:
Posted on Wed, Oct 21, 2009
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.
DOWNLOAD THE RECORDED WEBINAR HERE.
You might also be interested in:
Posted on Fri, Oct 02, 2009
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="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml
Title="Window1"
Height="300"
Width="300">
<Grid>
<Button Name="button1"
Click="button1_Click">Button</Button>
</Grid>
</Window>
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()
{
InitializeComponent();
}
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.
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.