Industry News, Trends and Technology, and Standards Updates

Resources Round-up: Videos

Posted by Kimberly Daich; Director of Marketing on Aug 3, 2019 1:28:00 PM

Resource Center-1The Cimetrix Resource Center is a great way to familiarize yourself with standards within the industry as well as find out about new and exciting technologies.

Our resource center features information about equipment connectivity and control, data gathering, GEM (SECS/GEM)EDA/Interface A, and more. These standards are among the key enabling technologies for the Smart Manufacturing and Industry 4.0 global initiatives that are having a major impact on the electronics assembly, semiconductor, SMT and other industries. Manufacturers and their equipment suppliers must be able to connect equipment and other data sources, gather and analyze data in real time, and optimize production through a wide variety of applications. The videos and video series featured in our resource center provide in-depth coverage of the some of these concepts.  Some of our featured videos are below.

Be sure to stop by our Resource Center any time or download the white papers directly from the links in this posting.

Resources

Topics: Industry Standards, SECS/GEM, EDA/Interface A, Doing Business with Cimetrix, Programming Tools, Photovoltaic/PV Standards, Smart Manufacturing/Industry 4.0

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

Resources Round-up: Ebooks

Posted by Kimberly Daich; Director of Marketing on Jun 19, 2019 11:23:00 AM

Resource Center-1The Cimetrix Resource Center is a great tool for anyone who wants to learn more about industry standards including Equipment Connectivity and Control, data gathering, GEM (SECS/GEM)EDA/Interface A, and more. These standards are among the key enabling technologies for the Smart Manufacturing and Industry 4.0 global initiatives that are having a major impact on many industries. Manufacturers and their equipment suppliers must be able to connect equipment and other data sources, gather and analyze data in real time, and optimize production through a wide variety of applications. The free eBooks listed below provide in-depth coverage of the some of these concepts.  They have been written by technical experts who have participated in and led the standards development processes for more than two decades.

Be sure to stop by our Resource Center any time or download the white papers directly from the links in this posting.

Resources

Topics: Industry Standards, SECS/GEM, EDA/Interface A, Doing Business with Cimetrix, Programming Tools, Photovoltaic/PV Standards, Smart Manufacturing/Industry 4.0

Resources Round-up: White Papers

Posted by Kimberly Daich; Director of Marketing on Mar 26, 2019 11:15:00 AM

Resource Center-1The Cimetrix Resource Center is a great tool for anyone who wants to learn more about industry standards including GEM (SECS/GEM), GEM300, EDA/Interface A, and more. These standards are among the key enabling technologies for the Smart Manufacturing and Industry 4.0 global initiatives that are having a major impact on many industries. Manufacturers and their equipment suppliers must be able to connect equipment and other data sources, gather and analyze data in real time, and optimize production through a wide variety of applications. The free white papers listed below provide in-depth coverage of the most broadly used equipment connectivity standards. They have been written by technical experts who have participated in and led the standards development process for more than two decades.

Be sure to stop by our Resource Center any time or download the white papers directly from the links in this posting.

Resources

Topics: Industry Standards, SECS/GEM, EDA/Interface A, Doing Business with Cimetrix, Programming Tools, Photovoltaic/PV Standards, Smart Manufacturing/Industry 4.0

EDA Implementation Insights: What Data Should I Publish?

Posted by Derek Lindsey: Product Manager on Mar 19, 2019 11:30:00 AM

Previous blog posts have discussed the merits of choosing a commercial software platform for implementing the equipment side of EDA (Equipment Data Acquisition) and how you would use that package to differentiate your equipment data collection capabilities from your competitors.

In this post, we discuss how to design the equipment model to contain enough information to make it useful without publishing so much data that it becomes cumbersome for your factory customers to find the data that is most important to them.

Data to Publish

The automation requirements for the most advanced fabs call for the latest versions (Freeze II) of all the standards in the EDA suite, including the EDA Common Metadata (SEMI E164) standard. In addition to providing an excellent foundation for a new equipment model, E164 enables consistent implementation of GEM300, commonality across equipment types, automation of many data collection processes, less work to interpret collected data, and true plug-and-play client applications—all of which contribute to major increases in engineering efficiency. These capabilities benefit both the equipment suppliers and their factory customers alike. Therefore, equipment models should make all E164-compliant data available.

To summarize, those who remember the complexity of implementing SECS-II before GEM came along (pre-1992) will understand this analogy: E164 is to EDA what GEM was to SECS-II.

  • Fab-specified Data

The second blog post made the following statement:

“In effect, the metadata model IS the data collection 'contract' between the equipment supplier and the fab customer."

“This is why the most advanced fabs have been far more explicit in their automation purchase specifications with respect to equipment model content, going so far as to specify the level of detailed information they want to collect about process performance, equipment behavior, internal control parameters, setpoints and real-time response of common mechanisms.”

You only have to read the latest requirements specs for these fabs to get more specifics. Pick the one from your customer base that sets the bar highest and let that be your target.

Data to Avoid in the Model

It is easy to fall into the mindset that if publishing some data through the EDA interface is desirable, the more data we can publish, the better. This is not always the case. In his fascinating book, The Paradox of Choice, Barry Schwartz makes the case that freedom is defined by one’s ability to choose, but more choice doesn’t mean more freedom. In fact, too many choices actually cripple one’s ability to choose. The same can be said of data published in an EDA interface. Making too much data available actually hinders the creation of EDA client applications.information-overload-1-1

We were recently working with a fab to perform a proof-of-concept where we connected an EDA client to a piece of equipment with an EDA interface. We were able to connect to the equipment in a matter of minutes, but finding suitable data to collect for our proof-of-concept took almost an hour because there was so much superfluous data published from the equipment.

Publishing everything including the kitchen sink reduces the ability to create an efficient EDA client application.

Some examples of data to avoid publishing in the model include:

  • Parameters that have no value – If a parameter is available in the model, but the value is not published by the equipment control application, that parameter is just extra noise in the interface. Consider not adding it to the model.
  • Parameters with values that do not change – If a parameter value does not change during the life of the application, it does not make sense to collect that parameter’s data. For example, if an application uses an equipment constant, it may not be necessary to publish that constant through the EDA model.
  • Irrelevant data – If a parameter contains data that is irrelevant to data publication, it should not be added to the model. For example, having parameters in the model that contain the IP address or port number for connection are not very useful in the equipment model. This information is necessary in connecting with an EDA client, but is not relevant for data collection in the model.

The takeaway: Publish data required by E164 and additional fab-specified data, but carefully evaluate other data to be published to make sure it is relevant and useful for data collection.

If you have questions about Equipment Data Acquisition or would like a demo of the functionality described above, please contact Cimetrix to schedule a discussion

You can download an introduction to EDA White Paper any time.

Read the White Paper

Topics: Industry Standards, EDA/Interface A, Smart Manufacturing/Industry 4.0

EDA Implementation Insights: Competitive Differentiation

Posted by Alan Weber: Vice President, New Product Innovations on Feb 13, 2019 11:50:00 AM

people arrowIn the first blog of this series, Clare Liu of Cimetrix China made the compelling case for choosing a commercial software platform for implementing the equipment side of the EDA (Equipment Data Acquisition) standards interface rather than developing the entire solution in-house. 

Whenever this “make vs. buy” decision is discussed, however, the following question inevitably arises: “If we choose a standard product for this, how can we differentiate the capabilities of our equipment and its data collection capability from our competitors?” It’s a great question which deserves a well-reasoned answer.

Platform Choice and System Architecture

Most advanced fabs use EDA to feed their on-line FDC (Fault Detection and Classification) applications, which are now considered “mission-critical.” This means if the FDC application is down for any reason, the equipment is considered down as well. It is therefore important to choose a computing platform for the EDA interface that is highly reliable and has enough processing “headroom” to support the high bandwidth requirements of these demanding, on-line production applications. Moreover, this platform should not be shared by other equipment communications, control, or support functions, since these may adversely impact the processing power available for the EDA interface. 

Surprisingly, this approach is not universally adopted, and has been a source of problems for some suppliers, so it is an area of potential differentiation. 

Adherence to Latest Standards 

gold-thumbs-upThe automation requirements for the most advanced fabs call for the latest versions (Freeze II) of all the standards in the EDA suite, including the EDA Common Metadata (E164) standard. Dealing with older versions of the standard in the factory systems creates unnecessary work and complexity for the fab’s automation staff, so it is best to implement the latest versions from the outset. The Cimetrix CIMPortal Plus product makes this a straightforward process using the model development and configuration tools in its SDK (Software Development Kit), so there is absolutely no cost penalty for providing the latest generation of standards in your interface.

It takes time and effort for equipment suppliers with older versions of the standards to upgrade their existing implementations, so this, too, is an opportunity for differentiation.

Equipment Metadata Model Content

This is probably the area with the largest potential for competitive differentiation, because it dictates what a factory customer will ultimately be able to do with the interface. If an equipment component, parameter, event, or exception condition is not represented in the equipment model as implemented in the E120 (Common Equipment Model) and E125 (Equipment Self-Description), and E164 (EDA Common Metadata) standards, the data related to that element cannot be collected. In effect, the metadata model IS the data collection “contract” between the equipment supplier and the fab customer.

eye-with-maglassThis is why the most advanced fabs have been far more explicit in their automation purchase specifications with respect to equipment model content, going so far as to specify the level of detailed information they want to collect about process performance, equipment behavior, internal control parameters, setpoints and real-time response of common mechanisms like material handling, vacuum system performance, power generation, consumables usage, and the like. This level of visibility into equipment operation is becoming increasingly important to achieve the required yield and productivity KPIs (Key Performance Indicators) for fab at all technology nodes.

The argument about “who owns this level of information about equipment behavior” notwithstanding, providing the detailed information the fabs want in a structure that makes it easy to find and access is a true source of differentiation.

Self-Monitoring Capability

If you really want to set your equipment apart from your competitors, consider going well beyond simply providing access to the level of information needed to monitor equipment and process behavior and include “built-in” Data Collection Plans (DCPs) that save your customers the effort of figuring out what data should be collected and analyzed to accomplish this. Your product and reliability engineering teams probably already know what the most prevalent failure mechanisms are and how to catch them before they cause a problem… why not provide this knowledge in a form that makes it easy to deploy?

A few visionary suppliers are starting to talk about “self-diagnosing” and “self-healing" equipment… but it will be a small and exclusive group for a while – join them.

Readiness for Factory Acceptance

checklistBefore the fab’s automation team can fully integrate a new piece of equipment, it must follow a rigorous acceptance process that includes a comprehensive set of interface tests for standards compliance, performance, and reliability. This process is vital because solid data collection capability is fundamental for rapid process qualification and yield ramp that shorten a new factory’s “time to money.” If you know what acceptance tests and related software tools the fab will use (which is now explicit in the latest EDA purchase specifications), you can purchase the same software tools, perform and document the results of these same tests before shipping the equipment. 

This will undoubtedly speed up the acceptance process, and your customers will thank you for the effort you took to put yourself in their shoes. Incidentally, this usually means the final invoice for the equipment will be paid sooner, which is always a good thing.Red_smart_factory-TW

In Conclusion

In this posting, we have only scratched the surface regarding the sources of competitive differentiation. As you can see, choosing a commercial platform enables this far more readily than the in-house alternative, because it allows your development team to focus on the topics above rather than worrying about compliance to the standards. If you’d like to know more, please give us a call or click below to talk schedule a meeting. 

Contact Us

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

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 Applications and Benefits for Smart Manufacturing Episode 6: Trace Data Analysis

Posted by Alan Weber: Vice President, New Product Innovations on Oct 25, 2018 11:20:00 AM

In this final article of the “EDA Application and Benefits” series we discuss an application that is one of the most basic and intuitive, but also provides the foundation for the many of the emerging capabilities in the machine learning and artificial intelligence (AI) domain—trace data analysis. Moreover, of all the applications we’ve introduced over the past 6 months, trace data analysis is the one that most directly leverages the capabilities of the SEMI Equipment Data Acquisition (EDA) standards

Problem Statement

When we ask fab process engineers and their supporting automation teams why they are now requiring the latest SEMI EDA/Interface A standards on their new equipment, the answer we hear most often is “To better understand equipment and process behavior.” And when asked why this cannot be achieved using the SECS/GEM interfaces, the answers are equally consistent: “The detailed information we need is either unavailable or cannot be collected at the frequencies we need to accurately see and characterize the behaviors we are interested in. And even if this were possible, we don’t have the operational freedom to change our data collection systems as quickly as our needs change, so we must have a more flexible approach.” 

What these engineers are looking for as a starting point is a way to easily specify a list of potentially related equipment parameters and collect their values at a rate that is fast enough to see how they are changing in relationship to one another. Human beings are wonderful at pattern recognition, and simply being able to juxtapose a set of signals on a “strip chart” display (see first figure below) can yield important insights into the underlying process. Of course, this capability is most useful when the engineer can precisely specify the timeframe of interest for this visual analysis. This is sometimes called data “framing” and can be accomplished by using equipment events to bracket the period of interest (see second figure below).

eda_apps_benefits6.1-1-1

EDA_apps_Benefits6.2-1

While humans may be good at pattern recognition, they quickly get overwhelmed when the number of parameters to view grows and/or the timespan to consider expands… which is where trace data analysis software enters the picture.

Solution Components

In addition to very flexible time-series data visualization tools, trace data analysis software packages must be able to “slice and dice” subsets of large data sets to compare every imaginable combination of equipment instance, process chamber, product, layer, recipe, fixture, consumable batch, shift, operator, … (you get the picture) to look for correlations between important factory metrics and the behavior of the equipment involved. Moreover, they must be able to identify and flag “abnormal” (which must be flexibly defined) situations for further analysis, since these may hold clues about incipient failures that traditional multivariate FDC (fault detection and classification) applications may not catch.

In fact, there is an emerging school of thought for fault detection that states “most of the time, the equipment is making good wafers, so unless there’s something very different about the tool behavior between the most recent lots and the current lot (as determined through trace data analysis), it’s very likely that the current lot is good as well.” This simplified approach has also been called “model-less FDC” because it mostly compares trace data signals rather than passing tool parameters into highly context-specific multivariate statistics-based models.

Of course, any trace data analysis application is only as good as the data that feeds it… which is where the EDA standards and the related equipment purchase specifications come into the picture.

EDA (Equipment Data Acquisition) Standards Leverage

Previous postings such as Episode 4 on Fault Detection and Classification and Precision Data Framing during Process Execution – Tricks of the Trade have highlighted the capabilities of the Freeze II EDA standards related to Data Collection Plans (DCPs) and the Trace Requests, Event Requests, and Exception Requests that comprise them. We have also highlighted the need for broad stakeholder involvement when creating the EDA section of an equipment purchase specification and described the process we’ve crafted to accomplish this.

However, to fully support a world-class trace data analysis application, it’s important to understand what to ask of the equipment suppliers. To this end, we’ve excerpted some key sample requirements from a typical purchase specification below.

  • Equipment Model Content (SEMI E120, E125, E164)

    • The hierarchical depth of the metadata model should include at least the “field replaceable unit” (FRU) level, and one of two levels below this for complex sub-systems.
    • The metadata model must contain command and status information for all equipment components that affect material movement. This includes not only material transfer elements such as robot arms, but also devices that may inhibit/enable material movement, such as gate valves, interlocks, etc.
    • The metadata model must include control parameters for all significant operating mechanisms and subsystems in the equipment. The control parameters may include but are not limited to: process variable setpoints and status values; control variable status values; PID tuning parameters, control limits, and calibration constants.
    • The metadata model must include whatever additional usage counters, timers, and other parameters that may be useful in time-based, usage-based, and condition-based maintenance scheduling algorithms.
    • The metadata model must contain parameters the describe consumption rates and levels for key process resources such as electricity, process gases, and other consumables. These are used in some of the FDC models to detect potentially abnormal process conditions.
    • Suppliers 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.
    • Etc.

  • Data Collection Capability (SEMI E134)

    • Equipment must include 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.
    • 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.

  • Performance Requirements

    • Performance requirements will 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.
    • Example: The EDA interface must be capable of reporting at least 5000 parameters at a sampling interval of 0.1 seconds (10Hz) with a Group Size of 1, for a total data collection capacity (bandwidth) of 50,000 parameters per second. It must also support simultaneous data collection from at least 5 clients while still achieving a total bandwidth of 50,000 parameters per second; Group Sizes greater than 1 may be used to achieve this level of performance.
    • Some equipment types may have more stringent performance requirements than others, depending on the criticality of timely and high-density data for the consuming applications.

apc2017_5KPIs Affected

Trace data analysis will undoubtedly take its place among the other “mission-critical” applications in today’s fabs because of the increasing process complexity and the need to maintain the traditional “time to yield” production ramp. This is especially true for the industry pioneers now using the latest EUV scanners, as there will be much to learn about this new technology in the coming years.

Let Us Hear from You!

EDA_apps_benefits_6

If you want to understand how the latest EDA standards and trace data analysis can support your future manufacturing objectives, or how to make this a reality in your Smart Manufacturing roadmap, please schedule a meeting!

Schedule a Meeting

Topics: EDA/Interface A, Smart Manufacturing/Industry 4.0, EDA in Smart Manufacturing Series

EDA Applications and Benefits for Smart Manufacturing Episode 5: Fleet Matching and Management

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

In the fourth article of this series, Fault Detection and Classification, we highlighted the application that has been the principal driver for the adoption of EDA (Equipment Data Acquisition) standards across the industry thus far, namely Fault Detection and Classification (FDC). In this posting, we’ll discuss another important application that effectively leverages the capabilities of the EDA standard: Fleet Matching and Management. 

Problem Statement

The problem that fleet matching (which also covers chamber and tool matching) addresses is maintaining large sets of similar equipment types at the same operating point in order to maximize lot scheduling flexibility by the real-time scheduling and dispatching systems that run modern wafer fabs. This avoids the situation where specific equipment instances are dedicated to (and therefore reserved for) critical layers of certain products, processes or recipes, which can reduce the effective capacity of the affected process area. This situation can arise because tools naturally “drift” apart over time, especially when manual adjustments are made to the equipment, or other factors (maintenance actions, consumable material changes, key sub-system replacements, etc.) affect the equipment’s operating envelope. eda5.1

Of course, part of the problem is choosing which equipment should be the one matched to—the so-called “golden tool.” And depending on the breadth of the fab’s product/process mix, there may be multiple targets to choose from, further complicating the task. 

Solution Components

The solutions for many of today’s complex manufacturing problems require lots of high-quality equipment data, and fleet matching is no exception. Like FDC, choosing the golden tool(s) also requires some information about which recent lots exhibited the highest yields, which must be correlated with the equipment used throughout the process. Unlike FDC, however, it is NOT necessary to build hundreds (if not thousands) of multivariate fault models specific to the various context combinations, because the underlying principle of chamber/tool/fleet matching is that “if all the fundamental operating mechanisms of a set of equipment are working consistently, then the behavior of the equipment in aggregate should likewise be consistent.” This means that the matching process can be largely recipe independent, which is a major simplification over other statistically based applications.

This is not as simple as it may first appear, because a complex equipment may have scores of these mechanisms (pressure/flow control, multi-zone temperature control, motion control, power/phase generation, etc.) for which thousands of parameters must be collected to characterize and monitor equipment behavior accurately. Static and dynamic equipment configuration information also comes into play, since similar (but not identical) tools may be interchangeable for certain processes. 

This is where the EDA standards enter the picture.

EDA Standards Leverage

Although not explicitly required by the SEMI EDA standards, the intent and expectation of its designers was to support a far richer (read “more detailed”) equipment metadata model than is practical in most SECS/GEM implementations. With respect to fleet matching and management, this would include not just the high-level status variables for key equipment mechanisms (listed above), but also the setpoints, internal control parameters, and detailed status of their underlying components. 

The metadata model must also include the complete set of equipment constants that govern tool operation, since these “constants” are sometimes changed “on the fly” by an operator within some allowable range. While this may be an acceptable production practice, it nevertheless affects the tool’s operating window, and must be accounted for in the matching algorithms.EDA5.2-667640-edited 

Moreover, the communications interface should support sampling and data collection of these detailed parameters at a frequency sufficient to observe the complete real-time operation of these mechanisms so the process and equipment engineers can more deeply understand how the equipment actually works. Support for this level of equipment visibility was also a stated requirement for the EDA standards.

Once this data is collected, a variety of analysis tools can look for similarities and anomalies in the equipment parameters to identify the factors that matter most in achieving consistent process performance. At this writing, a number of companies are looking at this domain as an ideal application for Artificial Intelligence and Machine Learning technology. Stay tuned for exciting developments in this area. 

KPIs Affected

The KPI (Key Performance Indicators) most impacted by the fleet matching and management application is overall factory cycle time, since the scheduling systems can make optimal use of all available equipment to move material through the fab.Accelerate gains, reduce costs

Equipment uptime is also improved, because the continuous equipment mechanism “fingerprinting” process which is fundamental to fleet matching also catches potential problems before they cause the entire tool to fail. Finally, when more equipment instances are available for running experimental lots (rather than having dedicated tools for this), the yield ramp for new processes can be shortened as well.

If keeping a large set of supposedly identical equipment operating consistently is a challenge you currently face, give us a call. We can help you understand the approaches for building a standards-based Smart Manufacturing data collection infrastructure to support the machine learning algorithms that are increasingly prevalent in this latest generation of manufacturing applications… including fleet matching and management. Smart Factory

To Learn more about the EDA/Interface A Standard for automation requirements, download the EDA/Interface A white paper today.

Download

 

Topics: EDA/Interface A, Smart Manufacturing/Industry 4.0, EDA in Smart Manufacturing Series

한국에서의 EDA 연착륙을 위한 3 차 세미나 개최; Hosting the third seminar for soft landing of EDA in Korea

Posted by Hwal Song on Aug 15, 2018 11:04:00 AM

Hwal Song of Cimetrix Korea talks about EDA/Interface A and Korean Equipment Makers. Read now in Korean or below in English.

Koreablog-2

Cimetrix Korea와 국내 파트너사인 링크제니시스는 EDA에 대한 세미나를 7 월 19 일에 개최했습니다. 삼성, SK 하이닉스를 포함한 글로벌 반도체 제조사들이 공정 장비의 추가 통신 프로토콜로 EDA를 채택함에 따라 EDA가 더욱 각광을 받게 되면서 개최한 세번째 세미나였습니다. 지금까지 200 명이 넘는 엔지니어가 이들 세미나에 참석하였으면, 이에 따라 한국에서의 EDA 연착륙이 진행 중입니다. 이들 세미나의 목적은 EDA의 이해부족로 오는 시행착오를 줄이고 첫번째 EDA구현을 가장 빠른 시간에 구현하기 위함입니다.

반도체 제조사의 EDA 채택은 차세대 분석 기능을 구현하고 딥러닝 및 머신 러닝 등과 같은 빅 데이터 및 AI의 새로운 기술을 수용하기 위한 주요 노력의 일환입니다. 대부분의 공정장비들이Freeze II 및 E164가 포함된 EDA 기능의 장착이 요구되거나 요구될 예정이여서,  Cimetrix Korea는EDA의 일반적인 개념뿐만 아니라 심도 있는 구현 방법론에 대한 이해를 위한 도움이 각 장비 제조사의 소프트웨어 엔지니어들에게 필요함을 인지하였습니다. 이러한 요구를 충족시키기 위해 다음과 같이 내용으로 세미나가 준비되었습니다.

Koreablog-1
  • EDA관련 업계 동향 및 채택 현황 -  E164의 중요성 포함
  • 반도체 제조사가 EDA 사양을 어떤 과정을 거쳐 준비하는가?
  • 장비제조사의 소프트웨어팀 관점에서 EDA 구현의 모범 사례와 방법론
  • 여러 장비제조사의 소프트웨어팀을 코칭한 컨설팅 및 지원 팀의 관점에서 EDA 구현 모범 사례와 방법론
  • 구현중이거나 구현된 EDA 적합성 테스트의 모범 사례

활발한 토론과 Q&A를 통해서 한국의 장비 제조사들의 EDA에 대한 높은 관심을 엿볼 수있는 행사였습니다.

궁금한 점이 있으시면 언제든 연락주시기 바랍니다.

Hwal Song


Cimetrix Korea and our local partner, Linkgenesis, held a seminar about SEMI EDA on July 19, the third one since 2016. EDA continues to gain momentum as global chip makers like Samsung and SK hynix have adopted EDA as an additional communication protocol for process tools. So far, over 200 engineers have attended these seminars, promoting the soft landing of EDA in Korea. Their goals include minimizing trial and error due to the lack of understanding on EDA, and speeding up the first deployment of EDA.

Koreablog-2

Adoption of EDA by chip makers is one of the major efforts for factories to implement their next-generation analytic capabilities and also embrace new technologies from big data and AI such as deep learning and machine learning. As most process tools are or will be required to ship with EDA capability, with Freeze II and E164, Cimetrix Korea recognized that Korean software engineers employed at equipment makers were looking for help in understanding in-depth deployment methodologies as well as understanding the general concept of EDA. In order to accommodate these needs, our seminars have been put together with following agenda:

  • General industry trends of EDA and its adoption – the importance of E164
  • Koreablog-1How an EDA specification is put together by a chip maker
  • Best practices & methodologies for implementation of EDA – from the perspective of a software team at a tool maker
  • Best practices & methodologies for implementation of EDA – from the perspective of a consulting and support team who have coached many software teams in tool makers
  • Testing best practices during and after EDA implementation

Active discussions and Q&A showed the high level of interest in EDA among Korean equipment makers. 

Please feel free to contact us whenever you have any questions.

Hwal Song

Topics: EDA/Interface A, Doing Business with Cimetrix, Smart Manufacturing/Industry 4.0