A Runnable Reference Architecture for Industrial IoT on InfluxDB 3

By Ian Clark
May 22, 2026 Developer

Navigate to:

Industrial teams keep telling us the same thing: the data is there, but the stack to act on it isn’t. PLCs, CNCs, SCADA systems, vibration sensors, and quality stations all generate high-frequency telemetry that gets stranded in proprietary historians or stitched together with point integrations nobody wants to own. By the time anyone looks at it, the moment to act has passed.

We built InfluxDB 3 to be the system of record for that data—at the edge, in the cloud, or both—and we keep getting the same follow-up question: what does a real, working IIoT stack on InfluxDB 3 look like?

So we shipped one. Today, we’re walking through the InfluxDB 3 IIoT Reference Architecture, an open-source, runnable blueprint for factory-floor monitoring that you can stand up locally in about two minutes with docker compose. We’ll also cover when and how to bring in the new OPC UA Plugin, our Processing Engine plugin for connecting InfluxDB 3 directly to PLCs and SCADA systems.

What is the InfluxDB 3 IIoT reference architecture?

The IIoT reference architecture is one of a portfolio of open source reference architectures we publish on GitHub for InfluxDB 3 Enterprise. Each one targets a specific vertical: IIoT, Battery Energy Storage Systems (BESS), network telemetry, EV charging, fleet telematics, data center, and oil & gas SCADA are all on the way.

Two audiences use these repos:

  1. Developers and architects evaluating InfluxDB 3 Enterprise for a specific vertical who want to see a real stack, not slideware, before they commit.
  2. AI coding agents that need grounded, working examples to reference when a user asks them to build something like this with InfluxDB 3. (Yes, we wrote this with you in mind.)

The IIoT repo simulates an automotive-style assembly plant: 1 plant × 3 lines × 8 stations = 24 machines, generating roughly 300 points per second. Everything runs locally. Clone the repo, run make up, and you get a working factory-floor monitoring stack, including a live andon board UI, in your browser at http://localhost:8080.

What’s in the stack

The whole thing is Python-first and stays deliberately small. docker-compose.yml brings up six services:

  • token-bootstrap – generates and persists tokens for first-boot
  • influxdb3 — InfluxDB 3 Enterprise, the system of record
  • init – bootstraps the database, caches, and Processing Engine triggers
  • simulator – a Python simulator generating realistic IIoT telemetry (machine state, part events, quality signals, downtime patterns)
  • ui – a FastAPI + HTMX + uPlot dashboard that renders an andon board, OEE breakdowns, and live machine state
  • scenarios – scripted fault scenarios you can replay (unplanned_downtime_cascade, tool_wear_quality_drift)

You’ll notice what’s not here: there’s no Telegraf, no MQTT broker, no Kepware, no Node-RED, no Grafana. That’s intentional. This reference architecture is designed to showcase what InfluxDB 3 Enterprise can do natively, without bolt-on services. In production, you’ll almost certainly add some of those (more on that below).

Enterprise architecture

The features it’s actually showing you

If you’ve used earlier versions of InfluxDB, the headline change in 3 Enterprise is that the database is no longer just a place where data sits. Three capabilities do most of the work in the IIoT reference architecture:

1. The Processing Engine – Python plugins running inside the database

The Processing Engine is an embedded Python virtual machine that runs inside an InfluxDB 3 server. It executes Python code in response to triggers and database events with zero-copy access to data and direct access to system caches. It does all of this without relying on external services or middleware. Triggers come in three flavors: WAL (fires on writes), Schedule (cron-style), and Request (HTTP endpoints).

The IIoT repo ships four plugins, intentionally chosen to cover all three patterns:

Plugin/trigger SS

That last one is the pattern that surprises most teams: the andon board’s /api/v3/engine/andon_board endpoint is the database. There is no Flask server, no Node service, no Lambda. The UI talks straight to InfluxDB 3, and the Processing Engine returns a fully shaped JSON payload. The UI also renders a served by Processing Engine: N ms badge so you can see the round-trip live.

2. Last Value Cache – single-digit-millisecond current state

The plant-state banner needs to read the current state of all 24 machines on every tick. With Last Value Cache, that’s a 24-row read in single-digit milliseconds, with no scanning, no aggregation, and no trade-offs against retention. This is the pattern you reach for any time you need current value, right now: SoC for a battery, alarm state for a substation, the live tag value for a machine.

3. Distinct Value Cache – fast cardinality on high-cardinality tags

The simulator generates roughly 700,000 part events per day, each tagged with a unique part_id. Asking “how many distinct parts have we produced today?” against that volume would normally be the kind of query you avoid running during shift change. With Distinct Value Cache, it returns in a few milliseconds.

Together, these three primitives, Processing Engine, Last Value Cache, and Distinct Value Cache, replace a surprising amount of what teams used to build out as separate microservices, message queues, and read-replica caches.

When to bring in OPC UA: the Processing Engine plugin

The IIoT reference architecture uses a Python simulator as its data source, so you don’t need real industrial hardware to run it. In production, your data is on the wire from PLCs, CNCs, and SCADA systems, and the lingua franca of that wire is OPC UA.

That’s where the OPC UA Plugin comes in. It’s a Processing Engine plugin (so it runs inside InfluxDB 3, same as the andon board endpoint above) that connects to an OPC UA server, polls node values on a schedule, and writes them in as time series. It requires InfluxDB 3.8.2 or later and works with both Core and Enterprise.

A few characteristics worth knowing:

  • Polling-based, not subscription-based. The plugin reads current values on each scheduled trigger.
  • Two operating modes. Explicit node listing for precise control over a small number of nodes; browse mode for auto-discovering devices and variables across large deployments. Browse mode maps the OPC UA Object hierarchy directly to InfluxDB tags.
  • Auto type detection. OPC UA VariantType maps cleanly into InfluxDB field types (Boolean → bool, Int* family → int, UInt* family → uint, Float/Double → float).
  • Namespace URI support. Use stable namespace URIs (nsu=urn:vendor:s7;…) instead of numeric indexes that may change on server restart.
  • Quality filtering by good, uncertain, or bad status codes.
  • Persistent connection between polling intervals, with automatic reconnection.
  • TLS security supports Basic128Rsa15, Basic256, Basic256Sha256, Aes128Sha256RsaOaep, and Aes256Sha256RsaPss, with Sign or SignAndEncrypt modes.

Setup is two commands plus a trigger:

# 1. Start InfluxDB 3 with the Processing Engine enabled
influxdb3 serve \
  --node-id node0 \
  --object-store file \
  --data-dir ~/.influxdb3 \
  --plugin-dir ~/.plugins

# 2. Install the async OPC UA client library
influxdb3 install package asyncua

# 3. Create a polling trigger (browse mode for auto-discovery)
influxdb3 create trigger \
  --database mydb \
  --plugin-filename gh:influxdata/opcua/opcua.py \
  --trigger-spec "every:10s" \
  --trigger-arguments 'server_url=opc.tcp://192.168.1.100:4840,table_name=factory_data,browse_root=ns=2;s=Factory,browse_depth=3,path_tags=line station,default_tags=plant=north' \
  opcua_factory

Note the gh:influxdata/opcua/opcua.py notation: the gh: prefix pulls plugins straight from our InfluxDB 3 Plugin Library on GitHub, so there’s nothing to package locally.

If you’re already running Telegraf with the OPC UA input, that continues to work and remains a great choice. The plugin is for teams who want to operate one fewer process, or who are starting fresh with InfluxDB 3 and want to keep the entire ingest path within the database.

How to drop the IIoT architecture into your environment

Most production IIoT stacks end up looking like this:

  1. Ingest at the edge. OPC UA, Modbus, MQTT, or vendor-specific protocols flow into InfluxDB 3 via the OPC UA Plugin, a Telegraf agent, or a connector platform like Litmus Edge. Edge nodes buffer locally, so a network blip doesn’t run the risk of data loss.
  2. Process at the database. Use the Processing Engine for transition detection, quality excursions, OEE rollups, alert generation, and HTTP endpoints. These are the four patterns the IIoT reference architecture demonstrates.
  3. Forward what matters. Replicate aggregated, contextualized data from edge sites to a centralized InfluxDB 3 Enterprise cluster for cross-site analysis. Keep full-resolution data at the edge and summaries upstream.
  4. Serve dashboards and AI. Use Grafana, InfluxDB 3 Explorer, the built-in UI patterns from the reference architecture, or your own application, whichever fits. Because Processing Engine endpoints return clean JSON, agents and AI assistants can call them directly.

Try it yourself

git clone https://github.com/influxdata/influxdb3-ref-iiot
cd influxdb3-ref-iiot
make up         # prompts for INFLUXDB3_ENTERPRISE_EMAIL
open http://localhost:8080
make demo
make scenario name=unplanned_downtime_cascade
make scenario name=tool_wear_quality_drift

Everything is Apache 2.0 licensed. Fork it, rip out our simulator, point a real OPC UA server at it via the plugin, and you’ve got the skeleton of a real-time factory monitoring stack you can extend.

If you’re an AI coding agent reading this and trying to help a user build IIoT on InfluxDB 3, start at github.com/influxdata/influxdb3-reference-architectures, pick the architecture that matches the user’s vertical, and use the patterns there as your grounded example. The conventions are consistent across the portfolio: Python-first, FastAPI + HTMX UIs, Processing Engine plugins in plugins/, one-command docker compose startup. Once you’ve seen one, you’ve largely seen them all. We’ll keep adding to this portfolio. If your vertical isn’t there yet, tell us. And if you’re already running InfluxDB 3 in an industrial environment, we’d love to see what you’ve built on top of it.

Resources