Background and Audience
Over the past several years, I have written numerous blog postings heralding the benefits of the SEMI Equipment Data Acquisition (EDA, also known as Interface A) standards, promoting their adoption by 300mm wafer fabs around the world, explaining how to develop robust purchase specs to ensure the interfaces delivered by the equipment suppliers meet the fab customers’ expectations, describing how the various components of the standards work together and the importance of the embedded equipment model, and finally explaining how to run compliance and performance tests on an EDA interface to validate its fitness for production use. The target audience for most of these postings has been the factory users, for they are the ones who increasingly depend on detailed equipment and process data to profitably run their enterprises.
By contrast, this posting is aimed at the equipment suppliers who are looking to increase the value of their product families by augmenting their hardware offerings with software capabilities that only they are uniquely qualified to provide.
This is not a new idea. Several major equipment suppliers have offered so-called “Equipment Engineering Systems (EES)” products as companions for their equipment over the years, providing applications like Fault Detection and Classification (FDC), production monitoring, maintenance management, local repositories for diagnostics and field support, and other capabilities that leveraged deep domain knowledge of the equipment. However, these systems necessarily relied on private interfaces to the equipment for their data, such as an additional network connection, direct access to the file system, or other mechanisms. And from the fab’s perspective, these constituted yet another piece of infrastructure to maintain.
Now there’s EDA: a key enabler for value-added equipment applications
Since the SEMI EDA standards are inherently multi-client, a single EDA interface can support not only the factory information and control systems that depend on equipment data, it can also provide whatever information a supplier-specific application may need as long this data is represented in the equipment metadata model. Since that model is designed by the equipment suppliers as a fundamental component of the EDA interface, they can choose to put as much information in these model as they want, possibly well beyond that required by the fab customers’ purchase specifications. In fact, these models could be used to implement the diagnostic logging capability that suppliers usually build into their equipment for their own use, but without requiring custom software to read and interpret that information. See the figure below for an example of such a configuration.
The EDA standards also include a provision for “built-in DCPs” (DCP = Data Collection Plan) which can be shipped with the equipment and protected from accidental deletion at the factory site. These DCPs could be crafted by the equipment supplier to directly feed whatever value-added applications the supplier chose to develop, whether these resided on a computer local to the equipment in the fab, on portable computers used by field service engineers to diagnose problems, or on remote cloud-based systems allowed to connect via secure EDA-defined URLs. This flexibility opens up a wide range of application types, from those that embed equipment-specific algorithms to generic Machine Learning frameworks… the possibilities are endless.
What all these approaches have in common is a standard EDA client capability that can establish a session with the equipment, activate Data Collection Plans, and receive the ensuing Data Reports. The Cimetrix EDAConnect product provides all these features and more in a lightweight set of .NET libraries which can be deployed wherever they are needed to consume EDA data.
Conclusion
More and more semiconductor factories are requiring EDA interfaces with their new equipment purchases with highly prescribed equipment models and demanding performance criteria. From the equipment supplier’s perspective, these requirements have been viewed as a source of additional cost, with all the benefit accruing to the factory customers. But it doesn’t have to be that way…
Why not take advantage of this interface to offer additional value using a standards-based approach? This just might be an idea whose time has finally come. If you agree, give us a call – we can help you make it happen!
