---
title: "Additional SECS/GEM Simulator Features"
---

# Additional SECS/GEM Simulator Features

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

## Default Variables

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](ignition-modules/secs-gem/secs-gem-simulator/secs-gem-simulator.md#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.

```json
{
  "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"
    }
  ]
}
```

:::tip Example Details

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

```json
{
  "ecid": 201,
  "name": "EstablishCommunicationsTimeout",
  "minValueFormat": "U2",
  "minValue": 0,
  "maxValueFormat": "U2",
  "maxValue": 10000,
  "format": "U2",
  "defaultValue": 15,
  "units": "seconds"
}
```

:::tip Example Details
* **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**.

```json
{
  "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.

```json
{
  "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"
          }
        ]
      ]
    ]
  ]
}
```