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


News You Can Use in SEMI Command and Control Standards, Part 2

Posted by Brian Rubow and Alan Weber

May 31, 2016 1:00:00 PM

 172SEMI.pngIn a previous blog we mentioned that two new SEMI standards, E172 and E173, demonstrated that the GEM standard was alive and well and even gaining new momentum by evolving to adopt new technology. The earlier blog focused on E172 with its SEDD files that use an XML schema to describe what is in a GEM interface. Today’s blog is about the E173 Specification for XML SECS-II Message Notation: a new way to log and document GEM/SECS messages, again using an XML schema.

A few years ago Cimetrix was involved in a project prototyping Wait Time Waste concepts and implementation alternatives. This work required Cimetrix engineers to review and extract data from many different SECS-II message log files from a variety of sources, and in the process, exposed a serious weakness in the industry. Because there was no standardized notation for logging SECS-II messages, everyone represented them differently, using different nuances and variations in their notation based loosely on SML (SECS Message Language, which is mentioned in the GEM standard). Additionally, SML itself was designed primarily for human readability, and certainly not for consumption by software programs; moreover, you can’t analyze a long message log without software to do the parsing for you. As a consequence, writing software to review the log files and to extract meaningful data from the log files was far more difficult than it should have been – SML and SML-like notations are simply not suitable for today’s needs. But now there is a suitable, industry-standard alternative. 

At Cimetrix we have utilized various notations for logging SECS-II messages for many years. In order for any notation to be useful it must meet certain criteria. First of all, it has to be easy for software to write (serialize). Secondly, it also needs to be easy for software to read (deserialize). And finally, it should be easy for humans to read and understand.

The original technique we used many years ago was based on the scripting language Tcl (pronounced “tickle”), which uses curly braces as structural delimiters. When programming within the Tcl language, this works very well. In other programming languages, however, it is easy to serialize, but not so easy to deserialize. Another technique Cimetrix had used for a few years was based on XML, which is well supported by all modern programming languages and an integral part of most internet activity. It is very easy to serialize and deserialize. And when formatted with carriage returns and indentation, it is quite easy to read for most humans (at least the ones who are software programmers or web page gurus).

Here is a subjective comparison between the notation alternatives using a scale of 1 to 5 where 5 is excellent and 1 is very poor or difficult.


At Cimetrix we decided to leverage our experience with XML, SECS/GEM standards and the SEMI Standards organization and related communities to develop a notation that everyone in the industry could benefit from. The result was this new standard: SMN. It is comprised of two parts: an XML schema defined specifically for GEM/SECS messaging; and a specification document describing how to use it (although many details of the specification are embedded as annotations within the XML schema file itself). It looks like this:


The schema is found on the SEMI website:

SMN brings the representation of SECS messages into the Internet era by defining an open, standard, XML-based notation for these messages. So what can you do with this? Here are some ideas:

  • Document individual SECS/GEM messages (the SEMI E172 SEDD file uses SMN for this). You can also document entire message scenarios.

  • Log individual SECS/GEM messages or scenarios in XML format. These can include only the messages, or might also include protocol messages (like the HSMS separate message).

  • Share message logs with others. If their software supports SMN, they can immediately make use of it. This should increase collaboration in the manufacturing community, particularly between equipment suppliers and their customers.

  • Embellish log files with comments and meaningful metadata, like data item names, variable names, collection event names, etc.

  • Analyze and extract information from log files offline for projects like Wait Time Waste, where you don’t need to process a live data stream.

  • Log messages in a raw binary format to save disk space, yet encapsulated in XML for convenience.

  • Many of the numerous XML tools in the software development community can now be used by SECS/GEM software developers. This opens up a world of opportunities.

  • Products like our CIMConnect and CIM300 can make use of SMN to make it easier to implement GEM and GEM300 interfaces on the equipment by using the SECSData element from SMN to pass data from the equipment supplier’s software into our product.

It is exciting to see the GEM standard evolve and embrace new technologies like XML to make integrating manufacturing equipment into the factories easier and easier.

For more information about these latest standards, and how you can incorporate them into your interface implementation, please contact us.

Topics: SEMI Standards, SECS/GEM, SEMI

CIMConnect: Making GEM Implementation Simple for Any Industry Using Automated Manufacturing Equipment

Posted by Brian Rubow: Director of Client Training and Support

May 26, 2016 1:00:00 PM


Interest in SEMI standard E30, known as the GEM standard has grown in recent years. That interest has increased in various manufacturing industries has matured in which factories are seeking to increase automation and carefully monitor equipment activity in order to increase production and product quality. Initially, the GEM standard targeted just the semiconductor industry, but then expanded to include any industry that used manufacturing equipment. In fact, a number of years ago the name of the GEM Standard changed from the “Generic Model for Communication and Control of Semiconductor Equipment” to “Generic Model for Communication and Control of Manufacturing Equipment.” Adoption by other industries is possible because the GEM standard defines generic features to control and monitor any manufacturing equipment. The GEM standard technology is not limited to semiconductor manufacturing. Over time, other industries have taken notice, especially as they try to develop increased control over their equipment.

CIMConnect™ is the best software product on the market for implementing the GEM standard. Of course CIMConnect supports all of the required GEM features as well as additional capabilities. This even includes excellent support of the Spooling feature, which saves messages that are otherwise dropped during a loss of communication. Early implementations of the GEM standard by others gave the GEM standard’s Spooling feature a bad reputation. This reputation is undeserved when Spooling is implemented by a robust product like CIMConnect. In CIMConnect, not only does Spooling work; it works well. It has been proven by customers that CIMConnect’s Spooling implementation does not lose any messages—even while under high-stress conditions. This means that when using CIMConnect, the Spooling feature can be used to effectively preserve critical data from the equipment.

Another feature that makes CIMConnect the best GEM software product is the CIMConnect Control Panel. In the new CIMConnect release, this application was completely rewritten, redesigned in .NET,  giving it a modern look and feel while adding lots of new convenient functionality. With other GEM products, the GEM interface is essentially a black box. With CIMConnect, however, the Control Panel application gives full visibility into the GEM interface. And you can run it at any time during GEM interface development and also during production. This means that you can see what reports and traces are defined, the link between reports and events, the status of all state machines, the state of each alarm, the enable status of every event, the history of occurring collection events, the history of alarm state changes and the current values of all data variables, and status variables and equipment constants. You can also view and capture the SECS-II message logging at any time for scenario diagnostics. Additionally, the CIMConnect Control Panel provides features to simulate the occurrence of collection events, collection event data, alarms, and variable data; thereby making it a built-in simulator included requiring no additional effort. And when you are ready to update your GEM documentation appendix with the list of defined collection events, alarms, status variables, data variables, and equipment constants, use the documentation builder feature.

CIMConnect has also already adopted use of new SEMI standard E173 Specification for XML SECS-II Message Notation (SMN). CIMConnect allows software applications to use SMN notation both when providing variable values to CIMConnect, as well as when getting variable values from CIMConnect. This means that you can pass data around in XML, retaining the data type and data structure information; bringing the convenience of XML into the SECS/GEM technology. You can log the GEM communication messages using SMN format making log messages much more useful, and they are able to be easily deserialized by any software applications that has XML libraries.

For additional detailed information about CIMConnect or to request a product demonstration, please contact us.

Topics: SECS/GEM, SEMI, CIMConnect

News You Can Use in SEMI Command and Control Standards

Posted by Brian Rubow and Alan Weber

May 24, 2016 1:00:00 PM


As the SEMI GEM standard celebrates its 25th birthday, you may have thought its evolution had just about run its course — but you’d be wrong. Last year, the Information and Control Committee of SEMI Standards passed two new standards that enhance the usability of the entire SECS/GEM suite of standards for equipment suppliers and semiconductor manufacturers alike: E172 SEDD and E173 SMN.

Let us talk about the first of these, the E172 Specification for the SECS Equipment Data Dictionary (SEDD) and postpone E173 Specification for XML SECS-II Message Notation (SMN) discussion for another blog. SEDD standardizes the approach for documenting an equipment’s GEM interface in a way that is both human- and computer-readable. All factories in every industry that use GEM require their equipment suppliers to provide GEM interface documentation in some electronic form for each type of equipment. This is because the GEM interface on every equipment type is unique, supporting unique features and publishing a unique set of data. Of course, the GEM standard itself requires documentation and what has to be in the documentation but does not specify how this is to be accomplished. Until now there has been no common approach or format. This has always left the equipment suppliers to come up with their own format. At best this might be in a multiple-tabbed Excel spreadsheet or a PDF file; and at worst a text document that might or might not have been accurate or even complete. And every equipment supplier completes the documentation in a different structure and style so that no two GEM documents look the same. In summary, everyone is trying to complete this GEM and factory requirement by providing documentation, but in the end what factories are receiving has to be consumed and digested differently based on the equipment supplier, and sometimes even based on the specific equipment type from the same equipment supplier. It is a lot of work for the factory just to understand exactly what is in each GEM interface.

SEDD was created to solve this problem by defining a standard XML schema for documenting a GEM interface. Equipment suppliers create an XML file that complies with the SEDD XML schema to document the GEM interface and then deliver this XML file (called an SEDD file) to the factory.

Why XML? Because XML is the perfect technology for organizing data into a uniform structure that is well supported by modern programming languages. This means that equipment suppliers can use a software program to generate the SEDD file. It also means that factories can write software to read and view the SEDD file. Moreover, they can create intelligent host applications that automatically configure themselves and adapt to a specific GEM interface.

So what’s in an SEDD file? Below is a visual representation of the SEDD file schema, identifying the major elements of the SEDD file.

172Picture1.pngSo essentially the SEDD file includes a list of the data available for collection by a host, some general information about the equipment (in the header), and the format of the data variables, status variables and equipment constants. As an example of what details are included, here are the details for collection events.

As an example, for a collection event, the SEDD file includes a list of all collection events available, and the ID, name, description, related SEMI standard, and the list of related data variables and other variables for that collection event. This is everything you need to use a collection event.


So far this is a summary of what is available today in a SEDD file. Cimetrix is leading the GEM300 task to extend the SEDD file to include additional information. This work is in SEMI ballot 5872 that proposes to extend the SEDD file to also include:

  • A list of supported SECS-II messages and the acceptable format for each message (using E172 SMN)

  • A list of support remote commands and available parameters for each remote command

  • A list compliance tables for supported SEMI standards

  • The list of predefined event reports

This is all work that was postponed from the original SEDD standard development. Hopefully ballot 5872 will pass and make SEDD files even more useful. With this additional information an SEDD file would empower GEM host software to configure itself to fully communicate with a GEM interface and make all of the features in the GEM interface available.

This is one example of how GEM technology just keeps getting better. It is not surprising that GEM is getting used in more and more industries.

For more information about this latest standard, and how you can incorporate it into your interface implementation, please contact us.

Topics: SEMI Standards, SECS/GEM, SEMI

XP is Dead, It’s Time to Move On

Posted by Derek Lindsey: Product Manager

May 19, 2016 1:00:00 PM


When my daughter turned one year old, she got a very soft blanket as a birthday present. She loved that blanket and would take it everywhere with her. She couldn’t/wouldn’t go to sleep at night without it. When she got old enough to talk, she called it her special blanket or “spesh.” Needless to say, after many years of toting that blanket around, it started to wear out – in fact, it started getting downright nasty. She adamantly refused to part with it even though it was just a rag with little redeeming value.

A couple of years ago, Microsoft made the following announcement: “After 12 years, support for Windows XP ended April 8, 2014. There will be no more security updates or technical support for the Windows XP operating system. It is very important that customers and partners migrate to a modern operating system.”

In the immortal words of Dr. Leonard “Bones” McCoy from Star Trek, “It’s dead Jim!”


Many arguments have been proffered on both sides as to why users should stay with or move away from XP. Windows XP was first introduced in 2001. That makes the operating system 15 years old — an eternity in computer years. The main argument I see for upgrading from XP is that it is impossible to keep up with advances to the .NET framework and remain on the old operating system. By staying with XP, you are missing out on new features and technologies. These features include taking advantage of better hardware integration for improved system performance and being able to use 64-bit applications and memory space.

Since Microsoft no longer supports XP and no longer provides security updates for the OS, staying with XP is a security risk. Any security holes that have been discovered since Microsoft withdrew support have been ruthlessly targeted.

To come full circle, my daughter finally did give up the little rag that she had left of the blanket. I don’t remember what ultimately made her give it up. She is now 18 and a few months ago, we came across that small piece of her special little blanket that we had stored away. The rag brought back good memories, but we were both glad it had been retired. Isn’t it time to do the same with XP?

Topics: Microsoft, Software

Testing for and Finding Memory Leaks

Posted by Bill Grey: Distinguished Software Engineer

May 12, 2016 1:00:00 PM

An issue that inevitably crops up in long-running, complex software systems is memory use. In the worst cases it manifests as a crash after several hours or days of running when the software has consumed all available memory.

Another inevitability is that these out-of-memory crashes are found very late in the development cycle, just prior to a delivery date. Or, worse, they are found after delivery. Given the fact that the crashes take hours or days to occur because the testing cycles are very long, they cause a lot of stress for the development team and frequently delay delivery.

The rest of this blog contains a proposed process to find these issues sooner in the development process and some tools to help the developer investigate memory use.

Early and continuous testing of the software system is the key to avoiding delivery of memory leaks. As soon as possible a dedicated system should be set up for endurance testing. The software should be built in debug mode, but it is not necessary to run it in a debugger. Preferably, for equipment control software, this would use a simulator for the hardware. This should be done as soon as there is enough of the software developed to be able to perform any significant functionality in a repetitive manner. This test can evolve as more of the software is developed with functionality being added to the test as it becomes available. For semiconductor equipment control software, a logical test would be to perform wafer cycling as this would exercise a good majority of the software. 


This endurance test should be kept running during development, right up to delivery. The computer running the endurance test should be configured to collect Windows crash dumps for the software application(s) and have Windows Performance Monitor configured to monitor Private Bytes for the application(s), The test should be checked daily to see how the Private Bytes memory use has changed.  If the application has crashed, then the crash dump .DMP file can be collected and analyzed. Visual Studio can be used to open the .DMP file for analysis on the developer’s computer. 

The endurance test should be maintained and updated as the software is updated. However, since run time is important for this test, consider only updating it on a weekly basis unless the update is to fix an issue that caused the test to crash.

If the endurance test shows that the Private Bytes for the application increases steadily with no signs of levelling off, then the application probably has a memory leak.

For C++ programs, Microsoft’s UMDH memory dump utility is very useful for tracking down what allocations are occurring in the application, The concept is to take two or more memory snapshots and analyze the differences to see what new objects have been created. Remember to have the software built in debug mode so full debug information is available in the memory dumps.

For .NET programs, newer versions of Visual Studio have built in memory profiling,

There are third party memory analyzers on the market that some have found to be useful. Most of these will report numerous false positives that the developer will have to wade through to get to the real leaks. Most third party memory analyzers for .NET seem to frequently report false positives for COM objects. 

The tools just provide the developer a location to review the code for leaks. It still requires diligence and expertise on the part of the developer to analyze the information and find the cause of the leak. Seldom do the tools create a treasure map with "X" marking the spot of the leak.

Having an endurance test running allows the developer to understand the memory profile of the software and watch how the profile changes as the software changes. Early detection is critical given the length of the testing cycle.

Topics: Microsoft, Software

Learning from Others

Posted by David Francis: Director of Product Management

May 10, 2016 2:37:12 PM


Almost everyone I know that has built a house has given me a list of things they would “do differently next time,” but a lot of those same people would also say that they would never build again. So does that mean everything they learned through the process is lost? Is it possible to get it right the first time? Maybe not, but there are a lot of things you can do to learn from the experience of others. For example, you can buy house plans that have been used before and are designed to leverage standard components. Rather than designing and building everything from scratch, you can use pre-built sub systems like fabricated floor joists and manufactured roof trusses. Using proven components saves a lot of time and worry about whether or not they will work properly and as expected. This allows you to focus on the customizations that will make the home meet your unique needs.

Implementing an equipment control application is a lot like building a house. You can design and build a complete control system from the bottom up—building all the components necessary to handle communication with the hardware, display information to the operators, manage user access, log relevant event and data information—but it doesn’t add value to the core competency of your equipment. The best option is to leverage proven design that has been built through multiple prior applications and leverages those lessons learned along the way.

Cimetrix's CIMControlFramework provides all the standard components necessary to build an equipment control application. With working samples for both atmospheric and vacuum equipment, it can easily be customized and extended as needed to meet specific control needs.

There is an old saying that goes, “If you don’t have time to do it right, when will you have time to do it over?”

If you would like to learn more about CIMControlFramework and how it can help you on your next project, give us a call or feel free to contact us here.

Topics: CIMControlFramework, Equipment Automation Framework

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


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.  


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


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


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



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.


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.


  Download the Presentation


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

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


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


GEM 300

Interface A/EDA