IEC 60870-5-104, DNP3 and Modbus: Selecting a Substation SCADA Protocol

A standards-based decision guide comparing telecontrol semantics, security, event recovery, command handling and acceptance testing for IEC 104, DNP3 and Modbus.

IEC 60870-5-104, DNP3 and Modbus can all move substation data, but they solve different problems. IEC 104 and DNP3 are telecontrol protocols designed around events, timestamps, quality and control-center operation; Modbus is a compact register-oriented application protocol whose engineering simplicity is valuable inside equipment, but whose native semantics are too limited for many utility SCADA duties.

The right selection is not a popularity contest. It follows the control-center standard, required event fidelity, communications quality, cyber profile, installed base, vendor conformance and the cost of preserving semantics through gateways. This guide establishes a practical selection and acceptance method for MV switchgear projects.

1. Begin with the communication boundary

BoundaryTypical requirementUsual preference
IED to station HMI/gatewayRich equipment model, quality, reports, controlsIEC 61850 MMS
Station gateway to regional/control-center SCADATelecontrol events, commands, WAN resilienceIEC 104 or DNP3 according to utility standard
PLC, meter or auxiliary package to gatewaySimple cyclic process values/registersModbus TCP/serial when limitations are managed
Protection/interlocking peer-to-peerDeterministic fast messagingIEC 61850 GOOSE or hardwired logic—not these SCADA links

Do not force one protocol across every boundary. A common, robust arrangement is IEC 61850 within the station and IEC 104 or DNP3 northbound. Every conversion, however, needs a controlled mapping for value, quality, time, event class and command state.

2. IEC 60870-5-104 engineering characteristics

  • IEC 104 carries IEC 60870-5-101 application information over standard TCP/IP transport profiles.
  • It uses typed application service data units, common addresses and information-object addresses rather than free-form registers.
  • Spontaneous transmission, interrogation, counters, commands and time-tagged events support telecontrol workflows.
  • Cause of transmission provides important operational context such as spontaneous, interrogation, activation and termination.
  • Sequence numbers and start/stop/test mechanisms supervise the application connection.
  • The consolidated IEC 60870-5-104 edition includes Amendment 1 and the August 2023 corrigendum.

Best fit: utilities whose control centers, RTUs and operating procedures are already standardized on the IEC 60870 family, especially Europe, the Middle East and many international grid projects. Its principal risk is not protocol capability but underspecified interoperability: type identification, causes, common address, IOA ranges, time tags, command qualifiers, cyclic/background behavior and redundancy must be fixed in a project interoperability profile.

3. DNP3 engineering characteristics

  • DNP3, standardized as IEEE 1815, uses typed objects and variations for binary, analog, counter, command and event information.
  • Static classes and event classes support integrity scans, class polling and report-by-exception.
  • Unsolicited responses can reduce latency and polling load when both ends implement them consistently.
  • Time-stamped events, confirmation, link/application integrity features and multi-master options suit constrained or intermittent utility communications.
  • A device profile and supported object/variation list are essential to multi-vendor interoperability.
  • DNP3 Secure Authentication and related Users Group work address command/message authentication; deployment details must be specified and tested.

Best fit: North American and other utility fleets already using DNP3, or WAN applications needing its mature event-class and outstation behavior. As of this review, IEEE lists IEEE 1815-2012 as Inactive-Reserved and the replacement P1815 project as an active PAR. Procurement documents should therefore state the exact supported DNP3 specification, implementation level/profile, secure-authentication version and device-profile revision instead of writing only “DNP3 compliant.”

4. Modbus engineering characteristics

  • Modbus defines application-layer functions for coils, discrete inputs, input registers and holding registers.
  • Its simple client/server transactions are widely available in PLCs, meters, drives and auxiliary systems.
  • Modbus TCP adds an MBAP header over TCP; serial deployments commonly use RTU framing.
  • The protocol does not natively give a register universal engineering meaning, quality model or substation logical-node context.
  • Time-stamped event and sequence-of-events behavior is normally vendor-specific or absent.
  • Traditional Modbus has no native authentication/encryption; the Modbus Security protocol adds TLS and X.509 certificate-based authentication on port 802 where supported.

Best fit: local integration of non-critical auxiliary equipment with stable register maps. Avoid using plain Modbus as the primary remote breaker-control or forensic event protocol unless a rigorous application layer adds command validation, time, quality, audit, security and fail-safe behavior.

5. Functional comparison

CriterionIEC 104DNP3Modbus
Native utility telecontrol modelStrongStrongLimited
Time-tagged eventsDefined typesDefined event objectsUsually proprietary
Quality/status semanticsDefined quality descriptorsDefined flags by objectRegister-map convention
Report by exceptionSpontaneous dataEvents/unsolicitedUsually polling
Control workflowSelect/execute and direct options by profileSelect/operate and direct operate optionsWrite function plus application logic
WAN/store-and-forward suitabilityGood with engineered buffering/gatewayVery good event/outstation heritageBasic
Configuration burdenInteroperability profile and IOAsDevice profile, objects/variations/classesRegister map, data types/word order
Typical ecosystemIEC-centric utilitiesDNP-centric utilitiesIndustrial/auxiliary equipment

6. Selection decision matrix

  1. Control-center compatibility: select the native master protocol unless a gateway has a clear lifecycle advantage.
  2. Information fidelity: list every required status, quality, timestamp, counter, measurement and command result before scoring protocols.
  3. Communications environment: consider LAN/WAN, bandwidth, latency, outages, redundant paths and buffered event recovery.
  4. Operational model: define polling, spontaneous/unsolicited reporting, integrity scans, time synchronization and alarm handling.
  5. Control risk: specify select-before-operate/direct operate, interlocks, origin, termination, feedback and timeout.
  6. Cybersecurity: require supported secure profiles, key/certificate lifecycle, segmentation, logging and patching—not an assumed secure protocol name.
  7. Conformance evidence: review tested editions, options and device profiles, then run project-specific interoperability tests.
  8. Lifecycle: score engineering tools, competence, spares, vendor support, migration and future point capacity.

7. Event, time and quality mapping

A gateway can translate syntax but cannot invent missing semantics. The mapping database should record source timestamp origin, synchronization quality, source quality, target flags, event class/cause, deadband and replacement behavior. A Modbus “1” may mean breaker closed, relay alarm active or communication healthy; none is safe without a controlled register definition and communication-failure rule.

  • Preserve source time for sequence-of-events; never silently substitute gateway receipt time.
  • Map invalid, blocked, substituted, overflow, not-topical/stale and communication-loss states explicitly.
  • Use double-point/intermediate indication for switchgear where the target protocol supports it.
  • Distinguish a process transition from a data refresh or gateway reconnection.
  • Define buffer capacity and behavior when events exceed it; alarm overflow.
  • Keep raw and scaled analog definitions, units, sign, resolution and deadband under version control.

8. Control security and safety

  • Use network zones/conduits, allowlists and least-privilege accounts regardless of protocol.
  • For IEC 104, evaluate IEC 62351-5:2023, IEC TS 60870-5-7:2025 and transport security in IEC 62351-3.
  • For DNP3, specify the applicable Secure Authentication/profile support and credential lifecycle.
  • For Modbus, prefer read-only integration for low-criticality devices; where control is necessary, require Modbus Security or a protected conduit plus application safeguards.
  • Reject remote control on stale/invalid position, wrong authority, failed interlock or ambiguous device selection.
  • Audit user, master/client identity, selected object, command, response, final feedback and time.

9. Redundancy and reconnect behavior

  • State whether redundant masters are hot/standby, dual-active or independent and how command ownership is prevented from splitting.
  • Define TCP reconnect backoff, session initialization, interrogation/integrity scan and event replay.
  • Prevent duplicate commands during gateway/control-center failover.
  • Test sequence rollover, buffer rollover, duplicate events, out-of-order delivery and long WAN outage.
  • Do not treat a live TCP socket as proof that source IED data is healthy.
  • Expose active path, standby health, last successful update and protocol diagnostics to operators/maintenance.

10. Procurement specification deliverables

  • Exact standard edition/amendment/corrigendum and supported protocol options.
  • IEC 104 interoperability profile; DNP3 XML/device profile; or signed Modbus register map.
  • Point list with value, type, address, quality, timestamp, event/deadband and control mapping.
  • Connection/session/redundancy/time-sync and communication-loss behavior.
  • Secure-protocol capabilities, certificates/keys, roles, logs and vulnerability support.
  • Capacity limits: points, events, clients/masters, buffers, scans and command rate.
  • Conformance evidence and a project-specific FAT/SAT procedure.
  • Configuration backup, source files, licenses, change method and long-term support.

11. FAT/SAT acceptance sequence

  1. Freeze protocol profiles, point database, gateway build and test tools.
  2. Verify every point end-to-end: normal/abnormal value, quality, source time, address and text.
  3. Test spontaneous/unsolicited/event-class behavior, integrity/general interrogation and counter handling.
  4. Operate each control through select, execute, cancellation, rejection, timeout and final position feedback.
  5. Inject bad quality, time loss, stale source, IED link loss and gateway restart.
  6. Interrupt WAN long enough to exercise buffers; verify replay order and overflow alarm.
  7. Fail active/standby master, gateway and link during status changes and a control sequence.
  8. Apply maximum normal load and event storm; measure missed/duplicate events and operator response.
  9. Test permitted and denied cyber connections, credentials, secure-session rollover and audit logs.
  10. Repeat installed end-to-end cases at SAT and archive packet captures/results with as-built files.

12. Practical recommendation

Use IEC 104 when it is the utility/control-center standard and the project can define a complete interoperability profile. Use DNP3 where the master fleet, maintenance competence and event/outstation philosophy are DNP-centric. Use Modbus for bounded equipment integration, preferably monitoring, when its register-level simplicity is an advantage and its missing utility semantics are deliberately supplied. A gateway is justified only when its mapping, security, buffering, redundancy and lifecycle are engineered as a protection-adjacent system—not treated as a protocol converter appliance.

References and further reading

Engineering note: Select a protocol only after the project has demonstrated how breaker position, bad quality, source time, command authority and command termination survive the complete IED-to-control-center chain.

LearnSwitchgear

Search the engineering library