What do the factories DO with all that data?
Unlike the other postings in this series which deal with specific features and capabilities of the SEMI E30 GEM (Generic Equipment Model) standard, this blog identifies a number of the factory applications that depend on collecting data from the equipment.
Moreover, since we often hear the question “How do the factories actually use the different types of equipment information we’re expected to provide?” this posting will summarize the specific data required to support a number of these applications. This list is by no means exhaustive, but should give you an idea of the range of factory stakeholders whose objectives are supported by GEM data collection.The figure below illustrates the relationship between the Key Performance Indicators (KPIs), the factory stakeholders responsible for optimizing them, the applications used to achieve this, and data required by these applications.
The most effective way to share this kind of information is in tabular form. Within a group of related applications (e.g., scheduling, preventive maintenance), the applications are listed in generally increasing order of complexity, which is also the likely order of implementation by the factory applications development staff.
| Factory Application | Equipment Data Required |
| OEE (Overall Equipment Effectiveness) | Transition events and status codes sufficient to classify equipment states for all time periods |
| Intra-equipment material flow | Material tracking events; material location state indicators and state change events |
| Process execution tracking | Start/stop events for all processing modules; recipe step indicators and step change events for all processing modules that support multi-step recipes |
| WTW (wait time waste) analysis | The combination of events required for the intra-equipment material flow and process execution tracking applications (see above) and context data required to classify material states for all time periods (see the SEMI E168 Product Time Management standard for a deeper explanation) |
| Time-based PM (Preventive Maintenance) | Run timers at the FRU (field replaceable unit) level |
| Usage-based PM | Usage parameters and accumulators appropriate for each FRU, such as time-in-state, execution cycles, fluid flow rates, consumables flow rates, power consumption, etc. |
| Condition-based PM | Meaningful “health indicators” for each FRU |
| FDC (Fault Detection and Classification) | Equipment/process parameters required by specific fault models and associated context information (this is difficult to do completely because most FDC models are “trained” with knowledge of “good” and “bad” runs, which is not known to the equipment supplier a priori) |
| Automated equipment interdiction | Remote stop command (e.g., issued by an FDC application sensing an existing or imminent fault) |
| Equipment configuration monitoring | Vector of important equipment constants with expected values and acceptable ranges; may need to support multiple sets, if the values are setup-dependent. Designed to catch human errors resulting from operator manual adjustments |
| Component fingerprinting | Performance parameters for key equipment mechanisms, including command/response signals at the sensor/actuator level |
| Static job scheduling | Setup and execution times per product/recipe combination and current setup information |
| Real-time job dispatching | Estimate of current job completion time; estimate of completion time for all material queued at the equipment |
| Factory cycle time optimization | Material buffer contents, job queue information |
| Operator notification | Notification codes for frequent operator actions in a non-/semi-automated environment, such as load/unload material, select/confirm recipe, provide manual “assist” if the equipment is stuck, etc. |
| Real-time dashboard | Equipment/component production status indicators |
| Equipment failure analysis | Meaningful alarm/fault codes and perhaps recent history/statistics |
| Run-to-run process control | Identification of recipe adjustable parameters and commands to remotely update them |
To the extent that some of the application data described in the table above can be standardized across equipment types, there is an opportunity to create generic factory applications that would only require a mapping from the supplier-specific GEM IDs (collection event IDs, status/data variables, equipment constants, etc.) to their generic counterparts. But this is a topic for another posting on the concepts of “plug-and-play” in a GEM context.
We hope this explanation helps you appreciate how valuable equipment information is for the factories that consume it, and therefore how important it is to provide a rich set of events, variables, and other detailed information in the GEM interfaces you design in the future.
Click here to read the other articles in our SECS/GEM Features and Benefits series.
To download a white paper on an introduction to SECS/GEM, Click below:
