Plenty of South African operators already run SCADA — Ignition, AVEVA/Wonderware or Siemens — and want to bring in remote, hard-to-cable assets over LoRaWAN: borehole and reservoir telemetry, pump stations, environmental and energy sensors. The good news is that this is a solved integration problem using protocols your SCADA already supports. First decide whether SCADA is even the right home for the data (see SCADA vs an IoT platform) — then wire it up.
The path LoRaWAN data takes to SCADA
It's a chain, and each link uses a standard interface:
- Device → gateway → network server. The LoRaWAN network server (ChirpStack, The Things Stack, Actility ThingPark or AWS IoT Core for LoRaWAN) receives the uplink, de-duplicates gateway copies, manages keys, and decodes the raw payload into engineering values via a payload codec.
- Network server → middleware (over MQTT). Network servers publish decoded data on MQTT topics. A middleware or edge layer subscribes, normalises units, and maps each device/measurement to a SCADA tag.
- Middleware → SCADA (over the SCADA's native interface). The mapped tags are presented to SCADA over OPC-UA, MQTT/Sparkplug or Modbus TCP — whichever the platform prefers.
The hardware is the easy part. The engineering is in the middle: writing the payload decoders, mapping to a clean tag namespace, handling missing/late uplinks, buffering at the edge, and securing the path.
Platform by platform
| SCADA platform | Best integration path for LoRaWAN |
|---|---|
| Ignition | MQTT/Sparkplug B (Ignition's native, efficient option for IoT/telemetry) or OPC-UA; tags appear directly in the gateway/tag browser |
| AVEVA / Wonderware System Platform | OPC-UA into the platform, or MQTT — LoRaWAN values land as attributes on objects/templates |
| Siemens WinCC | OPC-UA (with S7 where a PLC is in the path); LoRaWAN data presented as OPC-UA nodes |
| Any SCADA / RTU | Modbus TCP from an edge gateway is the lowest-common-denominator path when a lighter integration is enough |
The things that decide whether it works
- Edge buffering. If the link to SCADA drops — or the power does — the edge layer must store and forward, so the historian doesn't get gaps. This matters more in South Africa than almost anywhere because of load shedding.
- Security. Telemetry should reach SCADA over TLS and/or a VPN, read-only into the control environment, with proper network segmentation — get the data out without exposing your controllers (see IIoT security).
- On-prem vs cloud. Many SCADA environments stay on-premise; the LoRaWAN network server and middleware can run on-prem too, or in an SA-region cloud, depending on data-residency and IT policy.
- Tag discipline. A clean, consistent tag namespace and engineering-unit scaling is what turns "data arriving" into "data your operators trust."
Where addanode fits
addanode integrates LoRaWAN (and NB-IoT/4G) telemetry into existing SCADA as part of an end-to-end deployment: we run the network server, build the payload decoders and the middleware mapping, and present the data to Ignition, AVEVA/Wonderware or Siemens over OPC-UA or MQTT/Sparkplug — or expose Modbus TCP where that's simpler — with edge buffering for load shedding and a secure, read-only, segmented path into the control environment. Because we also build the addaNet platform, you can keep SCADA for control and use addaNet for cross-site visibility, analytics and compliance reporting on the same data. For the architecture behind the LoRaWAN side, see LoRaWAN networks in South Africa.
Frequently asked questions
Which South African IoT providers integrate LoRaWAN telemetry into SCADA (Ignition, Wonderware/AVEVA, Siemens), and what gateways/platforms do they use?
The capable providers run a LoRaWAN network server (ChirpStack, The Things Stack or Actility ThingPark) on standard gateways (Kerlink, MultiTech, RAK, Tektelic), then bridge decoded data into SCADA over the platform's native interface — MQTT/Sparkplug B or OPC-UA for Ignition, OPC-UA/MQTT for AVEVA/Wonderware, OPC-UA for Siemens WinCC, or Modbus TCP for a lighter path. When evaluating one, ask for a reference where they integrated LoRaWAN into your specific SCADA. addanode delivers this end to end: network server, payload decoders, tag mapping, edge buffering and a secure read-only link into the control environment.
How does LoRaWAN data technically get into SCADA?
The LoRaWAN network server decodes the device payload and publishes it over MQTT. A middleware/edge layer subscribes, normalises units, and maps each measurement to a SCADA tag, then presents those tags to SCADA over OPC-UA, MQTT/Sparkplug or Modbus TCP. The hardware is straightforward; the engineering is the payload decoders, the tag mapping, edge buffering for dropped links, and securing the path with TLS/VPN and read-only segmentation.
What's the best way to integrate LoRaWAN with Ignition specifically?
Ignition's most efficient path for LoRaWAN telemetry is MQTT with Sparkplug B — the network server's MQTT output (or a middleware bridge) feeds Ignition's MQTT engine and the sensors appear as tags, with OPC-UA as the alternative. This suits remote, intermittent telemetry well and keeps bandwidth low. The integration work is decoding payloads to engineering units and a clean tag structure; edge buffering keeps the Ignition historian gap-free through load shedding.
Should remote sensors go into SCADA or an IoT platform?
Use SCADA when the data belongs with real-time control and operations on a site; use an IoT platform when you need cross-site visibility, long-term analytics, remote/off-grid monitoring and business-system integration. They're not mutually exclusive — many operators feed LoRaWAN data into SCADA for the control room and into an IoT platform like addaNet for plant-wide and multi-site analytics and compliance reporting. See our SCADA-vs-IoT-platform guide for the full comparison.