The industrial protocol stack landscape

Nobody connects a plant, a substation or a building with one library. Every integration leans on stacks written by other people: a C library in a gateway, a Python tool on a laptop, a Java server in a SCADA system, a vendor SDK inside a controller. OT Fabric only makes sense as part of that ecosystem, which is why each of our protocols ships with an interop suite that tests against the established implementations.

So we mapped the ecosystem. This post is the research: ten protocol families, 134 implementations, and what we learned checking every one of them against its own release channel. The interactive version lets you pick a protocol, filter by language, licence and activity, and jump straight to the source.

134 implementations · 10 protocolsExplore the interactive ecosystem mapFilter by language, licence and activity, then jump straight to the source.→

How we counted

We sort every implementation into one of four groups, because a flat list of repositories hides how the ecosystem actually fits together:

• Independent stacks handle the protocol themselves.
• Derived libraries and bindings wrap, port or extend another stack. They link to their upstream instead of counting as a new engine.
• Commercial SDKs are proprietary or dual-licensed developer libraries, including those without public source.
• Legacy and reference code is historically important but superseded or no longer maintained.

Each entry records its language, licence (as an SPDX expression, read from the licence file, or the licence’s own name where it has no SPDX identifier), protocol roles, documented capabilities, latest release, last commit, stars and forks, and the OT Fabric interop suite that exercises it, if any. Every entry also lists its sources and the date we last verified it.

GitHub Releases are the wrong place to look

The first draft of this inventory took versions from GitHub Releases. Checking each project against the channel it actually publishes to changed a third of the version column:

• NModbus has no GitHub Release objects, but publishes 3.0.83 on NuGet (April 2026).
• jsmodbus shows v2.0.1 as its GitHub Release; npm has 5.0.0, published in September 2026.
• Modbus4J is at tag v3.1.0, ahead of its old 2.x GitHub Release.
• BACnet Stack releases on SourceForge (1.6.1, August 2026), not as GitHub Releases. The project dates back to 2004; the GitHub repository only to 2019.
• BACpypes3 is at 0.0.110 on PyPI and System.IO.BACnet at 4.0.0 on NuGet. Its MIT licence, unclear in the first pass, is confirmed.
• tokio-modbus (0.17.0), simonvetter/modbus (v1.6.4) and NModbus tag and publish without creating GitHub Releases.
• The EPRI OpenADR reference code is BSD-3-Clause throughout; two licences had been left open.

The registry now names the source of every version: GitHub, PyPI, npm, crates.io, NuGet, Maven Central, pub.dev, SourceForge, the Go module proxy or a vendor’s release notes.

Modbus

Very mature. The broadest open-source ecosystem in OT, from microcontrollers to cloud services. Modbus TCP versus serial is a capability, not a separate implementation, and so is client-only versus client and server.

libmodbus, PyModbus, NModbus, digitalpetri/modbus and tokio-modbus are the reference implementations in our modbus-interop suite. goburrow/modbus and ModbusMaster are still widely used but have not changed since 2016 to 2018. On the commercial side, Triangle MicroWorks sells Modbus source libraries, and Modbus4J is dual-licensed by Radix IoT.

OPC UA

Very mature, with a strong commercial market. OPC UA lets you compare independent open source, foundation-backed code and proprietary SDKs side by side. Client/server and PubSub are separate capabilities, and no stack covers every security profile, transport and information model.

open62541, Eclipse Milo, the OPC Foundation .NET stack, node-opcua and the FreeOpcUa family are the essential open-source references. Two lineages are worth knowing: python-opcua is deprecated in favour of opcua-asyncio, and the Rust code base started by locka99/opcua continues as async-opcua. Unified Automation, Prosys and Softing are the established commercial SDK vendors. OpenOpcUa CoreServer, the native C/C++ runtime behind 4CE Industry’s OOUAMiddleware, takes another route: closed source, but free to deploy without licensing fees.

134 implementations · 10 protocolsSee the OPC UA lineages on the mapFilter by language, licence and activity, then jump straight to the source.→

BACnet

Mature, but fragmented. BACnet/IP, MS/TP, BACnet/SC and the device profiles make very different demands, so “BACnet supported” on its own says very little. The map records which data links each stack documents.

BACnet Stack stands out: extensive service coverage, embedded targets, and a GPL linking exception that lets proprietary products link it. BACpypes3, BACnet4J and System.IO.BACnet (the stack behind YABE) complete the reference set, and all four run in bacnet-interop. BACpypes3 now also ships an MCP server, so AI agents can talk BACnet. Cimetrics, PolarSoft and SoftDEL lead the commercial SDK market.

IEC 60870-5-104

Specialized. A handful of credible engines, with bindings and forks built on top of them, which is exactly where the relationships matter.

The independent engines are lib60870, OpenMUC j60870 and go-iecp5. The Python package c104 binds lib60870; wendy512/iec104 builds on a go-iecp5 fork. The original go-iecp5 was archived in March 2023 and lives on in two maintained forks. j60870 is distributed through OpenMUC and Maven Central (1.8.0) rather than a GitHub repository. MZ Automation, OpenMUC and Triangle MicroWorks offer commercial licences.

IEC 61850 and MMS

Specialized, with few comprehensive implementations. IEC 61850 is not just MMS: it adds information models, GOOSE, Sampled Values and SCL. A stack that only speaks MMS is not an IEC 61850 stack.

libiec61850 is the dominant open-source reference: MMS client and server, GOOSE, Sampled Values, reports, datasets, logging, file services and TLS, with commercial licences from MZ Automation. IEC61850bean (formerly OpenIEC61850) is an established Java MMS implementation, quiet since 2023. dscsystems/go-iec61850 is three months old and worth watching.

Siemens S7

Mature for classic S7comm, constrained beyond it. Talking to an S7-300 over ISO-on-TCP is not the same as talking to an S7-1500 with optimized data blocks and access protection. S7comm and S7commPlus are separate branches on the map.

Snap7 is distributed on SourceForge; the popular GitHub repository under SCADACS is a fork with server extensions, not the canonical source. python-snap7 is no longer a wrapper: since 3.0 (March 2026) it implements TPKT, COTP and S7 natively in Python. Apache PLC4X counts stars for its whole multi-protocol framework. The new s7commplus project opens the S7-1200/1500 branch. Softing siAccess, successor to ACCON-AGLink, and PLCcom for S7 are the commercial options.

OpenADR

Smaller and still evolving. OpenADR 2.0b and 3.x are different technologies, and 3.1 is not backward-compatible with 3.0, so the map separates versions and roles: VEN, VTN and business logic.

OpenLEADR covers both generations: Python for 2.0b, Rust for 3.1, where its README is upfront that subscriptions (webhooks) are not supported yet. ElaadNL’s openadr3-client comes from an organization that builds EV charging infrastructure. The EPRI projects are legacy references; EPRI has discontinued support. The OpenADR Alliance’s reference implementation is not publicly available, so it is not on the map, and we found no standalone commercial OpenADR SDKs comparable to other protocols. That branch stays open for verified submissions.

OCPP

Mature for 1.6J, maturing for 2.x. OCPP 2.0.1 is not backward-compatible with 1.6, while 2.1 extends 2.0.1, so a claim of “OCPP support” says little without the version. The map lists versions and roles: the charging station and the CSMS.

The open-source side is broad, with libraries in Python, Java, Go, C++, Rust, JavaScript, C# and Kotlin. Five of them run in ocpp-interop: The Mobility House ocpp, ChargeTimeEU Java-OCA-OCPP, ocpp-go, EVerest libocpp and CitrineOS. libocpp’s own repository is archived; it now lives inside EVerest, the LF Energy charging station stack. SteVe and OCPP.Core are complete CSMS products rather than libraries, and MicroOcpp brings the station side to microcontrollers. Commercial stacks are sold for both sides, though versions and platforms are rarely published.

DNP3

Mature, with few active open stacks. DNP3 (IEEE 1815) has been the SCADA protocol of North American utilities for three decades, and the commercial side is well established: source code libraries from Triangle MicroWorks, FreyrSCADA and others run inside many RTUs and IEDs. The open-source side has thinned out.

opendnp3, for a decade the default open-source stack, was archived in September 2022 at 3.1.2, and still sits under the Python bindings pydnp3, VOLTTRON’s dnp3-python and the new yadnp3 fork. Step Function I/O’s Rust library, with C, C++, .NET and Java bindings, is actively maintained, but its licence allows non-commercial, non-production use only, with a commercial licence for production: the map files it under its own licence family, source-available. The rest is young: DSC Systems’ go-dnp3 (GPL-3.0) and cB-Sigma’s dnp3 (Apache-2.0) are pure Go stacks from 2026, both with Secure Authentication, and dnp3py brings a pure Python master and outstation with a MESA DER profile. Four of them run in dnp3-interop: Step Function I/O, opendnp3, DSC go-dnp3 and dnp3py. The Triangle MicroWorks adapter is on hold until its licensed source has an agreed way into the builds.

IEEE 2030.5

Young, and shaped by two mandates. IEEE 2030.5 (Smart Energy Profile 2.0) carries export limits, schedules and prices from utilities and aggregators to inverters, batteries and chargers. California’s Rule 21 made it the default for smart inverters through CSIP, and Australian distributors use CSIP-AUS for dynamic operating envelopes, so most of the open field is a research lab’s, a utility programme’s or one developer’s answer to one of those two profiles.

The Australian side is the most active: ANU’s Envoy is a complete CSIP-AUS utility server, with its document models and the CACTUS test harnesses built around it, and open-dynamic-export is a CSIP-AUS client that drives home solar and batteries. In the US, PNNL’s GridAPPS-D, whose Python server never got past alpha releases, published a Go server and client in 2026, DER Security’s py20305 is a new client for CSIP and CSIP-AUS, and VOLTTRON has an agent that connects its devices to a server. The EPRI client, written for California’s certified open-source programme, is the oldest open stack and has not changed since 2018. Four of them run in ieee20305-interop: Envoy, GridAPPS-D (server and client), py20305 and the EPRI client. Commercially, embedded clients such as Kitu’s sit next to the test systems that certification runs on, and few vendors publish versions.

The picture across protocols

Protocol	Open source	Commercial SDKs	Primary references
Modbus	Very mature	Established	libmodbus, PyModbus, NModbus, Modbus4J, tokio-modbus
OPC UA	Very mature	Very established	open62541, OPC Foundation .NET, Eclipse Milo, node-opcua, FreeOpcUa
BACnet	Mature, fragmented	Very established	BACnet Stack, BACpypes3, BACnet4J, System.IO.BACnet
IEC 60870-5-104	Specialized	Established	lib60870, OpenMUC j60870, go-iecp5
IEC 61850 / MMS	Specialized	Established	libiec61850, IEC61850bean
Siemens S7	Mature for classic S7	Established	Snap7, S7NetPlus, python-snap7, Apache PLC4X
OpenADR	Smaller, evolving	Not transparent	OpenLEADR (Python and Rust), ElaadNL
OCPP	Mature for 1.6J, maturing for 2.x	Established	The Mobility House ocpp, Java-OCA-OCPP, ocpp-go, EVerest libocpp, CitrineOS, SteVe
DNP3	Mature, few active open stacks	Very established	opendnp3 (archived), Step Function I/O dnp3 (source-available), DSC go-dnp3, dnp3py
IEEE 2030.5	Young, growing, profile-driven	Certification-driven	Envoy, GridAPPS-D, py20305, EPRI client (unmaintained)

These are judgements about maturity and visibility, not measured conformance, security or quality. Our interop suites are where we test behaviour; this map is where we record who is out there.

Help us complete it

This is a strong baseline, not an audited directory. We know it misses implementations outside GitHub, commercial SDK details (versions, platforms, evaluation editions) and capability evidence beyond what each README claims.

The whole map is one JSON file, src/data/ecosystem.json, with sources and a verification date on every entry. Open a pull request to add a stack, a commercial SDK, a correction or interop results, and the map updates when it merges. Maintainers are especially welcome to check their own entries.

134 implementations · 10 protocolsOpen the ecosystem mapFilter by language, licence and activity, then jump straight to the source.→