An overview of some features built into CoreTegral that are particularly relevant to the automation of more complex cluster or linked tools.
The CoreTegral template solution uses a 'Run' workflow. In this solution a ‘Run’ is defined as a group of material that makes its way through the tool using a common process. The typical common stages in a Run flow are :
• VERIFY – Where the material is verified as requiring common processing on the equipment (this involves primarily MES interaction). At the same time, the equipment is verified as currently being capable and available to process the material.
• LOAD – Where the material for the Run is loaded onto the equipment. Tracking/moving in at the MES may occur here.
• PREPROCESS – Preparation of the equipment to run the material (recipe selection, download or upload/compare etc)
• PROCESS – Where the material is processed. MES equipment processing state changes typically here.
• POSTPROCESS – Verification of the correct processing on the correct number of wafers etc.
• UNLOAD – Controlled removal of the material.
Tracking/moving out at the MES may happen here. Using that main approach, design features have been added that allow it to be applied to all equipment types. These features include:
1) De-coupling of material handling from the Run flow. The Run flow is informed by a lower level component when material has arrived or removed for it. The Run flow is only responsible for determining when it has enough material to start processing and when all material has been processed. This de-coupling allows the same basic Run flow to be used in SMIF (integrated / non-integrated / semi integrated), FOUP, Open Cassette, Tray. It also allows the same basic Run flow to be used regardless of the carrier identification mechanism (the material handler component is modified to cope with the carrier Id system for a facility). In the case of cluster tools, this also provides flexibility of whether to model as a single tool (most common for cluster), or as separate tools (most common for linked equipment like track/stepper combinations)
2) Multiple equipment connections. In CoreTegral the concept of multiple equipment connections to a single Run workflow is fully supported. These can either be multiple device ids in a single SECS connection, multiple different SECS connections, or alternative protocols. Appart from OPC applications, this feature is also useful in a linked solution where a decision is made that tools that have separate SECS connections are so tightly integrated that processing through them will be controlled by a single Run flow from start to finish.
3) Multiple workflow managers in a single solution. This feature means that a single solution process can be created that can contain, for example, several different independent equipment managers and associated Run flows – but integrated so that any of the run flows can communicate in a tightly coupled way with any of the associated equipment connections or other Run flows
4) Easy communication between solution processes. The fact that all components in all solutions are directly accessible using an API built on top of .Net remoting means that if a decision is made to loosely couple equipment automation solution processes, then they can still communicate efficiently directly to the interfaces on components within another solution – e.g. If the last stage in completing processing on a linked but independently controlled Track requires an informational SECS message to a Stepper - then it could be sent directly if required.
5) Our use of SQL Databases for all processing data within the automation solutions means that the database itself also allows significant sharing and combining of data. This facility means that information can be maintained accurately at the automation level, supporting rapid and controlled update (e.g. material location information and mapping information). This gives a lot of flexibility about how often and at what point external systems need to be updated.
In practice we have found that most front-end cluster tools we have encountered are tightly integrated and managed as a single equipment from the automation perspective – allowing the standard fab template automation solution to be used without significant modification. Linked solutions (e.g. track/stepper) are often more likely to be modelled as separate equipment, using some the of the features above. Tools like furnaces often see us using a separate solution instance per tube (effectively treating each tube as a separate equipment from the automation perspective). In situations where there is a continuous flow of material from one tightly coupled equipment to another (discrete manufacturing or some backend processes), then a design decision needs to be made based on how much data has to be passed between them and what the external systems require in terms of data and control.
Copyright © 2024 Savantech Limited
