Traditional Chinese websiteSimplified Chinese website

Industry News, Trends, and Technology, and Standards Updates

Direct Dashboard Support: Episode 5 in the “Models in Smart Manufacturing” Series

Posted by Alan Weber: Vice President, New Product Innovations on Sep 13, 2017 10:30:00 AM

The definition for a traditional dashboard is fairly simple—“the panel facing the driver of a vehicle or the pilot of an aircraft, containing instruments and controls”—and well understood by anyone with much time behind the wheel.

EDAModels5.1.jpg

However, information technology dashboards in a business context take a few more words to describe. From Wikipedia, “dashboards often provide at-a-glance views of KPIs (key performance indicators) relevant to a particular objective or business process (e.g., sales, marketing, human resources, or production).” An example of such a dashboard for a single manufacturing process follows.

EDAModels5.2.png

Although only recently popularized by commercial BI (business intelligence) software packages, dashboard-style display technology has been around a long time. Specifically, the PLC (programmable logic controller) industry saw early on that the PC (personal computer) was an ideal user interface platform for machine operators, providing what most would call today an interactive “dashboard” for a piece of equipment or portion of a manufacturing process. PLCs were originally designed as solid-state replacements for the relay panels used for sequence control for small- to medium-sized manufacturing equipment of limited complexity. Over time, they grew in sophistication to include PID (proportional, integral, differential) control capabilities for unit processes across a wide range of industries, and became a vital component of major manufacturing facilities worldwide.

Despite the number of vendors that provided PLCs and the variety of applications they supported, all PLCs shared a common internal architectural feature called an “image register,” which is a section of memory that contains the process and state variables representing the complete status of the machine at any moment. Even though there were initially no industry standards that dictated the exact structure of an image register, they were similar enough that a basic PLC-specific driver was sufficient to map any PLC’s image register into the standard widgets of a dashboard-style operator interface, providing real-time display of process status and sometimes interactive control capabilities. One of the most successful such packages was the Wonderware InTouch software product, shown below in a batch process context.

EDAModels5.3.png

Until recently, the lack of standardization in the embedded control system architectures for semiconductor manufacturing equipment made the implementation of equipment-oriented factory-level dashboards fairly challenging. However, with the advent of the SEMI EDA (Equipment Data Acquisition) standards and, in particular, the increasing fidelity of the equipment models required by these standards, all that has changed. Especially for equipment suppliers who follow the SEMI E164 (EDA Common Metadata) standard, the structure and content of the embedded equipment model are sufficient to provide direct access to most of the parameters and events you’d expect to find in a dashboard. Displaying some equipment KPI's, such as OEE, may require a little additional calculation and perhaps some minimal user input, but the most of information needed to compute these metrics is readily available.

For example, if you want to see the list of jobs active on a piece of equipment, look no further than the JobManager logical element of the metadata model (see below*).

EDAModels5.4.png

If you want to display the material status of a piece of equipment—for example the carriers, lots, and substrates that are present—the MaterialManager logical element contains all of this information.

EDAModels5.5.png

To display the current performance status and recent history of the major equipment modules, use the state information and reason codes in the SEMI E116 (Equipment Performance Tracking) EPTTracker logical elements to achieve this objective.

EDAModels5.6.png

Recipe execution status information for each module capable of processing material is found in the ModuleProcess state machine within the relevant Process Chamber.

EDAModels5.7.png

And finally, if you want to show the current operations status of the equipment as a whole, this information is found in the GEM variables present in the metadata model.

EDAModels5.8.png

You can see from the above examples that despite the lack of standardization in the embedded equipment controller architectures across the semiconductor industry, the information needed in equipment level dashboards is directly provided by the industry standards that define the EDA interfaces. This provides yet another use case for factories to drive for the adoption of these standards.

In addition to the standardized data access, another feature of EDA that makes it ideal for dashboard implementation is its multi-client capability. The software implementing a factory-level dashboard can communicate with many pieces of equipment at once, since the data volume required from any single equipment is small. From the equipment point of view, the dashboard system would appear as a separate client from the other application client(s) with more intense data collection requirements. This separation of clients also means that the dashboard content can be changed easily, since this is accomplished by modifying the relevant DCPs (data collection plans) rather than changing the data collection application itself.

Last but not least, since SEMI E164 standardizes the actual event and parameter names in the metadata model, the DCPs that collect this information can be programmatically generated and activated for all the equipment that is E164-compliant. This represents a significant engineering cost reduction over the conventional methods used to identify, collect, and manage the information required to animate a real-time dashboard.

This article is the fifth in the series recently announced in the Models in Smart Manufacturing Series Introduction posting – be sure to watch for at least one more posting that wraps up this overall theme.

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

 

*The visualizations of equipment metadata model fragments are those produced by the Cimetrix ECCE Plus product (EDA Client Connection Emulator).

Topics: Equipment Models, Industry 4.0, Smart Manufacturing

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)