Lucent Owl logo Lucent Owl

IoT Architecture Diagrams

Last updated:

9 related guides
diagrams device-twin edge-computing architecture-diagrams

Device Twin Reconciliation

C4 · Dynamic

Desired and reported state converging after a device reconnects.

How a device twin reconciles desired and reported state The backend sets desired state in the twin while the device is offline. When the device reconnects it reads the desired state, applies it, and writes its actual configuration back as reported state. A fleet query compares desired and reported values to find devices that have not caught up. CLOUD SITE Backend or operator changes configuration while the device sleeps Device twin or shadow desired interval 60 s firmware 2.1 reported interval 300 s firmware 2.0 Fleet query finds devices where desired differs from reported Device offline for hours, then reconnects 1 desired 2 read on reconnect 3 apply, then report 4 compare writes and reads of the twin read-only query

Hot, Warm, and Cold Paths

Flow

One stream fanning out to hot, warm, and cold paths.

One telemetry stream feeding hot, warm, and cold paths Devices and gateways send events to a broker or event log. Each path reads the same stream through its own consumer group. The hot path runs a stream processor that drives alerts and a live cache within seconds. The warm path loads a time-series store that serves dashboards over days to weeks. The cold path writes a raw archive in object storage that batch jobs and ML training scan, and the archive can be replayed through the pipeline to rebuild results. Devices and gateways Broker or event log one stream, one consumer group per path, so a slow path never blocks a fast one HOT PATH Stream processor windows, thresholds, per-device state Alerts, live cache act within seconds WARM PATH Time-series store queryable in seconds, keeps days to weeks Dashboards trends and ad hoc queries COLD PATH Raw archive object storage in Parquet, kept for years Batch jobs and ML full scans, training, compliance replay the archive to rebuild results event flow reprocessing

The Edge ML Loop

Flow

Scoring at the edge, and the samples that retrain the model.

The edge ML loop between device and cloud On the edge device, a fixed-length sensor window feeds an optimized edge model that scores every window. A confident score acts locally by alerting or actuating. An uncertain score forwards the reading to a larger, slower, more accurate cloud model. Alerts and uncertain samples are uploaded selectively to a labeled dataset in the cloud, which feeds training, evaluation, and quantization. The result is stored as a versioned artifact in a model registry and delivered back to the edge model, reaching canary devices first. EDGE DEVICE CLOUD Sensor window fixed-length input Edge model optimized, scores every window Act locally confident score: alert or actuate uncertain: forward Selected samples alerts and uncertain selective upload Larger cloud model slower, more accurate Labeled dataset reviewed samples Train and optimize evaluate, quantize Model registry versioned artifact new model version, canary first data and decisions model delivery

Segmenting IoT Devices

Trust boundary

An IoT segment where only allowlisted cloud endpoints are reachable.

IoT network segmentation with an allowlisting firewall IoT devices sit in their own VLAN. A firewall between that segment and everything else allows only named cloud hosts and ports. Legitimate sensors and gateways reach the cloud IoT endpoint through the firewall. A compromised device in the same segment is denied at the firewall both when it tries to reach workstations and file servers on the corporate LAN and when it tries to reach an attacker's command-and-control (C2) server on the internet, because neither is on the allowlist. IOT SEGMENT (VLAN) Sensors and gateways each talks to one endpoint on one port Compromised device attacker's foothold Firewall allowlist only: named cloud hosts and ports deny everything else, including IoT to LAN CORPORATE LAN Workstations, file servers no path in from the IoT segment, so a device cannot be a pivot INTERNET Cloud IoT endpoint on the allowlist Attacker C2 server command and control, never allowlisted allowed to LAN: denied to C2: denied allowed flow denied at the firewall

A Dual-Slot Update With Test and Confirm

Flow

Three failures during a dual-slot update, each rolling back.

A dual-slot firmware update with test-and-confirm rollback The device runs its image from slot A while it downloads the new image into spare slot B, resuming after interruptions. It verifies the signature over the whole image and manifest. If verification fails, the staged image is discarded and A never stopped running. If it passes, the device marks B pending and reboots into it on probation, where B runs a self-test. If the self-test passes and B confirms itself, B becomes permanent. If B crashes, hangs, or reboots without confirming, the bootloader reverts to A on the next boot and the old image runs again. Running image slot A active, slot B spare Download into slot B, resume after interruptions Verify signature whole image and manifest Mark pending then reboot into slot B Probation boot B runs self-test Confirmed B is permanent passes, confirms Revert bootloader boots A crash, hang, or no confirm Discard staged image A never stopped fails old image runs again update succeeds failure path, old image kept

Zero-Touch Provisioning

C4 · Dynamic

A device routed from the provisioning service to its hub.

Zero-touch provisioning through a provisioning service The factory injects a unique identity into each device and records a batch manifest, and its CA or manifest is loaded into the provisioning service's enrollments, which hold the group CA or group key and the allocation policy. The device, which knows only the provisioning address, attests its identity to the provisioning service. The service matches the device to an enrollment, applies the allocation policy to choose among candidate hubs in region A, region B, and tenant C, registers the device on the chosen hub in region B, and returns the endpoint address to the device. From then on the device connects directly to that hub. Factory injects unique identity, records batch manifest Device knows only the provisioning address Enrollments group CA or group key, allocation policy Provisioning service checks attestation, picks an endpoint, registers the device Hub, region A candidate endpoint Hub, region B chosen for this device Hub, tenant C candidate endpoint CA or manifest 1 flashed 2 attest identity 4 endpoint address 3 match enrollment 4 register 5 connect directly from now on device provisioning flow setup the device never sees

The Purdue Levels and the Industrial DMZ

Trust boundary

The Purdue levels, with the DMZ between OT and IT.

Purdue model levels with an industrial DMZ and data diode Seven horizontal bands, from level 0 physical process at the bottom through level 1 basic control, level 2 supervisory, level 3 site operations, level 3.5 industrial DMZ, level 4 site business, to level 5 enterprise and cloud at the top. Data flows upward from sensors and actuators to PLCs and DCS controllers, to SCADA servers and HMIs, to the plant historian and MES. From level 3 it crosses a hardware data diode in the DMZ into a historian replica, which ERP and business systems at level 4 read. Separately, an edge gateway in the DMZ collects from level 3 and connects outbound only to a cloud IoT platform at level 5. There is no path from IT at level 4 down into the control levels; that path is blocked at the DMZ. LEVEL 5 ENTERPRISE, CLOUD LEVEL 4 SITE BUSINESS LEVEL 3.5 INDUSTRIAL DMZ LEVEL 3 SITE OPERATIONS LEVEL 2 SUPERVISORY LEVEL 1 BASIC CONTROL LEVEL 0 PROCESS Cloud IoT platform ERP, business systems Data diode one-way, in hardware Historian replica what IT is allowed to read Edge gateway outbound only Plant historian, MES SCADA servers, HMIs PLCs, DCS controllers Sensors, actuators collects from level 3 no path from IT down to control data flow blocked at the DMZ

OT-to-Cloud Reference Architecture

C4 · Container

Plant systems, the edge gateway, and the path to the cloud.

OT-to-cloud reference architecture through an edge gateway in the DMZ In the plant, at Purdue levels 1 to 3, a PLC with an OPC UA server is read directly, a legacy Modbus PLC is read through a protocol gateway that converts to OPC UA, SCADA and the historian are read through OPC UA or historian interfaces, and a safety system is read only through its vendor's isolated monitoring port, if at all. All of these feed an edge gateway in the industrial DMZ, which acts as an OPC UA client with subscriptions and dead-band filters, keeps a durable buffer, adds asset context, and connects outbound only over MQTT or AMQP with TLS. In the cloud, a broker or ingestion service receives data from every site and feeds a time-series store and a plant context model or twin, which both feed analytics and dashboards for maintenance, quality, and energy. PLANT, LEVELS 1 TO 3 INDUSTRIAL DMZ CLOUD PLC with OPC UA server read directly Legacy PLC Modbus Protocol gateway to OPC UA SCADA, historian OPC UA or historian interface Safety system vendor monitoring port only Edge gateway OPC UA client subscriptions and dead-band filters durable buffer adds asset context connects outbound only, MQTT or AMQP over TLS Broker or ingestion service receives from every site Time-series store Plant context model or twin Analytics and dashboards maintenance, quality, energy read-only data flow isolated read-only interface, if connected at all

Reducing Vibration Data at the Edge

Flow

A vibration stream reduced to features, spectra, and raw captures.

Edge data reduction for high-frequency vibration monitoring An accelerometer on the machine is sampled at 25.6 kHz, about 51 KB per second. On the edge device or smart sensor, the stream feeds a raw ring buffer holding the last few minutes, and an FFT and envelope stage that computes spectra and features for each capture. Features go to a lightweight anomaly check on the device, against the asset's baseline, which sends features and alerts upstream every few seconds. Spectra go upstream every few minutes. When the anomaly check fires, it triggers the ring buffer to upload raw waveforms, so full-resolution data is sent only around events. MACHINE EDGE DEVICE OR SENSOR SENT UPSTREAM Accelerometer 25.6 kHz samples, about 51 KB/s Raw ring buffer last few minutes FFT and envelope features per capture Anomaly check against the baseline Raw waveforms only on a trigger Features and alerts every few seconds Spectra every few minutes trigger continuous data reduction event-triggered raw upload

Found this useful? Share it:

Share on LinkedIn