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