Industry News, Trends and Technology, and Standards Updates

EDA Best Practices Series: Choose to Provide E164-Compliant Models

Posted by Derek Lindsey: Product Manager on Aug 28, 2019 11:42:00 AM

In the EDA Best Practices blog series, we have discussed choosing a commercial software platform, using that package to differentiate your data collection capabilities and how to choose what types of data to publish. In this post we will review why you should choose to provide an E164-compliant equipment model.

What is E164?

Equipment Data Acquisition (EDA) - also referred to as Interface A - offers semiconductor manufacturers the ability to collect a significant amount of data that is crucial to the manufacturing process. This data is represented on the equipment as a model, which is communicated to EDA clients as metadata sets. The metadata, based upon the SEMI E125 Specification for Equipment Self-Description, includes the equipment components, events, and exceptions, along with all the available data parameters.

Since the advent of the SEMI EDA standards, developers and fabs have recognized that equipment models, and the resulting metadata sets, can vary greatly. It is possible to create vastly different models for similar pieces of equipment and have both models be compliant with the EDA standards. This makes it difficult for the factories to know where to find the data they are interested in from one type of equipment to another.

Recognizing this issue, the early adopters of the EDA standards launched an initiative in to make the transition to EDA easier and ensure consistency of equipment models and metadata from equipment to equipment. This effort resulted in the E164 EDA Common Metadata standard, approved in July 2012. Another part of this initiative was the development of the Metadata Conformance Analyzer (MCA), which is a utility that tests conformance to this standard. With this specification, equipment modeling is more clearly defined and provides more consistent models between equipment suppliers. This makes it easier for EDA/Interface A users to navigate models and find the data they need.

Power of E164

The E164 standard requires strict name enforcement for events called out in the GEM300 SEMI standards. It also requires that all state machines contain all of the transitions and in the right order as those called out in the GEM300 standards. This includes state machines in E90 for substrate locations and in E157 for process management. The states and transition names in these state machines must match the names specified in the GEM300 standards.

These requirements may seem unnecessarily strict, but implementing the common metadata standard results in:

  • Consistent implementations of GEM300
  • Commonality across equipment types
  • Automation of many data collection processes
  • Less work to interpret collected data
  • Ability for true “plug and play” applications
  • Major increases in application software engineering efficiency

Knowing that a model is E164 compliant allows EDA client applications to easily and programmatically define data collection plans knowing that the compliant models must provide all of the specified data with the specified names. For example, the following application is able to track carrier arrival and slotmap information as well as movement of material through a piece of equipment and process data for that equipment.eda-best-practice-e164-1

This application will work for any GEM300 equipment that is E164 compliant. The client application developer can confidently create data collection plans for these state machines, knowing that an E164-compliant model must provide the needed state machines and data with the proscribed names.

Decide to be E164 compliant

A number of leading semiconductor manufacturers around the globe have seen the power of requiring their equipment suppliers to provide EDA/E164 on their equipment, and now require it in their purchase specifications.

If you are a semiconductor manufacturer, you should seriously consider doing the same because it will greatly simplify data collection from the equipment (and most of your candidate suppliers probably have an implementation available or underway.

If you are an equipment supplier and your factory customers have not required that your EDA models be E164 compliant, you should still seriously consider providing this capability anyway as a way to differentiate your equipment. Moveover, E164-compliant models are fully compliant with all other EDA standards. Finally, it is much easier and more cost effective to create E164-compliant models from the outset than it is to create non-compliant models and then convert to E164 when the factory requires it.

Conclusion

The purpose of the E164 specification is to encourage companies developing EDA/Interface A connections to implement a more common representation of equipment metadata. By following the E164 standard, equipment suppliers and factories can establish greater consistency from equipment to equipment and from factory to factory. That consistency will make it easier and faster for equipment suppliers to provide a consistent EDA interface, and for factories to develop EDA client applications.

Contact Us

Topics: Industry Standards, EDA/Interface A, Doing Business with Cimetrix, Smart Manufacturing/Industry 4.0, Cimetrix Products, EDA Best Practices

EDA Best Practices Series: Specifying and Measuring Performance and Data Quality

Posted by Alan Weber: Vice President, New Product Innovations on Aug 1, 2019 12:14:00 PM

The old adage “You get what you pay for” doesn’t fully apply to equipment automation interfaces… more accurately, you get what you require, and then what you pay for!

This is especially true when considering the range of capability that may be provided with an equipment supplier’s implementation of the EDA (Equipment Data Acquisition, also known as Interface A) standards. Not only is it possible to be fully compliant with the standard while delivering an equipment metadata model that contains very little useful information, the standards themselves are also silent on the topics of Performance and Data Quality.  So you must take extra care to state these requirements and expectations in your purchase specifications if you expect the resulting interface to support the demands of your factory’s data analysis and control applications. Moreover, to the extent these requirements can be tested, you should describe the test methods and tools that you will use in the acceptance process to minimize the chance of ugly surprises when the equipment is delivered.

We have covered the importance of and process for creating robust purchase specifications in a previous posting. This post will focus specifically on aspects of Performance and Data Quality within that context.

Scope of Performance and Data Quality Requirements

From a scope standpoint, Performance and Data Quality requirements are found in a number of sections in an automation specification. The list below is just a starting point suitable for any advanced wafer fab – your needs may extend and exceed these significantly.

Here are some sample requirements that pertain to the computing platform for the EDA interface software:

  • The interface computer should have the capability of a 4-core Intel i5 or i7 or better, with processing speed of 2+ GHz, 8 GB of RAM, and 500 GB of persistent storage with at least 50% available at all times.
  • The equipment must monitor key performance parameters of the EDA computing platform such as CPU utilization (%), memory utilization (GB, %), disk utilization (GB, %) and access rate, etc. using system utilities such as Perfmon (for Windows systems) and store this history either in a log file or in some part of the equipment metadata model.
  • The network interface card must support 1 GB per second (or faster) communications.

In the area of equipment model content, the following requirements are directly related to interface performance and data quality:

  • The equipment should make the EDA computing platform performance parameters available as parameters of an E120 logical element that represents the EDA interface software itself.
  • The supplier must provide a written description of the update rates, recommended sampling intervals, normal operating ranges and behaviors, and high/low/rate-of-change limits for all key process parameters. These will be used to design data quality filters in the data path between the equipment and the consuming applications/users.
  • Equipment parameters provided through the EDA interface must exhibit a number of data quality characteristics, including, but not limited to: an internal sampling/update rate sufficient to represent the underlying signal accurately; timing of trace reports that is consistent with the sampling interval within +/- 1.0%; values in adjacent trace reports must contain then-current values at the specified sampling interval; and rejection of obvious outliers.

Advanced users of the EDA standards are now raising their expectations for the equipment to provide self-monitoring and diagnosis capability in the form of built-in data collection plans (DCPs), as expressed in some of the following requirements:

  • The supplier must provide built-in DCPs to support common equipment performance monitoring, diagnostic, and maintenance processes that are well known to the supplier. Documentation for these DCPs must define their purpose, activation conditions, interface bandwidth consumed, and the types of analysis the collected data enables.
  • The supplier must describe the operating conditions that can lead to a PerformanceWarning situation for the EDA interface.
  • The supplier must describe the algorithms used to deactivate DCPs under PerformanceWarning conditions. These might include LIFO (i.e., the last DCP activated is the first to be deactivated), decreasing order of bandwidth consumed or “size” (in terms of total # of parameters and # of trace/event requests), etc.

Because of the power and complexity of the DCP structure defined in the EDA standards, it is not sufficient to specify the raw communications performance requirement as a small number of isolated criteria, such as total bandwidth (in parameters per second) or minimum sampling interval. Rather, since the EDA interface must support a variety of data collection client demands for a wide range of production equipment, these requirements should be expressed as combinations of sampling interval, # parameters per DCP, # of simultaneously active DCPs, group size, buffering interval, response time for ad hoc “one-shot” DCPs, maximum latency of event generation after the related equipment condition occurred, consistency of timestamps in trace reports with the specified sampling interval, and perhaps others.

Moreover, some equipment types may have more stringent performance requirements than others, depending on the criticality of timely data for the consuming applications… so there may be process-specific performance requirements as well.

Measurement and Testing

Methods for measuring and testing the above requirements should also be described in the purchase specifications so the equipment suppliers can know they are being successfully addressed during the development process and can demonstrate compliance before and after shipping the equipment. Clarity at this phase saves time and expense later on.

Examples of such requirements include:

  • The supplier must test the EDA interface across the full range of performance criteria specified above and provide reports documenting the results.
  • An earlier requirement states that the EDA interface must be capable of reporting at least 2000 parameters at a sampling interval of 0.1 seconds (10Hz) with a group size of 1, for a total data collection capacity (bandwidth) of 20,000 parameters per second. In addition to this overall bandwidth capability, the supplier must demonstrate that this performance is possible over a range of specific data collection deployment strategies, meaning different #s and sizes of DCPs, different sampling intervals, group sizes, etc. without causing the EDA interface to reach one of its “Performance Warning” states or overstress its computing platform. To this end, all combinations of the following data collection configuration settings must be run for at least 15 seconds each; assuming the equipment has n processing modules:
    • Trace intervals (in seconds): 1, 0.5, 0.2, 0.1 (and 0.05 if possible)
    • # of parameters per DCP: 10, 50, 100, 250, 500, 1000 (and 2000 if possible)
    • # of DCPs: 1, 2, 3, … to n
    • Group size: 10, 5, 2, 1
  • The test client should be run on a separate computing platform with sufficient computing power to “stay ahead” of the EDA interface computer; in other words, the EDA interface should never have to wait on the client system.
  • Test reports should indicate the start and stop time of each iteration (i.e., one combination of the above settings), and verify that the timestamps of the data collection reports sent by the EDA interface are within +/- 1% of the value expected if the samples were collected exactly at the specified trace interval.
Performance parameters of the EDA interface platform should also be monitored during the tests and included in the report. These parameters should include memory usage, CPU processing load, and disk access rate (and perhaps others) for all processes that constitute the EDA interface software.

This approach is shown in tabular form for a 2-chamber tool (see below); since Group Size does not (or should not) impact the effective parameters per second rate, it is not shown in the table.edabest-measure-1
  • A summary report for all performance tests that show acceptable message generation and transmission timing across the full range of data collection test criteria must be available.
  • Detailed SOAP logs for specific performance tests must be available on request.

In Conclusion

Red_smart_factory-TW

We hope you now have some appreciation for the importance of solid requirements in this area, and can accurately assess how well your current purchase specifications express your actual needs. If you want to know more about a well-defined process for improving your specifications, or have any other questions regarding the status and outlook of the EDA standards, and how they can be implemented, please contact us.

Contact Us

Topics: Industry Standards, EDA/Interface A, Doing Business with Cimetrix, Smart Manufacturing/Industry 4.0, Cimetrix Products, EDA Best Practices

Why choose a commercial product for the EDA (Equipment Data Acquisition) interface solution for your equipment? 为什么要为您的设备选择商用EDA解决方案?

Posted by Clare Liu (刘波); Solutions Engineer on Nov 20, 2018 11:10:00 AM
Lessons-Learned-small

Clare Liu, a Cimetrix Solutions Engineer, goes over the pros and cons of choosing a commercial product for EDA/Interface A vs. building a solution from scratch. Read it now in Chinese, or below in English. 

本文的焦点是当许多半导体设备制造商面对他们那些最先进的客户提出的自动化需求时,如何在购买支持EDA(Interface-A)标准的软件产品,或者自主开发之间做出决策。

鉴于我本人在今年初加入Cimtrix之前,曾经在一家半导体装备公司里担任EDA标准实现项目的主要开发人员,我想解释说明一下选择商业解决方案的利与弊。

1. 经验

在半导体制造设备上实现EDA要求软件开发人员具有半导体行业标准(SEMI)和半导体设备的经验。这对大多数设备供应商来说是非常困难的。即使他们已经拥有良好的软件开发人员,经验丰富的工厂自动化工程师和一个完整的硬件设计团队,他们还是需要有效的共同协作,找出如何设计一个结构良好的设备模型(SEMIE120 CEM 通用设备模型规范)并将设备所有的变量、时间和报警映射到设备模型的各个节点上(SEMI E125 EqSD设备自我描述规范)。 一个商业的EDA解决方案能够同时为OEM提供这些知识,并且可以基于该设备,提供EDA开发过程的指导方针。

2. 验收

checkmark简单地实现EDA接口功能和正确有效地实现的结果是不一样的。我从中得到的教训之一是,我们花了几乎整整一年的时间来实现EDA Freeze I的各种功能,并为测试的需要开发了客户端软件。然而,当我们将我们的EDA解决方案发布给客户工厂时,他们使用权威的第三方测试软件产品对所有设备的EDA解决方案进行了验证。我们的实现最初没有通过验收,因为我们对EDA标准的理解与客户的理解有些差异。为此我们花了很长时间来逐一解决验收中遇到的问题。商业的EDA解决方案通常已经在许多工厂得到了验证,因此更加标准化。

gantt-chart-cimetrix3. 时机

一个商业的EDA解决方案可以帮助OEM在短时间内开发出合格的EDA接口。自主开发EDA会给本已紧张的交付进度增加时间压力,如果需求来自一个新客户,第一个支持EDA标准的设备供应商通常会更有优势。在业务方面,EDA功能很有可能是获得订单的关键。在技术方面,第一个EDA的使用会成为整个Fab的范例,可以被用来制定其他设备在生产环境中必须满足的操作要求。

4.服务

使用商业EDA解决方案通常包括来自软件供应商的良好的技术支持,这些技术支持可能包含在最初的许可证费用中,或者是单独的技术支持合同。这意味着OEM公司不需要维持一个专门的软件团队来维护和解决遇到的软件问题。相反,他们可以依靠更专业的支持团队,而不用担心任何内部开发人员离开公司所带来的影响。

5. 知识更新

由于很多改进得到认同,还有很多新的技术在关键产品中的使用变得可行,半导体行业的EDA标准每年都在发生变化,在写这篇文章的时候,一个新的EDA标准冻结版本Freeze III正在投票中。商业EDA解决方案通常会紧紧追随标准的发展,同时会不断根据其他工厂用户的请求增加新的功能。这使得OEM能够快速、可靠地响应客户的最新需求。

1.成本

OEM必须为商业软件的许可证,以及可能的、每年的技术支持支付费用。

2.知识产权(IP)

一些OEM公司为了对EDA功能的源代码有完全的控制权和所有权,他们选择自主开发并拥有这些软件,其原因是大多数商业软件包通常不会为基本许可证的使用者提供源代码。

3.修复错误的时间

如果在商业软件包中发现错误,设备工程师甚至工厂客户可能需要帮助软件供应商找到根本原因。他们还必须等待供应商修复并发布新版本的软件。这对于使用者来说非常不方便。

如果您的公司正面临这样的决定,请联系我们——我们很乐意分享我们的专业知识和市场知识,并协助您做出明智的决定。

Schedule a Meeting

您可能还对以下信息感兴趣:

View Presentation: Raising the Bar
View Video: Importance of Process Module Tracking
View Video: E164 EDA Common Metadata
View Video: Equipment Modeling - E120/E125
Learn about CIMPortal 


Lessons-Learned-smallThe focus of this blog posting is the decision that many semiconductor manufacturing equipment suppliers face when deciding how to address the automation requirements of their most advanced customers, namely, whether or not to buy a commercial software package that supports the SEMI Equipment Data Acquisition (EDA / Interface A) Standards, or to develop this capability in-house.

I am especially qualified to explain the pros and cons of choosing a commercial solution, having worked as the EDA standards implementation lead developer in an equipment supplier before joining the Cimetrix team earlier this year.

  • Pros

1. Experience

Implementing EDA on a single unit of semiconductor manufacturing equipment requires that the software developers have experience with both SEMI Standards and the equipment. This is very difficult for most equipment suppliers. Even if they have good software developers, experienced factory automation engineers and a complete hardware design team, they must still work together efficiently to figure out how to design a well-structured equipment model (SEMI E120 CEM) and map all the equipment variables, events and alarm to the CEM nodes (SEMI E125 Equipment Self-Description).  A commercial EDA package provides all this knowledge for the OEM and guidelines explaining the EDA development process for their systems.

2. Qualifications

checkmarkSimply being able to implement the EDA interface functions is not the same as implementing them in a robust fashion. One of my lessons learned is that we spent almost an entire year to implement the EDA Freeze I version of the standards and the client software required to test these functions. However, when we released the EDA interface to the factory customer, they qualified the EDA solution for all equipment modules with an authoritative third-party compliance testing software product. Our implementation failed at first because our understanding of the SEMI Standards specifications was different from the customer’s understanding. So we struggled for a long time to fix all the problems.  A commercial EDA package will necessarily have been proven in many sites and is therefore far more standardized.

3. Timing

gantt-chart-cimetrix

A commercial EDA product can help the OEM develop a qualified EDA interface in a short time. Developing EDA in house adds time pressure to already tight delivery schedules, and if the requirements are coming from a new customer, the first equipment supplier supporting EDA standards may have an advantage. On the business side, EDA might be the key feature to get the order. On the technical side, the first usage may determine the approach used across the entire fab, thereby dictating operational requirements that the other equipment must meet in the production environment.

4. Service

Using a commercial EDA package normally includes good technical support from the software supplier; this may be covered in the initial license fee or as a separate support contract. This means the OEM company does not have to dedicate a large software team for maintenance and troubleshooting of software issues. Instead, they can rely on a professional support team, and not worry about what happens if any of the in-house developers leave the company.

5. Knowledge update

The SEMI EDA standards are changing every year as improvements are identified and new technologies become viable for mission-critical production usage. At this writing, a new Freeze III version is being balloted. A commercial EDA package will closely follow the standards as they evolve and provide new features according to the requests from other factory users. This enables OEMs to respond quickly and reliably to the latest feature requests from their customers.

  • Cons

1. Cost

OEM must pay for the commercial package licenses and possibly for the annual support.

2. Intellectual Property (IP)

Some OEM companies want to have full control of the EDA interface source code, so they choose to develop and own the software by themselves. Most commercial packages don’t provide source code with a basic license.

3. Bug fixing lead time

If bugs are found in the commercial package, the equipment engineers and perhaps even the factory customers may need to help the software supplier find the root cause. And they must also wait for the supplier to fix and release a new version of the software. This can be quite inconvenient.

If this is a decision your company is facing, get in touch with us – we’re happy to share our expertise and market knowledge and help you make a well-informed decision.

Schedule a Meeting

You also might be interested in the following information:

View Presentation: Raising the Bar
View Video: Importance of Process Module Tracking
View Video: E164 EDA Common Metadata
View Video: Equipment Modeling - E120/E125
Learn about CIMPortal 

Topics: EDA/Interface A, Customer Support, Doing Business with Cimetrix, Smart Manufacturing/Industry 4.0, EDA Best Practices