Industry News, Trends and Technology, and Standards Updates

Cimetrix is proud to announce that Ranjan Chatterjee, Executive Vice President of Smart Factory Solutions at Cimetrix, has been newly elected to the iNEMI Board of Directors. 

iNEMI, The International Electronics Manufacturing Initiative is a not-for-profit, highly efficient R&D consortium of approximately 90 leading electronics manufacturers, suppliers, associations, government agencies and universities.

iNEMI roadmaps the future technology requirements of the global electronics industry, identifies and prioritizes technology and infrastructure gaps, and helps eliminate those gaps through timely, high-impact deployment projects. These projects support their members' businesses by accelerating deployment of new technologies, developing industry infrastructure, stimulating standards development, and disseminating efficient business practices. They also sponsor proactive forums on key industry issues and publish position papers to focus industry direction.

In the official press release from iNEMI, they explain “The iNEMI Board plays an integral role in the governance of our organization,” said Marc Benowitz, CEO. “They provide oversight for our operations, including decisions regarding policy, strategy and direction of the consortium. These recently elected individuals bring a high caliber of leadership, as well as supply chain diversity, to our Board. We welcome the new and returning Directors and look forward to working with them.”

In addition to being elected to the Board of Directors, Mr. Chatterjee has also had the opportunity to Co-Chair the Smart Manufacturing Roadmap with Dan Gamota from Jabil.

Cimetrix is excited to play a role in the ongoing mission of iNEMI.

Read now in Chinese or below in English

矽美科很高兴地宣布和欢迎刘立聪先生加入矽美科并担任中国区总经理。刘先生将领导一支由中国软件技术专家组成的团队，负责本地区市场销售和客户服务，确保我们在中国半导体设备制造和智能制造工厂领域里领先的并不断增长的客户群的成功，为矽美科在中国市场长期成功发展制定战略方向。

刘先生拥有工商管理硕士学位和机电一体化工程学士学位。他在半导体和电子行业拥有超过20年的经验，其中包括中国本土公司和国际公司的经历。他担任过销售管理、客户管理和渠道管理等多方面的职责。他深刻理解半导体行业面临的诸多挑战，他将通过矽美科产品的价值和定位给我们的客户带来贡献，帮助客户发展业务。

矽美科中国，即矽美科 软件（上海）有限公司，成立于2019年，是一家在中国本土注册的企业，目的是更方便地为中国企业提供智能制造软件产品，并提供行业内最强的技术支持。

矽美科从五年前开始服务于中国市场和客户。最初，我们的中国市场策略侧重于与部分选择性的半导体300毫米设备制造商密切合作，通过为他们提供卓越的本地技术支持，确保他们成功使用矽美科产品。现在，这些最初阶段的客户已经向领先的中国半导体300毫米晶圆工厂批量提供设备，为矽美科赢得了高质量产品的声誉和证明。我们相信，现在是扩大本地团队，提高本地支持能力的正确的时机，可以让我们有能力更好地为规模庞大并不断增长的中国半导体界服务。刘先生将带领的核心技术团队是由经验丰富的软件工程师组成，他们是工厂自动化、设备控制和矽美科SEMI GEM、GEM300和设备数据采集（EDA）等方面产品的专家。我们过去一段时间一直在寻找一位高素质的国家总经理来补充我们的技术团队，也包括面试许多候选人。我们很高兴最终找到刘先生加入矽美科团队。”

Bob Reback，矽美科总裁兼首席执行官

矽美科在世界各地建立国际团队，为我们的客户提供在当地时区工作、讲本国语言和了解其独特文化的技术专家。在全球半导体和电子制造的主要地区，我们现在都有一位经验丰富的高级管理人员担任该地区的国家经理，能够帮助我们的客户获得最高质量的技术支持并取得成功。

欢迎刘立聪先生！

Cimetrix is pleased to announce and welcome Lewis Liu as its Country Manager for Cimetrix China. Mr. Liu will be responsible for ensuring the success of our growing customer base of leading semiconductor equipment manufacturers and smart manufacturing factories in China, providing strategic direction for Cimetrix China to have long-term success in the China market, overseeing local sales and account management, and leading an expert team of China-based software engineers.

Mr. Liu earned a Bachelor of Engineering in Mechatronics and a Master of Business Administration. He has over 20 years of experience in the semiconductor and electronics industries with both China local and international companies. He has held a variety of positions in sales management, account management and channel management. He deeply understands the many challenges of the semiconductor industry and will be an asset to our customers by demonstrating the value propositions of Cimetrix products for their businesses.

Cimetrix China (Cimetrix Software Shanghai Co., Ltd.) was formed last year as a local China company with the goal to empower China companies with smart manufacturing software, be easy to do business with and provide the strongest technical support in the industry.

“Cimetrix has been serving customers in China for the past five years. Initially, our China strategy focused on working closely with a few select manufacturers of semiconductor 300mm equipment to ensure their success using Cimetrix products by providing them with exceptional local technical support. Now that these initial customers are shipping equipment in high volume to leading China semiconductor 300mm wafer fabs and have earned Cimetrix a reputation for very high-quality products, we believe it is time to grow our local capabilities to better serve the large and growing China semiconductor community. Mr. Liu will lead our core technical staff of very experienced software engineers who are experts in factory automation, equipment control and the full portfolio of Cimetrix products for SEMI GEM, GEM300 and Equipment Data Acquisition (EDA) capabilities. We conducted an extensive search for a high-quality Country Manager to complement our technical team, which included interviewing many candidates. We were very pleased to find Mr. Liu and are excited to have him join the Cimetrix team.”

Bob Reback, President and CEO, Cimetrix

Cimetrix has been building international teams throughout the world to provide our clients with technical experts who work in their local time zones, speak their native languages, and understand their unique cultures. In all of the major regions for semiconductor and electronics manufacturing, we now have an experienced executive who serves as that region’s Country Manager and is able to help our customers be successful and receive the highest levels of technical support.

Welcome Lewis Liu!

You may be familiar with the brain teaser that starts, “As I was going to St. Ives, I met a man with seven wives.” As the poem continues, each wife has seven sacks, each sack has seven cats, etc. Eventually the question comes out, “How many were going to St. Ives?” The common misconception of this brain teaser is that to answer the question you must multiply all of the items together, resulting in a huge number.

Cimetrix has extensive experience in helping application developers integrate the Equipment Data Acquisition (EDA) / Interface A standards into their equipment control applications. Occasionally we encounter an equipment type that has a very large number of process modules and each process module has a very large number of exceptions. An exception in EDA Freeze II is represented by both an exception definition and an exception instance. What are the options for creating a model with a large number of exceptions?

Good

The most direct approach is to have one exception definition per exception instance as shown in the following EDA equipment model:However, with this approach, if each module has 5000 exceptions, 200 modules would result in 1 million exception instances with a corresponding 1 million exception definitions. The system resources required to deploy and maintain this model are very large.

Better

EDA allows multiple exception instances to refer to a single exception definition. The following model shows this approach:In this example, we can see that the process module has ten exception instances, but now there is only one set exception definition. Using this approach, if each module has 5000 exception instances, 200 modules would still result in 1 million exception instances, but we would now only have 200 exception definitions (one for each module). This is a significant reduction, but still quite large.

Best

The best approach for equipment with many process modules each with a large number of exceptions is to define only a few distinct exceptions per module, and then use a transient parameter (or data variable) to indicate the actual cause of the problem. The following model shows how this might look:The process module in the model above only has one exception. The transient parameter AlarmCode would contain the information about what caused the exception to be triggered. It is possible to have multiple exception parameters if additional information is necessary (sub error code, description, etc.)

The EDA standards reference four exception severity levels – Information, Warning, Error, and Fatal. If we create one exception definition for each of these severities and no more than four exception instances per module, we see that a model with 200 modules would have four exception definitions and an upper limit of 800 exception instances.

This approach to exception consolidation benefits equipment makers and factories alike by reducing model complexity and model size.

The answer to the brain teaser above is that only one person was going to St. Ives – me. You don’t have to spend a lot of time and effort trying to figure out how many people, cats, etc. were in the other party, because they were travelling in the opposite direction! Similarly, if you consolidate your exception handling in EDA, you don’t have to spend a lot of time and system resources trying to handle too many exceptions.

The COVID-19 pandemic is impacting businesses worldwide, and in many regions, working from home is now mandatory or at least strongly encouraged.

While this doesn’t pose a major disruption for many types of jobs, it can be problematic for people working with the automation features of advanced manufacturing equipment. The network connections to production equipment are normally part of a secure factory system infrastructure, which makes them almost impossible to reach from outside the company’s intranet. Luckily, for those responsible for testing and characterizing the SEMI EDA (Equipment Data Acquisition, also known as Interface A) interfaces on new 300mm equipment, this should only be a minor inconvenience. And why is that?

The choice of internet technologies (Web Services, SOAP/XML) as the foundation for the EDA standards makes it easy to connect to a piece of equipment over the internet as long as the user’s client computer can “reach” the connection URLs of the equipment (and vice versa). What this probably means in practice is setting up a VPN (Virtual Private Network) connection from your client computer (say, the laptop you normally use) to the company’s network. This is something that road warriors and remote employees must often do as a matter of course to access internal file systems, in-house applications, and other private information.

Once this is done, you can connect to the various service URLs for that equipment by including the remote computer name in the session connection strings. Note that you may have to modify the firewall settings of your client machine so the E134 NewData messages can find their way back to you. This is necessary because these are NOT request/reply messages like many of the EDA services; rather, they are initiated from the equipment, so your application has to be listening for them on the Consumer URL. This address is passed to the equipment when the connection session is first defined and established.

Using the Cimetrix ECCE Plus client product as an example, here is how I would set up a remote (from home!) session with an EDA-enabled 300mm equipment simulator running in our office on a machine named “edasimulator.” The first screenshot shows the choice of connections defined for my instance of the ECCE Plus; note that last one in the list that is highlighted.

Clicking on the “Edit Session Definition” button and then the “More >” checkbox yields the screen below. You can see that the equipment IP address is “edasimulator” (the remote computer name referenced above) and each of the Freeze II service URLs (E132 Location, E125 Location, and E134 Location) for the session are defined on that machine.

Note that the client ID (From/Client Name), which is “MyHomeTestClient,” must also be defined in the equipment’s Access Control List (ACL). For me to be effective, this client must have sufficient privileges for the kinds of work I need to do, which may include using existing DCPs (Data Collection Plans), creating additional DCPs, viewing interface configuration parameters (e.g., Max Sessions) and ACL entries, browsing the metadata model, and looking at the SOAP logs. Results of some of these tasks using the ECCE Plus are shown below.

This may sound like a lot of trouble, but with a little help from your company’s IT support team, you can follow the “shelter in place” guidelines and STILL work effectively on your EDA-related tasks. And when the current crisis has passed, you’ll know how to be even more effective when you’re on the road!

We hope the posting is useful for you, and most importantly, that you and your loved ones stay safe and calm.

To our valued clients and partners –

With the ongoing spread of COVID-19 (Coronavirus), we are in unprecedented times. This situation changes rapidly, and Cimetrix wants to reassure our clients and partners that we are continually adapting our operations and business practices to ensure that we continue to serve your needs and that no client experiences a decline in the quality or responsiveness of our technical support.

Today I want to personally share what we are doing to maintain continuity during this time.

TECHNICAL SUPPORT

As always, our technical support capabilities can be accessed around the clock, anywhere in the world. We have offices throughout Asia, the U.S. and Europe to make sure that your needs are taken care of 24 hours a day. While many of these offices are in countries that have asked their residents to self-isolate, we will continue to work remotely to make sure all the needs of our clients are covered.

PRODUCT SUPPLY

Some of our clients have asked if our supply of products could be interrupted during the COVID-19 virus. We currently expect no interruptions whatsoever in our supply of products.

SAFTEY OF OUR CLIENTS AND EMPLOYEES

I have personally requested that the employees of Cimetrix stay home if they show any signs of illness. In addition, I have also issued a statement to all employees saying they should work from home if their local government requests it, or if they feel their health could be compromised. Cimetrix has long been a proponent of the work-from-home option, allowing even employees near a Cimetrix office to work from home several days a week. We are now very experienced at working collaboratively with employees in many different locations, including employees working from home. We do not expect any decline in our ability to serve our clients or continue executing our product roadmaps.

In addition, when and if it might be appropriate for our team members to visit our clients’ facilities, our team members have been coached on appropriate hygiene requirements as well as ensuring they will not visit if they feel unwell. As always, the health and safety of our clients, employees and partners is of paramount concern.

Cimetrix is determined to stay connected and working for you. We will continue to evaluate this evolving situation, and are here to assist all of our clients as needed.

2019 was another exciting year for Cimetrix. In our journey as a Smart Manufacturing and Industrial IoT solutions provider, we were able to increase revenues year-over-year to a new record high during a year that saw double-digit revenue drops for capital equipment suppliers in the semiconductor industry. Also, our attention to fiscal discipline enabled us to achieve our tenth consecutive year of profitability and further strengthen our strong cash position.

Cimetrix continues to provide software that makes the world’s most sophisticated and expensive manufacturing equipment smarter, as well as an innovative IIoT platform for the world’s leading factories. We focus on ensuring the success of our worldwide customers with local presence and support. Our global team members in North America, Europe, Japan, Taiwan, Korea, China and Southeast Asia provide unmatched expertise and technical support to our customers.

For 2020, Cimetrix expects a double-digit increase in revenues as the results of our growth initiatives undertaken over the past several years gain further traction. We believe the foundation of Smart Manufacturing and Industrial IoT begins with smart equipment and smart connections. Furthermore, we believe that Cimetrix is uniquely positioned to help equipment manufacturers and factories in their pursuit of Smart Manufacturing. We will relentlessly pursue understanding our customers’ challenges and providing them with innovative solutions.

From all of us at Cimetrix, we thank our customers, partners and shareholders for the faith and confidence they have placed in us. We will continue to strive for excellence in satisfying our worldwide base of customers and delighting them with innovative new products and solutions.

Sincerely,

Bob Reback
President and Chief Executive Officer

When it is time to deploy equipment in a factory it is very apparent if proper software testing has been conducted. As Ron Michael said, “If you automate a mess, you get an automated mess.” This notion holds true for GEM-enabled equipment. Software tools are available that are designed to make automated testing painless and efficient. While it is important to test all software on the equipment, this blog focuses on testing the GEM interface.

Testing the GEM interface is crucial throughout the equipment’s Software Development Life Cycle as you will see below.

Development Phase

The stakeholder (customer) has communicated the need for the equipment to have a GEM interface so it can integrate with an in-house GEM host. The customer’s written specification includes the GEM scenarios the equipment must support to interact effectively with the host.

As the requested features are added to the GEM interface, the developer must be able to simulate the host’s role in each scenario. Testing is crucial to ensure the equipment correctly satisfies each requirement. After the GEM interface is completed, E30 compliance testing is paramount before deployment.

Deployment Phase

After the equipment is set up in its permanent location, the field engineer will need a way to connect to the equipment and test the GEM interface before the equipment is connected to the factory host.

Once the equipment is in production it can be difficult to gain access to the equipment because of its geographical location or factory access restrictions. So deploying equipment that has a tested and compliant GEM interface allows you to avoid a significant loss of time and resources and ensure a smooth deployment.

Sustaining and Maintenance Phase

The GEM interface should be tested after every software update, GEM feature addition, or any change that could affect how the interface performs.

In this sustaining and maintenance phase equipment that have been properly tested experience less downtime.

Using the Right Tools

Some of the biggest challenges that equipment manufacturers face stem from not having the correct GEM testing tools.

Perhaps they have a testing tool, but it is outdated and therefore, not effective. Having outdated tools in your testing portfolio is much like hanging on to a worn, rusty wrench. It may appear to be working, but it is gradually stripping the bolts. As Benjamin Franklin noted, “The best investment is in the tools of one’s own trade.” Therefore, as developers, it is important to know when it is time to “throw away the rusty wrench.”

Cimetrix EquipmentTest^TM is a new software tool designed to reduce factory acceptance time and harden your factory GEM interface. It also helps factories and equipment suppliers characterize equipment, gather information from equipment, determine an equipment’s compliance to SEMI standards, and consolidate any equipment-specific unit tests into a single interface.

EquipmentTest is the multi-purpose tool that every equipment developer should have in their toolkit.

To understand why, let’s look at a few of its key features.

The Message Tab

The Message tab in EquipmentTest is crucial during development and testing. As parts of the GEM interface are completed, the ability to send atomic messages or to reply to messages from the equipment is vital. The messages are formatted in SMN (SEMI E173, SECS Message Notation). This XML syntax combined with a library of raw message templates makes it easy to quickly create and send SECS messages without writing any code. This is especially useful in situations such as sending a remote command to the equipment or ensuring a GEM alarm is reported to the host.

Users can also define custom messages and add these messages to their own libraries. These messages can then be saved into the EquipmentTest profile for that equipment to be used again later.

GEM Compliance Plug-in Report

EquipmentTest Pro provides an out-of-the-box GEM (SEMI E30) compliance testing capability called the GEM Compliance plug-in. This plug-in ensures that all GEM requirements implemented on the equipment are done so correctly. The GEM Compliance plug-in also provides a report that can be used to determine what areas of the GEM standard the equipment has implemented properly, and where improvement is needed. This report can help mitigate a common scenario I have witnessed where an inadvertent lack of congruence between stakeholders leads to missing or improperly implemented GEM items.

EquipmentTest is also configurable so that if a certain area of GEM functionality is not required by a factory, the report will define it as “not implemented.” EquipmentTest allows developers, testers, and all stakeholders to deploy their GEM interfaces with confidence.

Test Execution

Tests can be run one at a time, or as a group. Each test contains embedded documentation that explains the test purpose and the steps that comprise the test. The Output tab shows the results of the test. The SMN log can be used when a test fails for diagnostics or to view the contents of messages that were sent and received by EquipmentTest.

Custom Tests

Every equipment is unique. Moreover, a particular equipment’s unique features are likely what differentiate it from the competitive alternatives and therefore contribute significantly to its value. For this reason, it is impossible to test every behavioral scenario of all manufacturing equipment. Inevitably, innovative equipment will require custom testing. Custom testing may also be required to ensure the equipment will meet the specific requirements of a given factory.

Support for custom testing is one of the most valuable features of EquipmentTest. Unlike its predecessors that use a limiting scripting language, EquipmentTest allows users to create custom tests called plug ins in standard .NET programming languages. The ability to write host-side tests in an extensible programming language, with access to the EquipmentTest’s SECS/GEM software libraries offers limitless testing possibilities. This makes sending and receiving SECS messages in a custom test very simple (as shown below).Once a developer creates a test, the project Dynamically Linked Library (.dll) file can be distributed to others involved in the testing project. This allows engineers, technicians, and other stakeholders to load the custom plug-in and test the equipment without writing any code.

Trace Report Test Example

This plug-in was created during training and showcases the basics of plug-in development. When we load our custom plug-in, the look and feel is the same as the Cimetrix-provided plug-ins.

Documentation

The documentation displayed in the UI is populated from the following method decorations.

Parameters

Parameters can be changed by the EquipmentTest user and can be of any type, even custom data types.

Test Logic

As the test runs, everything that is printed to the console in code shows up in the output window.Assertions

Assertions are what a test actually evaluate. In this example, we assert that all samples of the trace are sent by the equipment. If any assertion fails, the test will fail on the UI. In this case, “1 or more samples did not complete” would appear on the UI upon a test failure.

SMN Log

The SMN log contains all messages transmitted during the test. This can be very helpful for diagnosing the root cause of a test failure when used with the test output.

Conclusion

The Cimetrix EquipmentTest software is designed to make automated testing painless and efficient. Using this shiny new tool instead of a rusty one can make deploying a quality GEM interface much easier and helps ensure your new or existing GEM interface is fully E30 compliant.

For more information on Cimetrix EquipmentTest visit our website today.

Background

Several years ago, I was working with a client implementing EDA who wanted to collect data at higher than typical rates using the EDA trace data collection feature (essentially periodic data polling). The typical EDA data collection rate I was used to was 10 Hz, with a couple of clients implementing 20 Hz or even 40 Hz. This client, however, wanted to collect data at about 1000 Hz. This was a lot faster than we normally could accomplish, especially since the software timers and clock functionality in Windows are really designed for about 15 ms intervals. Therefore, the normal means of implementing the data collection was not going to work very well.

With a little creative thinking, I came up with a solution. Instead of using trace data collection, I decided to try event data collection. Every 1 second, I triggered an event notification and provided 1000 data samples with the event that had been collected at 1 ms intervals and stored. The 1000 samples were presented to the EDA client as an array of data, which EDA supports directly, and this solution worked very well. I also found that this approach used surprisingly few resources to implement and transmit, largely because the data is so compact. It was also very reliable.

Although this event with array data solution worked in this very specific situation, there were a few drawbacks. First of all, the client could not choose the data collection interval. Normally with trace data collection the client chooses the data collection rate to meet the needs of a specific data collection application. Secondly, the client receiving the data had to know what the data meant. The client application software had to be programmed to understand that each value in the 1000 sample array represented data collected every 1 ms. Finally, I could not use the trace start trigger and stop trigger to automatically enable and disable the reporting of the data collected. Normally, trace data collection can be started and stopped automatically to collect data between specific equipment events, which is a nice feature to focus data collection between specific processing steps or other meaningful activities.

EDA Freeze 3

A couple of years ago, the SEMI North America DDA (Diagnostics and Data Acquisition) task force, which I co-lead, decided to begin work on the next version of the EDA standards suite, commonly referred to as EDA Freeze 3. As part of this work, I raised an issue that I wanted our task force to address. That is, I wanted to be able to collect data using the EDA standard at higher frequencies than the typical 10 Hz available using today’s trace data collection. In particular, I wanted to leverage what I had learned using the event data array solution to report data collection at 1000 Hz and faster, and make this an integral part of the EDA standard without the limitations of my current solution. This new feature is now called Cached Data.

Cached Data Features

The basic principle behind this new feature is simple. First, allow the EDA client to define a Cached Data Request and specify the reporting frequency, data collection frequency, and other attributes like the number of samples, a start trigger, a stop trigger, and whether or not the triggers are cyclical. Then have the EDA server report the data for each parameter as a compact data array.

For example, an EDA client might ask for a parameter at a collection interval of 0.1 ms (10 KHz) and a reporting interval of 1 second. The result would be a set of Cached Data Reports that look like this:

The equipment would collect the data every 0.1 ms and store the values for 1 second, and then send the Cached Data Report with the collected values in a tightly packed array. The EDA client would receive the data once per second and would know the data collection frequency.

Limitations

There are some limitations to the Cached Data proposal. For example, this type of data array reporting is only practical for some data types like integers, floats, Booleans and bytes. This type of data reporting is not practical for structured data or strings. Moreover, not all data can or should be collected at such high rates. Collecting data at these high rates requires robust software specifically designed for high-speed data collection. Therefore, the EDA proposal includes a way for parameter metadata to specify where the cached data feature can be used, and includes the specific minimum and maximum data collection frequencies. Therefore, the Cached Data feature is expected to be used for a limited subset of the available parameters for which the EDA server is specifically designed to provide such high-speed data collection.

gRPC & Protocol Buffers

The proposed EDA Freeze 3 standards also include the use of gRPC and Protocol Buffer technology, thereby moving EDA away from SOAP/XML over HTTP. gRPC with Protocol Buffers is a solution for a binary interface. Prelimiary test results reported to the DDA task force show dramatic throughput improvements and reduced bandwidth requirements for EDA. Additionally, the testing confirmed that reporting data in compact arrays is far more efficient for transmitting large amounts of data. In other words, the Cached Data feature is expected be even more effective due to this EDA protocol change.

SEMI Voting

Soon a new voting cycle for SEMI standards will begin where we vote on new versions of the standard. The Cached Data feature is included in two SEMI ballots: ballot 6553, a major revision of the SEMI E134 SPECIFICATION FOR DATA COLLECTION MANAGEMENT, and ballot 6527, a major revision of the SEMI E125 SPECIFICATION FOR EQUIPMENT SELF DESCRIPTION. Both are planned for voting in SEMI voting cycle 2 in 2020. Task force members are currently reviewing the latest revision of the proposed ballots.
Studies have already shown vast improvements in factory applications when collecting data at 10 Hz instead of 1 Hz. The increased performance of EDA Freeze 3 will allow the industry to dramatically improve manufacturing processes even more when data can be collected and reported at rates of 1000 Hz, 10 KHz, and beyond.

As a young boy, I liked to work on the family car with my dad. He taught me how to change the oil, check the spark plugs, replace the shock absorbers, adjust the timing and lots of other tasks that were common on older cars. I remember the first time he let me use the socket wrench. I thought it was the greatest tool ever invented. I could loosen bolts, then moving a small switch into a different position, the same wrench could now tighten bolts. It is a very versatile tool, one I still make sure to have handy to this day. 

I appreciate having well-designed tools available that can be used in a variety of situations. In my career, these tools have sometimes been software tools. I have spent a lot of my career working with equipment connectivity standards and seeing the benefits of having process equipment connected to a factory control system. Whether it is for full equipment control, or just to monitor and gather data from the equipment, having a robust connection to equipment is valuable.  

When I first started connecting equipment to factory control systems, the GEM standard had not been finalized. There was a lot of variability in the SECS message implementations available from the different equipment vendors. I was almost always able to get the equipment connected to the factory system, but generally each connection was custom to that equipment vendor and equipment type. This meant that each connection took far too much time to complete and made supporting different equipment very difficult. 

Once the GEM standards were finalized and adopted, there was now a versatile way to provide consistency and reusability across equipment types and across equipment vendors. Connecting to different types of equipment was principally a configuration task instead of a custom coding task.  

In addition, industry standard compliance test tools were developed to ensure compliance with the GEM standards and harden the implementations for reliable production use. This increased reliability helped drive the adoption and implementation of GEM in the global semiconductor front-end manufacturing industry. As a result, GEM has become a well-established reliable communication standard that is widely used and accepted.  

As other segments of the semiconductor and related electronics manufacturing markets have looked to connect equipment to their factory control systems, many have evaluated GEM and other communication standards to provide this functionality. In some cases, GEM was considered too old, too complex, or not a good fit. But, like the versatile socket wrench, many industry segments have seen the value of the stability and proven nature of GEM. They found that the socket wrench (GEM) was the right tool—they just needed a different sized socket (industry-specific guidance) to fit their needs. Let’s look at a few examples.  

SEMI PV2 

In 2007, when the photovoltaic industry wanted to increase manufacturing efficiencies and reduce costs, they looked to implement industry-wide standards. They formed the Photovoltaic Equipment Interface Specification Task Force to define the interface between the factory control system and the equipment. 

The task force created two working sub-teams to evaluate existing solutions and the requirements of the industry. Several existing solutions such as SECS/GEM, EDA, OPC-UA, and XML were evaluated based on functionality, reliability, extendibility, and the ability to be integrated into different environments. The conclusion of both teams was to build on the SEMI GEM (E30) standard.  

The socket wrench (GEM) was the right tool, and a new socket (SEMI PV2) provided the required fit for their equipment and industry. 

HB-LED 

In 2010, when the high-brightness light-emitting diode (HB-LED) industry started their search for connectivity standards. They needed something that would allow low-cost, common hardware and software interfaces, and other means to enable HB-LED factories to effectively utilize multiple equipment types from multiple vendors in a highly automated manufacturing environment. 

This search found that the best course was to leverage the functionality, reliability, and extendibility of GEM. The SEMI HB4: Specification of Communication Interfaces for High-Brightness LED Manufacturing Equipment (HB-LED ECI) defines the behavior of HB-LED equipment and is based on the SEMI E30 (GEM) standard.  

Again, the socket wrench (GEM) was the right tool. What they needed was a socket (HB4) that would meet the needs of their industry. 

PCBECI 

In February 2019, the Taiwan Printed Circuit Association (TPCA) initiated an activity seeking to boost network connectivity of PCB equipment and help PCB makers implement smart manufacturing practices in the industry.  

The result of this effort was the publication in August of 2019 of the SEMI A3: Specification for Printed Circuit Board Equipment Communication Interfaces (PCBECI). This is a robust and comprehensive shop-floor communication standard that specifies the detailed, bidirectional communications needed to improve productivity and reduce the costs to develop equipment interfaces for PCB manufacturing. The SEMI A3 (PCBECI) standard is based on the SEMI E30 (GEM) standard. 

Yet again, the socket wrench (GEM) was the right tool and all that was needed was a socket for their specific needs (PCBECI).  

It is understandable to think of GEM as an old and complex standard. It has been around for years and can be difficult to understand. However, it has continued to be reviewed and updated as manufacturing needs have changed. As different market segments have looked for equipment communication standards to meet their specific needs, several have found that the functionality, reliability, extendibility and the ability to be integrated into different environments provided by GEM was the right tool. All that was needed were some companion specifications related to GEM to provide a better fit for their requirements.