Semiconductor Industry News, Trends, and Technology, and SEMI Standards Updates

Semiconductor

CCF Provides Fully Implemented GEM300 and EDA Interfaces

Posted by Bill Grey: Distinguished Software Engineer

Feb 15, 2017 1:00:00 PM

What does this mean and why should I care?

The SEMI standards for 300mm Semiconductor Manufacturing Equipment can be an overwhelming burden of information to understand, let alone implement.

The GEM standards comprise over 450 pages of documentation: E4, E5, E30, E37, E37.1, E172, E173.

The 300mm standards add another 280 pages: E39, E40, E87, E90, E94, E116, E157, E148.

And the EDA standards pile on an additional 480 pages: E120, E125, E128, E132, E134, E138, E164.

That’s over 1200 pages of standards documents filled with requirements and implementation information. 

On top of that GEM and EDA collect data differently from the equipment.  See a post we did on data collection for more information on those differences.

Implementing the requirements defined in those standards without an SDK would be a very brave undertaking.  Even with SDKs for the standards, it would be a fair amount of work, when all you really want to do is get your equipment automated.

In addition, it is very important that those standards be implemented correctly in order for your equipment to be smoothly integrated and accepted into each fab.  Different fabs use the standards slightly differently or have additional requirements.   This requires experience.

GEM300 and EDA standards implementation is a very large burden.

semi standards difficult burden

So what does this mean?

One of the large tasks for the EDA standards is defining a hierarchical model of the equipment and what data it can produce in XML per the schemas defined in the standards.   Creating the initial model and keeping it up to date as the equipment evolves is a tedious task.  In addition, that model must be conformant to the E164 standard (which has over 10 pages of requirements on its own).   See our blog post on conformance testing. CCF does this for you, producing an E164 compliant EDA model in the background based on your CCF programming. See our blog post on CCF dynamic model creation further details.  CCF also builds the GEM interface model for you at the same time.

Further, CCF is completely GEM compliant and 300mm compliant, using the Cimetrix CIMConnect and CIM300 products which have been successfully deployed in every 300mm fab around the world on many different equipment types.

Twelve hundred pages of standards, compliantly implemented, at no additional effort.  That is what this means.

Turn that donkey into a goat and use CCF.

 

 

Topics: SECS/GEM, EDA, CIMControlFramework, GEM Interface

EDA Testing – How is this accomplished today??

Posted by Alan Weber: Vice President, New Product Innovations

Feb 7, 2017 1:30:00 PM

Over the past several months, we have posted a number of blogs dealing with the testing of SEMI’s Equipment Data Acquisition (EDA / aka Interface A) standards suite. The first of these posts connected the importance of this topic to the increased adoption of the EDA standards across the industry, and broke the overall problem domain into its three major components. 

Subsequent postings provided additional detail in each of these areas:EDA_Icon.png

To bring this series to a close, this post addresses the “as-is” state of EDA testing as it is practiced today by the advanced semiconductor manufacturers who are requiring EDA interfaces on new equipment purchases and the suppliers who provide that equipment. 

For compliance testing, the three options in general use include: 

  1. ECCE Plus product- this software tool was originally developed under contract with the International Sematech Manufacturing Initiative (ISMI) to validate the fidelity, usability, and interoperability of early versions of the standard; it can used to manually execute a set of procedures documented in the “ISMI Equipment Data Acquisition (EDA) Evaluation Method for the July 2010 Standards Freeze Level: Version 1.0” document (see title page below) to exercise most of the capabilities called for in the standard; note that this is the only commercially available solution among the three.

ISMI.png

  1. Company-specific test suites – one major chip manufacturer (and early adopter of EDA) maintains its own partially-automated set of compliance tests, and provides this system to its equipment suppliers as a pre-shipment test vehicle. This set of tests is then used in the fab as part of the tool acceptance process; however, this system also includes a number of company-specific automation scenarios, which are not available for outside use. This highlights the need to support custom extensions in an industry-validated tester if it is to be commercially viable.

  2. In-house custom test clients – this is a variation of #2 that some of the major OEMs have chosen as their economies of scale dictate; the problems with this approach are that a) the test clients must be kept current with the EDA standards, which are themselves a moving target, and b) unless thoroughly validated by the eventual customers of the equipment, there is no guarantee that passing these tests will satisfy the final acceptance criteria for a given factory. 

For performance and stability testing, there are no automated solutions currently available. The ISMI EDA Evaluation Method does describe some rudimentary performance evaluation procedures, but these no longer reflect the expectations of the customers with many years of accumulated EDA production experience. Clearly a better solution is needed.

Finally, for metadata model conformance testing, the only available solution is the Metadata Conformance Analyzer (MCA) that was commissioned by Sematech and implemented by NIST (National Institute of Standards and Technology). It has not been updated in almost five years, and exhibits a number of known issues when applied to a SEMI E164-compliant equipment model (E164 = Specification for EDA Common Metadata), so it will be increasingly insufficient as more companies require full Freeze II / E164 specification compliance. 

The good news in all this is that Cimetrix has recognized and anticipated this emerging need, and is actively addressing it on our product roadmap. If you want to know more about EDA testing and/or discuss your specific needs, please contact Cimetrix for a demonstration of this exciting new capability!

Topics: Interface A, EDA, EDAConnect, ECCE, Data

EDA Metadata Conformance Testing

Posted by Derek Lindsey: Product Manager

Nov 15, 2016 11:00:00 AM

In a recent blog posting we introduced the topic of EDA (Equipment Data Acquisition) standards testing and sub-divided the domain into three parts:

  • Compliance testing – does the equipment adhere to the specifications described in the SEMI Standards?

  • Performance and stability testing – does the equipment meet the end users’ performance and availability specifications?

  • Equipment metadata model conformance testing – does the equipment model delivered with the interface represent the tool structure and content anticipated by the end customer?

Today’s post deals with the equipment metadata model conformance testing in greater detail.

The impetus for the metadata conformance requirement is SEMI Standard E164 – Specification for EDA Common Metadata. Although this standard is not part of the original core suite of EDA standards, it is now being required by GLOBALFOUNDRIES and a number of other major semiconductor manufacturers on EDA-enabled equipment.

The purpose of the standard “is to promote commonality among implementations by defining common representations and conventions of equipment metadata based on SEMI E125.” (Section 1.1 of E164)

In other words, conformance to E164 requires a consistent implementation of E125. All state machines required by the GEM300 standards must be implemented and use the same names for required events, parameters, state names and transitions. It requires that all process modules implement the E157 Module Processing state machine using specified names. As a result, E164 ensures a high level of implementation commonality across all equipment types. This commonality enables better automation of data collection processes across the fab, driving major increases in engineering efficiency. In summary, E164 is to EDA what GEM was to SECS-II.

Currently, the only E164 conformance tester is Metadata Conformance Analyzer (MCA) that was commissioned by Sematech and implemented by NIST (National Institute of Standards and Technology). In our discussions with potential users of an EDA test tool, most clients agree that the sooner a replacement can be created for MCA, the happier they will be.

In a previous post, we mentioned that Cimetrix has automated the EDA compliance evaluation procedures. We are also in the process of designing the performance testing components of this tester. The plan is to also create an E164 conformance tester that will replace MCA.

If you want to know more about EDA testing and/or discuss your specific needs or provide input on what you would like to see included for E164 conformance testing, contact Cimetrix for a demonstration of this exciting new capability!

 

Topics: Interface A, EDA

EDA Performance Testing

Posted by Derek Lindsey: Product Manager

Nov 1, 2016 1:00:00 PM

In a recent blog posting we introduced the topic of EDA (Equipment Data Acquisition) standards testing and sub-divided the domain into three parts:

  • Compliance testing – does the equipment adhere to the specifications described in the SEMI Standards?

  • Performance and stability testing – does the equipment meet the end users’ performance and availability specifications?

  • Equipment metadata model conformance testing – does the equipment model delivered with the interface represent the tool structure and content anticipated by the end customer?

    Today’s post deals with the performance and stability testing in greater detail.

In our discussions with EDA users (both OEM implementers and fab end users) about EDA testing, they all acknowledge the need for compliance testing. However, the vast majority have said, “If you can help me automate my performance testing, I would be able to save a huge amount of time.” Most thought they could reduce testing time from several weeks to just a couple of days.

Everyone has different ideas about what should be included in performance testing of their EDA software. Everyone can agree that generally they need to test if the equipment meets the end users’ performance and availability specifications in terms of data sampling intervals, overall data volume transmitted, size and number of DCPs (data collection plans) supported, demands on the computing/network resources, and up-time. They also need to know if the software will support the range of application clients expect in a production environment.

Data Volume

EDA users want to know the sheer volume of data that can be collected.

ISMI has reported in public forums that IC makers expect EDA to achieve data rates of 50+ variables per chamber at rates up to 10 Hz. In EDA specifications, IC makers have requested the ability to gather 1,000 to 2,000 parameters using data collection rates from 5 to 20 Hz, which translates to 40,000 values per second.

These rates are easily achievable with today’s computing platform technology, but users also want to know the upper limit. In other words, at what point does the ability to collect data break down?

Data Quality

EDA users want to know that the data comes in at the specified rates and that the values and timestamps that are received at those rates are accurate.

Resource Usage

EDA users want to know how different data collection rates and volumes will affect the system resources. Will memory usage be too high? How will different collection rates affect CPU usage? Is the network bandwidth sufficient for gathering the required data at the required speeds and still maintain high data quality?

In a previous post, we mentioned that Cimetrix has automated the EDA compliance evaluation procedures. We are also in the process of designing the performance testing components of this tester. The ISMI EDA Evaluation Method discusses some basic performance testing in Appendix B; performing these tests will be included in the feature set of EDA tester now under development. In addition, we are designing ways to help evaluate the data volume, data quality and resource usage of a given equipment.

If you want to know more about EDA testing and/or discuss your specific needs or provide input on what you would like to see included for performance testing, contact Cimetrix for a demonstration of this exciting new capability!

 

Topics: Interface A, EDA

EDA Compliance Testing – Scope and Approach

Posted by Alan Weber: Vice President, New Product Innovations

Oct 19, 2016 11:30:00 AM

In a recent blog posting we introduced the topic of EDA (Equipment Data Acquisition) standards testing and sub-divided the domain into three parts:

  • Compliance testing – does the equipment adhere to the specifications described in the SEMI Standards?

  • Performance and stability testing – does the equipment meet the end users’ performance and availability specifications?

  • Equipment metadata model conformance testing – does the equipment model delivered with the interface represent the tool structure and content anticipated by the end customer?

Today’s post deals with the first of these parts in greater detail.

To begin, we should point out that standards compliance testing is not a new idea – it has been an integral part of the acceptance testing process for automated manufacturing equipment for decades. As each new generation of SEMI’s communications standards (SECS-II, GEM, GEM300, and now EDA / Interface A) reached critical mass, the compliance testing process naturally evolved from an ad hoc, manually driven set of procedures to a more thorough, formal process supported by automated testing software. Moreover, the use of this kind of software and the reliance of leading chip makers on its results has greatly contributed to the efficiency of the overall new fab startup and initial yield ramp process, so its importance to the industry cannot be overstated.

So where does the industry turn for information about how to test for EDA standards compliance?Although the Sematech manufacturing consortium’s R&D program no longer includes SEMI Standards definition, validation, and promotion support, the work that its ISMI subsidiary (International Sematech Manufacturing Initiative) did in the formative years of the EDA standards is still directly applicable. In particular, the “ISMI Equipment Data Acquisition (EDA) Evaluation Method for the July 2010 Standards Freeze Level: Version 1.0” is the globally accepted approach for checking compliance of an equipment’s EDA interface.

 ISMI2.png

This document takes an automation test engineer through the entire set of steps for connecting a tool to a known-compliant test client (in this case, the Cimetrix Equipment Client Connection Emulator, or ECCE Plus product), adding entries to the interface’s Access Control List (ACL), uploading and inspecting the equipment metadata model, managing Data Collection Plans (DCPs), and invoking all the other services defined by the SEMI EDA Standards suite (E120, E125, E132, E134, E164, etc.). Its appendices not only define the required procedures in detail, they also describe the expected results and suggest a format for reporting these to interested stakeholders.

Of course, those familiar with the use of this method and the associated software tools know that it can take 2-3 days to execute this process manually, which is an inefficient way to check compliance for the incoming tool set of an entire fab. Fortunately, there IS a better approach. Cimetrix has automated these evaluation procedures in a way that ensures the target equipment meets the automation software purchasing requirements to the satisfaction of both the equipment supplier and the semiconductor manufacturer, while leaving the door open for factory-specific requirements that represent unique competitive advantage.

Note that ISMI and its member companies also recognized that much of the potential value of the EDA standards would be derived from (and limited by!) the content of the equipment metadata model, so they funded the development of another software tool to check these aspects of a supplier’s implementation. But that is a topic for an upcoming blog – watch for it.

So… if you want to know more about EDA testing and/or discuss your specific needs, contact Cimetrix for a demonstration of this exciting new capability!

Alan Weber
VP, New Product Innovations
Cimetrix Incorporated

Topics: Interface A, EDA

EDA Testing – What Does the Problem Look Like for the Industry?

Posted by Alan Weber: Vice President, New Product Innovations

Oct 4, 2016 11:15:00 AM

Anticipating and promoting the increased adoption of SEMI’s Equipment Data Acquisition (EDA / aka Interface A) standards, we’ve posted a number of blogs over the past 12 months to address questions that potential stakeholders have repeatedly asked across the value chain. These postings have dealt with everything from the factory applications enabled by EDA to the best practices for OEM implementation of these standards to the development of robust equipment purchasing specifications.

Since the adoption process has now clearly reached critical mass, we must seriously address the question “How are we going to test the equipment and systems that incorporate these standards?” in a way that supports the entire industry. It’s an excellent question, and one that has a multi-part answer.

EDA_Icon.png

Given the structure and expected use of the EDA standards, the acceptance testing process for a unit of semiconductor manufacturing equipment will include at least three components, each of which addresses a different aspect of the standards. Note that we’re explaining this from the perspective of the end customer in a semiconductor factory, since this is the most common use case, but most of the same principles apply when testing EDA client infrastructure/application components as well.

  • Compliance testing – does the equipment adhere to the specifications described in the SEMI Standards, and were these specifications interpreted correctly? Will it cleanly connect to the EDA client infrastructure without modification or extensive configuration?

  • Performance and stability testing – does the equipment meet the end users’ performance and availability specifications in terms of data sampling intervals, overall data volume transmitted, size and number of DCPs (data collection plans) supported, demands on the computing/network resources, up-time, etc.? Will it support the range of application clients expected in a production environment?

  • Equipment metadata model conformance testing – does the equipment model delivered with the interface represent the tool structure and content anticipated by the end customer? If the customer has requested that SEMI E164 (EDA Common Metadata) be fully supported, does the metadata model meet these specifications?

Of course, in addition to the requirements dictated by the standards themselves, most advanced semiconductor manufacturers will have a number of factory-specific requirements that must also be supported by the EDA interface. These may include special events and data for particular automation schemes, vectors of process parameters to support fault detection applications or other feature extraction algorithms, synchronization signals for external sensor integration, and the like. To address these requirements efficiently, an EDA test system should be extensible by its users.

You can see how interesting and vital this topic becomes when you consider the range of requirements outlined above. We’ll explore each of these in more detail in the next few postings, so stay tuned!

 

Topics: Interface A, EDA

Realizing Industry 4.0 with SEMI Standards: Right Here and Now

Posted by Alan Weber: Vice President, New Product Innovations

May 6, 2016 1:00:00 PM

IoT1.png

Since the concept was first articulated in 2011 by a German government-supported program promoting deeper integration of manufacturing software and hardware across the production value chain, the term “Industry 4.0” has gained recognition and momentum as the rallying cry for the 4th industrial revolution (see left). Wikipedia  summarizes it like this: “Industry 4.0 facilitates the vision and execution of a ‘Smart Factory.’ Within the modular structured Smart Factories of Industry 4.0, cyber-physical systems monitor physical processes, create a virtual copy of the physical world, and make decentralized decisions. Over the Internet of Things, cyber-physical systems communicate and cooperate with each other and with humans in real-time…”

This definition may lead you to ask “What aspects of Industry 4.0 are truly revolutionary, and what technologies and tools are available today that would enable me to start building “Smart[er] Factories?” In this blog, I offer some potential answers to these questions that put the vision of Industry 4.0 within reach for automation practitioners familiar with the latest generation of SEMI Standards.  

IoT2.png

Semiconductor manufacturers have been collecting and using data from the equipment in their factories for decades. Throughout this period, device sizes and process windows have shrunk continuously according to Moore’s Law, and the SEMI Standards have evolved by necessity to support the insatiable demand for data exhibited by the process analysis and control applications that keep a modern fab running profitably (see left). The newest of these standards, the Equipment Data Acquisition suite (EDA, also known as “Interface A”), provides the power and flexibility to support a wide range of critical manufacturing applications and human users with ever-changing requirements; moreover, these standards can be deployed in a variety of system architectures without disturbing the “command and control” capabilities of existing factory systems.

“What does all this have to do with Industry 4.0?” To understand this, let’s look at the foundation of a “Smart Factory,” the collection of the many thousands of devices that might need to communicate over the so-called “Internet of Things.” 

We already see evidence that the availability of low-cost, low-power, networkable computing hardware will likely result in an explosion of “smart sensors” and other intelligent devices on the factory floor. However, as social scientists have observed over the millennia, groups of smart individuals don’t necessarily exhibit smart behavior in the aggregate, so what additional attributes must these devices possess to be good citizens of a collaborative, Industry 4.0 environment? How will these devices communicate effectively with one another? And what oversight will be required to ensure this communication achieves the ultimate manufacturing objectives?

As a starting point, I propose that each device, or manufacturing “thing,” at a minimum should be discoverable, autonomous, model-based, self-aware, communicative, and well-behaved. Depending on the role the device must play, it might also be self-monitoring, capable of defending itself (secure), and a consumer of data from other devices/systems as well as a provider. So defined, these devices would need a minimum of external monitoring and supervision (read “management overhead”) to perform their basic functions, but would rely on higher-level systems to provide specific objectives, instructions, and constraints (read “configuration, recipes, and limits”) for their operation in a given context and timeframe.

I realize that’s a lot to absorb at once, but now imagine that each of these devices could implement a subset of the services called for in the EDA standards, especially those defined in E120/E125/E164 (equipment modeling and standard metadata modeling), E132 (session management), and E134 (data collection management). Consider the collaboration among independent devices and systems this would enable…and ask yourself, how much closer to the vision of Industry 4.0 can you possibly get?

I hope the ideas above were useful…or at least thought-provoking. We’ll be developing this theme further in the coming months, but I wanted to use this blog as a conversation starter. We’d love to hear your feedback, so give us a call, or feel free to reach out to us.

Topics: SEMI, EDA, IoT

OEM EDA Implementation Best Practices

Posted by Alan Weber: Vice President, New Product Innovations

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

European Advanced Process Control and Manufacturing Conference XVI in Review

Posted by Alan Weber: Vice President, New Product Innovations

Apr 19, 2016 2:01:05 PM

APC1.png

APC2.png

Cimetrix participated in the recent European Advanced Process Control and Manufacturing (apc|m) Conference, along with more than 130 control professionals across the European and global semiconductor manufacturing industry. The conference was held in Reutlingen, Germany, a picturesque city of stone and half-timber buildings just south of Stuttgart.

APC3.png

This conference, now in its 16th year, is one of only a few global events dedicated to the domain of semiconductor process control and directly supporting technologies. The conference’s attendance this year was comparable in numbers and demographics to that of the previous two years, a clear indication that this area continues to hold keen interest for the European high-tech manufacturing community. Another highlight this year was the sponsorship of Bosch, a relative newcomer to the conference but a pillar of the German manufacturing industry. Reutlingen is home to Bosch’s automotive electronics division and its related semiconductor manufacturing facilities, so they were very well represented in the conference and excellent hosts!

Cimetrix was privileged to make two presentations at this year's conference. The first was entitled “Data Fusion at the Source: Standards and Technologies for Seamless Sensor Integration,” authored and delivered by myself. The external sensor integration and related data unification topics have enjoyed increasing interest over the past year, and even though the techniques outlined in the presentation leverage the latest versions of the Equipment Data Acquisition (EDA)/Interface A standards, they apply equally well for the 200mm manufacturing nodes prevalent in European wafer fabs and assembly/test factories. The solution architecture is shown in the slide below, but for the background and rationale behind this approach, feel free to download a copy of the entire presentation from our website by clicking on the link below.

APC4.png

  Download the Presentation

APC5.png

The second presentation, entitled “'Smart Manufacturing' solutions for high-mix manufacturing using Wait-Time-Waste improvement opportunities” was authored by Jan Driessen, a Principal Industrial Engineer with NXP Semiconductor in the Netherlands. It summarized the work of a project team from six companies and as many countries, and funded by the European Union's “integrate” program (cover page is on the left). Because of an unexpected work conflict during the conference, however, Jan was unable to attend, and, based on our companies’ shared interest in the Wait-Time-Waste technology and standards over the past several years, he thought that Cimetrix would be well qualified to give his presentation. I willingly agreed, worked with Jan to make sure I understood the latest material, and made the presentation. It essentially makes a compelling case for using equipment event data in a legacy 200mm fab to improve OEE, operational effectiveness, and factory capacity through a “chain of data operations” paradigm that he explains in some detail. The good news for 300mm fabs is that these same results can even more readily be achieved, because the availability and fidelity of the event data is much higher, especially if the fab has a full GEM300/EDA E164-compliant system infrastructure. For more information, request a copy of this presentation directly from Jan Driessen at jan.p.driessen@nxp.com.

Other themes that were evident at the conference included 1) applications of APC and supporting metrology techniques for structures found in smart sensors, MEMS devices, LEDs, and other semiconductor products outside the traditional processor and memory segments; 2) increasing emphasis on equipment data collection in the back end to support productivity monitoring and control applications; 3) unit process control for a number of equipment types; and 4) an entire session devoted to industrial engineering topics.

As with other similar conferences around the globe, the takeaway for Cimetrix is that “Smart Manufacturing,” Industrie 4.0, the Industrial Internet of Things (IIoT), advanced process control and fault detection applications, “big data” analytics, and a host of other high-tech manufacturing technologies all depend on the ability to get the right data at the right time from the right sources on the factory floor, and then make it available wherever and whenever needed… For more information about how Cimetrix’s product families that directly address this “sweet spot,” please contact us.

Topics: SEMI Standards, Interface A, EDA, Events, Data

CIMControlFramework Dynamic Model Creation

Posted by Derek Lindsey: Product Manager

Apr 14, 2016 1:00:00 PM

turkey-218742_960_720.jpg

Have you ever watched one of those cooking shows where the chef spends a lot of time whipping up the ingredients to some elaborate dish, and, when it comes time to put the dish in the oven to bake, there is already a finished one in there? If only the real world worked that way. Sometimes it would be nice to be able to go to the oven and have a delicious meal already waiting for you.

The Cimetrix CIMControlFramework™ (CCF) product is unique among Cimetrix products in that it not only provides source code, but also combines several other Cimetrix products (CIMConnect, CIM300, and CIMPortal™ Plus) and takes full advantage of all the features provided by each product.

One of the features of CIMPortal Plus that is used in CCF is the concept of an equipment model. The equipment model describes the data that your equipment provides through Interface A. The tool hierarchy is modeled along with all of the parameters, events, and exceptions published by the tool. It used to be that CCF users had to manually create the tool hierarchy in their base equipment model. CCF would then populate the model with the parameters, events, and exceptions. If the tool hierarchy changed, the base model would have to be modified. It made changing the tool configuration much more difficult.

Starting with the CCF 4.0 release, a base equipment model that is common to all equipment was installed. Generally, CCF users will not need to modify the base model. CCF takes advantage of the modeling API provided by CIMPortal Plus to dynamically add hierarchy nodes to the base model depending on the components that are created in CCF. This new feature makes it easy to change the configuration of the CCF tool because the user does not have to make modifications to the base model and redeploy the package to be able to run CCF.

The dynamically created model is also compliant with the SEMI E164 Common Metadata standard. This compliance is possible because of the dynamic nature of model creation. The required elements of E164 are added to the equipment model dynamically during the startup of Tool Supervisor.

Having a dynamically created Interface A model that exactly matches your equipment structure and is guaranteed to be E164-compliant without having to do any extra work is similar to going to the oven and finding a delicious dish already cooked and waiting for you.

Topics: EDA, CIMControlFramework, Product Information, Software

Receive Email Updates

Follow Us

Learn More About the
SEMI Standards

SECS/GEM

GEM 300

Interface A/EDA

PV2 (PVECI)