Industry News, Trends and Technology, and Standards Updates

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.

Recently, I had the opportunity to participate in the development, testing, and integration of the Cimetrix ELS library that encompasses the SEMI A1, A1.1, and A2 (SMT-ELS) standards. It’s been exciting to see how ELS has increasingly been embraced as a connectivity solution for electronic manufacturing equipment.

I was first introduced to the SMT-ELS standard in June 2019 by Alan Weber (VP, New Product Innovations, Cimetrix). To begin, I obtained a functioning ELS implementation from Siemens Japan as well as the needed hardware. To make sure I fully understood ELS, I attended a 2-day class presented by Siemens and began studying the ELS standard and the Siemens ELS implementation.

It took a significant amount of time to get familiar with Siemens Implementation and gain an understanding of what they did to support the ELS standard. Siemens Japan has done a great job with their SEMI SMT-ELS implementation, and their assistance with my efforts is greatly appreciated. Once I felt familiar enough with ELS, I built a SMEMA interface driver to simulate the conveyor signals.

Using the SMT-ELS communications library, the Cimetrix development team designed a sample equipment application which I was able to use for initial connectivity testing. At first, it was fairly difficult to get the two libraries to communicate. However, when I used the Cimetrix EquipmentTest^TM software, I was able to find defects in our library, which were quickly and easily resolved by our development team. 

While it was beneficial to have a known ELS implementation to test against, it is now clear how valuable using a testing tool would be for anyone creating or validating their own SEMI SMT-ELS implementation.

Even though the SEMI A1, A1.1 and A2 standards are not long, they are dense. As adoption of these standards increases, it becomes paramount that equipment manufactures can test their SMT-ELS implementations during development. It is not effective or efficient for equipment manufacturers to test against other equipment as their primary form of testing. This is why the Cimetrix EquipmentTest SMT-ELS plug-in is so valuable.

I am currently working on test are written in C# and the code is easy to follow. The tests are split into two categories; one for horizontal communication between equipment ,and vertical communication to a factory system.

Horizontal Tests

For Panel Transfer verification, EquipmentTest connects to the first and last equipment in the line. This allows EquipmentTest to send messages to the first equipment and validate the format and content of the message from the last equipment. 

For this test, the user defines the panel parameters. The panel is sent to the first equipment. Once the last equipment in the line sends the panel to EquipmentTest, the Material Data Content is verified. 

In addition to actual tests, EquipmentTest can be used to send user defined atomic messages such as SetMDMode.

Vertical Tests

EquipmentTest Connects directly to the vertical port of the equipment. Using EquipmentTest, I can set and validate the Net Configuration.

The EquipmentTest software has been pivotal in developing and test our SMT-ELS Implementation. A demonstration of EquipmentTest SMT-ELS and the Cimetrix EquipmentConnect^TM SMT-ELS software will be given at Productronica from November 12-15, 2019 in Munich, Germany. Please drop by our booth any time, or feel free to set up an appointment in advance. We look forward to meeting with you and discussing your ELS needs!