Milliseconds matter
A PLC (programmable logic controller) runs its logic every 1 to 50 ms. Nothing in a control loop goes near the WAN (wide area network) or the cloud.
Operational technology
Connecting the plant without putting it at risk
I design how plant and building systems connect, how they are protected, and how their data reaches the business. This page shows the models I work to, the design choices I make, and where I have used them. You can step through each diagram at your own pace.
IT and OT
Different priorities, different rules
Operational technology runs physical processes: production lines, plant rooms, power and buildings. The network skills are the same as in IT (information technology). The priorities are not, and every design decision starts there.
Swipe sideways to see the whole diagram.
IT view. Protect the data first. Keep it confidential, keep it correct, and keep systems available. A reboot at night to patch is normal.
OT view. Safety comes before everything, then availability. A line that stops costs money every minute, and a wrong command can hurt someone. Confidentiality still matters, but it comes last.
Twenty year assets
PLCs and drives often run for 20 years or more. I design to connect older kit safely, not to assume it will be replaced.
Rare change windows
Some lines stop for maintenance only once or twice a year. Every change is planned around those shutdowns.
My role: I work on architecture, integration and security: how plant systems connect, how they are protected, and how their data reaches the business. Controls engineers and system integrators own the PLC logic, and I work closely with them.
The plant
How the machines actually run
Before I design a network for a factory, I need to know what it carries and what it must never interrupt. Every line is run by a controller repeating the same short loop, over and over, whatever happens above it.
Swipe sideways to see the whole diagram.
The PLC (programmable logic controller) reads every switch, sensor and analogue signal at once into an input image. The program works on that snapshot, so no value changes half way through a decision.
It runs its logic from top to bottom, written in the IEC 61131-3 languages: ladder diagram, function block diagram, structured text or sequential function chart.
It writes every output in one go: start this motor, open that valve. The machine moves.
Between scans it answers the HMI (human machine interface) and SCADA (supervisory control and data acquisition), runs its own checks and talks on the network. This is the only part of the loop my network touches.
Then it starts again, typically every 1 to 50 milliseconds, the same way every time. That is why control and safety stay local: no interlock ever depends on the cloud, or even on the plant network staying up.
Who controls what
| System | What it does | Examples |
|---|---|---|
| PLC, Level 1 | Controls one machine or line with fast, deterministic logic. | Siemens S7-1500, Rockwell ControlLogix, Schneider Modicon |
| SCADA and HMI, Levels 2 and 3 | Supervises many PLCs: screens, alarms, trends and setpoints. The PLCs keep running if it fails. | AVEVA, Ignition, Siemens WinCC |
| DCS, Levels 1 to 3 | A distributed control system: controllers, consoles and often the historian from one vendor, for large continuous plants. | Honeywell Experion, Emerson DeltaV, ABB 800xA |
| SIS | A safety instrumented system: an independent controller that brings the process to a safe state. It has its own zone. | Certified safety controllers |
| RTU | A remote terminal unit at an unmanned site, reporting over telemetry. | Water, energy and pipelines |
Process plants that mix, heat or react, such as food, chemicals or paper, lean towards a DCS. Discrete plants that make countable items, such as cars or electronics, lean towards PLCs and SCADA.
The business end of the plant
| System | What it does |
|---|---|
| MES, Level 3 | The manufacturing execution system sends orders to lines, tracks materials and batches, records quality checks, downtime and OEE. |
| MOM, Level 3 | Manufacturing operations management: the umbrella for production, quality, maintenance and inventory at a site. |
| ERP, Level 4 | Enterprise resource planning: orders, finance, purchasing and stock, such as SAP S/4HANA or Microsoft Dynamics. |
| PLM | Product lifecycle management: designs, bills of materials and engineering changes, the start of the digital thread. |
The ISA-95 equipment hierarchy
| Level | Food maker | Electronics maker |
|---|---|---|
| Enterprise | A cereal company | An appliance company |
| Site | A named plant | A named plant |
| Area | Baking | Motor assembly |
| Line or process cell | Packing line 2 | Final assembly line 4 |
| Work cell or unit | Carton filler | Screwdriving robot |
Working out OEE
Overall equipment effectiveness (OEE) is availability times performance times quality. It is usually the first number a plant wants once machine states are in one place, so I make sure the network and data design can deliver it. Try it with your own shift.
| Measure | Result | How it is worked out |
|---|---|---|
| Availability | 90.0% | Running time ÷ planned time |
| Performance | 88.0% | Units made ÷ (running time × ideal rate) |
| Quality | 98.0% | Good units ÷ units made |
| OEE | 77.6% | Availability × performance × quality |
The biggest loss here is slow running and small stops. Leading plants often quote about 85%.
Purdue model
The plant, layer by layer
The Purdue model splits a site into levels, from the physical process up to the business. I use it as the security model: it shows where each system sits and which boundaries data may cross. Level 3.5 is the industrial DMZ (demilitarised zone), the buffer between IT and OT. Choose a level to see what lives there.
Swipe sideways to see the whole diagram.
Levels 4 and 5: enterprise and business
- Typical systems
- ERP (enterprise resource planning), email, planning, cloud analytics and AI.
- Speaks
- HTTPS, APIs, SQL, and MQTT (Message Queuing Telemetry Transport) from the DMZ.
- Owned by
- Corporate IT.
- How I protect it
- Never connects down into the plant. Business systems subscribe to plant data published through the DMZ.
Level 3.5: the industrial DMZ
- Typical systems
- Historian copy, MQTT bridge, patch server, remote access jump host.
- Speaks
- OPC UA (Open Platform Communications Unified Architecture), MQTT over TLS (Transport Layer Security), and remote sessions to the jump host only.
- Owned by
- Shared, by written agreement between IT and engineering.
- How I protect it
- A firewall on each side and no traffic straight through. Every flow ends in the DMZ and a new, controlled flow starts on the other side.
Level 3: site operations
- Typical systems
- MES (manufacturing execution system), site historian, SCADA (supervisory control and data acquisition) servers, the site UNS (Unified Namespace) broker and OPC servers.
- Speaks
- OPC UA, MQTT and SQL.
- Owned by
- Plant engineering and OT.
- How I protect it
- The site keeps running if the WAN or the DMZ fails. Hardened servers, tested backups and accounts kept apart from corporate IT.
Level 2: area supervisory control
- Typical systems
- HMI (human machine interface) panels, SCADA operator clients and engineering workstations.
- Speaks
- Vendor protocols, OPC and Modbus TCP.
- Owned by
- Operations.
- How I protect it
- Application allow listing, no internet access, removable media control, and every change logged.
Level 1: basic control
- Typical systems
- PLCs, DCS (distributed control system) controllers, safety controllers and RTUs (remote terminal units).
- Speaks
- PROFINET, EtherNet/IP, Modbus and vendor protocols.
- Owned by
- Controls engineers.
- How I protect it
- Only known engineering stations may talk to them. Monitoring is passive, because some older PLCs fail if they are scanned.
Level 0: physical process
- Typical systems
- Sensors, valves, motors, drives and the product itself.
- Speaks
- Analogue signals and fieldbus.
- Owned by
- Process and maintenance teams.
- How I protect it
- Physical security and the safety systems. A bad command that reaches here can spoil a batch, stop a line or hurt someone.
Purdue was designed for data to climb one level at a time. Modern edge and cloud designs do not fit that, so I keep Purdue as the security model and let a Unified Namespace handle the data flow, as shown further down.
IEC 62443
Zones, conduits and security levels
IEC 62443 is a family of standards for securing industrial systems. Its core idea is simple: group assets into zones, allow traffic only through named conduits, and match the strength of the controls to the risk.
Swipe sideways to see the whole diagram.
Assets with the same trust level, owner and risk share a zone. Each production line is its own zone, so trouble on line 1 stays on line 1, and the SIS (safety instrumented system) gets a zone of its own.
Zones talk only through conduits: defined paths with a named protocol and purpose, such as OPC UA from a line to SCADA. Anything not written down as a conduit is not allowed.
Each zone gets a target security level (SL) from 1 to 4, based on the attacker it must resist. That sets the strength of its controls, so effort and money go where the risk is.
A firewall enforces every conduit with allow rules only, and passive sensors watch for anything new. There is no direct path from IT into a line.
The seven foundational requirements
| Requirement | What I look for |
|---|---|
| 1 · Identification and authentication | Named accounts and device identities, not shared logins. |
| 2 · Use control | Roles and least privilege for every operator and engineer. |
| 3 · System integrity | Protection against changed code, malware and unapproved changes. |
| 4 · Data confidentiality | Encryption where data leaves the zone or reveals the process. |
| 5 · Restricted data flow | Zones and conduits, enforced by firewalls with allow rules only. |
| 6 · Timely response to events | Logs and passive monitoring that someone actually watches. |
| 7 · Resource availability | The plant keeps running under attack or overload. |
Security levels
| Level | The attacker it resists |
|---|---|
| SL 1 | Casual or accidental misuse. |
| SL 2 | Deliberate attack with simple means, few resources and general skills. |
| SL 3 | Sophisticated attack with moderate resources and industrial control skills. |
| SL 4 | Sophisticated attack with extensive resources, such as a state backed group. |
The family has parts for asset owners, such as the security programme in IEC 62443-2-1. It has parts for system design: risk assessment, zones and conduits in IEC 62443-3-2, and system requirements in IEC 62443-3-3. Suppliers follow IEC 62443-4-1 for secure development and IEC 62443-4-2 for components. Products and integrators can be certified against them.
Protocols
From polling to publish once
Most plants still poll: a server asks every device for every value, every second. Publish and subscribe flips that around, which cuts traffic, removes inbound connections to the controllers and makes new uses cheap.
Swipe sideways to see the whole diagram.
Reading 10,000 tags every second moves 10,000 values a second, and most have not changed. Every new consumer means another connection into the plant.
About 500 updates a second if 5 percent of values change. Each device publishes once and the MQTT broker passes it to every subscriber. PLCs and gateways open their connections out to the broker, so nothing connects into the controllers. Business systems reach the data through the DMZ bridge.
The protocols I design around
| Protocol | Port | Where it lives | What I watch for |
|---|---|---|---|
| Modbus TCP | TCP 502 | Everywhere, from PLCs to meters. Modbus RTU runs over RS485 serial | No authentication or encryption at all, so only the gateway or SCADA host may reach port 502, and it stays inside its zone |
| PROFINET | Layer 2, plus UDP for setup | Mostly Siemens lines, real time Ethernet | Real time traffic is Layer 2 only, so it does not route. Sensitive to jitter, scans and broadcast storms; keep it on its own VLAN |
| EtherNet/IP | TCP and UDP 44818, UDP 2222 for IO (input and output) | Mostly Rockwell lines | The IP means Industrial Protocol. IO uses multicast, so IGMP (Internet Group Management Protocol) snooping and a querier on each VLAN are essential |
| S7comm | TCP 102 | Siemens engineering and HMI access | Programming access to the PLC, so only the engineering PC may reach it |
| OPC DA | TCP 135, then dynamic ports | Older SCADA and historian links | Relies on Windows DCOM (Distributed Component Object Model), so I do not let it cross a zone boundary. I convert it to OPC UA at the edge |
| OPC UA | TCP 4840 | Machines to SCADA, edge and historians | Use sign and encrypt, manage application certificates, disable anonymous access |
| MQTT and Sparkplug B | TCP 1883, or 8883 with TLS | Edge to broker, broker to business and cloud | TLS on 8883 only, client certificates and topic level access control |
| DNP3 (Distributed Network Protocol 3) and IEC 60870-5-104 | TCP 20000 and TCP 2404 | Utilities, substations, water | Long life field devices; prefer the secure variants where supported |
| IEC 61850 | MMS (Manufacturing Message Specification) on TCP 102, GOOSE (Generic Object Oriented Substation Event) at Layer 2 | Substation automation | GOOSE messages need millisecond delivery, so they stay on dedicated, well engineered VLANs |
| BACnet/IP | UDP 47808 | Building management and HVAC (heating, ventilation and air conditioning) | Discovery uses broadcasts, so crossing subnets needs a BBMD (broadcast management device). Often flat and unauthenticated; segment it, and move to BACnet Secure Connect where vendors allow |
OPC UA and MQTT work together
OPC UA gives structured, secure access to machines and controllers, with rich information models, at Levels 1 to 3. MQTT spreads that data to many consumers. I usually read with OPC UA at the edge and publish with MQTT.
Companion specifications
Industry groups publish OPC UA information models for common equipment, such as packaging machines and general machinery. When machine builders use them, the same kind of machine looks the same from every vendor.
Open standards first
OPC UA, MQTT, ISA-95 and IEC 62443 are all open. I design to principles and standards first, then fit products, so the plant is never locked to one vendor's roadmap.
Namespace
One live source of plant data
A Unified Namespace is a central, event driven hub where every system publishes its current state, named the way the business is organised. Anyone authorised reads it there instead of building another interface.
Swipe sideways to see the whole diagram.
Point to point. Every pair of systems needs its own interface, so links grow as n(n minus 1)/2. At 20 systems that is up to 190 interfaces, each one built, tested and maintained separately.
Unified Namespace. Every system connects once, to the broker. Links grow in a straight line: 20 systems, 20 connections. Adding a dashboard or an AI model is a new subscription, not a new project.
Named the way the business is organised
I name every topic with the ISA-95 hierarchy: enterprise, site, area, line, cell, then a small set of categories. If you know the site and the machine, you can guess the topic.
acme/kettering/packing/line2/filler/state/running true
acme/kettering/packing/line2/filler/metrics/speed_ppm 412
acme/kettering/packing/line2/filler/metrics/oee 0.78
acme/kettering/packing/line2/_mes/order/current PO4471
acme/+/packing/+/filler/metrics/oee every filler, every siteWhat a UNS is not
It is not a product: HiveMQ, EMQX, HighByte and Ignition are parts of one. It is not a historian or a data lake, though it feeds both in real time. It never sits in a control loop, and it does not replace Purdue zoning.
Governance makes it work
A written ISA-95 naming rule, a payload schema with value, time, units and quality, an owner for each branch, and publishers that can only write to their own branch. A new line is a copy of a standard template.
The stack
Connectivity tools such as Kepware, Ignition Edge or Litmus talk to the PLCs. A context layer such as HighByte adds the asset, units and state once, near the source. A clustered broker carries it, and the historian, MES, dashboards and AI subscribe.
Securing it
Zones and conduits stay, and connections run outbound only. TLS everywhere with a certificate per edge device and a renewal plan, topic level access control, and broker monitoring that feeds the security team.
What goes wrong
No governance, so the tree grows wild. A big bang across every site. A product bought and called a UNS. One broker with no resilience. And forgetting to bring the controls engineers with you.
What it gives back
New use cases in weeks instead of months, like for like comparison of OEE, energy and scrap across sites, fewer point to point interfaces and less load on old PLCs. The MQTT mechanics are on the IoT and edge page.
The reference architecture I work towards
Swipe sideways to see the whole diagram.
Levels 0 to 2 keep running exactly as they are. Nothing I add sits in a control loop, and the plant keeps working if everything above it stops.
An edge gateway per line or area reads the machines once, using OPC UA where it can and converting older protocols, then publishes over MQTT with store and forward.
Each site has a clustered UNS broker at Level 3, with a context layer that names every value to ISA-95. The site historian and MES subscribe to it, and the site runs on if the WAN drops.
Selected topics are bridged out through the industrial DMZ. Remote support stops at a jump host there. Nothing passes straight into the plant.
The enterprise UNS and cloud platform feed analytics, AI, ERP and group dashboards. IEC 62443 zones protect every tier, and one ISA-95 model keeps every site comparable.
Historians
Years of plant history, kept small and safe
A process historian is a time series database built for the plant. Each record is a tag, a time, a value and a quality flag, kept for years. SCADA trends cover hours or days, and an ordinary database would drown in the volume, so historians store data cleverly and never lose it when the network drops.
Swipe sideways to see the whole diagram.
A collector reads a tag every second. Most readings barely change, and storing all of them for years across tens of thousands of tags would cost a fortune and slow every query.
An exception deadband drops any value that has not moved by more than a set amount since the last one kept. Noise goes; real changes stay.
Swinging door compression keeps only the points needed to redraw the trend within a set error. Here 36 samples become 7, and the trend still looks the same to an engineer.
If the link to the historian drops, the collector buffers everything locally. Nothing is lost while the buffer lasts, so I size it for the longest outage we expect.
When the link returns, the buffer is replayed in order, with the original time stamps, and the history has no gap.
Historians in tiers
- Site historian at Level 3. It collects from SCADA and the PLCs and keeps running if the WAN drops.
- A copy outside the plant. It replicates outbound, for example PI to PI, to a historian in the industrial DMZ or the enterprise.
- Users read the copy. Business users and analytics never touch the OT network, and no inbound firewall rule is needed.
- Store and forward at every hop. Each tier buffers, so an outage anywhere loses no data while the buffer lasts.
Historians I meet
| Product | Where it is common |
|---|---|
| AVEVA PI System | Widely used across process industries, with PI Asset Framework for context |
| AVEVA Historian (formerly Wonderware) | Discrete and mixed plants |
| AspenTech IP.21 | Refining and chemicals |
| Honeywell Uniformance PHD | Honeywell DCS sites |
| Canary and Ignition Tag Historian | Lighter and newer deployments |
| AWS IoT SiteWise and AVEVA CONNECT | Cloud copies for group analytics |
Context, not just tags
A tag called DB10.DBW4 means nothing to anyone outside the plant. PI Asset Framework models tags as assets, such as Pump 101 on Line 2, which is the same idea as the asset tree in a Unified Namespace.
A different historian at every site
After acquisitions this is normal. I standardise the interface first, so every site publishes into the same namespace and model, then rationalise products at natural refresh points. Ripping out a working historian rarely pays.
History in the cloud, safely
The site historian replicates outbound to a copy in the DMZ, and that copy feeds the cloud. Nothing in the cloud ever opens a path into the plant.
Sparkplug B: MQTT that knows what is alive
Plain MQTT moves messages but says nothing about their meaning or whether the sender is still there. Sparkplug B, an Eclipse Foundation specification that version 3.0 made ISO/IEC 20237:2023, adds a fixed topic structure, a compact payload and state awareness. How MQTT itself works is on the IoT and edge page.
Swipe sideways to see the whole diagram.
Birth. When an edge node connects, it registers an MQTT Last Will, then publishes NBIRTH, and a DBIRTH for each device: every metric it will ever send, with its type and a short alias. The host learns the whole data model at once.
Data. From then on the node sends only changes, as NDATA and DDATA, in a compact Protocol Buffers payload using the aliases. Sequence numbers let the host spot a gap and ask for a fresh birth.
Death. If the edge node drops, the broker publishes its NDEATH message for it, from the Last Will. The host marks every value from that node as stale at once, so nobody acts on old data.
Command. Write back uses NCMD and DCMD from the host. I keep it on a separate, tightly controlled path with operator confirmation and an audit trail, and many sites start read only.
Sparkplug or a plain namespace?
Sparkplug topics follow edge nodes, not the business, and the payload is not human readable. I usually use both: Sparkplug from the edge to the broker for reliability and state, then a modelling layer republishes into an ISA-95 namespace that business users can read.
The topic is the contract
Every Sparkplug topic follows spBv1.0, then group, message type, edge node and device. Because the structure is fixed, a new line or SCADA system can find the data without a custom interface.
State the host can trust
The primary host application publishes its own STATE message. When a primary host is set, edge nodes wait until it is online before they publish, so a SCADA restart does not miss the birth messages it needs.
Resilience
Networks that survive a cut cable
Industrial networks are often rings, because a ring survives a cut cable. The protocol that runs the ring decides whether the line notices. Pick one and cut a link.
Swipe sideways to see the whole diagram.
- Indicative recovery
- What the line sees
Built for the floor
Industrial switches are DIN rail mounted, fanless and rated for heat, dust and vibration, with power budgets planned for PoE (Power over Ethernet) cameras and sensors.
Time you can trust
Precision Time Protocol (IEEE 1588) keeps controllers and recorders in step, so a sequence of events still makes sense after an incident.
Resilience by tier
Rings or parallel networks on the floor, clustered brokers at site level, and store and forward at the edge so a WAN outage loses no data while the buffer lasts.
Visibility
See everything, touch nothing
Some OT devices fail if you probe them, so I listen to their traffic instead. I also make sure there is only one, controlled way in.
Listen, do not probe
Passive sensors read copies of traffic from mirror ports, or run inside industrial switches. Tools such as Cisco Cyber Vision, Claroty, Nozomi Networks and Dragos work this way.
Know every asset
The traffic itself builds the inventory: vendor, model, firmware and who talks to whom. Most sites find devices nobody had on a list.
Baseline, then alert
OT networks are predictable, so anything new stands out: a new talker, a new protocol, or a PLC program download outside a change window.
How a vendor gets in, safely
Swipe sideways to see the whole diagram.
The vendor raises a request against a ticket, and the asset owner approves it for a specific job, asset and time.
The vendor signs in with a named account and multi factor authentication. Shared vendor accounts are not allowed.
The access gateway opens a session to the jump host in the DMZ only, for the approved window, then closes it automatically.
From the jump host the vendor reaches one engineering PC and one PLC. Every session is recorded and can be watched live by the site team.
There is no route from outside straight into the plant. If the gateway or jump host is down, remote access is unavailable.
Buildings
Buildings run on OT too
Heating, cooling, doors, cameras, meeting rooms and power metering are all operational technology. They need the same discipline as a plant: segments, controlled paths and clear ownership.
Swipe sideways to see the whole diagram.
Flat. Everything shares one network. Cameras and door controllers are often weakly patched and long lived, so one compromised device can reach the BMS (building management system) and the plant room.
Segmented. Each family of systems has its own segment and default deny rules. Only a firewalled integration layer reaches across them, and every allowed flow is written down.
Power keeps security up
I size PoE budgets for cameras and readers, and put the switches and recorders that keep a building secure on a UPS (uninterruptible power supply).
The physical layer matters
Risers, fibre and copper runs, and plant room space are planned with the network, not after it. My fibre and copper cabling training helps here.
Owners agreed up front
Facilities, security and IT each own part of a building. I agree who owns which segment and which flow before anything is connected.
I have trained in Honeywell and Control4 building systems, BMS, HVAC (heating, ventilation and air conditioning), power and electrical systems, and fibre and copper cabling. I have also completed Kramer training in AV (audio visual) over IP and control system design, and Hikvision CCTV Expert training. At EMW Construct, from 2017 to 2018, I delivered LAN, WAN and cloud for a multi site estate, with BACnet/IP building automation and IoT (Internet of Things) sensor networks. See all credentials
A CCTV and access control edge
| Segment | What sits there | What it may reach |
|---|---|---|
| VLAN 90 | Cameras, on PoE or PoE+ | The video management system and recorders only |
| VLAN 91 | Door controllers and readers, on PoE | The access control server only |
| VLAN 92 | Intercoms and sensors | Their own head end only |
| Management | Switches, recorders and servers | Admin access through a jump host |
An example plan. The access switches have a PoE budget sized for the cameras, sit on UPS power, and use MAC (media access control) address authentication with profiling. The boundary denies everything except the named video and door flows. Recording storage is sized from camera count, bit rate and retention.
How a building management system fits together
- Field devices. Sensors, valves and actuators, wired to controllers or on RS485.
- Controllers. On BACnet/IP or Modbus, in their own address pool, with a controlled path to the head end.
- Supervisor. The head end, such as Honeywell, Siemens Desigo, Johnson Controls Metasys or Schneider EcoStruxure Building.
- Integration. A gateway exposes the whole system as MQTT or OPC UA for energy analytics, never as a hole into the controllers.
In BACnet every device is a set of objects with properties, such as a temperature input with its present value. I keep accurate time on every controller and put UPS power on key panels.
Its own security domain
CCTV, door entry and building systems are a separate security domain with their own segments, owners and rules, not more devices on the office LAN. They are long lived and rarely patched, so the segmentation does the work.
When a site cannot take the standard design
I treat it as a recorded exception with the smallest change that keeps the intent: a bigger or stacked switch, a midspan PoE injector, fibre uplinks or an extra cabinet, each costed and approved.
Rolled out across many sites
A standard pattern per site size, a survey before each install, and acceptance tests for recording, door events and failover. The installers work to the pattern, and every site looks the same to support.
Roadmap
Modernise without stopping production
Plants cannot pause for a transformation. A good roadmap orders the work so the network is safe before data moves, value is proved on one line, and every site after that is a copy.
Swipe sideways to see the whole diagram.
Site visits, an OT asset inventory, a maturity score per site and a security review against IEC 62443, tied to the goals the plant cares about, such as OEE (overall equipment effectiveness), downtime and energy.
Segmentation and the industrial DMZ, secure remote access, passive monitoring, the broker platform and one naming standard. Data moves on a line only once that line's network is safe.
One lighthouse line, edge to UNS to cloud, with OEE and downtime views. I measure the benefit, then turn that line into a template.
The template rolls out site by site with site kits and runbooks, MES and ERP links, and a support model the plant can run.
Predictive maintenance, energy optimisation and AI, on data that is clean and in context.
From assessment to a fundable roadmap in sixteen weeks
| Weeks | Stage | What I do | What comes out |
|---|---|---|---|
| 1 to 2 | Mobilise | Stakeholder map, goals and measures, document review, the maturity scale and a site visit plan. | A plan on a page |
| 3 to 8 | Discover and assess | Site walks on the shop floor, surveys, workshops and interviews. Asset and data flows captured. Network and security checked against Purdue and IEC 62443. | A baseline, gaps and a maturity score per site |
| 7 to 12 | Design the target | The reference architecture, data foundation, naming and ISA-95 asset model, governance and technology standards. | A reference design |
| 11 to 16 | Roadmap and business case | Phases by site, the deployment approach, benefits, a lighthouse line, risk register and RACI (responsible, accountable, consulted, informed) chart, then a playback to the executive team. | A roadmap the business can fund |
The stages overlap on purpose, so design starts while the last sites are still being assessed.
One maturity scale for every site
I score every site the same way, from 1 to 5, across connectivity, security, data, integration, people and governance. Public models help: the acatech Industrie 4.0 Maturity Index runs from computerisation to adaptability, and many plants turn out to be connected, but not yet visible.
A business case in plant terms
Each phase is tied to a number the plant already tracks: OEE, unplanned downtime, scrap, energy or cyber risk. Foundations such as segmentation are justified on risk and on what they make possible.
Pilots built to be copied
A pilot uses the target architecture and the real naming from day one, with agreed success measures and a stage gate. The foundations for scale are funded before it ends, so the rollout is a template, not a restart.
Why OT roadmaps are hard
Some lines stop only once or twice a year. PLCs run for twenty years or more. Validated systems in food and pharmaceuticals need formal testing. Machine builders own parts of the line. I plan around all of it.
People, not just technology
Controls engineers and IT teams often distrust each other. Joint governance, shared monitoring and early wins for the plant matter as much as the architecture.
What the engagement delivers
An assessment report, a maturity scorecard per site, the reference and target architecture, the gap analysis, a phased roadmap, the business case, a risk register, RACI, standards and stage gates.
The principles I design to
- Control stays local. Nothing in the data layer sits in a control loop.
- Read once, publish once. The edge reads each machine once, and many systems consume it.
- Report by exception. Publish on change, not on a polling timer.
- Outbound only. Nothing passes straight from IT into OT. Remote access ends at a DMZ jump host, which opens a new, recorded session to one approved asset.
- Purdue for security. Use it as the security model, not the data flow model.
- One naming standard. The same ISA-95 model at every site, so sites can be compared.
- State and history apart. The UNS holds now. Historians and the data platform hold the past.
- Interfaces before products. Standardise the interface first, choose products second.
- Resilient at every tier. Broker clusters, site autonomy and store and forward.
- Prove it, then copy it. One lighthouse line first, then roll out by template.
Engagement
How I run an OT engagement, without stopping production
In a plant, production and safety come first, and the people who run the lines know things no drawing shows. So I spend time on the shop floor, prove the facts with passive tools, and plan every change around the production calendar.
Swipe sideways to see the whole diagram.
I start with the plant's own goals: less unplanned downtime, better OEE, lower energy, less cyber risk. Controls engineers and IT sit at the same table from day one, because OT programmes fail when either side feels left out.
Functional requirements cover the data each use case needs and the connections allowed. Non functional ones protect the plant: availability, latency for control traffic, ring recovery times, change windows, and validation for regulated lines such as pharmaceuticals.
I walk the floor with the people who run it, then listen to the network with passive tools rather than scanning, because some OT devices fail when probed. The result is an asset inventory, a flow map and a maturity score for each site.
The design sets zones and conduits to IEC 62443, the industrial DMZ, remote access through a jump host, and the data foundation named to ISA-95. One line is designed as a template that every other line and site can copy.
Changes go in during planned outages agreed with production planning, with a tested way back and the operators on site. A lighthouse line proves the design with real numbers, then the template rolls out site by site.
Support is shared between site engineering, IT and security operations, with clear rules on who may touch what. Passive monitoring alerts are tuned with the plant, and vendor remote access follows one recorded, approved route.
PLCs and HMIs run for twenty years or more, so I keep a lifecycle register, patch where the vendor allows and the line can stop, and protect the rest with segmentation and monitoring. Maturity is reassessed each year and the roadmap refreshed.
Functional requirements
What it must do.
- Collect the data each use case needs, read once at the edge and published to a site namespace.
- Separate each line, the safety system and the site operations zone, with named conduits only.
- Send data out to the business through an industrial DMZ, with nothing connecting straight into the plant.
- Give vendors and engineers remote access through one recorded jump host, approved per session.
- Detect new devices and unusual traffic without probing the control network.
- Keep each site running if the WAN or the cloud is unavailable.
Non functional requirements
How well it must do it, with a number wherever one can be agreed.
- Safety
- No change to control or safety functions; safety systems stay independent.
- Availability
- No unplanned stops caused by the network, and ring recovery within the IO watchdog time.
- Latency
- Control traffic stays local, with real time protocols kept on their own segments.
- Data
- Store and forward at every tier, so an outage loses no data while the buffer lasts.
- Change
- Changes only in agreed windows, with validation on regulated lines.
- Security
- Target security levels per zone under IEC 62443, monitored continuously.
- Lifespan
- Designs that can connect equipment fifteen to twenty years old.
Typical starting targets. Each site's risk assessment and production needs set the real numbers.
Who I talk to
- Plant managers, shift supervisors and operators
- Controls, automation and maintenance engineers
- Machine builders and system integrators
- IT, security and data teams
- Quality, health and safety, and compliance
How I find out
- Walking the floor with the people who run each line
- Workshops by site and by use case
- Passive network monitoring for asset and flow discovery
- Review of drawings, backups and the existing documentation
- Maturity scoring with one scale for every site
Discovery tools
| Tool or source | What it tells me |
|---|---|
| Passive OT monitoring (Claroty, Nozomi Networks, Microsoft Defender for IoT, Cisco Cyber Vision) | Every device, its firmware, the protocols it speaks and who it talks to, without sending a packet. |
| Switch configurations and port maps | VLANs, rings and uplinks as they really are. |
| SCADA and historian tag lists | What data exists, where it lives and how it is named. |
| PLC programs and backups | Which controllers are in use, and whether backups exist and match. |
| Packet captures on mirror ports | Protocol details and timing for specific problems. |
| Maturity scorecard | A comparable score across connectivity, security, data, integration and people. |
OT faults are found carefully. I never scan a live control network, and I agree every action with the plant before taking it, because a fix that stops a line is not a fix.
My approach
- Define with the plant. What stopped or slowed, which line, since when, and what changed? Ask the operators first.
- Look, do not touch. Use passive monitoring, switch counters and logs before any active test.
- Physical first. Check cables, connectors, power and ring status. On the floor, physical faults are common.
- Then the protocols. Check timing and watchdogs, multicast for EtherNet/IP, and broadcast load on PROFINET segments.
- Fix in a window. Make the change in an agreed window, with the controls engineer present and a way back.
- Record. Record the cause and update the drawings, so the next shift knows.
Faults I see most
- A damaged cable or connector on a moving machine
- A ring that did not recover within the IO watchdog time
- Multicast flooding because IGMP snooping has no querier
- A duplicate IP address after a device swap
- A broadcast storm on a flat segment
- Firewall rules missing a new conduit after a change
Layer by layer
| Layer | What I check |
|---|---|
| 1 · Physical | Cables, connectors, power and PoE budget, ring port state and link errors. |
| 2 · Data link | VLANs, ring status with show rep topology on REP rings, multicast and broadcast levels, the IGMP snooping querier with show ip igmp snooping querier, and MAC table changes. All read only. |
| 3 · Network | Addressing, duplicate addresses and routing between zones through the conduits. |
| 4 · Transport | Session timeouts and firewall conduit hits, in both directions. |
| 5 to 7 · Application | Protocol timing and watchdogs, OPC UA certificates, broker connections and what the HMI shows. |
My general method is on the troubleshooting page.
OT support must work for the plant at three in the morning, so I build it around the people on site.
Who touches what
Clear rules: site engineers own the control systems, IT owns the IT side and the DMZ, and security watches both.
Remote access
One recorded route through a jump host, approved for each session, for staff and vendors alike.
Monitoring
Passive monitoring alerts tuned with the plant, so an alert means something to the shift.
Spares and backups
Spare switches and modules on site, and current backups of every PLC and switch.
Runbooks
Simple guides for the common faults, written with the site and kept at the line.
Escalation
A clear route to controls engineers, integrators and vendors, out of hours as well.
OT equipment lives far longer than IT. I plan for decades, not refresh cycles.
- Register. An asset lifecycle register with versions and vendor support dates for every device.
- Patch. Patch where the vendor approves it and the line can stop, and protect the rest with compensating controls.
- Monitor. Continuous passive monitoring, so changes and new devices are seen straight away.
- Reassess. Maturity and security reassessed every year against the same scale.
- Modernise. Old protocols wrapped or converted at the edge, rather than ripped out early.
- Replace. Replacement planned into major outages, years ahead, with the line template ready.
Projects
Where I have done this work
OT has been a thread through my career, from food depots and a rail data centre to industrial software and global manufacturers. Since 2020 it has been a large part of my work.
Inside an industrial software company
Supported IT and OT convergence across manufacturing sites: OPC DA and OPC UA from PLC layers, Modbus TCP and MQTT telemetry under SCADA and HMI platforms, zoned to feed MES and MOM (manufacturing operations management) systems. Shaped network security for AVEVA Historian and, during the OSIsoft acquisition, the PI System.
Plant to enterprise connectivity
Designed connectivity for food manufacturing sites along ISA-95 and Purdue lines, with an industrial DMZ carrying OPC UA and historian traffic from the SCADA and PLC networks to business systems.
IT and OT convergence and roadmap
Supported convergence across Dyson's global manufacturing: industrial segmentation, OT cyber security controls and secure MQTT paths to MES and cloud. Assessed OT maturity and shaped a phased roadmap covering Purdue zoning, OT security and a Unified Namespace.
Industrial data architecture
Designed MQTT broker architecture and edge gateways for smart building and industrial use cases, with topics structured as a Unified Namespace and OT to IT segmentation.
Data centre with segregated OT
Delivered the 25 million pound data centre build from an empty shell, with building management and power monitoring on a segregated OT network.
Manufacturing and mining sites
High and low level designs for Rolls Royce and Rio Tinto covering manufacturing and mining site connectivity, with control networks kept apart from corporate IT.
Warehouse automation
Integrated distribution centres after the merger, with warehouse automation segmented from corporate IT.
Cold chain at the depots
Looked after the network across the depots, including warehouse, cold chain and temperature monitoring systems linked to the group ERP.
I have also trained in OT, BMS, HVAC, and power and electrical systems, alongside my network and security certifications. See all credentials
Explore
More areas I design and deliver
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.