IoT DC3: A Java Industrial IoT Platform with 36 Protocol Drivers and an LLM Agent Center

The problem IoT DC3 solves, and who it is built for

Industrial sites accumulate protocols. A plant floor may run Modbus TCP on one line, OPC UA on another, Siemens S7 on a third, and a DLMS or DLT645 meter somewhere in the power distribution room. Each protocol has its own client library, its own addressing model, and its own idea of what a data point is. The usual outcome is a set of one-off scripts and a database that nobody wants to touch. IoT DC3 targets that situation by treating protocol connectivity as a set of replaceable driver modules behind a common platform, so the device model, the data pipeline and the access control do not change when a new protocol appears.

The README lists 36 access driver modules grouped into industrial protocols (Modbus TCP and RTU, OPC UA and DA, Siemens S7, BACnet/IP, EtherNet/IP, Omron FINS, Mitsubishi MELSEC, IEC 60870-5-104, IEC 61850, DNP3, DLMS, DLT645, KNX, M-Bus, SL651), IoT protocols (MQTT, CoAP, LwM2M, HTTP, BLE, Zigbee, LoRaWAN), data bridging (MySQL, PostgreSQL, Oracle, SQL Server, Redis), basic communication (TCP/UDP, Serial, SNMP, CAN, Kafka) and simulation modules. That list is the product's main claim. The audience is therefore engineers who already know which protocol they are dealing with and want the surrounding platform handled: device registry, point read and write, edge-to-cloud delivery, multi-tenancy, and an operations interface.

The secondary audience is narrower. The repository describes an evolution toward AI agents, with an agentic center built on Spring AI. That points at teams who want natural-language queries over device data, or LLM-assisted alarm triage, and are willing to run that alongside the connectivity layer rather than in a separate tool. If you only need a protocol converter, the AI layer is weight you are carrying for no reason.

Six layers, four center services, and a driver count that is really a runtime contract

The architecture image in the README lays out the flow: clients reach a gateway, the gateway fronts four center services, those services talk over a message bus, the bus reaches the protocol drivers, and the drivers reach field devices. Persistence is PostgreSQL with three extensions, TimescaleDB for time-series, pgvector for embeddings, and AGE for graph. Observability is optional and consists of ELK, Prometheus and Grafana.

The four center services are not named individually in the supplied material, so their exact division of labour cannot be confirmed here. What is stated is the design discipline around them. Cross-service calls always go through Facade interfaces, which keeps a service's internal API from leaking into callers. The DO/BO/VO three-tier model separates persistence shape, business shape and API shape, so a database column rename does not become a breaking API change. Tenant isolation is described as running end to end across database, cache and API paths, which is the harder version of multi-tenancy: not a tenant column on one table, but a consistent boundary through every layer.

Service-to-service communication uses gRPC with Proto definitions, while Spring Cloud Gateway is the single entrypoint with static routes and environment-variable overrides. That combination is conventional for Spring Cloud shops and means the operational surface is familiar: a gateway config, a registry, and generated gRPC stubs. The cost is that you are running a distributed system with a message bus in the middle, not a single binary. For a two-device prototype that is overkill. For a site with several protocol families and more than one team touching the data, the boundary is the point.

The driver count matters less than the Driver SDK. The README states that the SDK supports developing custom protocol drivers and registering them into the running platform. That is the real extensibility claim: a protocol not on the list of 36 is supposed to be addable without forking the platform. Whether the SDK documentation is sufficient to do that in practice is not something the README establishes.

Getting it running: the shape of a deployment

The supplied README does not include a quickstart block, so exact commands cannot be quoted from it. What can be stated is the dependency envelope the badges and architecture description imply. The project targets Java 21 and Spring Boot 4, with Spring Cloud 2025 for the microservice layer. A working deployment therefore needs a JDK 21 runtime, and because the architecture names PostgreSQL with TimescaleDB, pgvector and AGE, it needs a PostgreSQL instance with those three extensions available. That is not the default PostgreSQL build on most managed database services, so provisioning is a real step rather than a checkbox.

The gateway is configured with static routes and environment variables, according to the README. That means the entrypoint routing is declared rather than discovered, and environment-specific values are expected to be injected at deploy time. The observability stack (ELK, Prometheus, Grafana) is described as optional, so a minimal run does not require it.

For anything beyond reading the source, the README points at two external resources: the documentation site at docs.dc3.site, including a System Architecture Overview page, and the project homepage at dc3.site. There is also a README.ai.md file that the README explicitly tells AI assistants to read first for a concise overview. That file is the most likely place to find a condensed setup path, and it is worth reading before the main README because the main README is organised as a feature tour rather than an installation guide.

The honest summary is that this is a platform you deploy, not a library you add. Budget for database extensions, a message bus, and a gateway before the first device point moves.

The AI agent center is the least verifiable part of the pitch

The agentic center is built on Spring AI and connects LLMs into operations workflows. The README lists five capabilities: natural-language assisted operations through Tool Calling under access control, so an LLM can query devices and read or write points; intelligent alarm analysis with root-cause suggestions; data insights that query device data in natural language and generate charts; multi-model support for OpenAI API-style providers including GPT, Claude, DeepSeek and Qwen; and conversation memory persisted to the database.

The access-control qualifier is the important one. An LLM that can write to points on industrial equipment is a different risk category from one that answers questions about them. The README says Tool Calling operates under access control, which suggests the existing permission model gates the tools. It does not describe what happens when a model selects the wrong point, or how a write is confirmed before it reaches a PLC. Those are the questions an integrator will ask first, and the supplied material does not answer them.

There is also a maturity question. The README frames the project as evolving toward AI agents, and the release cadence shows three releases dated 2026.8.17, 2026.8.18 and 2026.8.19 all published within minutes of each other on 2026-08-19. That pattern is consistent with automated or batch publishing rather than three independent development milestones. It tells you releases are frequent; it does not tell you the AI layer is stable. Treat the agent center as the component to pilot on read-only queries before you let it near a write path.

Where IoT DC3 is the wrong tool

The most concrete limitation is stated in the repository metadata rather than the README. The licence field reads NOASSERTION, while the README badge says AGPL 3.0. GitHub uses NOASSERTION when it cannot match the repository's licence files to a known SPDX identifier. The likely explanation is a modified or supplemented AGPL 3.0 text, but that is an inference, not a fact from the material. Anyone planning to embed this platform in a product, or to expose a modified version as a network service, needs to read the actual LICENSE file and get their own legal review. This article cannot resolve that, and the discrepancy is a real adoption blocker for some organisations.

Second, the architecture is heavy by design. A single-site installation with three Modbus devices gains little from four center services, a message bus, a gateway and a PostgreSQL instance with three extensions. A single-process gateway such as Node-RED, or a library-level approach with pymodbus or Eclipse Milo, will be faster to stand up and easier to debug for that case.

Third, IoT DC3 is not a SCADA HMI. The screenshots show a platform dashboard, a device management list and an AI chat page. There is no mention of alarm acknowledgement workflows, historical trending with operator annotations, or the redundancy features a control room expects. If your requirement is an operator console with shift handover notes, this is not that product, and the driver list will not compensate.

Fourth, the bus in the middle is a failure domain. The README does not describe buffering or store-and-forward behaviour when the message bus or the persistence layer is unavailable, so whether field data survives an outage of the center services cannot be confirmed. In an industrial setting that is usually the first question asked.

Alternatives and the actual difference in approach

The closest architectural comparison is Eclipse Ditto plus Eclipse Hono. Hono handles protocol adaptation and device connection over AMQP and MQTT, and Ditto provides the digital twin layer with a JSON-based thing model and change notifications. The difference from IoT DC3 is where the protocol logic lives. Hono's protocol adapters are a smaller set focused on IoT messaging standards, and industrial fieldbus protocols are typically bridged in by an external gateway. IoT DC3 puts 36 drivers, including the fieldbus protocols, inside the platform itself and gives you a Driver SDK to add more. If your estate is mostly MQTT and you want a twin abstraction, Ditto and Hono fit better. If your estate is Siemens S7, IEC 60870-5-104 and DLT645, IoT DC3 addresses the harder half of the problem directly.

A second comparison is Apache PLC4X. PLC4X is a Java library for industrial protocols, with drivers for many of the same fieldbus families. It is a library, not a platform: you write the service, the device registry, the storage layer and the access control yourself. IoT DC3 is what you get if you decide not to write those. The trade is control for speed. PLC4X also has a permissive licence, which matters if AGPL 3.0 is unacceptable for your distribution model.

A third option is to skip the platform entirely and use protocol-specific clients with a time-series database. That works until you have four protocols and two teams, at which point the shared device model and the tenant boundary in IoT DC3 start paying for themselves. The decision point is the number of protocol families you expect to support over the next two years, not the number you have today.

Maintenance cost, licence implications, and what to verify first

Maintenance cost here is dominated by the runtime footprint, not the code. You are operating a Spring Cloud 2025 microservice set, a gRPC mesh, a message bus, a gateway, and PostgreSQL with TimescaleDB, pgvector and AGE. Upgrades mean coordinating Spring Boot and Spring Cloud versions across services, and the release history shows frequent tagged releases, so there is a steady stream of versions to evaluate. The optional ELK, Prometheus and Grafana stack adds operational work that is easy to defer and hard to add later.

On licence, the README badge says AGPL 3.0 and the repository metadata says NOASSERTION. AGPL 3.0 requires that users interacting with a modified version over a network be offered the corresponding source. For internal industrial deployments that obligation is often manageable; for a product where the platform is embedded and exposed to customers, it changes the commercial calculus. Because the metadata does not confirm a standard AGPL 3.0 file, verify the LICENSE contents directly rather than relying on the badge. This is not legal advice; it is a pointer to the one file that decides whether you can use this at all.

Before deploying, verify three things. First, the licence file itself. Second, that the specific driver for your protocol is implemented and exercised, not merely listed, since a name in a table is not evidence of a working adapter. Third, whether the AI agent center is positioned as production-ready or as preview, and if it is the latter, restrict it to read-only tool calls until you have tested its behaviour against your own point namespace. The documentation at docs.dc3.site and the README.ai.md file are the places to start, because the main README is a feature inventory and will not tell you what is unfinished.

Editorial conclusion

Adopt IoT DC3 if you need a Modbus, OPC UA, IEC 61850 or DLT645 gateway behind a Spring Cloud stack and can accept AGPL 3.0 terms. Do not adopt it if you need a vendor SLA, a permissively licensed codebase, or a turnkey SCADA HMI. Before deploying, confirm the exact licence text behind the NOASSERTION label, verify that the driver for your protocol is functional rather than listed, and check whether the AI agent center is a supported component or a preview.

Official sources

1. Issues
2. pnoker/iot-dc3 on GitHub
3. Project website
4. README
5. Releases