secs-simulator is a visually appealing, easy-to-use tool with high flexibility in auto-reply for SECS/GEM testing and device simulation.
Built on electron-egg, using arco-design-vue as the UI component library and secs4js as the SECS/GEM communication library.
Core Dependencies:
electron-egg: A desktop application framework built onelectron.arco-design-vue: A Vue component library by ByteDance, providing rich UI components.secs4js: A SECS/GEM communication library built on TypeScript for implementing SECS/GEM protocol communication.
SEComSimulator:
FASTSim:
You can create and manage SECS/GEM engines through the Engines module. Each engine can be configured to communicate with different devices.
Main Features:
- Support for creating multiple SECS/GEM engine instances.
- Each engine instance can be configured to communicate with different devices.
- Support for configuring engine connection parameters such as IP address, port number, etc.
- Support for starting and stopping engine communication.
You can load and parse SECS/GEM protocol SML files through the SML File module. SML files are text files used to describe SECS/GEM protocols, typically used to define device functionality and communication parameters.
Main Features:
- Support for viewing and editing SML file content.
- Support for generating corresponding SECS/GEM protocol code from SML files.
You can view SECS/GEM engine communication logs through the LogPanel module. The log panel displays communication details between the engine and device, including sent messages, received messages, etc.
Main Features:
- Support for viewing SECS/GEM engine communication logs.
- Automatic log saving to the
secs-logsfolder in the root directory.
You can configure automatic replies for SECS/GEM engines through the AutoReply module. The auto-reply feature can automatically reply with predefined messages based on messages sent by the device.
Supports three automatic reply mechanisms (sorted by priority):
- Priority-based reply using AutoReply Scripts
- Next, based on reply rules in SML File, automatically search for files named
S{stream}F{func + 1}, parse the SML, and auto-reply. - If neither mechanism is triggered, use default reply (S stream F func+1)
You can configure automatic reply scripts for SECS/GEM engines through the AutoReply Scripts module. Auto-reply scripts are JavaScript-based scripts used to automatically reply with predefined messages based on messages sent by the device.
Main Features:
- Support for viewing and editing AutoReply Scripts content.
- Support for parsing corresponding SECS/GEM SML code from SML files using AutoReply Scripts.
You will see the main application interface:
Supports three communication modes:
- HSMS-SS
- SECS-I
- SECS-I On TCP/IP
After configuration, click the Open button to open the engine.
After configuration, click the Send button to send messages to the device.
AutoReply Scripts are JavaScript-based scripts used to automatically reply with predefined messages based on messages sent by the device.
The default method name is handler(comingMsg, filePaths), with parameter meanings as follows:
comingMsg: The message sent to this engine by the device, which is aSecsMessageobject.filePaths: The relative paths of all local SML files.
Additionally, the tool provides a method getMsgByFilePath(filePath: string) to obtain the corresponding SECS/GEM message object based on the SML file path. This method returns a SecsMessage object parsed from the SML text, which you can manipulate as needed.
Example:
/**
* Auto reply handler
* use getMsgByFilePath(filePath) to get sml message object
* @param {object} comingMsg args: stream, func, wBit, body(example: body[0][1].value)
* @param {number} comingMsg.stream
* @param {number} comingMsg.func
* @param {boolean} comingMsg.wBit
* @param {object} comingMsg.body
* @param {string[]} filePaths args: sml files directory paths
* @returns {string} sml file path
*/
async function handler(comingMsg, filePaths) {
let targetPath = filePaths.find((f) => f.includes('S1F2_Other'))
const msg = await getMsgByFilePath(targetPath)
const value = msg.body[0].value
if (value === 'MDLN-A') {
return targetPath
}
}The above script logic: Search for files containing S1F2_Other in all SML files. If the file exists and the first element value in its SML body is MDLN-A, return the file path. Otherwise, default to returning undefined.
If this rule is triggered, you will see logs similar to the following in the corresponding LogPanel:
23:33:16[INFO]Received Message: DeviceId=10, SystemBytes=1, Data=
S1F1 W.
23:33:16[INFO][Action Script Reply] Reply Message: DeviceId=10, SystemBytes=1, Data=
S1F2
<L [2]
<A [6] "MDLN-A">
<A [13] "SOFTREV-0.0.1">
>.
EventBind generates a complete set of GEM event-binding related SML commands from a TOML configuration, so you can quickly apply DefineReport / DefineLink bindings on the equipment side.
- Click
EventBindin the top toolbar. - Fill in or adjust the TOML configuration in the left editor.
- Click
Convertto generate the preview (switch tabs on the right to view all 6 SML outputs). - Click
Saveto write files to:sml/EventBind/EventBind_YYMMDDHHmm/. - In the left
SML Filetree, locate the generated folder and send the files to the equipment (recommended order below).
[CEID_RPTID_BINDING]: maps a CEID (Collection Event) to a list of RPTIDs (Reports).[RPTID_CEID_BINDING]: maps an RPTID (Report) to a list of CEIDs (used to generate DefineReport content).
You can provide only one section, but it is recommended to keep both sections consistent to get a complete set of generated files.
01_S2F37_DisableAllEvents.txt: S2F37, Disable All Events.02_S2F35_DisableLink.txt: S2F35, Disable Link (generated from CEIDs inCEID_RPTID_BINDING).03_S2F33_DisableReport.txt: S2F33, Disable Report (generated from RPTIDs inRPTID_CEID_BINDING).04_S2F33_DefineReport.txt: S2F33, Define Report (generated fromRPTID_CEID_BINDING).05_S2F35_EnableLinkEvent.txt: S2F35, Enable Link Event (generated fromCEID_RPTID_BINDING).06_S2F37_EnableAllEvents.txt: S2F37, Enable All Events.
In most cases, send files in filename order (01 → 06) to clear existing bindings first and then re-define them.
Convertis disabled: check whether TOML is empty, has syntax errors, or is missing required section names (CEID_RPTID_BINDING/RPTID_CEID_BINDING).- Some generated outputs look empty: the related section may be missing (e.g., only
CEID_RPTID_BINDINGis provided, so report-related outputs may contain empty lists). - Cannot find the saved folder: in dev it is under project root
sml/EventBind/; in packaged app it is under the exe sibling foldersml/EventBind/.
example:
# DefineLink Configuration Template
# Format: CEID_RPTID_BINDING section maps Collection Event IDs to Report IDs
# Format: RPTID_CEID_BINDING section shows which CEIDs use each RPTID (for reference)
# value is an array of Report IDs
[CEID_RPTID_BINDING]
# CEID = RPTID
1001 = [2001, 2002]
1002 = [2002, 3001]
1003 = [2001]
# value is an array of Collection Event IDs
[RPTID_CEID_BINDING]
# RPTID = CEID (optional - shows reference mapping)
2001 = [2004]
2002 = [2005]
3001 = [2001]AutoFlow lets you chain “send / wait / delay / log” steps into a runnable flow, with live progress and run logs. It is designed for automating EAP/GEM interaction sequences.
- Only
simulate=Equipmentengines are supported (Host engines are not selectable). - The target equipment engine must be opened and in RUNNING state.
sendsteps require existing SML files from theSML Filetree (filePathuses the relative path shown there).
- Click
AutoFlowin the top toolbar. - Click
New, select an equipment engine inSelect Engine, and enter aFlow Name. - Add steps via
+ Send / + Wait / + Delay / + Log / + End. - Click
Save. - Click
Runto start; usePause / Resume / Stopduring execution if needed.
- Each flow is stored as a JSON file:
autoflows/<FlowName>.json. - Dev: under project root
autoflows/; packaged: under the exe sibling folderautoflows/.
send: send an SML file.- Required:
filePath. - Optional:
timeoutMs(default 30000). - Optional:
waitReply(use engine “wait reply” send mode). - Optional:
expect(wait for an incoming message matching the condition after sending).
- Required:
wait: wait for an incoming message matchingexpect.- Required:
expect. - Optional:
timeoutMs(default 30000).
- Required:
delay: wait for a duration.- Required:
ms(milliseconds, can be 0).
- Required:
log: write an internal AutoFlow log (does not go to engine LogPanel).- Required:
message. - Optional:
level(INFO/WARN/ERROR).
- Required:
end: end the flow.
Note: the first step must be send (used to trigger the flow start).
expect defines what message to wait for. It supports:
sf: shortcut likeS6F12.stream/func/wBit: detailed matching (can be used with or withoutsf).smlIncludes: requires the SML text to contain a substring.conditions: an AND list of advanced conditions, each contains:path: value path likea.b[0].c/a[0][1].value.op:exists/eq/neq/contains/regex/gt/gte/lt/lte.value: required for most ops exceptexists.
Minimal example: send S1F1 and wait for S1F2, then end.
{
"name": "DemoFlow",
"tool": "TOOL",
"steps": [
{
"type": "send",
"filePath": "Commnication\\S1F1.txt",
"timeoutMs": 30000,
"expect": { "sf": "S1F2", "smlIncludes": "MDLN" }
},
{ "type": "end" }
]
}








