Industrial integration is not approved on its architecture. It is approved on its write paths, and those should be chosen before the diagram is drawn.
The objective is interoperability, not control.
This table is the single most useful artefact to put in front of an OT integration project at the start. The engineering effort for these six is broadly similar. The approval effort differs by an order of magnitude.
Scope downward through this table wherever the business requirement allows it. A requirement that can be met from the historian should never be met from the controller.
Legacy industrial equipment and proprietary interfaces
Older controllers with vendor-specific protocols, sometimes undocumented, occasionally requiring a vendor tool to read at all. The vendor conversation is part of the engineering work, which is the second position on this page.
Fragmented PLC, SCADA, DCS and historian environments
Several generations and several vendors in one plant. The integration strategy is to read from the highest aggregation point that holds what you need, because every step closer to the controller costs more approval.
Inconsistent industrial communication protocols
Multiple protocol families across a plant, some serial, some proprietary. Translation is routine engineering. Where the semantics are reconciled is covered on the Industrial IoT & Edge Computing page and is not repeated here.
Limited secure connectivity between IT and OT
In most plants there is a deliberate gap, and it exists for good reasons. The work is to cross it through a reviewed, documented conduit rather than to remove it.
Disconnected industrial equipment and enterprise systems
The machine knows, the enterprise does not, and the gap is bridged by a person reading a screen and typing. That is the thing being replaced.
Industrial network reliability and availability constraints
The control network is engineered for determinism rather than throughput. Adding traffic to it is an engineering question, which is why controller reads require controls engineering approval.
Poor industrial asset and device visibility
Most plants cannot produce a current list of what is on the OT network. That list is both the first deliverable and a security finding in its own right.
Inconsistent machine data structures and tag definitions
Three machines reporting running where one means the drive is energised, one means the cycle is active and one means the PLC is in run mode. Normalising this is a definition exercise owned jointly with the execution layer.
Cyber security risks from IT and OT convergence
Every connection is a new path into a network that was previously isolated. This is why the zone model in section 6 is an amendment to an approved design rather than a fresh one.
Difficulty scaling industrial integrations across plants
Each plant has its own network layout, its own equipment mix and its own OT approver. The standard that travels is the pattern and the zone model, not the configuration.
The boundary definition is stage three of ten and everything after it depends on it. Projects that leave it until the design review have already built something that may not be approvable.
Step 1
Industrial asset and OT environment assessment
What equipment exists, what each unit exposes, and which systems already aggregate it. The historian is usually richer than anybody expects.
What equipment exists, what each unit exposes, and which systems already aggregate it. The historian is usually richer than anybody expects.
Step 2
Industrial network and protocol discovery
What is actually on the network, by passive observation where possible. This regularly finds devices nobody had recorded, which matters for security as much as for integration.
What is actually on the network, by passive observation where possible. This regularly finds devices nobody had recorded, which matters for security as much as for integration.
Step 3
IT and OT integration boundary definition
The read and write boundary, agreed in writing with OT security and controls engineering, using the table in section 2. Nothing is designed before this is signed.
The read and write boundary, agreed in writing with OT security and controls engineering, using the table in section 2. Nothing is designed before this is signed.
Step 4
Industrial connectivity architecture design
Zones, conduits, the DMZ and the data paths, prepared as an amendment to your existing approved zone model rather than as a new architecture.
Zones, conduits, the DMZ and the data paths, prepared as an amendment to your existing approved zone model rather than as a new architecture.
Step 5
Industrial device and data model mapping
Assets, tags and the meaning of each state, reconciled across vendors. The resulting dictionary is maintained as an asset rather than produced as documentation.
Assets, tags and the meaning of each state, reconciled across vendors. The resulting dictionary is maintained as an asset rather than produced as documentation.
Step 6
Secure gateway and protocol integration
Built with per-device identity and a patching route from the start. The fleet operation of those gateways at scale is covered on the Industrial IoT & Edge Computing page.
Built with per-device identity and a patching route from the start. The fleet operation of those gateways at scale is covered on the Industrial IoT & Edge Computing page.
Step 7
OT to enterprise data flow implementation
Through the DMZ, one direction wherever possible, with the enterprise side never initiating a connection into the control network.
Through the DMZ, one direction wherever possible, with the enterprise side never initiating a connection into the control network.
Step 8
Connectivity testing and operational validation
Including a measured check on the load placed on the SCADA server or the controller, before and after, which is what controls engineering will ask for.
Including a measured check on the load placed on the SCADA server or the controller, before and after, which is what controls engineering will ask for.
Step 9
Industrial cyber security and governance alignment
The control set documented per device class and handed over in a form your OT security function can audit against its own framework.
The control set documented per device class and handed over in a form your OT security function can audit against its own framework.
Step 10
Multi-plant integration standardisation and rollout
The pattern and the zone model standardised, the configuration local, and the approval route established per plant because the approver is different at each.
The pattern and the zone model standardised, the configuration local, and the approval route established per plant because the approver is different at each.
Every item below is a read path. Where a client genuinely needs a write path, we specify it, document its effect, and hand it to the engineering change process rather than implementing it.
PLC and industrial controller connectivity
Reading state, counts and parameters directly where no aggregation layer holds them, with the controller load measured before and after.
SCADA and DCS integration
Reading process state and alarms at the aggregation layer, which is usually the better route: more context, lower approval cost, less load on the controller.
Industrial historian integration
Reading recorded signals and events. The lowest-risk, fastest-to-approve integration available, and the first option to test against any requirement.
Industrial IoT gateway connectivity
Gateways where no existing layer exposes what is needed, built with per-device identity and a remote update path from the first installation.
Industrial protocol translation
Normalising multiple protocol families into one representation at the gateway, so nothing downstream needs to know which protocol a value came from.
OT to IT data integration
Through a DMZ, one direction wherever the requirement allows, with no inbound connection initiated from the enterprise side.
Machine telemetry and event ingestion
Continuous signals and discrete events delivered to enterprise platforms, with event time carried separately from arrival time.
Industrial asset and tag normalisation
The asset hierarchy and tag dictionary that make data from different vendors comparable. Maintained jointly with your controls engineers, since they hold the knowledge.
Secure industrial data exchange
Authenticated, encrypted transport with per-device credentials and a documented revocation path for each.
Manufacturing equipment integration
Per machine type, which is the unit of reusable work. The second machine of a type is fast and a new type is a new piece of engineering.
Multi-vendor industrial connectivity
Reconciling several vendors’ interfaces and state definitions into one model, including the contractual position on each from section 3.
All ten are achievable. They differ in approval cost, and the order below is the order to attempt them in if you want early delivery.
SCADA and historian data exchange
Reading what is already recorded and aggregated.
Industrial asset inventory and connectivity mapping
Establishing what is on the network and what each unit exposes.
Plant utility and energy system integration
Electricity, compressed air, water and gas metering.
Machine telemetry integration
Continuous signals from production equipment to enterprise platforms.
Industrial equipment event collection
Discrete events: starts, stops, alarms, state changes.
PLC to enterprise data integration
Reading directly from controllers where nothing else holds the data.
Legacy equipment connectivity
Getting data from equipment with proprietary or no interfaces.
Secure OT data sharing with enterprise platforms
Establishing the DMZ path and the governance around it.
Multi-vendor equipment interoperability
One model across several vendors’ equipment.
Standardised industrial connectivity across plants
One pattern and one zone model applied at every site.
Your plant already has a zone architecture. Somebody designed it, somebody approved it, and in many plants it forms part of a safety or regulatory position. An integration is a change to that design.
Presented as an amendment, with the new flows marked on the existing drawing and the control for each stated, approval is a review. Presented as a new reference architecture, it becomes a debate about architecture, and that debate takes months and is not about the integration.
Purdue Model and ISA-95 architectural alignment
Used as the shared vocabulary for describing where each component sits and which conduit it crosses. Treated as a description of your existing approved design rather than as a template to impose on it.
Industrial IoT integration reference architecture
Device, gateway, DMZ, enterprise, with every path marked read-only or read-write and every conduit named. The marked drawing is the approval document.
OPC UA, MQTT, Modbus and other industrial protocols
OPC UA where equipment supports it, MQTT for transport across the DMZ, direct protocol reads where neither exists, and a vendor protocol where that is the only option.
PLC, SCADA, DCS and historian interfaces
Read interfaces at each level, selected by the preference order in section 5 rather than by convenience.
Industrial gateways and protocol adapters
Standard build, per-device identity, remote update with rollback. Fleet operation at scale is covered on the Industrial IoT & Edge Computing page.
OT DMZ and secure network segmentation
A broker or relay in the DMZ, with the control network never reachable from the enterprise side and no inbound connection initiated across the boundary. Who operates the DMZ is named rather than assumed, because it sits between two organisations.
Event streaming and industrial message brokers
Authenticated and encrypted, with delivery guarantees stated per topic and a dead letter path so an unprocessable message is visible rather than lost.
Industrial asset and tag data models
The asset hierarchy and the tag dictionary, maintained as a living artefact with your controls engineers. Registered against the shared dictionary held by the data platform rather than kept as a second copy.
On-premises and hybrid integration
On-premises for anything the plant depends on, hybrid for everything else. Hybrid is the permanent state here rather than a transitional one.
Secure OT to cloud connectivity
Outbound only, through the DMZ, with per-device credentials and a revocation path. A cloud service holding a credential that reaches the control network is the configuration to avoid.
Governance defines who may change an interface, how exceptions get resolved, and how production continuity is protected. Everything below serves one of those three.
Each control below is standard practice. The one that decides whether a programme is approvable is the read versus write boundary, and it is listed in the middle of the brief’s own sequence because that is how these lists are usually written. It belongs first.
Read-only versus write-enabled integration boundaries
Stated per interface, in writing, before design. Our default and our delivered position is read-only. Where a write is genuinely required, we specify it, document its operational effect and hand it to your engineering change process. We do not implement control writes.
IT and OT network segmentation and access controls
Zones and conduits maintained as an amendment to the approved design, with no direct path from enterprise systems to the control network.
Industrial device identity and authentication
A unique credential per device, issued at provisioning, individually rotatable and revocable. A shared credential across a plant means a single compromise reaches everything it was installed on.
Secure remote access and connectivity
Brokered, time-bounded, approved per session and recorded. A permanent tunnel is a standing path that nobody is watching.
OT change management and maintenance windows
Changes released through the plant change process within agreed windows, with rollback. Software touching the OT environment is a plant change whichever function builds it.
Industrial system safety and availability
Integration must not affect determinism, scan time or availability. The load assessment from section 3 is the evidence, measured rather than asserted.
Industrial data ownership and traceability
Who owns the data from each machine, including the contractual position where a vendor collects it. Established in the assessment because it decides what you may use.
OT integration monitoring and incident response
Connectivity and security monitoring with an incident route that reaches both the IT and the OT side, since an industrial incident needs both and neither can resolve it alone.
Vendor access and third-party connectivity governance
Every vendor connection inventoried, assessed against the zone model and brought under the same session controls. Permanent vendor tunnels into the control network are the most common finding in an industrial security assessment.
IEC 62443 aligned security practices
The control set documented per device class in a form your OT security function can assess against the framework it uses, including the zone and conduit definitions.
An industrial integration can be available and still be losing data, and it can be working and still be drifting out of its approved security posture. Both need measuring, and neither shows up in an uptime figure.
Industrial device connectivity availability
Per device, distinguishing a device that is off from a device that is unreachable. They need different responses and are routinely confused in reporting.
Protocol and gateway reliability
Read success rate per protocol and per machine type, which localises a problem to an equipment family rather than to the network in general.
Industrial data delivery latency
From the source timestamp to enterprise availability, at the percentile that matters for the fastest consumer.
Data loss and transmission completeness
Records expected against records delivered, per device and per outage. This is the measure that shows whether the integration is actually complete, and it is the one least often collected.
Industrial network utilisation
Load added to the control network by integration, trended, because the approval was granted on a measurement and the measurement has to stay true.
Tag mapping and data quality
Share of tags with a confirmed definition and an owner, plus the number carrying a value that fails a plausibility check. Unmapped tags are data you are storing and cannot use.
Gateway and adapter performance
Resource use and processing time per node, with the software version attached so a regression can be traced to a deployment.
OT integration security posture
Credential age, patch currency, open vendor sessions and devices not in the inventory. The oldest item in each category matters, not the average.
Multi-site connectivity standardisation
Share of sites on the standard pattern, and effort per site in rollout order. A flat line means the pattern is not actually reusable.
Integration incident resolution and recovery
Time to detect and to restore, split by whether the cause was on the IT side or the OT side, because the two have different response paths and different owners.
Securely connected industrial equipment, through a documented conduit that your OT security function approved rather than tolerated
Improved IT and OT interoperability, which in practice means one approved path that later integrations reuse instead of each one negotiating its own
Better industrial data availability, usually achieved from the historian and SCADA rather than from controllers, at a fraction of the approval cost
Reduced integration complexity, by reading from the highest point that holds what is needed rather than from the deepest
Improved legacy equipment connectivity, subject to the vendor position in section 3, which occasionally makes a machine genuinely inaccessible
A scalable industrial integration architecture, where the pattern and the zone model travel between plants even though the approval does not
If an industrial integration proposal has been sitting with OT security for two months, the cause is usually a write path nobody meant to request, or a zone drawing presented as a new architecture. Both are fixable in a week.
CaliberFocus scopes industrial integration by its write paths before anything is designed. We read from the highest point that holds what you need, present every change as an amendment to your approved zone design, check the vendor position on each machine type early, and hand any genuine write path to your engineering change process rather than implementing it.
- Read and write boundaries agreed in writing with OT security
- Historian and SCADA first, controllers only when necessary
- Zone changes presented as amendments to your approved design
- Vendor support and data-ownership positions checked per machine type
Security & Compliance
