Protocols
Eleven field protocols, and the honest validation status of each
This page is useful not because the driver list is long, but because it tells you which drivers have met a real device. Mature drivers and brand-new ones are marked differently; putting them on the same footing only wastes your evaluation time.
How the field connection works
Field drivers run in a separate process (ScadaRuntime), not inside the web application. That split maps onto the IEC 62443 zone and conduit model: restarting the web server does not interrupt field polling, and a fault in the user interface does not drop a PLC connection.
Every connection runs its own loop, with its own scan interval (1,000 ms by default), its own state and its own error counters. One unresponsive device does not stall the others.
Each raw value is scaled and offset, passed through a deadband filter and published onto the live data path. If that path is briefly unavailable, values accumulate in an in-memory store-and-forward buffer and are drained in order once it recovers. The buffer is bounded; when it fills, the oldest entry is dropped — we chose that over unbounded growth.
Driver matrix
The read and write columns describe what the code can do. The validation column describes what has actually been on the other end of the wire — the two are not the same thing.
| Protocol | Read | Write | Validation status | Typical use |
|---|---|---|---|---|
| Modbus TCP | Yes | Yes | Compile only | PLCs, power analysers, drives, smart meters |
| Modbus RTU | Yes | Yes | Compile only | Meters, drives and devices on an RS-485 bus |
| Modbus RTU over TCP | Yes | Yes | Compile only | Devices behind a serial-to-Ethernet gateway |
| OPC UA (client) | Yes | Yes | Compile only | Reading from an existing OPC UA server, including vendor UA servers |
| Siemens S7 | Yes | Yes | Compile only | Direct ISO-on-TCP link to S7-300/400/1200/1500 |
| MQTT | Yes | Yes | Compile only | Remote sites, cellular links, IIoT gateways |
| EtherNet/IP | Yes | Yes | Compile only | Allen-Bradley and compatible PLCs, tag-name addressing |
| IEC 60870-5-104 | Yes | Yes | Compile only | RTU telemetry in power and water infrastructure |
| DNP3 | Yes | Yes | Compile only | Distribution grid and infrastructure outstations |
| BACnet/IP | Yes | Yes | Compile only | Building automation: HVAC, boilers, lighting |
| IEC 61850 (MMS) | Yes | Yes | Compile only | Substations, protection relays and other IEDs |
| Simulation | Yes | Yes | Laboratory | Hardware-free demos, training, screen and alarm testing |
The DNP3, BACnet/IP and IEC 61850 drivers were read-only for a long time; write support was added in this release and has not yet been validated against a real device. For those three we recommend starting a pilot read-only. This table is updated whenever a driver's status changes.
What the three validation levels mean
Only these three values are used in the column. There is no intermediate grade — an intermediate grade ends up making every row look like it works.
Field verified
The driver has read from and written to a real device in a real installation. Disconnects, reconnects and bad addresses have been observed on site. None of our drivers is at this level today — the field validation campaign is on our roadmap and begins with the first pilot installations.
Laboratory
The driver has been run against a simulator or a test harness. The protocol exchange behaves correctly, but it has not met a real field device, so vendor-specific implementation quirks would not have surfaced.
Compile only
The code compiles against the protocol library and address parsing is covered by unit tests. There has been no real device on the other end yet. These rows are a roadmap, not a commitment.
The OPC UA server — separate from the client
OPC UA (client) in the table above means we read from someone else's server. The reverse also exists: the embedded OPC UA server lets an MES, ERP, LIMS or another SCADA pull data from us. The endpoint is opc.tcp://server:4840/BellaScada.
This server ships disabled by default and is enabled during commissioning. The reason is a principle: an unused network listener stays closed. When you do enable it, the defaults are not permissive — the table below shows what applies when you change nothing after installation.
Writing to the field does not happen over this channel. The command path is the authenticated REST endpoint, where permission checks, command approval and the audit trail live. The OPC UA server is designed as a read window, not as a second control door.
OPC UA server security defaults
These are the values that apply when nothing is changed after installation. Looser options exist, but each has to be turned on deliberately.
| Setting | Default | Note |
|---|---|---|
| The server itself | Disabled | Enabled during commissioning |
| Security policy | Basic256Sha256, sign and encrypt | Unsigned None is only added through an explicit relaxation setting |
| Anonymous access | Disabled | Username and password required; the identity token travels over the encrypted channel |
| Untrusted client certificate | Rejected | No auto-accept; an operator moves the certificate into the trust store by hand |
| SHA-1 signed certificates | Rejected | Minimum key size 2048 bits |
| Certificate store | Persistent application data directory | Not a temporary directory, so clearing temp does not change the server identity |
| Writes to the field | Not available | The command path is the REST endpoint, with permissions and audit |
| Under redundancy | Only the active node listens | The standby node does not attempt to open the same port |
If a legacy client can only connect unsigned, the relaxation setting can be enabled. When you do that, it has to be recorded as residual risk in the compliance dossier; our commissioning checklist carries that item.
UNS and Sparkplug B
UNS (Unified Namespace) publishing writes live tag values to an MQTT broker as retained JSON on a hierarchical topic structure ({prefix}/{device}/{tag}). That makes the SCADA a participant in the single namespace your MES and analytics teams subscribe to. Adding a new consumer requires no work on the SCADA side.
Sparkplug B is a separate publisher and speaks protobuf rather than JSON. The SCADA acts as an Edge Node: NBIRTH on connect (all tags plus bdSeq), NDATA on each update, and an NDEATH will message published by the broker when the link drops. Topics follow spBv1.0/{group}/{type}/{node}.
Both ship disabled by default. And to be straight about it: Sparkplug interoperability has not been validated against a real host application (Ignition, HiveMQ and the like). Where Sparkplug is critical to a project, we put that validation into the commissioning scope and test it together with the host side.
Your protocol is not on the list?
A protocol missing from the table is not an automatic no. Here is how we handle it.
One interface, one registration line
Every driver implements the same interface: connect, read, write, report state. Adding a protocol touches no existing driver — it adds a single line to the driver factory. A new driver therefore does not put the protocols of a running installation at risk.
We have not measured the effort, so we do not guess
We have no measurement of driver development time that we would be willing to publish. A protocol with a mature, widely used library is markedly quicker; a proprietary, undocumented one is slow. A concrete figure comes only after we see the protocol name and the device family.
Validation needs a device
The only way to lift a driver above the "compile only" level is a real device — or a trustworthy simulator — on the other end. Either you provide it or we source it; either way it becomes a visible line item in the project.
Acceptance criteria stay in the contract
On work involving a new driver we write the site acceptance test into the contract: which points get read, which commands get written, which fault conditions get exercised. That way the claim that it works rests on a list both sides signed.
Frequently asked
How many protocols can run at the same time?
There is no limit on protocol count in the code. Each connection runs in its own loop, so one installation can poll a PLC over Modbus TCP, another over S7 and a remote site over MQTT simultaneously. We have measured it: at 20,000 tags there was no queue overflow and no data loss. The ceiling is not the tag count but the refresh rate: the poll loop takes 1.2 s at 1,000 tags, 6.3 s at 5,000 and 26 s at 20,000. So 20,000 tags work, but they do not refresh once per second. If your tender specifies a minimum tag count, state the refresh rate you need alongside it — the two only mean something together.
How do serial devices (RS-485 / RS-232) connect?
Two ways. If the server sits on site, the Modbus RTU driver uses the serial port directly (COM3, /dev/ttyS0), with baud rate, parity, data bits and stop bits set on the connection. If the server is remote, a serial-to-Ethernet gateway is used and the connection is defined as Modbus RTU over TCP — the framing stays RTU, the transport becomes TCP.
What does it mean that a driver is "not validated"? Does it not work?
It does not mean it fails; it means we cannot claim it works. The code compiles against the protocol library and address parsing is covered by unit tests, but without a real device on the other end you never see vendor-specific implementation differences, timing behaviour or error responses — and those are usually exactly what breaks a commissioning. That is why we do not label those rows field verified.
Can I write to a field device over DNP3, BACnet or IEC 61850?
The code supports writing on all three; write support was added in this release. It has not been validated against a real device. Our recommendation is to start the pilot read-only and enable writing under control during the site acceptance test. Where control is critical, a validation plan is agreed before commissioning.
Is there an extra licence fee per protocol?
All eleven protocols are included in the Plant and Critical Plant packages; there are no modules to buy. The Machine / Edge package covers a single connection and you choose the protocol. See the pricing page for details.
See it on your own plant
We open a working demo environment with no hardware to install and no licence to wait for. Tell us which protocol is on your floor and we will prepare an example that speaks it.