Taiwan translated pages

Semiconductor Industry News, Trends, and Technology, and SEMI Standards Updates

Models in Smart Manufacturing Series – Introduction

Posted by Alan Weber: Vice President, New Product Innovations on Mar 24, 2017 11:30:00 AM

As a child I was an avid model builder—airplane models, trains, engines, cars, ships, even monsters (anyone remember “The Visible V8” and “The Creature”?)—anything I could get my hands on. At the time I didn’t reflect on the source of this fascination, but with the benefit of hindsight, it is clear that these models provided an interactive, tangible way to visualize, explore, understand, and enjoy the topics that were interesting to me. It was a way to enrich an otherwise intellectual activity.

Visible_V8.pngCreature.png

In fact, when Hurricane Carla ravaged the Texas coast and cut our electricity for 3 days, one of our luckier neighbors snaked an extension cord over the fence, which provided just enough power to run the refrigerator, a small black-and-white TV, and… you guessed it… my electric train. 

Model_train.png

More than four decades later, I still enjoy working with models, but in the high-tech manufacturing domain, they often operate in the reverse direction, providing a logical way to interact with and understand physical entities, like materials, fixtures, processes, devices, components, equipment, and entire systems. And as important as various model types have been throughout the relatively brief history of the semiconductor industry, they are increasingly an integral part of the “Smart Manufacturing” initiative that is sweeping a wide range of industries worldwide. 

The focus of my next few blog posts will be the specific models that are inherent in the communications interface definitions for manufacturing equipment, subsystems, and other devices that are expected to cooperate over the [Industrial] Internet of Things. Our first post in this domain almost a year ago introduced the notion that the metadata models called for in the latest generation of SEMI Equipment Data Acquisition (EDA) standards were already directly aligned with the Industry 4.0/Smart Manufacturing vision. This series goes into much more detail, showing how specific sections of the equipment models in the GEM and EDA standards directly support many of the factory monitoring, analysis and control applications that are essential for running a Smart Manufacturing enterprise (see Substrate Management example below).

substrate_management.png

Moreover, to the extent that the structure and content of these models can truly be standardized, their associated applications can be process- and supplier-independent, greatly reducing the development and support costs for the factory IT departments while providing useful capabilities for the production engineering and operations stakeholders.

To get a feel for the overall direction of this series, download the presentation "The Role of Models in Semiconductor Smart Manufacturing",  along with the transcript,  from the APC Conference held last October in Phoenix. Then watch for subsequent postings that address specific applications, from productivity (OEE) monitoring, material tracking, product traceability, process execution monitoring, and beyond.

We look forward to your feedback and to sharing the Smart Manufacturing journey with you.

Topics: Equipment Models, Industry 4.0, Smart Manufacturing

OEM EDA Implementation Best Practices

Posted by Alan Weber: Vice President, New Product Innovations on Apr 26, 2016 1:00:00 PM

quality-mark-seal-2.jpg

With all the recent news of increased EDA (also known as “Interface A”)adoption, especially in Asia, this is the perfect time to highlight the “Top 10 Best Practices” that semiconductor manufacturing equipment suppliers can follow in planning and executing their implementations of this important suite of standards. As we’ve said in previous blog postings and other EDA-related material, it is best to take a long-term view of your EDA interface design, independent of what a particular semiconductor manufacturer’s automation specifications may initially require. In so doing, you can be certain your implementation will satisfy all future EDA requirements, enabling your control system software team to focus on the features that truly differentiate your equipment from that of your competitors. The information in this posting can give you a running start on this process. It’s important to note that the “best practices” summarized below are the culmination of many years of EDA standards definition, related software product development, and manufacturing production experience among the early adopters. As such, most of them could support a dedicated blog posting, so watch for these in the coming months. In the meantime, if you’re interested in more specifics, please contact us.

1. Build a useful equipment model

First and foremost, since the content of the “equipment metadata model” is effectively the data collection “contract” between the equipment supplier and the factory users, your customer’s ultimate satisfaction with the EDA interface depends on the content and structure of this model. The role most affected by this model is the process engineer, so the equipment component, variable, event, and exception names should match the tool documentation, and the logical hierarchy should mirror the actual hardware structure.

2. Consider non-functional requirements

System performance expectations change over time, and, as a result, the equipment automation requirements may not include sufficient or up-to-date detail in this area. Therefore you must document your assumptions about the performance of your interface in terms of maximum sampling rate, average number of parameters per data collection plan (DCP), total bandwidth required (e.g., 20,000 parameters per second), and other factors important to the customer. In addition to performance, these will include scalability, availability, flexibility, extensibility, and ease of use, among others.

3. Define robust system architecture

The architecture of an EDA interface is greatly affected by the non-functional requirements mentioned in number 2 above, in addition to the specific capabilities required by the SEMI standards. One way to ensure these requirements can be met is to separate the EDA interface software from the equipment controller. In other words, run it on a different computer dedicated to the interface. Moreover, stick with the services and protocols defined by the standard – don’t be tempted to implement custom extensions that will only apply to a specific customer or client application, as this just increases your future support costs.

4. Choose platform with extra “headroom”

Computer hardware is inexpensive compared to the cost of downtime and support, so choose a platform that has room to grow. Based on many years of production experience, Cimetrix can provide specific guidelines in terms of CPU speed, number of cores, memory, disk, and other system attributes. Note that you may also be expected to upgrade these platforms in the field as the standard and/or customer requirements evolve, so plan accordingly!

5. Implement E164 common metadata standards

The E164 “EDA Common Metadata” standards likewise incorporate equipment modeling best practices from many early EDA implementations, so you should consider these as a required baseline for your equipment model, whether or not the first EDA customer calls for them in the automation specs. It is actually easier to do this when developing a new EDA interface than it is to come up with a separate set of structural and naming conventions, but it can be very difficult to implement later. (Note that we have had a number of previous blog postings on this topic.)

6. Use equipment modeling tools

Since typically 75% of the interface development and maintenance time is spent dealing with the content and behavior of the equipment model, these tasks are a perfect candidates for [at least partial] automation via model creation/editing tools and associated “wizards.” These tools should be able to generate an E164-compliant baseline model to which process-specific information can be added naturally. Moreover, if possible, use the resulting tool configuration files to create models programmatically, which will greatly reduce support costs over time.

7. Provide complete visibility into equipment behavior

The principal motivation expressed for EDA adoption by the factory operations people across the industry is “better understanding of equipment/process behavior.” Therefore, to satisfy this need, equipment suppliers should provide as much information as possible about key process variables/events/exceptions, and all the underlying mechanisms (sensors, actuators, I/O, low-level fault conditions) that affect them. Also make sure the E157 “steps” (recipe step-level transition events) are visible and meaningful to enable the kind of fine-grained condition-based trace data collection required by leading-edge fault detection, run-to-run control, and predictive analytics applications. Apply the principle “when in doubt, include it” – your customers will thank you.

8. Build in “hooks” for field service support

An EDA interface can be valuable for your own field support team if the proper “hooks” are included in the model from the outset. These capabilities range from a simple “sniff test” (Is the interface up and running?) to complete recent history of the platform’s operating conditions and the EDA clients’ demands on the interface. An explicit logging strategy should also be defined and documented to enable the factory customers to do their part in getting you the information required for prompt, one-pass success in support situations.

9. Develop thorough test plans and use them

In addition to the range of test techniques expected for mission-critical software (unit, system, regression), EDA interfaces should be subjected to performance and stability testing as well. Most customers will also require standards compliance and other acceptance tests to be run, and results provided before and after delivery of the equipment. Where possible, industry accepted packages are preferable for this purpose.

10. Use proven commercial software

checklist.jpg

Last, but not least, you should heed the advice of race car drivers, test pilots, and stunt men who regularly caution their audiences “Don’t try this at home!” The related message for interface developers is that the EDA standards, while mature and well documented, are complex, moving targets that require significant expertise, time, and effort to understand and implement reliably. For most equipment suppliers, this resource is far better spent building features that differentiate the equipment, and relying on companies with proven track records to provide off-the-shelf interface software products that minimize both time-to-market and project risk.


We sincerely hope this material is useful to you, and feel free to contact us for more information.

Topics: Interface A, EDA, Equipment Models

A case for custom programming tools when creating equipment models.

Posted by Cimetrix on Oct 13, 2009 8:00:00 AM

by Allyn Sullivan,
Software Engineer

I have recently worked with several customers who were in the process of building CIMPortal equipment models for their tools. Some were using the Equipment Model Developer (EMD) which ships with CIMPortal while others were programmatically building their models using the CxModel API. Working with both sets of customers, I saw a very real need for customers to develop programming tools to create equipment models instead of relying on the EMD alone.

Every model has a unique equipment configuration. Building an equipment model through the EMD is a laborious process. Each node of the equipment is added individually with a minimal amount of automation. Although suitable for those new to CIMPortal and initial model development, the EMD is not practical for building the many unique equipment models required for every tool configuration that a manufacturer makes.

Most manufacturers use a base tool to which they can add components to meet their customer's specification. Equipment configuration data can then be imported from the bill of materials (BoM), parts inventory, or other data from the manufacturing system of record. The model builder application can import this data (from a database or spreadsheet, for example) and use the CxModel API to generate several unique equipment models automatically. The application should be able to easily generate equipment models for any tool in the manufacturer's inventory.

Developing the proper tools that meet your individual needs is the most efficient way of creating equipment models for CIMPortal. You'll save time over using the EMD and have more consistent equipment models across tools.

Questions about developing equipment models?
Post a comment or send me an email.
Want to learn more about the Interface A Standards?
Cimetrix will be hosting a webinar on November 12, outlining the features & benefits of Interface A - presented by Doug Rust.

DOWNLOAD THE RECORDED WEBINAR HERE.

You might also be interested in:

Topics: Equipment Data Acquisition, CIMPortal, Programming Tools, Equipment Models, EMD

Subscribe to Email Updates

Follow Me

Learn More About the
SEMI Standards

SECS/GEM

GEM 300

Interface A/EDA

PV2 (PVECI)