SCADA und IoT in moderne Unternehmensplattformen integrieren

Plants, pipelines, substations, and water networks generate a continuous stream of operational data: temperatures, pressures, flows, run states, alarms, and energy use. Enterprise teams want that data for maintenance planning, energy management, quality analysis, and production reporting. The control systems that produce it — SCADA servers, programmable logic controllers, and human-machine interfaces — were built for a different purpose and a different threat model.

Operational technology prioritizes availability and safety above everything else. Assets stay in service for decades, patch windows are rare, and many industrial protocols, such as Modbus and older DNP3 deployments, were designed for closed networks with little or no authentication. Connecting these environments to enterprise and cloud platforms is valuable, but it has to be done without creating a new path for an attacker, or an accidental command, to reach the physical process.

This explainer covers the reference models, protocols, and patterns that let enterprise platforms consume operational data while leaving control where it belongs.

Start from the layers: Purdue and ISA/IEC 62443

The Purdue Enterprise Reference Architecture remains the common vocabulary for describing industrial networks, even where modern architectures blur its boundaries:

• Level 0: the physical process — sensors, actuators, and drives.
• Level 1: basic control — PLCs, RTUs, and other controllers.
• Level 2: supervisory control — SCADA, HMIs, and engineering workstations.
• Level 3: site operations — historians, manufacturing execution systems, and site-wide services.
• Industrial DMZ, often called Level 3.5: the brokered boundary between operations and enterprise networks.
• Levels 4 and 5: enterprise business systems and, increasingly, cloud services.

ISA/IEC 62443 builds on this with zones — groups of assets that share security requirements — and conduits, the controlled communication paths between them, each with a target security level. For integration work the practical rule is simple: no direct connection from the enterprise or the internet into Levels 0 to 2. Data moves outward through the DMZ, and connections are initiated from the more trusted side toward the less trusted side wherever possible.

Getting data out: OPC UA, MQTT, and Sparkplug B

OPC UA is the most capable bridge out of the control layer. Its information model means a value arrives with its engineering units, data type, quality status, and place in an asset hierarchy, and it provides built-in security through certificate-based authentication, signing, and encryption. Many modern controllers and SCADA platforms expose OPC UA servers directly; protocol gateways translate legacy fieldbus and serial protocols where they do not.

MQTT is well suited to moving data from the edge to enterprise platforms: it is lightweight, tolerant of unreliable links, and supports report-by-exception rather than constant polling. On its own, however, MQTT defines neither topic structure nor payload format, and teams that skip that decision end up with inconsistent topics and undocumented payloads. The Eclipse Sparkplug specification fills the gap with a standard topic namespace, a defined binary payload, birth and death certificates that tell consumers whether a value is current or stale, and sequence numbers for detecting lost messages.

# Sparkplug B: spBv1.0/<group_id>/<message_type>/<edge_node_id>/[<device_id>]
spBv1.0/site-north/NBIRTH/line3-gateway
spBv1.0/site-north/DBIRTH/line3-gateway/filler-01
spBv1.0/site-north/DDATA/line3-gateway/filler-01
spBv1.0/site-north/DDEATH/line3-gateway/filler-01
spBv1.0/site-north/NDEATH/line3-gateway

# Command topics exist in the spec; deny publish at the broker for enterprise clients
spBv1.0/site-north/DCMD/line3-gateway/filler-01        (ACL: deny)

# Contextualized topics published by the edge for enterprise consumers
uns/site-north/packaging/line3/filler-01/state
uns/site-north/packaging/line3/filler-01/oee

Many organizations combine these into a unified namespace: a single, governed hierarchy — often modeled on the ISA-95 levels of enterprise, site, area, line, and cell — through which operational data is published once and consumed by many systems. Note that command topics in the example are denied at the broker. Read-only by default should be enforced in infrastructure, not left to convention.

Enforce one-way flows where consequences are high

For high-consequence environments such as power generation, water treatment, and chemical processing, firewalls alone may not provide enough assurance. Unidirectional gateways, often called data diodes, enforce outbound-only flow in hardware: data can leave the operations network, but nothing can travel back. Because common protocols expect acknowledgments, these products typically replicate a server — a historian or an OPC UA server — on the enterprise side rather than passing traffic straight through.

The trade-off is deliberate: no write-back path and no remote access through that channel. Where vendors or engineers need remote access, provide it through a separate, brokered path in the DMZ with multifactor authentication, time-limited approval, and session recording — never through the data integration path.

Engineer the edge: buffering, context, and historians

An edge gateway, typically at Level 3 or in the DMZ, does more than forward data. It should store and forward, buffering locally so a WAN outage does not create gaps, with capacity sized for the longest outage you intend to tolerate. It should preserve source timestamps and the quality codes OPC UA attaches to each value, so downstream analytics can distinguish a real zero from a failed sensor. And it should normalize units and map raw tags to an asset model, because a controller register address means nothing to an enterprise analyst.

Most industrial sites already run a historian, and it is often the operational system of record. Integrate with it rather than replacing it: use its native replication or interface options instead of polling it heavily, and agree with operations on which system is authoritative for which data. Enterprise platforms are for analysis, reporting, and planning; alarm management and safety functions stay in the control layer.

On the platform side, plan for the realities of industrial data. Values arrive late or out of order after outages, so pipelines should key on source timestamps and tolerate backfill. High-frequency signals rarely need full resolution forever; tiered retention with downsampled aggregates keeps storage costs predictable while raw data stays available for a defined window. Much of the analytical value comes from context — joining time-series data with work orders from the maintenance system, batch and order data from MES or ERP, and the asset model — so design those joins in from the start rather than exporting raw tags to a data lake and hoping someone models them later.

Decide what the enterprise may send back

Once data flows reliably, someone will propose closing the loop — sending optimized setpoints or schedules from the cloud back to the plant. Some of these use cases are worth pursuing, but each one changes the risk profile of the entire integration.

A phased rollout keeps risk manageable:

1. Assess: build an asset inventory, verify network diagrams against what is actually installed, and run a risk assessment aligned to ISA/IEC 62443.
2. Pilot: connect one line or site read-only, with buffering, data-quality checks, and monitoring of the integration itself.
3. Model: establish the asset hierarchy and naming conventions before adding sites, because renaming later is expensive.
4. Scale: onboard further sites from a repeatable template, with a security review for each new conduit.

Bringing it together

Successful SCADA and IoT integration respects two sets of priorities at once. The enterprise needs timely, well-modeled, trustworthy data; operations needs the physical process to remain safe and available no matter what happens upstream. Layered architecture, standard protocols such as OPC UA and Sparkplug, outbound-only flows, careful edge engineering, and a strict default against write-back allow both to be true.

The result is a platform where operational data informs maintenance, energy, and production decisions across the enterprise, while control stays with the people and systems responsible for it.