Industrial IoT & Data Architecture Field Frameworks: The Data Chain
Eleven articles following one chain — process, sensor, signal, acquisition, transport, storage, context, decision — and the links that keep breaking while the dashboards carry on rendering. Plus six free field cards. Each article ends in an exercise that costs an afternoon and no capital.
Industrial data architecture is usually sold as a platform problem. It is better described as a chain, and a chain is only worth what its weakest link can carry.
The chain runs: process → sensor → signal → acquisition → transport → storage → context → decision. A physical process produces a condition. A sensor turns it into a signal. An acquisition device turns the signal into named, timestamped data. A network moves it. A store keeps it. A context layer gives it meaning. A consumption layer puts it in front of somebody.
Value is created at the last link only — when a person or a system decides something differently because the data existed. Every link before that is cost: engineering, hardware, configuration, bandwidth, licence, modelling, and the scarcest input of all, attention.
Break any one link and the rest still runs. That is the difficulty: a broken chain produces output. Collectors poll, brokers publish, historians ingest, dashboards render — beautifully, from stale values, through interpolated gaps, on tags nobody can join to a machine. The architecture stops being evidence about the plant and becomes evidence about itself.
This series is about where the links break, how to tell from inside the project, and what it costs to repair one.
Each piece stands alone. Read in order, they follow the chain from the decision that justifies a measurement to the ledger that says whether any of it paid. Every article ends with an exercise that costs an afternoon and no capital.
Where this comes from
The series draws on Industrial IoT and Data Architecture: From Sensor to Historian to Dashboard, a nine-part reference running from the data value chain and the sensing layer, through acquisition, edge placement, plant networks and time-series storage, into tag naming, asset models and data contracts, and out through displays, notifications, security, chain reliability and the implementation playbook.
Each article cites the section it draws from. The book renders verdicts on architecture evidence in three states — supported for this context, controlled trial, not demonstrated — and none of the three authorises anything on a plant. The articles keep that boundary. Worked numbers are recomputable from inputs printed on the page; they demonstrate a method rather than a benchmark, and the Meridian plant they run on is an invented composite.
Two of the site’s standalone references sit alongside this series rather than inside it: the five-layer machine data flow for readers who want the whole architecture in one pass, and the IoT, IIoT, Industry 4.0 decision framework for readers deciding which layer to fund first.
The series
- 01 Build the Data Chain Backwards From the Decision
Eight links carry a plant reading from a physical condition to somebody's judgement, and value is created at the last one only. Built forwards from the sensors, the chain produces a very complete record of nobody looking at anything.
- 02 Four Gates a Measurement Passes Before Any Sensor Is Priced
A sensor is a claim about the future: that some decision, some day, will be made differently because this measurement exists. The claim is testable in minutes, before a single wire is run, and failing it on paper is free.
- 03 Where Data Is Born: The Birth Certificate Your Chain Inherits
A sensor produces a signal, not data. Data is born in whatever device first samples that signal, stamps it and names it — and no downstream layer can add what the birthplace never recorded. Architecture reviews that start at the historian have already skipped the decisions that matter most.
- 04 Three Filters Decide How Much Reality Survives
The scan decides how often reality is looked at. The deadband decides how much it must move before the look is recorded. The reporting scheme decides which records travel. All three are legitimate, all three are usually inherited rather than chosen, and each one set carelessly deletes exactly what somebody later needed.
- 05 Modbus, OPC UA and MQTT Are Three Theories, Not Three Transports
Modbus hands you a number. OPC UA hands you a meaning. MQTT hands you a change. Treat them as interchangeable pipes and you keep paying the difference in integration labour — because conversion between them is exactly where meaning dies.
- 06 Time Is the Quietest Way a Data Chain Lies
Three trends, one incident, three different moments. Nothing malfunctioned — every device did exactly what it was configured to do. The plant simply never decided what time it was, and the chain answered the investigators with a confident, ordered, wrong story.
- 07 What Compression Did to Your Data While You Slept
An engineer trends last night's pressure and sees a smooth line through the upset she knows happened. Nothing is broken and nothing was deleted. A compression deviation set to save disk in 2011 and a retrieval mode that paints straight lines through gaps did the rest.
- 08 The Unified Namespace Is a Pattern, Not a Product
The hub diagram is genuinely better than the spaghetti it replaces. It is also a diagram — and the distance between the two pictures is not a purchase order but a programme: naming governance, payload discipline, and forty birthplaces connected without forging their birth certificates.
- 09 Notifications Are Not Alarms, and the Line Has to Be Architectural
The alarm system is one of the most heavily engineered artefacts in a plant. Into the same plant arrives a data platform — cheerful, unregulated, and able to notify anyone about anything a query can express. Nothing in it has read the alarm philosophy.
- 10 The Pilot That Earns the Second Project — and the Ledger That Funds It
Data pilots fail in two symmetrical ways: the ambitious one that connects half the plant and produces a login page, and the trivial one that works perfectly on a rig nobody cares about. Between them sits one real decision, the full chain built thin, and a verdict on the calendar before the kickoff is.
- 11 Six IIoT Data-Chain Field Cards
Six one-page cards for the records an industrial data project keeps skipping: the decision test, the load statement, the timestamp audit, the retrieval modes, the data contract and the chain health signals. Questions and record fields only.
Industrial IoT and Data Architecture — From Sensor to Historian to Dashboard
The nine-part reference this series draws on: the data value chain, the sensing layer, edge and acquisition, plant networks, historians and time-series storage, context and asset models, dashboards and analytics, security and chain reliability, and the implementation playbook — 40 sections covering signal families, protocol theories, timestamp discipline, compression and retrieval, tag naming, asset models, data contracts, notification engineering, threat modelling, and the pilot-to-wave economics a finance function can audit.