Skip to content

OT Architecture Overview

Overview

The Archon Platform OT layer applies industrial automation principles to a homelab-scale sensor network. IEC 62443 zone-and-conduit concepts govern network and identity separation. MQTT is the OT data contract. InfluxDB provides the historian. Alarm rationalization follows ISA-18.2 principles to prevent nuisance-alarm overload.

Zone Model: IEC 62443

The OT network is separated from the IT network by a firewall boundary. OT devices cannot initiate connections to IT systems; data flows from OT to IT through a defined conduit (MQTT broker to historian ingestion). Ansible automation for OT nodes uses a dedicated service account that has no access to IT nodes, and vice versa.

This zone-and-conduit model means that a compromised OT node cannot pivot to the IT network, and an IT-side incident does not directly affect OT sensor operation. The IT/OT separation policy is documented in IAM-0002.

Sensor Node Lifecycle

OT sensor nodes are embedded systems (ESP32-based) that follow a structured naming convention encoding cluster, zone, node type, and sequence number. Node types are three-letter codes (sensor, camera, gateway, controller, and others). Zones map to physical locations.

All sensor hardware and GPIO conventions -- naming pattern, type code registry, zone map, pin assignments, and measurement units -- are documented in OT-0001.

MQTT as OT Data Contract

MQTT is the message transport layer for all OT telemetry. Topic structure follows a hierarchical convention that encodes zone and node identity. Payloads are plain numeric values (not JSON objects) to minimise firmware complexity and bandwidth.

The MQTT topic structure, QoS levels, retained message policy, and broker configuration decisions are documented in OT-0002.

Historian: InfluxDB

OT telemetry is persisted in InfluxDB, which acts as the time-series historian for all sensor measurements. Flux tasks control bucket retention periods, balancing storage cost against operational and analytical data retention requirements.

Retention policy decisions -- raw data, downsampled aggregates, and long-term archive -- are documented in OT-0003.

Alarm Rationalization: ISA-18.2

Alarms are defined following ISA-18.2 alarm management principles:

  • Warning (P3): sustained threshold breach requiring attention but not immediate action. Delivered via Telegram notification.
  • Critical (P1): threshold breach or state condition requiring immediate response. Delivered via Telegram and creates a CMMS maintenance work order.

Each sensor context defines a small, rationalized set of alarms. Nuisance-alarm prevention is explicit -- every alarm definition must specify a sustain delay or deadband to prevent chatter from minor fluctuations.

Critical alarms also create ADO work items for traceability from physical event to maintenance record. The alarm rationalization framework and CMMS integration are documented in OT-0004.

Dashboard Taxonomy

OT dashboards in Grafana follow a five-tier taxonomy: platform home, zone overview, node detail, diagnostic, and maintenance. This structure makes navigation predictable for operators and prevents dashboard proliferation. The taxonomy is documented in OT-0005.

Key Properties

  • IEC 62443 zone-and-conduit model -- OT and IT zones are network-separated with no bidirectional initiation from OT to IT
  • MQTT is the sole OT data transport -- no OT device calls internal APIs directly
  • InfluxDB is the historian -- structured retention tiers control storage growth
  • ISA-18.2 alarm rationalization -- small alarm set with deadbands, no nuisance floods
  • CMMS integration closes the loop from sensor alert to maintenance work order