IoT DC3: Industrial IoT Platform with 36 Protocol Drivers and MCP Agent Gateway

Decoupling Devices from Applications with a Unified Message Bus

Industrial IoT deployments typically hardwire device connectivity to specific applications: the data pipeline for one PLC is different from the one for another, and adding a new sensor requires modifying both the driver layer and the application layer. IoT DC3 addresses this by placing a message bus between all drivers and all applications.

Drivers push normalized point data into the internal message bus. Applications consume that data through a single unified API. Adding a new device means deploying a new driver; changing an application does not affect the drivers. The README describes this as the core design principle: devices are decoupled from applications. This matters for industrial environments where device inventories change independently of the software systems that consume their data.

The platform targets teams building industrial IoT systems that span device connectivity, data acquisition, edge-to-cloud delivery, and operations. The six-layer microservice architecture separates clients, a gateway, four center services, the message bus, the 36 protocol drivers, and field devices.

36 Protocol Drivers Covering Industrial Automation, IoT, and Data Sources

IoT DC3 ships with 36 access driver modules organized into five categories. Industrial automation protocols include Modbus TCP, Modbus RTU, OPC UA, OPC DA, Siemens S7, BACnet/IP, EtherNet/IP, Omron FINS, Mitsubishi MELSEC, IEC 60870-5-104, IEC 61850, DNP3, DLMS, DLT645, KNX, M-Bus, and SL651. IoT communication protocols include MQTT, CoAP, LwM2M, HTTP, BLE, Zigbee, and LoRaWAN. Data bridging drivers cover MySQL, PostgreSQL, Oracle, SQL Server, and Redis. Basic communication covers TCP/UDP, Serial, SNMP, CAN, and Kafka. Simulation and debugging drivers allow testing without physical hardware.

A Driver SDK supports the development of custom protocol drivers that register into the platform runtime. This matters in practice because industrial environments often include proprietary or niche protocols not covered by the bundled set. The SDK path means teams can add custom drivers without forking the core platform.

Architecture Design Principles and Persistence Layer

The IoT DC3 README documents three design principles enforced across the microservice boundary. First, cross-service calls always go through Facade interfaces, which keeps service contracts explicit and prevents services from bypassing each other's API layers. Second, the DO/BO/VO three-tier model separates persistence objects (DO), business objects (BO), and API response objects (VO), so the database schema, the business logic, and the external API shape are independently changeable. Third, tenant isolation runs end to end across the database, the cache layer, and the API paths.

The persistence stack is PostgreSQL with three extensions: TimescaleDB for efficient time-series storage and historical queries, pgvector for embedding storage used by the AI assistant, and Apache AGE for graph queries. This combination means the platform can store device telemetry as time-series data, run embedding similarity searches for the AI query path, and represent device topology as a graph, all within the same PostgreSQL instance. The README documents an optional observability stack of ELK for log aggregation, Prometheus for metrics collection, and Grafana for dashboards.

The cloud-native layer uses Spring Cloud Gateway as the single external entrypoint with static routes and environment-variable configuration. Internal service calls use gRPC with Protobuf serialization rather than REST, which reduces serialization overhead on high-frequency inter-service paths. All services are stateless by design, so individual services can be scaled horizontally by workload without coordinating session state.

Deploying IoT DC3 and Running the First Instance

IoT DC3 uses a multi-stage Dockerfile with a Maven build stage and a minimal JRE runtime stage. The recommended approach for local development uses Docker Compose from the repository root. Environment variables are defined in .env.example and the runtime-specific dev.env file.

Key default values from .env.example include the PostgreSQL connection, which defaults to localhost:35432 with database name dc3, and the message broker selection:

DC3_MQ_TYPE=rabbitmq

The default message broker is RabbitMQ, but the .env.example documents alternatives:

# One of: rabbitmq (default) | kafka | rocketmq | pulsar | activemq | mqtt
DC3_MQ_TYPE=rabbitmq

A single service image can be built with:

podman build --target dc3-gateway -t pnoker/dc3-gateway:dev .

The Dockerfile comments note that BuildKit reuses the Maven builder stage cache across service targets, so building multiple service images does not re-run Maven from scratch. The make commands in the Makefile cover the full lifecycle from local dev to stack deployment.

The .env.example explicitly flags two secrets that must be set for any network-exposed deployment: DC3_SECURITY_KEY and AUTH_HMAC_SECRET. The file notes that the application/scale/swarm Compose stacks refuse to start without these values, and the pre/pro profiles additionally reject blank or publicly known values at startup.

AI Agent Integration via the MCP Tool Gateway

IoT DC3 includes an Agentic Center built on Spring AI. The platform exposes an MCP (Model Context Protocol) tool gateway that allows external AI agents to interact with physical devices under a controlled authorization model. The README describes the mechanism as OAuth client registration, per-tool authorization, and a full audit trail for every tool call.

Through this gateway, AI agents can query device point data in natural language, read or write device values through Tool Calling, receive AI-assisted alarm analysis, and generate charts from device data queries. The platform supports OpenAI API-compatible model providers including GPT, Claude, DeepSeek, and Qwen, configured through the standard Spring AI provider interface. Multi-turn conversation context is persisted to the database.

This architecture means the same platform that handles low-level Modbus TCP reads can also answer a natural-language question about which devices are offline, without requiring a separate AI infrastructure layer.

License Structure and Operational Constraints

IoT DC3 uses a dual license structure. The core platform is released under the GNU Affero General Public License v3 (AGPL-3.0), which requires that any modifications to the software be released under the same license when the software is provided as a network service. The repository also includes a separate LICENSE.txt, indicating that some components may carry different terms.

AGPL-3.0 has practical implications for commercial deployments: any company that runs a modified version of IoT DC3 as a service must make their modifications publicly available. Teams using the platform as-is without modification have fewer obligations, but legal review is advisable before production deployment.

The image tag convention in .env.example uses DC3_IMAGE_TAG=2026.9 and the latest release is v2026.9.22, published on 2026-09-23. The repository last pushed on 2026-09-25. The persistent storage layer is PostgreSQL with TimescaleDB for time-series data, pgvector for embeddings, and Apache AGE for graph queries.

Real-Time Data Engine and Rule Processing

IoT DC3 includes a real-time data collection layer that works asynchronously. Protocol drivers collect device telemetry and publish it to the internal message broker. The message broker is pluggable per deployment: the default is RabbitMQ, but Kafka, Pulsar, RocketMQ, ActiveMQ, and an MQTT 5 broker are all supported, selectable through the DC3_MQ_TYPE environment variable in .env.example. The broker selection is made once at deploy time and does not require driver changes.

On top of the time-series storage, the platform includes a rule engine that supports multi-level alarm rules. Alarms trigger notifications through configurable channels. The event traceability layer records device events for audit and root-cause analysis. The AI-assisted alarm analysis feature in the Agentic Center connects to this event stream and can generate root-cause suggestions and response recommendations using the configured LLM provider.

The DC3_IMAGE_TAG environment variable in .env.example is set to 2026.9, matching the v2026.9.22 release. The Makefile provides a complete lifecycle of commands: make dev starts individual center services in development mode, make up starts the full Compose stack, make logs tails logs for all services, and make reset performs a full environment reset. The changelog generation and OpenAPI documentation are also covered by Makefile targets, which signals that the project treats documentation automation as part of the build process.

Limitations and When to Consider an Alternative

IoT DC3 is a distributed microservices platform. The full stack runs Gateway, Auth, Manager, Data, Agentic, and optional observability services alongside RabbitMQ or Kafka, PostgreSQL, and TimescaleDB. This is appropriate for production industrial deployments but creates significant operational overhead for a small team testing a single device type.

The platform is Java-only (Spring Boot 4, Spring Cloud 2025). Teams working in Python-native data pipelines will need a translation layer between IoT DC3's API and their tooling. The frontend is built separately from the backend and requires a Node.js build step, as defined in the dc3-web/ directory.

The deployment complexity also shows in the secret management requirement. The .env.example explicitly states that DC3_SECURITY_KEY and AUTH_HMAC_SECRET are not set in the example file and must be supplied separately. Production deployments must set deployment-specific values, and the README example uses openssl rand -hex 32 as the generation method. The pre/pro profiles reject blank or publicly-known values at startup, which prevents accidental deployment with default credentials but also means a misconfigured secret will cause a startup failure rather than a security warning.

For smaller deployments or Python-native environments, Eclipse Mosquitto with a Python subscriber is a simpler path for MQTT-only device connectivity. IoT DC3's advantage is the breadth of protocol coverage and the built-in AI agent gateway, which would take considerable effort to assemble from separate components.

Editorial conclusion

IoT DC3 is the right starting point for Java teams who need to connect a mix of industrial protocols to a cloud-native data pipeline and want AI-assisted operations without building the integration themselves. The dual license (AGPL at the core, custom license for components) requires legal review before commercial deployment. Teams that need a lighter deployment footprint or a Python-native stack should evaluate alternatives. The v2026.9.22 release is recent and the repository shows active development, but the production secrets DC3_SECURITY_KEY and AUTH_HMAC_SECRET must be set to deployment-specific values before any network-exposed deployment.

Frequently asked questions

Official sources

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