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:
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.
- There must be a collection event for each state transition in the processing state model.
- The following status variables must be provided:
- 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.
|Initializing||Previous and Current Process State||Dispensing_Error|
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.
|#||Current State||Trigger||New State||Action||Comments|
|T1||Initializing||Vending Machine initialized||Wait_Payment||None||Update Events and variables|
|T2||Wait_Payment||Authorization failed||Wait_Payment||None||Update Events and variables|
|T3||Wait_Payment||Authorization Succeeded||Wait_Selection||None||Update Events and variables|
|T4||Wait_Selection||Balance Insufficient||Transaction Complete||None||Update Events and variables|
|T5||Wait_Selection||Items Selected and dispensed||Dispense_Item||None||Update Events and variables|
|T6||Dispense_Item||User wants more items||Wait_Selection||None||Update Events and variables|
|T7||Dispense_Item||User does not want more items||Transaction Complete||None||Update Events and variables|
|T8||Transaction Complete||Equipment prepares for next Transaction||Initializing||None||Update Events and variables|
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.