Guide · Data Acquisition & Integration

Open Protocols for Rail Data Acquisition & Integration

The protocol a wayside asset speaks decides who can read its data for the rest of that asset's life. Pick a proprietary one and every future integration runs through a single supplier; pick an open, standards-backed one and any conforming logger, gateway, historian, or analytics platform can join the conversation. This guide covers the open protocols that matter for rail data acquisition — OPC UA, MQTT, Modbus, DNP3 — where each fits, why proprietary protocols and locked hardware are an architectural liability, and why the right design is to define the interface and stay open to more than one transport.

Why protocol choice is an architecture decision, not a detail

Data acquisition is the act of getting measurements off a field device and into something that can store, display, and reason about them. Integration is everything that happens after: feeding a historian, a control-room console, a maintenance system, an analytics pipeline. The protocol sits at the boundary of both, and it is the one decision on a procurement that is hardest to reverse. Sensors get replaced, software gets upgraded, but the protocol is the contract every other system is written against — change it and you re-integrate everything downstream.

That is why protocol choice belongs in the architecture conversation, not buried in a device datasheet. An open, well-supported protocol keeps the cost of the next integration low and the supply base competitive. A proprietary one quietly transfers that leverage to whoever owns the specification. The rest of this guide is about choosing protocols that keep the leverage with the operator.

Vital signalling versus the monitoring overlay

First, a boundary that has to be drawn clearly. The vital signalling function — the safety-critical exchange between interlockings and field elements — runs over safety-rated communication. In modern European practice that is RaSTA, the safe transport protocol used under the EULYNX standardised interfaces and built to satisfy EN 50159 for safety-related communication over open networks. Those protocols exist to carry commands that can stop trains, and they are out of scope for a condition-monitoring platform.

The protocols in this guide are for the non-vital layer: data acquisition, condition monitoring, diagnostics, and integration. A monitoring overlay reads the same assets non-intrusively — drive currents, voltages, temperatures, relay and detection states — and reports them upward without sitting inside the safety circuit. Keeping that layer separate from and advisory to the vital function is the standard architecture. Using open protocols for the monitoring layer does not touch the signalling safety case; it just decides who can use the diagnostic data.

The open protocols that matter

Four families cover almost everything a rail data-acquisition estate needs, with request-response APIs filling the gaps. None is the universal answer; each earns its place in a different part of the architecture.

Protocol	Model	Best fit in a rail estate
OPC UA (IEC 62541)	Client-server & pub/sub, self-describing model	Rich diagnostic and integration interface; browsable, secured data
MQTT (ISO/IEC 20922) + Sparkplug	Broker-based publish-subscribe	Efficient field-to-platform telemetry over constrained links
Modbus	Register-based request-response	Legacy and cost-sensitive device tier; near-universal support
DNP3 / IEC 60870-5	Polled & event telemetry with timestamps	Utility-style WAN telemetry; estates with existing SCADA
gRPC / HTTP	Request-response API	Platform and service integration, configuration, on-demand queries

OPC UA — the integration backbone

OPC UA is standardised as IEC 62541, a multi-part international standard maintained by the OPC Foundation. Its distinguishing feature is the information model: instead of exposing anonymous registers, a device exposes named, typed, structured objects that a client can browse and discover. A point machine can present “throw time”, “drive current”, and “detection state” as labelled nodes with units, not address 40012. Security is part of the specification — application authentication with X.509 certificates, encrypted channels, user-level access control, and audit trails — rather than bolted on afterwards. A publish-subscribe extension, added in the 1.04 generation of the standard, supports event-driven telemetry alongside the original client-server model. OPC UA is the natural choice for the integration backbone: the interface other systems browse, subscribe to, and trust.

MQTT and Sparkplug — efficient telemetry from the field

MQTT is a lightweight publish-subscribe transport standardised as ISO/IEC 20922. Devices publish to topics on a central broker, and any authorised subscriber receives the data; the small footprint and report-by-exception style (sending values when they change rather than polling constantly) suit constrained or intermittent wayside links. MQTT on its own only defines how bytes move, not what they mean, so the Sparkplug specification — an open specification under the Eclipse Foundation — is layered on top to standardise topic structure, an efficient payload encoding, and device birth/death state so a host always knows whether a field node is alive. The pairing gives you efficient, well-described field-to-platform telemetry without a proprietary cloud agent.

Modbus — the universal device tier

Modbus is old, simple, and supported by almost everything. It is register-based and request-response, available over serial (RTU) and TCP, and it is the path of least resistance for bringing legacy and cost-sensitive devices — chargers, power supplies, I/O modules, transducers — into a monitoring system. The trade-offs are equally well known: no built-in security, no semantic model, and registers that mean nothing without a separate mapping document. The sensible pattern is to keep Modbus at the device tier, read it at the edge, attach meaning and units there, and republish over a richer open protocol upstream.

DNP3 and IEC 60870-5 — utility-style telemetry

Where an estate already runs utility-grade SCADA over wide-area links, DNP3 (standardised as IEEE 1815) and its European counterpart IEC 60870-5 are often already in place. Both are built for telemetry over imperfect WANs: event buffering so data survives a dropped link, and source timestamping so sequence and timing are preserved. For rail operators with power, traction-supply, or distributed wayside telemetry already on these protocols, integrating with them rather than displacing them is usually the pragmatic open choice.

gRPC and HTTP — where an API fits

Not everything is a stream of field values. Configuration, on-demand queries, and service-to-service calls inside the platform are request-response by nature, and there gRPC (efficient, schema-defined, over HTTP/2) and plain HTTP REST are the open, ubiquitous tools. They complement the telemetry protocols rather than compete with them: HTTP and gRPC for “ask a question, get an answer”, OPC UA and MQTT for “tell me when this changes”.

A middle tier: ecosystem protocols

Between the genuinely open standards above and the closed protocols below sits a middle tier that is easy to mislabel. Protocols such as PROFINET and PROFIBUS (governed by PROFIBUS & PROFINET International, IEC 61158/61784), EtherNet/IP and the Common Industrial Protocol (CIP) it runs on (governed by ODVA), and EtherCAT or CC-Link IE are not vendor-proprietary in the specification sense — their specs are published and consortium-maintained, and several vendors build to them. What sets them apart from OPC UA or MQTT is that each is the centre of gravity of one supplier's automation ecosystem, so in practice the best tooling, the deepest device support, and the smoothest experience all live inside that ecosystem.

MELSEC (Mitsubishi's MC Protocol / SLMP) is the more genuinely vendor-specific case: it is documented and there are drivers and SDKs for it, but it is one maker's protocol rather than a consortium standard. That is the practical spectrum — fully open, then ecosystem-bound, then single-vendor.

Protocol	Governance	Openness in practice
PROFINET / PROFIBUS	PI (IEC 61158/61784)	Open spec; Siemens-centric ecosystem and tooling
EtherNet/IP & CIP	ODVA	Open spec; Rockwell / Allen-Bradley centre of gravity
EtherCAT	EtherCAT Technology Group	Open spec; Beckhoff-led ecosystem
CC-Link IE	CLPA	Open spec; Mitsubishi-led ecosystem
MELSEC (MC Protocol / SLMP)	Mitsubishi	Documented, with SDKs, but single-vendor

The verdict is not “avoid”. These are documented, well-supported, and far better than a closed black box. They are simply not as portable as a true open standard: they generally lack the self-describing information model and the in-specification security that OPC UA carries, and they assume a particular automation stack. The right way to use them is the same pattern as Modbus — read them at the edge, attach meaning and units, and republish over OPC UA or MQTT/Sparkplug upstream — so an ecosystem protocol stays at the device tier and never dictates the shape of the whole estate.

The cost of proprietary protocols and locked hardware

The alternative to all of this is a closed protocol and a logger that only speaks to its maker's software. It rarely looks like a problem on the day of purchase. It looks like a problem later, in a series of small frictions that compound:

• No off-the-shelf tooling — every client, driver, and dashboard has to come from the one vendor, because nobody else can speak the protocol.
• No second source — the field hardware can only be bought from its maker, at its price, on its lead time.
• Vendor-gated integration — connecting a new system means a paid change request, a bespoke gateway, or both, and it happens on the supplier's schedule.
• Brittle bespoke gateways — the integrations that do get built are one-off translators that break on firmware updates and have no community maintaining them.
• Single-supplier dependency — the whole estate's data is hostage to one company staying solvent, supportive, and reasonably priced.

The data is nominally the operator's, but if it can only be read through one product it is not really portable. That is the same exit-cost trap that defines vendor lock-in, expressed at the protocol layer.

Don't force one transport — define the interface

The most common mistake in the other direction is to standardise hard on a single protocol and force every site to use it. That fails because the constraints genuinely differ: a constrained cellular site favours MQTT; a rich diagnostic interface favours OPC UA; a relay-room retrofit may only offer Modbus; an existing telemetry estate may already run DNP3. Mandating one transport everywhere either excludes good equipment or buries you in adapters.

The durable design is to define the interface — the data, its meaning, and its contract — and allow more than one protocol to carry it behind that interface. Model the asset once: what a point machine, a level crossing, or a battery bank exposes and what each value means. Then let OPC UA, MQTT/Sparkplug, Modbus, or DNP3 be the transport that suits each site, all mapping to the same model. The platform stays open to many implementations, the data model stays consistent, and no single transport choice can fragment the estate. Openness is a property of the interface, not of any one wire protocol.

What to demand before you buy

Openness is easiest to secure at procurement, before anything is installed. The following are reasonable, testable requirements to put to any data-acquisition supplier.

Demand	What good looks like
Published protocol	Speaks at least one open standard (OPC UA, MQTT/Sparkplug, Modbus, DNP3) end to end, not via a closed bridge
Documented data model	A point-by-point map of every value, its meaning, and its units — not a black box
Multi-vendor readability	A named third-party client can read the device without the supplier's software
Security in the protocol	Authentication and encryption are part of the chosen standard, not an add-on
Data export	Bulk historical data is exportable in an open, documented format
No per-integration gate	Connecting a new downstream system needs no licence, key, or change request from the supplier

None of these asks a supplier to give anything away that a genuinely open product does not already provide. A vendor that meets them comfortably is one you can leave — which is exactly why you are unlikely to want to.

Frequently asked questions