Industry News, Trends and Technology, and Standards Updates

This blog is the conclusion to the blog: Identifying Custom Test Cases in the SEMI E30 GEM Standard found here.

Unhappy Path Testing

Though this post will focus on the so-called “happy path” (i.e., no errors), it is also important to test unhappy paths.

Conditions that might show up in the “unhappy path” testing include:

1. Card reader loses internet connection.
2. Card reader loses power
3. Vending machine loses communication with Card reader

Happy Path Test Case

The happy path is the program flow that is followed given the user (or in this case, the equipment) only enters valid data. I

n this simple test, we ignore the Error/Alarm cases (Transitions T2 and T4).

Transition Test Steps for Happy Path

1. Initializing T1 =>
2. Wait_Payment T3 =>
3. Wait_Selection T5 =>
4. Dispense_Item T7=>
5. while (User wants more items && has sufficient funds)
   {
   Dispense_Item T6
   Wait_Selection T5
   }
6. Transaction Complete T8

EquipmentTest plugin setup

Prerequisites:

1. EquipmentTest 1.0.3 or later installed.
2. Visual Studio 2019 or later (Targeting .NET Framework)
3. .NET 4.8 SDK
4. A unit of GEM-enabled equipment (or equivalent) to test against
5. Follow the instructions in the EquipmentTest Developer Guide Section titled: “Creating a plug-in using Visual Studio”,

Test Flow

Sometimes I find it beneficial to assert the data as it occurs. For the sake of brevity, this test will gather all the data, and then verify it at the end of the test.

Documentation

Documentation is one if the items the user will see in the EquipmentTest User Interface. Each Test Step must be documented in the plug-in so the user understands what the test is doing.

User Parameters

In GEM, each Collection Event, Variable, and Alarm will have an ID. These IDs are needed for host-side testing. Most modern equipment allows us to get these IDs through characterization messaging. For this example, we will allow the user of our test (plug-in) to enter the values manually.

Custom Test Overview

The HSMS settings are retrieved from the set the user entered in the EquipmentTest user interface.

In Step 1, the Event Report for the Processing State Transitions and associated variables are created.

In Step 2, the test waits for an Auto Reset Event “timeOutWait”. If the result times out, the test fails. If the test receives Transition 8, the test continues.

Steps 1-2

Create Reports

The CreateReports API call sends an S2F33 message to create the report number specified by the user parameter ProcessState Report. The report will contain the status variables ProcessState and PreviousProcessState. Both have a value type of Ascii in this example.

Test Steps 3-4

Step 3 inspects the data to make sure all the state transitions occurred in the expected order.

The first 4 states should always be T1, T3, T5, and T7 respectively. However, the next states will vary depending on how the user responds. This requires the test to dynamically assert the data.

In test step 4, we extract the variable values, and then use the same approach as step 3 to ensure the previous and current process states were reported correct.

Conclusion

Though developing this test took a basic understanding of GEM and C#, running the test requires the user to understand neither. This means anyone with access to the equipment and an EquipmentTest run-time license can run successfully run this test.

Cimetrix EquipmentTest allows the developer to harness the extensibility of the .NET Framework. Furthermore, the well-written and proven GEM libraries flatten a significant portion of the learning curve associated with writing GEM tests.

For more information on Cimetrix EquipmentTest, to request a demo, or to speak with an expert, please click the button below.

Testing the interface capabilities of GEM-enabled equipment not only during development but also while in production has measurable benefits. There are portions of the GEM standard that are not explicitly specified, allowing implementations to vary from equipment to equipment. As a result, equipment manufacturers should write equipment-specific tests that will continue to provide value throughout the equipment’s service life.

Processing State Model

One GEM item that will almost always vary is the equipment’s processing state model. I will use the Cimetrix GEM test utility EquipmentTest to show an example of creating a custom test for an equipment’s processing state. You can request an evaluation of EquipmentTest on our website.

The E30 standard provides an example Processing State Diagram and Transition table.

Process State Requirements

Though implementations can vary without violating the standard, the processing state section includes the following requirements which must be followed for the interface to be compliant:

SEMI E030-00-0520

Explanation:

The examples for the Processing States (INIT, IDLE, SETUP, etc.) are not absolutely required in a GEM implementation. However, the equipment manufacturer must identify the equipment’s states and document them similarly to the examples.

SEMI E030-00-0520

Explanation:

• There must be a collection event for each state transition in the processing state model.
• The following status variables must be provided:
  
  • ProcessState
  • PreviousProcessState
• Whenever any state transition occurs, the ProcessState and PreviousProcessState status variable values must be updated

Pseudo example Vending Machine

Though it is unlikely a GEM interface would ever be implemented on a vending machine, it is a universally known system, often used as a state machine teaching example in academia. Therefore, we will likewise use our imaginary GEM-compliant Vending Machine as an example.

Assumptions to Maintain Simplicity

• The vending machine uses contact-less payment that authorizes $5.00 at the beginning of the transaction.
• The vending machine has no knowledge of the items it contains except their location and prices.
• All items are always in stock.

Make a Diagram

When your GEM documentation is final, the Process State diagram should be in Harel notation. For the purposes of brainstorming, I have used a simple UML diagram.

When building a diagram, first identify all the possible GEM states, transition/collection events, variables, alarms, and errors.

Transition Table

Note the above diagram has each state transition marked in red e.g. T1.

Each state transition must be documented in the Transition Table. The Transition Table will be crucial for developing an effective test.

Part 2 - The Conclusion will be published next week. In the meantime, if you have questions, would like to request a demo, or would like to speak with one of our experts, please click the button below.

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!

Purpose of Spooling Messages

Even the most robust computer networks experience communication failure. Regardless of the cause, a small outage could be responsible for a significant amount of mission critical data loss. GEM mediates this loss of data by providing the message spooling capability.

Spooling Definition

“Spooling is a capability whereby the equipment can queue messages intended for the host during times of communication failure and subsequently deliver these messages when communication is restored" SEMI E30-0717 7.12.

Spooling Benefits

Automated factories are data-driven. Data is extracted and analyzed to make decisions that influence how engineering and management teams react to ensure product yield is high and scrap is low.

Gaps in this data could lead to erroneous judgement or even guessing. Spooling is a backup system that ensures this data will be preserved and restored reducing the risk of losing valuable data.

GEM Capability Requirements

Spooling is not a GEM requirement however, if this additional capability is implemented it must be done so properly. Here are a few requirements for implementing a compliant spooling interface.

The equipment must provide the host with the ability to enable and disable spooling via the equipment constant “EnableSpooling”. This EC is published by the equipment and the host can select the desired state.

When Spooling is implemented, it must be functional for all relevant primary messages and accessible using an S2, F43/F44 transaction. This excludes stream 1 messages which must be rejected if they attempt to “set spool”. 

Non-Volatile Storage

The equipment is responsible for allocating enough non-volatile-storage to store all messages that have been spooled for at least one processing cycle of the equipment. The NVS will also house all spooling-related status variables. NVS is used for this data so that if a power outage occurs the data is persisted.

Loss of Power

All messages that were spooled prior to the equipment’s power loss will be available since they are persisted in non-volatile storage. All spooling context is restored from NVS if spooling was active at the time of the power loss occurred. This includes the spooled data as well as all spooling related status variables persisted in NVS.

Host responsibility for implementation of Spooling

Message spooling requires hosts to participate to successfully recover after a loss of communication. It is Ideal to leave spooling in the disabled state until the host has been programmed to properly handle all conditions that may occur in the entirety of this state machine. Disabled spooling is better than improperly managed spooling. 

Once communication is re-established, the host must manage requesting the spooled messages. The host also has the option of purging the files from the equipment when necessary.

Conclusion

Though spooling is not a fundamental GEM requirement, if implemented it must be done so properly. Both host and equipment software have a responsibility to ensure GEM compliance when spooling is enabled. GEM spooling protects the potential loss of valuable data and provides a standard for both equipment and host software to adhere to with ease.

Click here to read the other articles in our SECS/GEM Features and Benefits series. 

To download a white paper on an introduction to SECS/GEM, Click below:

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.