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