Additional SECS/GEM Simulator Features
Default Variables​
Each simulator is initialized with a set of status variables and equipment constants intended for demonstration and testing. These objects are active within the simulator, meaning standard SECS/GEM requests, such as S1F3, can be used to read their definitions and current values. Equipment constant values can also be updated using the S2F15 request.
Status variables and equipment constants are defined in the simulator SDL file under the data section. Any changes made in the Sim Variables panel are written to the simulator SDL file and take effect after the simulator is restarted. For more information on how these objects are structured, see the Simulator SDL File section.
Status Variables​
Status variables define values that represent the current state of the simulator, such as operating mode, control state, or sampled measurements. Each status variable includes an ID, name, units, format, and value. Optional event triggers can be defined so that a change in value generates a collection event. Status variables are stored in the simulator SDL file and edited in the "Status Variables" section of the Sim Variables panel. Definitions captured from an existing tool using the S1F11 request can be used as a reference when defining status variables in the simulator. Since S1F11 does not include format or value information, formats and values must still be configured manually.
Example Status Variable Definition​
The example below shows a single status variable entry as it appears in the simulator SDL file. To use this example, add a new entry under "Status Variables" in the Sim Variables panel and adjust the values as needed for your simulator.
{
"svid": 2,
"name": "ControlState",
"units": "states",
"format": "A",
"value": "ON-LINE/REMOTE",
"eventTriggers": [
{
"ceid": 1,
"newValue": "ON-LINE/REMOTE"
},
{
"ceid": 2,
"newValue": "ON-LINE/LOCAL"
}
]
}
- svid uniquely identifies the status variable.
- format defines the SECS data type returned in responses.
- eventTriggers specify which collection events are fired when the value changes.
After saving changes, restart the simulator for the variable to be available to SECS requests such as S1F3.
Equipment Constants​
Equipment constants define configurable parameters that typically change infrequently, such as limits, operating modes, or timeouts. Constants include minimum and maximum values, units, formats, and default values. Equipment constants are stored in the simulator SDL file in the "Equipment Constants" section and can be read or modified using SECS requests like S2F13 and S2F15. Definitions captured from an existing tool using the S2F29 request can be used as a reference when defining equipment constants in the simulator.
Example Equipment Constant Definition​
The example below shows a single equipment constant entry. To use it, add a new entry under "Equipment Constants" in the Sim Variables panel and adjust the values as needed for your simulator.
{
"ecid": 201,
"name": "EstablishCommunicationsTimeout",
"minValueFormat": "U2",
"minValue": 0,
"maxValueFormat": "U2",
"maxValue": 10000,
"format": "U2",
"defaultValue": 15,
"units": "seconds"
}
- ecid uniquely identifies the equipment constant.
- minValue and maxValue define valid limits.
- defaultValue is used when the simulator starts or resets.
Restart the simulator after saving changes for the constant to be applied.
Echo Responses​
Some SECS/GEM messages are not implemented by default in the simulator. Echo Responses allow you to define a fixed response for a specific request message. An Echo Response maps an incoming request to a predefined response message. This allows the simulator to return valid responses for unsupported messages or to emulate tool-specific behavior. Echo Responses are defined in the simulator SDL file and edited through the Sim Variables panel, where they appear alongside other simulator configuration data.
When adding support for new messages, you may also need to define the request and response messages in the messages section of both the simulator SDL file and the equipment connection SDL file.
Example Echo Response Definition​
The example below defines a response to an S1F1 request. Add this definition to the Echo Responses section of the simulator SDL. Once applied, the simulator returns a fixed S1F2 reply whenever it receives S1F1.
{
"request": {
"stream": 1,
"function": 1
},
"response": {
"header": {
"stream": 1,
"function": 2,
"reply": false
},
"body": [
{
"format": "A",
"value": "SimEquip",
"doc": "MDLN"
},
{
"format": "A",
"value": "1.0",
"doc": "SOFTREV"
}
]
}
}
Event Runs​
Event Runs allow the simulator to generate S6F11 Event Report Send messages on a defined schedule. An Event Run consists of one or more events that execute in sequence, each with a configurable delay. Each event in an Event Run contains a complete S6F11 message definition, which is sent when the event executes. Event Runs are defined in the simulator SDL file and edited through the Sim Variables panel. They are commonly used to simulate periodic reporting or state-driven events. Event Runs must be started manually. While an Event Run is active, events are sent in order until the run completes or is cancelled.
Example Event Run Message Body​
The example below shows a complete S6F11 message body used by an Event Run. To use this example, paste the message body into an event definition and adjust IDs and values to match your simulator configuration.
All referenced CEIDs, RPTIDs, and variables must already exist in the simulator SDL file for the message to be sent successfully.
{
"header": {
"stream": 6,
"function": 11,
"reply": true
},
"body": [
{
"format": "U4",
"value": 2,
"doc": "DATAID"
},
{
"format": "U4",
"value": 3,
"doc": "CEID"
},
[
[
{
"format": "U4",
"value": 1,
"doc": "RPTID"
},
[
{
"format": "A",
"value": "ON-LINE/REMOTE",
"doc": "V"
}
]
]
]
]
}