Industry News, Trends and Technology, and Standards Updates

A question that job seekers should always ask of potential employers is, “Why should I work in your industry?” It is an important question when you consider that only 60 of the original Fortune 500 companies from 1955 are still in existence in 2017. Changing customer tastes, mergers, technology and many other reasons are responsible for this, but it does give us at least one key takeaway: the company I start my career with probably won’t be the one I end it with. As a result, it is important to ensure the industry you go into will be able to stand the test of time.

When one enters an industry, be it as an engineer or an accountant, you begin to build specialized knowledge of that industry within your field. This provides you with a competitive advantage in the job market of that industry. Companies are willing to pay more for an engineer with experience in their industry than one they will have to train. If you suddenly find the industry you are in obsolete, all of your specialized knowledge becomes likewise obsolete. For example, someone who was an engineer in the cathode ray tube industry may not find themselves as competitive for the top jobs anymore. 

The electronics manufacturing industry is an exciting place to be, and there is no immediate replacement or end in sight. When you join a company like Cimetrix you have the opportunity to develop and support the software that runs manufacturing equipment in factories worldwide. Those factories create computer memory and processor chips, RF and microwave transmitters, sensors and actuators of all shapes and sizes, power devices and amplifiers, display drivers, and many more items that go into the electronics we use every day. 

You are also part of an industry that meets the demands of many different and diverse end users, providing some shelter from the ups and downs of any particular market. When cell phones became less popular in favor of smart phones, the demand for new products didn’t go away—it simply changed the type of products were called for. 

One specific benefit of life at Cimetrix is that we are an integral part of the the electronics manufacturing and related industriesy. We often refer to one another as family, we take care of each other, celebrate our successes and create an environment where people enjoy coming to work. We have very competitive benefits and compensation, so we can pay you what you are worth. Many employees even have the option of working from home up to three days a week, saving them wear and tear on their vehicles (and their nerves from driving in traffic!).

If you are ready to join an exciting, dynamic, growing and fun industry, please check out our open positions.

In 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 

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 (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.

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 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

Before 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.

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. 

IPC Apex Expo is one of the largest gathering of professionals from the printed circuit board and electronics manufacturing industry (EMS). Attendees and exhibitors come from around the world to participate in the expo, the technical conferences and Standards Development meetings. This is the third year in a row that Cimetrix has exhibited at the IPC Apex conference.Cimetrix features the latest in Smart Factory and Equipment Connectivity technology. For the show this year, we chose to upgrade our booth space, allowing us to have more meeting room within the booth as well as several prominent demo stations in each corner. We also featured a popular Virtual Reality station in our booth. We brought a great team of ten to the show this year to staff the booth, give demo’s and greet the many attendees who stopped by throughout the 3 day expo.

We chose to participate in the popular Passport to Prizes game for the second year in a row. This sponsorship is a great tool to get the Cimetrix name out in the industry. It also brings in many attendees to our booth for some great conversations about our products and services.

We also had to opportunity for the Cimetrix Vice-President and General Manager of Smart Factory Business, Ranjan Chatterjee, to be interviewed by SCOOP TV both one-on-one and as part of a larger panel discussion. You can view Ranjan's one-on-one interview in the Cimetrix Resource Center.

To learn more about our products or services, you can schedule a meeting any time. 

Yufeng Huang of Cimetrix China, talks about Equipment Control in the factory. Read now in Chinese or below in English.

在和半导体设备制造公司的接触中我们遇到这么一个尴尬的问题，很多懂得设备控制的优秀软件工程师对于GEM，GEM300和EDA标准不是很有经验。这些公司往往是在设备在实验室研发成功，准备产业化送入客户工厂时发现设备没有实现或只有部分实现GEM/GEM300标准，尤其是当客户工厂要求EDA（Interface A）通信接口的时候，这些设备制造商的软件工程师往往一脸茫然，不知道如何在短时间内开发出完全遵循GEM/GEM300/EDA标准的软件。

对于大多数设备公司而言，限制于有限的人力、财力资源，公司很难聘请到足够多富有经验的工厂自动化软件工程师开发自己的GEM/GEM300，甚至EDA软件模块。另外一个棘手的问题是我们发现很多软件工程师不是特别有意愿加入到半导体行业，而是选择比较热门的互联网、游戏，手机App等软件行业。纵观半导体工厂自动化软件市场，虽然已有多家公司提供GEM/GEM300/EDA的软件开发包（SDK），但软件工程师仍旧需要掌握一定的工厂自动化基础知识才能着手编写软件集成代码。工厂自动化涉及大量SEMI标准，譬如GEM标准大概有450页文档，包括E4，E5，E30，E37，E37.1，E172，E173，GEM300标准大概有280页文档，包括E39，E40，E87，E90，E94，E116，E157，E148，而更为复杂的EDA标准大概480有页文档，包括E120，E125，E128，E132，E134，E138，E164，对于大多数非专业的工厂自动化软件工程师而言，工厂自动化软件的集成工作是一件极其繁琐而艰难的任务。

Cimetrix Control Framework^TM (CCF) 是基于微软.Net技术的设备自动化控制软件框架，该软件不仅为设备制造厂商提供了监督控制和生产控制框架代码，而且完全实现了GEM/GEM300/EDA标准。借助CCF软件平台，软件工程师无需深刻掌握工厂自动化的所有SEMI标准，就能轻松变身为工厂自动化开发专家。CCF软件框架内的工厂自动化模块基于Cimetrix公司的CIMConnect，CIM300，CIMPortal Plus三个独立的软件开发套件（SDK）实现，分别对于实现GEM，GEM300，和EDA标准。全球任意一家300mm的芯片制造工厂都有安装了CIM300软件的设备运行，在支持EDA数据采集的工厂都有安装了CIMPortal Plus软件的设备运行。CCF软件框架将所有工厂自动化的开发工作交给Cimetrix公司来完成，设备软件工程师可以把更多的时间花费在如何设计自己的设备控制软件上。

在CCF框架下，CIMConnect/CIM300/CIMPortal Plus的底层API函数都被很好作了封装，软件工程师只需通过CCF框架提供的函数或接口就能轻松实现和工厂主机程序的所有GEM/GEM300标准。实现EDA标准的一个重要任务是创建一个支持分层次结构的设备模型，以及按照标准生成XML数据，此外生成的模型还需满足E164标准。在CCF软件初始化运行时会动态生成设备模型，软件工程师几乎不需要书写EDA代码，设备即可很好的遵循EDA标准。

采用CCF软件框架降低设备控制程序和工厂自动化程序的开发难度和开发周期，但并不意味着我们的客户一定得推翻自己已有的软件平台或已经测试过的稳定代码。CCF是一个提供源代码的完全开放的自动化控制程序框架，你可以将CCF理解成一个已经拼好的乐高玩具，用户既可以将自己的代码模块集成到CCF中，也可以挑选部分CCF功能模块并将其转移到用户自己的框架中。我们用户将CCF中工厂自动化模块（包括GEM/GEM300/EDA）搬迁到自己的程序框架中，在保证完全遵循工厂自动化诸多SEMI标准的同时，对用户已有程序的影响非常小。

得益于CCF框架的完全开放性，像玩乐高积木一样，软件工程师可以轻松享受自由裁剪自己想要的控制系统框架带来的乐趣，这是其他任何一家提供设备控制软件框架程序的公司都很难做到的一件事情。

在未来几年，越来越多的工厂往智能生产制造的方向发展，由此对数据的需要越来越高，EDA标准越来越成为工厂主流的数据采集方法，CCF无疑成为了设备制造商更快更好实现各种工厂自动化标准的最佳武器。 

---

We encountered an interesting issue when working with semiconductor equipment manufacturing companies. Many excellent software engineers who know equipment control are not very experienced with the GEM, GEM300, and EDA standards. Sometimes after equipment is successfully developed in the laboratory and before the equipment is shipped to the factory, we discover that the equipment did not implement or only partially implemented the required GEM/GEM300/EDA standard. This is especially prevalent when the factory requires the EDA (Interface A) communication interface. Equipment software engineers sometimes do not know how to develop software that fully complies with GEM/GEM300/EDA standards in a short period of time.

For most equipment companies with limited human and financial resources, it is difficult for the company to have the resources to develop their own GEM/GEM300/EDA software. Another issue is that we have found many of the more experienced software engineers are more interested in high-profile  internet, gaming, mobile phone apps and other software industries rather than the lower profile semiconductor industry.  Although many companies in the semiconductor factory automation software market have provided GEM/GEM300/EDA software development kits (SDKs), software engineers still need to master certain basic knowledge of factory automation to start writing software integration code. Factory automation involves a large number of SEMI standards. For example, the GEM standard has about 450 pages of documents, including E4, E5, E30, E37, E37.1, E172, E173. GEM300 standards have about 280 pages of documents, including E39, E40, E87, E90, E94, E116, E157, E148. The more complex EDA standard has about 480 pages, including E120, E125, E128, E132, E134, E138, E164. For less experienced factory automation software engineers, the integration of automation software can be an extremely tedious and difficult task.

Cimetrix CIMControlFramework^TM (CCF) is an equipment automation control software framework based on Microsoft .Net technology. This software not only provides equipment manufacturers with supervisory control and equipment control framework code, but also fully implements the GEM, GEM300 and EDA standards. With the help of the CCF software platform, software engineers can easily turn into factory automation development experts without having to master all the factory automation SEMI standards. The factory automation components within the framework of the CCF software are based on CIMConnect, CIM300, and CIMPortal Plus, three independent software development kits (SDKs) from Cimetrix for the implementation of the GEM, GEM300, and EDA standards, respectively. All 300mm chip manufacturing factories in the world have equipment installed which uses CIM300 software. Any factory requiring EDA data collection has equipment installed that uses CIMPortal Plus software. With the CCF software framework, Cimetrix has already done the work of integrating all factory automation into the framework. The equipment software engineer can spend more time on how to develop their own equipment control software.

Under the CCF framework, the underlying API functions of CIMConnect/CIM300/CIMPortal Plus are well encapsulated. Software engineers can easily implement all the GEM/GEM300/EDA standards of the factory host program through the functions or interfaces provided by the CCF framework. An important task in implementing the EDA standard is to create an equipment model that supports hierarchical structures and generate XML data in accordance with standards. In addition, the generated model must also meet the SEMI E164 standard. The equipment model is dynamically generated when the CCF software is initialized. The software engineer needs to do very little to have an equipment control application that is fully compliant with the EDA standard.

The use of the CCF software framework to reduce the difficulty and development cycle of equipment control programs and factory automation programs does not mean that our clients must replace their existing software platforms or stable code that has been tested. CCF is a fully open automation control program framework that provides source code. You can think of CCF as a LEGO toy that has been put together. Users can either integrate their own code modules into CCF or select some of the CCF functional modules and transfer them to their own framework. Our clients can reuse the factory automation modules (including GEM/GEM300/EDA) in CCF in their own program frameworks. While ensuring that all SEMI standards for factory automation are fully complied with. The impact on the user's existing programs is minimal.

Thanks to the complete openness of the CCF framework, like LEGO bricks, software engineers can easily enjoy the freedom of tailoring the control system framework that they want. It is hard for any company that provides an equipment control software framework program to implement such a rich library of functions. 

In the next few years, more and more factories will move in the direction of smart manufacturing. As a result, the demand for data is getting higher and higher. EDA standards are increasingly becoming the factory's mainstream data collection method. CCF will undoubtedly become the best weapon for equipment manufacturers to quickly and completely implement the various factory automation standards.

As part of the CIMControlFramework (CCF) product for creating equipment control applications, Cimetrix developed a logging package. Our logging package has two parts – collecting the log messages and analysis of the messages.

The logging package allows you to assign a source and a type for each log message. The source specifies where the log message originated. The type is a category that can be used to route the log 

messages to specific output locations called log sinks. We have found the most useful log sink to be a text-based log file. The logging package can be configured for the types of messages to log. It can also be configured for how long to keep log files and how many to keep. This helps keep hard drives from getting too full.

Adding a SECS/GEM interface to an equipiment is the first step in automation. Without the proper toolset, this can seem like an overwhelming endeavor. The CIMConnect™ toolkit provides developers and integrators with the ability to quickly create a SECS/GEM interface and the power to perfect it.

Purpose
Recently I was introduced to the Cimetrix CIMConnect tookit. I had the opportunity to attend a hands-on client training event. Though my knowledge of SECS/GEM was minimal, within three days, I learned the basics of implementing a SECS/GEM interface using CIMConnect and want to share some highlights of that very positive experience.

CIMConnect
CIMConnect provides a robust software development kit that helps developers implement and manage a SECS/GEM interface from their equipment control application. CIMConnect is always current with the latest version of required SEMI standards which simiplifies the process of producing a GEM-compliant interface. When CIMConnect is installed, it comes with multiple tools that make development and testing straightforward and efficient.

CIMConnect Sample projects
CIMConnect samples provide a functioning example of a SECS/GEM application. Sample projects are available in C#, VB.NET, and C++. I will be referring to the C# sample since that is what I used during training.

This sample provides a “known-good” environment that provides a way to accelerate development by taking care of the essentials. I was able to focus on debugging the scope of what I was working on in my application, rather than questioning the SECS/GEM connectivity aspects.

C# Sample Features

• Processing Simulation: The sample provides a loop that simulates equipment operation. This includes triggering events and updating variable values. 
• EMService Initialization: When the Sample is compiled and run, CIMConnect is initialized and GEM communication is started.
• GEM Operator Controls: GEM communication status is displayed in real time using GEM state machines. Communication can be controlled from the sample’s user interface.
• Multi-threading Examples: Data is processed in separate threads. This is a good practice and allows the user interface to remain responsive while data is effectively processed asynchronously. 
• Delayed GEM Communication Initialization: This demonstrates the concept of waiting for the equipment to be ready during initialization. 
• Trigger Events: Events are triggered from the process simulation loop. As events are triggered, related variables are updated.
• Get and Set Variable Values: This sample provides multiple examples of programmatically getting and setting variable values of varying data types.
• Set and Clear Alarms: An example alarm can be set and cleared by toggling a checkbox in the user interface. 
• Terminal Services: Terminal services provide an example of effective logging by displaying real-time messages to the equipment user interface.
• Remote Commands: The sample allows the user to start and stop the processing simulation by sending a SECS-II message from the host.

Training process
Training is very interactive; the instructor demonstrates a new topic, and then allows the trainees time to try it out. When presented with a new feature to try out, I found it beneficial to initially create a button or checkbox to ensure the new feature worked. Next, I embedded the feature into the application. Breaking each process into these two steps removes ambiguity and avoids unnecessary debugging.

The pace was set by the client. The instructor was available to provide assistance as needed. Though the training follows a curriculum, each session is custom tailored to the needs of the client who requested the training. 

My Application
I had created a C# application prior to training. My application read in an XML recipe and simulated wafer processing. Having a working application to modify during training was very beneficial, since it simulated a real-world practical implementation.

Adding the SECS/GEM interface
The first step was to initialize CIMConnect. This step was simplified by extracting the Initialization functions from the sample project. Once I could observe that CIMConnect was initialized, I was able to move on to adding the SECS/GEM functionality.

API Calls
My application sends API calls to, and receives call backs from CIMConnect. The API calls were somewhat difficult to understand initially due to the customization each call allows.

Wrapper functions
The sample project provides several useful wrapper functions that implement API calls. The overhead of API calls is handled inside the wrapper. The benefit of using wrapper functions is that the developer can focus on whether the result matches his/her expectations rather than whether the API call is incorrect.

After my success using wrapper functions to call APIs, I started to modify and make my own wrapper functions. Eventually I became comfortable calling the APIs directly.

Equipment Configuration
CIMConnect lets you statically define events, alarms, variables, and other attributes in a configuration file. In my file, I created multiple variables that related to my application. Later I learned that my application could dynamically define items instead. Also, my application could programmatically override configured attributes. I think these features would benefit companies that produce multiple equipment types with slight variances.

Adding Events and Alarms
The first event that I created was to let the host know when a FOUP had landed on the load port. I used the SendCollectionEventWithData() wrapper function to trigger the event and increment a variable I had previously defined in the configuration file. This variable provided me with a count of FOUPs that had landed on the input port.

Using the AlarmSET() and AlarmClear() functions, I created 3 alarms. Since I didn’t have hardware such as an EMO button, I used check boxes to toggle each alarm’s behavior.

My application with a SECS/GEM interface. 

Developing Using the CIMConnect Control Panel
The CIMConnect Control Panel is a graphical user interface utility that provides a way to observe the inner workings of CIMConnect.

During development, I used the control panel frequently. I could watch the alarms status change as I toggled each checkbox in my application. Event history and alarm history provided real-time updates. I could change variable values and trigger events from the control panel and verify results on the host without needing to constantly modify my application.

I watched the GEM communication status change on the control panel as I used my application’s GEM control. I could also change the status on the control panel and watch it change in my application.

CIMConnect Control panel 1.15.0

Host Testing with GEM Host Messenger
CIMConnect comes with GEM Host Messenger, a host application that allows the user to send and receive SECS-II messages to/from the equipment.

Using GEM Host Messenger, I could easily connect with my application. GEM Host Messenger displays and decodes messages into an easy-to-read format.

I could send S2F21 messages “START” and “STOP” to control processing on my application. It was very satisfying to see my once-standalone application being controlled remotely.

Gem Host Messenger 1.0.0

Help Documentation, Tools, and Support
CIMConnect provides an in-depth help file and developer’s guide. I found myself referencing these frequently to get details on different functionality available in the extensive CIMConnect libraries.

Conclusion
CIMConnect allowed me to rapidly develop a SECS/GEM interface and implement it into an already existing program. With CIMConnect training developers unfamiliar with SECS/GEM can learn the basics in as little as 3 working days. Although this was a simple example, CIMConnect has the power and functionality to facilitate projects on any scale.

Find out more
To find out more about CIMConnect and to request a technical product overview or product demo, visit the resources page now.

I have fond memories as a kid spending Saturdays working on the family cars with my dad. We would dive in to taking things apart and putting them back together again. Whatever the problem was we could figure it out and fix it. With cars from the 1960s and 1970s, there wasn’t too much risk with this approach to car repair. Today, I still like to do my own car repairs when I can. But cars nowadays are far more complicated and compact. I have learned that I can’t just jump in and wing it with any hope of getting it done right or in a timely manner. My experience has taught me to rely on the experience of others, learn from their lessons and save myself from late nights asking, “what have I gotten myself into?”

Cimetrix CIM300^TM tool kit out of the box has already implemented a lot of the GEM 300 work for you. Notice I said “a lot” and not “all” of the work for you. To complete your GEM 300 application, your software will have to integrate with CIM300. The GEM 300 standards can be quite complex and some of the scenarios have intricate details. CIM300 provides a rich set of APIs and callbacks to help you implement a compliant GEM 300 solution. The key to success is knowing how to use the APIs and callbacks for the different GEM 300 scenarios.

The SEMI E87 Carrier Id Status state model, pictured below, is just one of many state models defined in the GEM 300 standards.

Figure 1 CARRIER ID STATUS STATE MODEL

There are several transitions in this state model and intricate conditions that determine which transition should be triggered. CIM300 supports this state model, but it requires interaction with your application to know which transition to make in the state model. In my experience, most people handle the happy path scenarios correctly, whether they're “winging it” or had formal training. However, I have rarely seen people handle the error scenarios correctly, without training on GEM 300 and CIM300. While understandable, error scenarios are often hard to follow and the implementation differences are subtle. The risk of doing it wrong in the software will execute the wrong transition in the state model, which in turn sends the incorrect event to the GEM host. The wrong event could really mess things up for the host. In both the happy path and error scenarios, the CIM300 API to call is the same:

CMSLib::CCxE87CMS::CarrierAtPort

However, how you specify the parameters to the call, it is different for each scenario. The differences in how you call the API will trigger different transitions in the state model. Our documentation for this one API call alone is longer than this entire blog post. That is how important it is to get it right. In addition to our product documentation, Cimetrix also provides CIM300 training and sample applications illustrating how to use our products.

I strongly recommend taking advantage of our CIM300 training. Training is the best first step to integrating CIM300 with your tool application. Training is typically a week long and provides an overview of the GEM 300 standards as well as hands-on experience using CIM300. The goal for Cimetrix in training is that by the end of the week-long training, clients have completed an implementation of a GEM 300 happy path scenario. That is, you receive hands-on experience using CIM300 to implement carrier verification (SEMI E87), creating and running a process job (SEMI E40) and control job (SEMI E94), tracking substrates (SEMI E90), and tracking equipment performance (SEMI E116).

Make sure you also leverage the sample applications that accompany CIM300. The sample applications provided with CIM300 give a jumpstart on integrating CIM300 with your own application. You can use the sample application as a reference for how to use our APIs and callbacks, copy/paste portions of the code into your own code, or use our application as a starting point for your own software. If you’re like me, you like having working source code you can refer to for concrete examples of how to do things and to see how things should work together.

If you dive right in and start implementing CIM300 without training or mentoring from an expert, you may find yourself spending a lot of late nights asking yourself, “what have I gotten myself into?” A little training goes a long way in simplifying the implementation!

Find out more about CIM300 or request a Technical Product Overview and/or Product Demo today!

In a world of automated equipment, having tools to automate the testing of an equipment’s implementation of the SEMI EDA (Equipment Data Acquisition) standards (also known as Interface A) is invaluable. Cimetrix is proud to announce an integrated solution that supports the broadest range of use cases in EDA/Interface A testing - the Cimetrix EDATester™. EDATester is a tool that will help organize, streamline, and automate the testing process while also providing other analytical capabilities. 

Cimetrix knows that testing an equipment interface is not simply a one-time event; rather, tests should be performed in the OEM’s facilities throughout the development process and before final shipment, upon delivery to the customer’s factory, and even after the equipment has been placed into full production. Cimetrix EDATester is designed to do exactly that.

What do we really mean by “testing?” What are we testing? Since the scope is very broad, let's frame the answer in a few distinct categories.

Compliance Testing

Does the equipment’s EDA interface behave correctly based on the SEMI E120, E125, E132, and E134 standards and all the services defined therein? To answer this question, we make use of the ISMI EDA Evaluation Method. This document contains a set of functional evaluation procedures that “tests” the equipment’s implementation of the standards. These procedures check for things like ACL privileges and roles, establishing and terminating communications sessions, managing (or preventing the management of) Data Collection Plans (DCPs), and even looking for the proper notification of metadata revisions. If everything works as expected in these procedures, that equipment would be deemed “compliant.”

EDATester uses ISMI’s functional evaluation procedures as guidelines, and implements tests that are automated for all client-side actions. A process that might have taken multiple days to execute manually can be done in minutes, even when some interaction with the equipment itself is required; the fully automated tests that require no user interaction with the equipment can be run in seconds.

Performance Testing

Everything might look great on the client side with the ability to define a DCP, activate it, and start receiving data; but how many DCPs will the equipment actually support? How fast can I sample the parameters I want to collect in my Trace Requests without overloading the equipment’s EDA interface? Even if I could do this manually, how would I begin to answer this question?

EDATester automates multiple iterations of performance testing using different variations of DCPs while analyzing the timestamps of the E134NewData messages to determine the integrity of the actual sampling rate. Having such tests helps you determine whether the equipment can handle a new DCP in response to a process engineering request, or if the equipment supports the full range of performance requirements agreed to in the purchasing specifications. To this end, you can specify testing configurations for things such as:

• Number of simultaneously active DCPs 
• Trace Request Sampling Interval
• Number of parameters per Trace Request
• Group Size for message buffering
• Timing tolerance for expected vs. reported Data Collection Report (DCR) timestamps

Conformance Testing

The testing tool in practical use across the industry for measuring an equipment’s conformance to the SEMI E164 EDA Common Metadata standards is called the Metadata Conformance Analyzer (MCA). It uses a set of .xml files describing the metadata model as input, analyzes the model according to the requirements of E164, and provides feedback.

EDATester currently generates the .xml input model files required by the MCA, and may eventually incorporate the model conformance testing functions as well.

Summary

Having the correctly sized wrench when you need to apply the proper torque to a bolt is helpful and sometimes necessary—at least you can get the job done. But when you have hundreds of bolts to insert and tighten precisely, wouldn’t you rather have an adjustable ratchet? Or an air ratchet?

Whether it’s to test and characterize the EDA interface on a new equipment type,  verify that a software update to a production piece of equipment has been installed correctly, or debug an interface performance issue that has somehow arisen in production, the Cimetrix EDATester is the right tool to have in your arsenal to quickly, effectively, and thoroughly “test” an equipment’s EDA interface capabilities. Don’t waste another day with manual processes that leave you guessing. Get in touch with us today to find out more about the EDATester product. 

Generally, when I do a DIY (do-it-yourself) project around the house, I spend the majority of the time searching for my tools. The other day I was helping a friend with a project. He had a well-organized tool box and it seemed that the perfect tool was always at his fingertips. I was amazed at how fast the project went and how easy it was when the right tools were handy.

In April of 2016, we published a blog called OEM EDA Implementation Best Practices that outlined ten things to consider when designing an equipment-side EDA / Interface A solution to fit your needs. This blog post analyzes a few of those recommendations and looks at how using the Cimetrix EDA products CIMPortal Plus, ECCE Plus and EDATester (a well-stocked and organized tool box) makes it very easy to follow those recommendations.

The basic steps in creating a useful EDA implementation are:

1. Determine which data will be published
2. Build an equipment model
3. Deploy the model
4. Publish the data from the equipment control application
5. Set up a data collection application
6. Test the interface

The blog post mentioned above states, “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.” Before building your model, you need to determine what data the equipment will make available for collection. CIMPortal Plus has the concept of a Data Collection Interface Module (DCIM) that publishes this data to the EDA server. The engineer building the model will map the data from the DCIM into the equipment model.

Once the mapping of the data is complete, the engineer will need to put this data in a format understood by the server. CIMPortal Plus provides a utility called Equipment Model Developer (EMDeveloper – pictured below) that makes it easy to create the hierarchy of your equipment (SEMI E120) and embed the data from the DCIM into that model (SEMI E125). If you use the tools and best practices provided in EMDeveloper, your equipment model will conform to the SEMI E164 (EDA Common Metadata) standard as well. This can be very useful when writing data collection applications so conformance to E164 is being required by more and more fabs. The E164 standard was developed to encourage companies using Interface A connections to provide a more common representation of equipment metadata based upon the SEMI E125 Specification for Equipment Self-Description. This makes data collection more uniform across these pieces of equipment.

Once the model is created and validated, it is deployed to the CIMPortal Plus server. The server is the component that manages and tracks all data collection plans, reports, tasks, access control and timing. 

With the DCIM information embedded in the model (described above), it is easy for the equipment control application to push the data to be published to the EDA server for collection. This is done by using a simple API available on the DCIM interface.

In addition to CIMPortal Plus server capabilities, Cimetrix has other products available to help with client-side data collection. ECCE Plus is an industry approved method for manually testing EDA implementations. For users who need to create client-side data collection applications, Cimetrix also provides EDAConnect - a powerful library that handles all the connection details and allows developers to concentrate on the specific data collection and analysis tasks.

Fabs receive a wide variety of equipment with EDA implementations from numerous vendors. They want to use a single verification application to make sure that all EDA implementations are compliant to the EDA standards. That’s where EDATester comes in. EDATester is a new product that allows users to quickly and accurately verify EDA standards compliance by automating the test procedures ISMI EDA Evaluation Method that were defined specifically for this purpose. If you use Cimetrix products to implement your EDA interface, you are guaranteed to be compliant with the SEMI EDA standards. But whether you use Cimetrix products to implement your EDA interface or not, you (and your fab customer) want to rest assured that your implementation is fully compliant. Moreover, you’ll want to know that you’ve met the fab’s performance criteria for your equipment interface. To support this use case, the EDATester also allows users to quickly profile the performance of EDA data collection on a piece of equipment so that fabs and those using the data will know the boundaries within which they can successfully collect equipment data.

With the well-stocked EDA tool box provided by Cimetrix, following the EDA best practices in creating an efficient, standards-compliant EDA interface becomes a snap.

One of the habits outlined in Stephen R. Covey's book, The 7 Habits of Highly Effective People, is to "Begin with the End in Mind." He goes on to explain that beginning with the end in mind means to "begin each day, task, or project with a clear vision of your desired direction and destination, and then continue by flexing your proactive muscles to make things happen.”

Beginning an equipment control project with a clear vision of your desired destination makes it much more likely that you will have a successful project. A blog post titled CIMControlFramework Work Breakdown dated March 15, 2016 outlined the tasks necessary to create a first-class equipment control application using CIMControlFramework (CCF). Since that initial blog post, Cimetrix has explored each of the tasks labeled in the work breakdown structure in greater depth in their own blog posts as follows:

• Integrate devices – Create Device Drivers Using CCF
• Material movement through the tool – Create a Scheduler Using CCF
• Implement the process module – Implementing Your Process Module Using CCF
• Create an operator interface (OI) – Create Operator Interface Screens Using CCF
• Simulation – Testing Your CCF Application without Waiting for Hardware
• Recipes – Designing Recipes in CCF
• I/O – Using CCF IO Helper Functionality
• Data collection and storage – Storing Data in a CCF Application
• Factory Automation – CCF Provides Fully Implemented GEM300 and EDA Interfaces
• Diagnostics and Testing – This information was provided previously in a two-part blog regarding the benefits of logging. Read Part 1 (Logging - enabling passionate support) and Part 2 (CIMControlFramework Logging Benefits).
• Errors and recovery – CCF provides an Alarms package for signaling of and recovery from error conditions.

Looking back from the successful completion of a CCF equipment control application makes it clear that the work breakdown vision from the beginning helped gain that success.

You can also reference the following blog posts related to CimControlFramework:

CIMControlFramework Dynamic Model Creation

Learning from Others

Build vs. Buy

WCF and CIMControlFramework

To learn more about CCF, visit the CIMControlFramework page on our website!