Communication Drivers#

Each of the available communication drivers is documented within its own entry.

Custom communication drivers can also be developed and used. Please refer the Developers Guide for further information.

Choosing a Driver#

Choose the driver from how the equipment offers its data. The driver definition, the communication parameters, and the equipment tasks of every workflow are written for one protocol, so a change of driver later means building them again. Ask the following questions in order. The first question that applies decides the driver:

Question	Driver
Does the equipment exchange files in a folder?	File Raw, whatever the format of the files: read each file with `ReadFile`, and parse the content in the workflow. Use CSV only when each row must be handled and confirmed before the next one, with `MoreDataRequest`.
Is the equipment a GEM tool, with an HSMS port or a serial line?	Secs/Gem, also when the tool listens on TCP. HSMS is a protocol of its own, and the TCP/IP driver only cuts text into frames.
Does the equipment run an OPC UA server?	OPC UA. The driver is a client. For an OPC DA server, use OPC DA.
Does the equipment publish to, or read from, an MQTT broker?	MQTT. The driver is one client of the broker and does not host a broker.
Does the controller call an HTTP API?	Rest Client. Each command is one request, and connecting sends no request, so an unreachable server shows only as a failed command.
Does another system call the controller over HTTP?	Rest Server. Each event is an endpoint path, and the driver answers each request automatically or waits for the workflow to reply with Request Reply Command. When both directions happen, use one connection of each driver.
Does a simple device, such as a reader, a scale, or a printer, send text or frames over a TCP socket?	TCP/IP. For a serial port, use Serial.

Table: Questions that choose a driver

When the equipment fits none of the questions, or more than one, such as a GEM tool that also runs an OPC UA server, ask which interface the integration must use rather than guess. GEM collection events carry their data, and OPC UA gives live values.

What Each Choice Commits You To#

The File Raw, CSV, and Rest Server drivers work on entries that the integration chooses: folders, files, and endpoint paths. For the other drivers, collect the identifiers of the equipment before you build anything:

Driver	What to collect	From
Secs/Gem	SVIDs, DVIDs, ECIDs, CEIDs and their reports, and remote commands with their parameters and formats	The GEM manual of the tool
OPC UA	The NodeIds of the variables and methods, and the object of each method	The server
MQTT	The topics, and how each payload is encoded	The publishers
TCP/IP	The frame format: delimiter, tokens, and command texts	The manual of the device
Rest Client	The endpoints, methods, parameters, and success statuses	The documentation of the API

Table: Identifiers to collect per driver

A wrong identifier is not refused when you save the driver definition. It shows later as an event that never arrives, a report that the equipment refuses, or a value that is always empty.

Each choice also commits the integration to the following:

Declare what the equipment exchanges as properties, events, and commands of the driver definition, and reach them with the equipment tasks, such as On Equipment Event and Execute Equipment Command. Send Notification to Driver and Subscribe In Driver carry messages between the controller and the driver process, not the addresses of the equipment.
A direction parameter states the role of the driver, not of the equipment. Secs/Gem connectionMode and TCP/IP mode are Active when the equipment listens and the driver connects, so a tool documented as HSMS passive needs an Active driver.
One machine can use several drivers in one controller, such as Secs/Gem for the tool and File Raw for its result files, each with its own driver definition. See Create the Setup Workflow.

Available Data Types#

The available data types in the system are listed below:

Boolean
String
Decimal
Integer
Long
Object
Password
DateTime
Culture

Parameters#

All communication drivers share settings with the same format/meaning:

Name	Type	Default Value	Description
setupTimeout	Integer	10000	Max time for the setup flow (milliseconds)
heartbeatInterval	Integer	60000	Interval to trigger an optional heartbeat to validate communication or any other task (milliseconds)
intervalBeforeReconnect	Integer	5000	Time to wait between connection attempt (milliseconds)
connectingTimeout	Integer	30000	Max time for the connection to be established (milliseconds)

Table: Communication driver settings

Tokens#

Some communication driver parameters accept tokens: placeholders in the form ${TokenName} that the driver substitutes with a runtime value instead of a literal, hardcoded value.

Token support is protocol- and parameter-specific — not every parameter accepts them, and the set of available tokens depends on the driver and on which parameter is being configured. Where a parameter supports tokens, its description states so explicitly and lists the tokens it accepts.

Examples:

The Factory Automation driver's queueName parameter accepts ${SystemName}, replaced with the name of the Critical Manufacturing system.
The File Raw and CSV drivers' file-manipulation commands accept ${Path}, ${Archive}, ${Temp}, and ${Id} in their path parameters (token names are case-insensitive).
The OIB driver's Subscription Name Suffix settings accept ${id} and ${guid}.

Separately, the MQTT, TCP/IP, Serial, and Keyboard Wedge drivers support a Token identifier type on properties. This matches incoming message content by prefix rather than by exact value or regular expression — it is a property-matching mode, not a value-substitution token. See the "Identifier Type" description on the relevant driver page for details.

Communication States#

All communication drivers follow this state model:

A driver process starts in the Unknown state, and its first transition is to Connecting, when the controller asks it to connect. Ready follows Disconnected only when no connection is requested.

Driver/Controller communication#

The communication the Connect IoT components is done using WebSockets. The intention is to allow customization to override one or more components using the programming language of the choice of the customer. The establish communication is described in the following diagram:

sequenceDiagram
    activate Monitor
    Monitor->>Manager: Request Create Driver
    activate Manager
    Monitor->>Manager: Request Create Controller
    Manager->>Driver: Create Process
    activate Driver
    Manager->>Controller: Create Process
    activate Controller
    Driver->>Driver: Create Communication Channel
    Driver->>Monitor: Connect with Monitor
    Controller->>Monitor: Connect with Monitor
    Driver->>Monitor: Notify Communication Channel Details
    Monitor->>Controller: Notify Driver Communication Details
    Controller->>Controller: Prepare Workflows
    Controller->>Driver: Connect with Driver
    Controller-->>Driver: Exchange communication Data
    Driver-->>Controller: Exchange communication Data
    deactivate Driver
    deactivate Controller
    deactivate Manager
    deactivate Monitor