Introduction
More about sc and its usages
Introduction
Here we will discuss the overall architecture of sc, its many usages and proven use cases.
Overview
First, what is sc? It is a script interpreter. The scripting language is similar to other languages such as the Unix shell script. sc is also event driven, reacting to external events. The sc interpreter is the engine that interprets a script that the user develops.
History
Developed in 2001, sc was up and running in production in 2002. sc is developed in ANSI 'C' and initially ran on UNIX, and Linux. In 2004, sc was published and is freely distributed under the terms of the GNU General Public License. Under the Cygwin environment, sc runs on Windows platforms as well.
Architecture
When discussing the architecture it is best to think of sc as a script interpreter inside a layer of protocols. How sc works it that it waits for a message to arrive on one of the protocol connections, perform some action using the script interpreter on that message, and send subsequent message or messages using other protocol connections.
Client Server
Sc is built on a client server architecture. This means sc can be a host allowing external clients to connect, or a client to an external host. Having established these connections, sc will wait for messages from these connections and respond accordingly as defined by the developed script. Although sc is singled-treated, it can establish and handle several client and server connections, appearing to be multi-threaded.
Supported Protocols
Having established either a client or server (or both) connections mentioned above, sc supports several protocols including:
- SECSI
- HSMS
- XML
- Serial
- Modbus
When discussing protocols, we also need to mention the physical connection. These physical connections include:
- sockets over TCP/IP
- local file sockets
- named pipes
- serial device ports
So when creating the client/server connection, sc allows you to define the physical connection and the protocol. When connecting to SECS equipment as either a driver or for characterization, sc supports these protocols, you can use the SECSI or HSMS protocols over the RS 232 (serial device port) or TCP/IP connection.
When connecting to a serial device such a barcode reader, you can use the Serial protocol on a TCP/IP connection. Other serial devices could include Keithley analog measurement devices.
You can connect to a Modicon PLC using the Modicon Modbus Protocol on a TCP/IP connection.
A host application can connect to sc as a server using the Serial or XML protocol on a TCP/IP or local socket connection.
Script Language
Sc uses an easy to program scripting language. It is much like the Basic or shell script languages. The language supports all the common programming structures (if then else statements) and controls (for and while loops). But it implements a much simpler approach to data types, as all data is stored as strings with the proper decoding or casting automatically done when referenced. Associated data types are supported allowing for flexible data storing (wafer id's or lot id's could be used for array indexes).
Sending and Receiving Messages
The real power in sc is the ability to send and receive messages using the various protocols. Sc allows you to enter the desired message to send in a common readable format.
For Serial messages, you enter the character (or byte) string to send.
For SECSII messages (used with the SECSI or HSMS protocols), the message is entered in the standard SML format, typically what appears in the manufacturers documentation.
To receive unsolicited messages or replies, it is even simpler. sc will decode and save the received message so that it can later be interrogated in the script. For SECII messages, there is no need for any predefinition of messages or message libraries. This is especially useful when manufactures use a dynamic layout for data or list structures.
Typical Usages
There are typically three areas where sc is well suited:
- equipment characterization
- equipment simulation
- equipment integration (EI) solution
The first two can be used regardless of the is deployed today. The third is for those looking for a new EI solution.
But first a note, as the following is targeted at automating SECS equipment, the same concepts however can apply to non-SEC equipment as well.
Equipment Characterization
One of the simpler usages of sc is for equipment characterization. You can quickly develop a script with the desired messages or operation scenarios. A trip into the fab may not even be necessary, as this can all be conducted from a remote setting.
You can extend this effort and implement your entire equipment acceptance criteria. There are areas of acceptance that need to be cover:
The first area of testing would include compliance testing. Making sure the tool behaves according to the published standards.
The second area (and often skipped) is the testing of required (or desired) operational scenarios. This goes beyond the standards testing to see how well the tool fits the EI's expectation of tool performance. As often is the case, tools can be compliant but not perform as expected.
Using sc as an equipment driver is the best way to handle these deficiencies in performance.
The third area of testing is the validation of equipment bug fixes and enhancements.
Equipment Simulation
Equipment simulators are the best way to support and develop your EI solution. Simulators can initially be created from either characterizations or manuals during the initial EI development.
But the real power of sc is the ability to programmatically generate sc scripts from equipment logs of actual production runs. Although this is not part of sc, it is no coincidence that the script format of the SECS message closely matches the tool's format of the SECS message. It basically becomes a one-to-one translation. This serves two critical purposes:
- By having a library of equipment simulators, you can perform regression testing before deploying new EI releases.
- When troubleshooting a particular operation scenario, having a simulation of that offending scenario aids greatly in diagnosis and fix of the problem. But the point here is that scenario can
As a note to the above, these generated sc scripts are further modified to allow for dynamic parameters such as job id, lot id, and wafer ids at runtime.
Equipment EI
Equipment drivers are excellent candidates for using sc. But first, lets discuss the approach to EI's. EI's have two functions:
- To implement the business rules for operations scenarios
- To interface to the equipment. concept of a one-size-fits-all automation solution.
To often a single solution tries to do both which does not work very well. While the rules may be the same for all tools, the tool interfaces will vary. This leads to customization of each EI defeating the initial
A better approach is to have two layers:
- A top layer that implements the rules
- a bottom layer (driver) that interfaces with the tool .
The top layer could be an sc application or other and is the same for all tools (or nearly all). This really is a one size-fits-all application because each tool is encapsulated by its driver.
The bottom layer or sc driver is developed and customized for each tool type. This isolates the details of the tool from the top layer. But however implemented, the two layers are separate developed and maintained applications.
Top Layer
The top layer provides the interface between the supervisory systems (MES and other external entities) and the sc driver. It is a one-size fits all solution. It implements the generic operation scenarios (business rules) for running all the shop floor equipment. This layer treats all tools the same and assumes each tool behaviors in a common manner. The sc driver will implement the deficiencies.
This layer would typically have scenarios for handling:
- Tool initialization
- Job setup
- Job start
- Data collection
- Events for equipment utilization
- Events for resource tracking
sc Driver
The sc driver provides a generic interface to the rules layer and a SECS interface to the equipment. But more important, its function is to make each tool appear generic to the rules layer. This is what sc was designed to do, convert generic commands into equipment specific commands. And manipulate equipment events emulating a common behavior between tools.
There are many instances where the driver plays an important role in encapsulating equipment. Below are some typical cases:
There are cases where the layout of a SECS message for a particular command differs slightly from the standards. It may be a data format type, or an ordering of optional parameters. These cases are very tool/manufacture specific and are best handled in the driver.
There are cases where we don't get the desired event from a tool. If we want to know when a job starts on a tool, this might be the job start event on one tool, or the wafer entering a chamber on another tool.
In the case of cluster tools, the sc driver can connect to multiple tools making the cluster appear as a single tool to the top layer.
If a tool has a discrete I/O analog device, perhaps for measuring temperature, the driver can connect to both the tool and the I/O device.
But the real power in the sc driver is that the SECS messages are visible to the developer in the sc program script.
A true story: For one tool we wanted to prevent the operator from initiating a Process Program Upload (S7F1). In sc we would send the following: send_reply name=tool S7F2 B 01 0 Using the existing EI at the time required the intercepting of a low-level service call. Much time was spent investigating the solution for such a simple request.
Extending
Sc can be extended, and it is most likely that support for new protocols or APIs would be needed. The internal design is implemented in such a way that these can be merged with the existing sc protocols. The script commands open, send and send_reply can be extended for such support. Again, the idea here is to have sc implement the message transport level, and the script program handle the message content.
This extension however, may be limited by the API's license. With sc being open-sourced, additions would also need to be published and made freely available. And this may violate the API's licensing agreement. Should this be the case, a gateway between sc and the target server would be the better approach. The gateway would implement the API on one side, and a simple socket interface to sc on the other side.
Current Customers
Customers worldwide are using sc for the support, development and integration of shop floor equipment. The big users are: Avago (old HP/Agilent) is using sc as the automation solution if 3 fabs. They are using the two layer approach as discussed. Spansion, Qimonda and Infineon are using sc for equipment simulators and characterizations. These are the fully operational scenarios discussed above. And there are others using sc for various projects for testing.
Future
The future for sc will include general support for fixes and enhancements. Also an IDE for developing and debugging sc script programs is being considered.