IEC 104 Driver

dc3-driver-iec104 brings IEC 60870-5-104 telecontrol equipment into IoT DC3—targeting substation/dispatch automation devices, it connects as a 104 client and collects telemetry/status by Information Object Address (IOA), with support for sending control commands.

IEC 60870-5-104 (IEC 104 for short) is the international standard telecontrol protocol for power-system dispatch automation, carrying the IEC 60870-5-101 application layer over TCP/IP. It is widely used for "four-remote" communication (telemetry, telesignaling, telecontrol, telesetpoint) between substations, distribution terminals (DTU/FTU), RTUs, and master stations. Each data point is uniquely located by an Information Object Address (IOA), and each frame is described by an ASDU type (e.g. M_ME_NC_1 short-float telemetry, M_SP_NA_1 single-point status) that conveys the data semantics. This driver uses the j60870 (OpenMUC) library as a client, connecting over TCP to a 104 server and reading values / sending control commands by the IOA and ASDU type configured on each Point.

Use cases: connecting a master station/platform to substation integrated-automation systems, distribution-automation terminals, or RTUs to collect telemetry and status and issue telecontrol.

• Driver name / code: IEC 104 Driver / Iec104Driver
• Type: DRIVER_CLIENT (actively connects to the server)

Skeleton implementation for now

This driver is currently a template skeleton: protocol-layer I/O (IOA read and telecontrol write) is not yet implemented—read() / write() fail fast by throwing a "not implemented" exception (so the SDK records the failure and applies backoff, rather than echoing a cached value or faking success). Treat it as a starting point for onboarding a 104 device, not a production-ready driver. The attribute tables and schedules below are taken verbatim from the real application.yml and are safe to fill in, but the actual read/write behavior is still to be completed.

Driver configuration (device-level driver-attribute)

When onboarding an IEC 104 device, fill these attributes on the Device:

Attribute	code	Type	Default	Description
Host	host	STRING	localhost	104 server IP
Port	port	INT	2404	104 TCP port (standard 2404)
ASDU Address	asduAddress	INT	1	Common address (station address)
COT Length	cotLength	INT	2	Cause-of-transmission byte count
CA Length	caLength	INT	2	Common-address byte count
IOA Length	ioaLength	INT	3	Information-object-address byte count
Connect Timeout	connectTimeout	INT	10000	Connect timeout (milliseconds)

COT/CA/IOA lengths are a station-wide convention and must match the peer

cotLength / caLength / ioaLength are the byte widths of the respective fields in 104 frames, agreed between the master and the telecontrol device during engineering configuration (typically 2/2/3). These three must match the peer exactly, otherwise frame parsing will be misaligned. asduAddress (common address) distinguishes multiple logical stations under the same connection.

Point configuration (point-attribute)

Fill these on each Point to locate the information object to read by IOA:

Attribute	code	Type	Default	Description
IOA	ioa	INT	0	Information object address
ASDU Type	asduType	STRING	M_ME_NC_1	ASDU type identifier

IOA locates "which point to read", ASDU type defines the data semantics

ioa is the information object address, uniquely identifying one data point in the telecontrol device. asduType indicates the point's data type, defaulting to M_ME_NC_1 (short-float telemetry); status points commonly use M_SP_NA_1 (single point). The Point's data type (Point's pointTypeFlag) must match the actual data carried by the ASDU type.

Write-command configuration (command-attribute)

Points that issue telecontrol also need this on the write command:

Attribute	code	Type	Default	Description
Send Command	sendCommand	STRING	${value}	Command template, rendered with command parameters

sendCommand is a template with parameter placeholders

sendCommand uses ${paramName} placeholders; during execute, the driver substitutes the command parameters (e.g. ${value}) and then sends. The default ${value} simply uses the command value as the control value. Note: the actual protocol send for telecontrol is still at the skeleton stage (see the warning above).

Acquisition and health

• Acquisition cycle: default read cron 0/30 * * * * ? (one read round every 30 seconds); plus a custom scheduled task cron 0/5 * * * * ? (every 5 seconds, for the driver's custom logic).
• Health / online: device health check default cron 0/15 * * * * ?, lease timeout 45 seconds—see Device for the online-status mechanism.

Minimal onboarding example

Onboard one telecontrol device at IP 192.168.1.30:2404 and read one short-float telemetry point:

1. Create a Device with IEC 104 Driver, filling driver attributes host=192.168.1.30, port=2404, asduAddress=1 (leave cotLength / caLength / ioaLength at the defaults 2/2/3, as long as they match the peer's convention).
2. Add a telemetry Point to the Profile bound to the device (pointTypeFlag=FLOAT, READ_ONLY), filling point attributes ioa=16385, asduType=M_ME_NC_1.
3. Start the driver; a read round triggers within 30 seconds—once the protocol layer is completed, you will see the collected value in PointValue.

Common pitfalls

Mismatched COT/CA/IOA lengths = whole-frame parse misalignment

104 frames have no field delimiters and are split purely by the agreed byte widths. If cotLength / caLength / ioaLength differ from the peer, addresses get read off the wrong bytes, so you collect the wrong point or parsing fails outright. Before onboarding, confirm the peer's 2/2/3 (or other) configuration with operations and fill all three in exactly.

The standard port is 2404, and the common address distinguishes logical stations

The 104 standard TCP port is 2404, different from 101 and Modbus—do not reuse 502. One RTU may host several logical stations distinguished by asduAddress (common address); when host / port are identical, the asduAddress of the point's device determines which station to connect to.

Further reading

• Driver — the general driver model and registration mechanism
• Attributes and config — the three-layer origin of attributes like host / ioa
• Device onboarding — a complete onboarding flow
• Modbus TCP Driver — another TCP industrial-protocol driver