Savantech is a leading global supplier of equipment automation software (CoreTegral) and services to complex manufacturing industries. We have been helping our customers increase yield, improve productivity and obtain the most from their equipment since January 2005. Our experience in the semiconductor manufacturing industry, earned from having produced hundreds of equipment automation solutions over the last two decades, can help you return excellent ROI and achieve operational efficiencies that will make your business fly.
In today's high-tech manufacturing industry, companies are under ever-increasing pressure to distinguish themselves from their competitors. It is not enough to simply design world-beating products, they must ensure that their manufacturing facilities are operating at maximum productivity whilst retaining the flexibility to meet rapidly changing market demands.
Equipment automation is an extremely cost-effective means of increasing the ROI of the entire semiconductor manufacturing facility. Full-fab automation is not an option for most existing semiconductor/MEMS manufacturing facilities, and is, indeed, not usually the best solution.
Excellent ROI can be achieved by automating a select set of key equipment in the first instance, to address pressing problems of scrap, poor throughput or poor process yield. As the cost benefit of automating those tools is proven, further functionality can be introduced and/or further tools automated. Savantech Limited offers a complete package of tailored solutions and services to help you realise the many benefits to be gleaned from implementing tool automation.
Savantech offer a comprehensive range of software services to the Semiconductor Manufacturing, Solar/PV, MES and EMS industries.
Benefits of tool automation
We work with industry-leading software products, ensuring that our customers never find themselves with out-of-date or unsupported systems. We have integrated to all of the major factory-level MES, OEE, and APC systems available on the market today as well as several in house developments.
CoreTegral® is Savantech's deployment and management environment for distributed high-availability systems, focussing on low solution maintenance effort.
It provides an environment for rapid development of consistent, robust automation solutions, utilising visual and easily modifiable workflow business logic.
CoreTegral applications are created using the MS Visual Studio development environment, which both minimises the need for industry-specific software development skills and allows ease of maintenance once deployed.
In addition, there is a growing library of existing plug-in functionality e.g. Resource Management System (RMS), MES- and tool-specific connection components.
CoreTegral was launched at Semicon West 2010, and has continued to be actively developed and enhanced thereafter.
Please use the menu on the left to learn about the unique features of this exciting new product.
CoreTegral has several Unique Selling Points that elevate it above competing products:
(View example images of the environment features described above)
In 2007 the Savantech team identified that within the high-tech manufacturing industry there is a need for an equipment automation/integration product that will be flexible, adaptable, grow with a business and be simple to maintain on an ongoing basis. In order to achieve this, we determined that it was imperative that the platform not be proprietary or require specialist program language skills, but makes use of industry standard development tools.
Incumbent systems in the industry tend to be large and complex, and need either specialist internal resource or external consultants to maintain them. They have typically been written in proprietary technologies both due to inadequacies in the mainstream tools at the time, and also perhaps with the intention of securing long-term revenue from service/maintenance support. Critically, some are now end-of-life due to either the underlying technology being declared obsolete or the automation system becoming unsupported, with the only alternatives being expensive, overly complex and offering no migration path. CoreTegral was planned to be written in an industry standard program language which would allow customer end users to much more easily maintain the system. This unique and innovative approach is at the very heart of our new product.
The team who have developed CoreTegral are deeply steeped in the art of equipment integration and have invested all that they have learnt from their many years' experience in the industry into the product. As developers, we have focused on creating an environment that is tremendously flexible and instantly familiar to anyone versed in developing C# in the Visual Studio environment, whilst ensuring that all of the content and facilities that enable easy development of tool integration solutions in a high-tech manufacturing environment are readily to hand. As a company offering long-term support and maintenance for customers with automation solutions written in legacy systems, we have identified the most troublesome and oft-seen issues and worked hard to create supportive and capable deployment and management tools that trivialise what might otherwise be testing problems.
We believe that this fresh approach of making the maintenance easy for our customers, whilst offering specialist support and services, combined with the security of not relying on non-mainstream technologies, will prove an attractive and winning proposition.
The CoreTegral approach is to keep the product as lightweight as possible, utilising templates to increase productivity in creating site-specific solutions, without trying to second-guess all required functionality and scenarios in advance. Experience has shown that a ‘middle-ground’ template driven approach is more effective than either a toolkit approach or a pre-built monolithic solution approach. Re-invention of the wheel has been avoided as much as possible, and the standard Microsoft development environment and mainstream interface driven coding practice has been adopted.
It has been built from the ground up using C# within the .Net environment, but embodies many of the most successful algorithms, lessons and concepts encountered by the developers in the creation of bespoke factory automation solutions and products over the last 20 years.
CoreTegral has at its centre a base product that is an automation framework. This can be used in any manufacturing environment where there are complex tools involved. Built upon the core is tailored semiconductor functionality which specifically focuses upon the demands of integrating to tools with SECS interfaces and with the most common MES and other fab-level systems. Savantech also offer optional components within this layer - such as Recipe Management, Lot Identification and Automated Material Handling System integration - and which can be purchased to add new and higher level functionality as and when a company need them.
Finally, there is still be a requirement for specific logic services to tailor the product to the individual needs of an specific customer location. This final layer, the "application layer", is where CoreTegral users have free reign to customise and map solutions that fit their exact requirements. CoreTegral ships with working example template solution code, a web-based status UI and access to SQL Reporting services that facilitate full visibility into the heart of the automation solution.
(view some example images of the above features)
We recognise that every customer has different needs and specific requirements that will impact their equipment automation solution purchasing decisions. To that end, we have developed two main options for purchasing CoreTegral.
This purchase model is for customers who prefer to pay up-front for the CoreTegral platform and then use it for their own internal developments. The customer is granted licence to use CoreTegral site wide at that fab location.
This, our recommended option for customers purchasing CoreTegral, offers a partnership whereby Savantech will supply both the software and the services to implement specific tool solutions.
Savantech personnel will deliver a package comprising both the CoreTegral solution for the first target tool type, and a template for all future automation solutions for that customer.
If you would like further information about purchasing CoreTegral, please don't hesitate to contact us and we would be delighted to provide you with all the information required.
Like all technologies, it is often not until Workflows are used in anger that the techniques to get the most out of them become clear. Here are some things that our deployment engineers have picked up on when using parallel activities in flowcharts.
It is important always to remember that a workflow uses a single thread. This is key for understanding how a flowchart behaves when acting as a high level client to components in the (multi-threaded) CoreTegral environment. For example, if a 'parallel' activity is started that may be initiating some actions to the equipment at the same time as listening for events from it, then it is important to remember that 'parallel' activities are not really parallel. The leftmost sub-activity within the 'parallel' activity will be activated first, and only after it reaches a blocking point will the next sub-activity be kicked off. In practice, this typically means that if one of the parallel sub-activities is listening to an event that may result from logic in the other, then that sub-activity should be placed on the left.
Another feature of parallel activities to be aware of is the behaviour when a completion condition is set. Each parallel activity can have a completion condition, and if this is set to true then all the sub activities will complete at the next blocking point. The completion will not ripple upwards like a try-catch though, and the next activity in the flow should handle all completion states. The CoreTegral Event Listener activity can be used within parallel activities, but if listening for multiple different events it often makes more sense to use a single CoreTegral Event Listener in a traditional event handling loop. Once activated, each instance of the CoreTegral Event Listener has its own queue of events and will continue to receive events even though it is not currently active. This means that as long as the logic resulting from the received event does not take longer to complete than the queue expiry timer (default 30 seconds) then no events will be lost and they can be removed in order for processing from the queue.
Like all technologies, it is often not until Workflows are used in anger that the techniques to get the most out of them become clear. Here are some things that our deployment engineers have picked up on when using parallel activities in flowcharts.
It is important always to remember that a workflow uses a single thread. This is key for understanding how a flowchart behaves when acting as a high level client to components in the (multi-threaded) CoreTegral environment. For example, if a 'parallel' activity is started that may be initiating some actions to the equipment at the same time as listening for events from it, then it is important to remember that 'parallel' activities are not really parallel. The leftmost sub-activity within the 'parallel' activity will be activated first, and only after it reaches a blocking point will the next sub-activity be kicked off. In practice, this typically means that if one of the parallel sub-activities is listening to an event that may result from logic in the other, then that sub-activity should be placed on the left.
Another feature of parallel activities to be aware of is the behaviour when a completion condition is set. Each parallel activity can have a completion condition, and if this is set to true then all the sub activities will complete at the next blocking point. The completion will not ripple upwards like a try-catch though, and the next activity in the flow should handle all completion states. The CoreTegral Event Listener activity can be used within parallel activities, but if listening for multiple different events it often makes more sense to use a single CoreTegral Event Listener in a traditional event handling loop. Once activated, each instance of the CoreTegral Event Listener has its own queue of events and will continue to receive events even though it is not currently active. This means that as long as the logic resulting from the received event does not take longer to complete than the queue expiry timer (default 30 seconds) then no events will be lost and they can be removed in order for processing from the queue.
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.
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.
