Industrial connectivity and edge infrastructure designed from one question: what has to keep working when the link to the data centre is down.
Industrial edge architecture should follow the latency, resilience and security needs of the plant rather than the other way around.
Work down this table for your own functions before choosing any hardware. It answers the edge versus central question more reliably than a latency budget, because the latency requirement is often negotiable and the disconnection requirement is not.
Legacy equipment with limited connectivity
A large share of installed machines expose nothing useful without added hardware. This is a cost and a lead time rather than an obstacle, and it is the first thing to quantify because it usually dominates the budget.
Fragmented industrial communication protocols
Several protocol families across one plant, some vendor-specific, some serial, some undocumented. Translation is necessary and translation is where meaning gets lost, which is addressed in section 6.
High-volume industrial data streams
High-rate signals generate volumes that are uneconomic to transmit in full and unnecessary to retain in full. What to keep raw and what to summarise is a decision to make deliberately rather than by default.
Network latency and bandwidth constraints
Usually solvable and usually not the real constraint. Plants where this is the binding limit are the exception, and treating it as the headline problem leads to the wrong architecture.
Unreliable connectivity between plants and cloud systems
This is the real constraint in most estates, and it is the one most often designed around rather than designed for. It is the subject of the table above.
Limited local processing capabilities
Edge hardware is cheap and edge operations are not. The constraint is rarely the compute; it is who patches it, who replaces it when it fails and how long the plant waits.
IT and OT integration complexity
A device on the control network has to satisfy OT security before it satisfies anyone else. The approval route is a design input, not a project risk to be managed later.
Industrial device security challenges
Devices with default credentials, shared accounts across sites and no update path. One compromise then becomes forty, which is the whole argument for per-device identity in section 7.
Difficulty managing edge infrastructure across plants
The central problem of this page past the pilot stage. A fleet with no remote update path means a site visit for every change, and that cost should be in the business case from the start.
The first gateway is an engineering exercise and it always works. The economics of the programme are decided by installations ten through two hundred, and those are dominated by things that have nothing to do with the architecture: who installs it, who fixes it, how a change is applied and what happens when an update fails.
Step 1
Industrial asset and connectivity assessment
What each machine exposes, over what protocol, and what share of the estate needs added instrumentation. This number usually determines the budget.
What each machine exposes, over what protocol, and what share of the estate needs added instrumentation. This number usually determines the budget.
Step 2
Edge computing use case identification
What each site needs locally, derived from the disconnection test rather than from a general preference for edge or cloud.
What each site needs locally, derived from the disconnection test rather than from a general preference for edge or cloud.
Step 3
Device and protocol discovery
An inventory of what is actually on the network, which almost always finds devices nobody knew were there. The inventory is a security deliverable as much as an engineering one.
An inventory of what is actually on the network, which almost always finds devices nobody knew were there. The inventory is a security deliverable as much as an engineering one.
Step 4
Edge architecture and deployment strategy
Hardware standard, software stack, the deployment mechanism and the update path, chosen for repeatability rather than for the capability of any single node.
Hardware standard, software stack, the deployment mechanism and the update path, chosen for repeatability rather than for the capability of any single node.
Step 5
Industrial gateway and connectivity design
Protocol handling, the translation layer and where the tag dictionary is applied. The dictionary itself belongs to the data platform and is referenced rather than duplicated.
Protocol handling, the translation layer and where the tag dictionary is applied. The dictionary itself belongs to the data platform and is referenced rather than duplicated.
Step 6
Local data processing and filtering implementation
What is computed locally, what is summarised and what is transmitted raw. A cost decision as much as a bandwidth one, since ingestion is usually charged for.
What is computed locally, what is summarised and what is transmitted raw. A cost decision as much as a bandwidth one, since ingestion is usually charged for.
Step 7
Cloud and enterprise platform integration
Transport, buffering and the arrival semantics the central platform must handle. This is where store and forward has to be dealt with properly.
Transport, buffering and the arrival semantics the central platform must handle. This is where store and forward has to be dealt with properly.
Step 8
Edge security and device management
Per-device identity, hardening, patching and remote update with rollback. Built in the first installation because retrofitting it across a live fleet is substantially harder.
Per-device identity, hardening, patching and remote update with rollback. Built in the first installation because retrofitting it across a live fleet is substantially harder.
Step 9
Pilot deployment and operational validation
Validated against a deliberately induced disconnection, not only against normal operation. If the recovery has not been tested, it has not been built.
Validated against a deliberately induced disconnection, not only against normal operation. If the recovery has not been tested, it has not been built.
Step 10
Multi-site scaling and lifecycle optimisation
Rollout with the per-site effort tracked, plus the end-of-life plan for hardware that will need replacing in a few years, which is rarely in the original case.
Rollout with the per-site effort tracked, plus the end-of-life plan for hardware that will need replacing in a few years, which is rarely in the original case.
Each is specified as part of a standard build rather than as an individual installation, because the second to hundredth deployment is where the cost sits.
Industrial equipment connectivity
Getting data off machines that expose it, and adding instrumentation where they do not. The split between those two groups is established in the assessment and it drives the budget.
Industrial IoT gateway implementation
A standard gateway build: one hardware specification where possible, one software image, one configuration method, one update path.
Edge data collection and processing
Local collection with the processing that has to happen near the asset: high-rate reduction, feature extraction and local aggregation.
Local event detection and analytics
Detection that must survive disconnection: stoppages, threshold breaches and state changes, evaluated locally and raised locally.
Edge-based AI inference
Models executed at the edge where the decision cannot wait for a round trip or cannot tolerate a lost link. Includes vision inference, which is the most common case.
Industrial protocol translation
Protocol handling and normalisation into a consistent representation, with the semantic mapping applied here rather than left to downstream consumers to guess at.
Data filtering and aggregation
Deciding what is transmitted, at what resolution, and what is summarised locally. Reviewed as a cost decision, because ingestion charges and retention are usually the surprise in year two.
Store and forward data buffering
Local persistence through a disconnection and ordered, deduplicated delivery on reconnection, with the downstream consequences handled explicitly rather than discovered later.
Edge device and application management
Inventory, configuration, health monitoring, software deployment and rollback across the fleet, from one place.
Cloud to edge platform integration
The link between the fleet and the enterprise platform, including the arrival semantics the platform has to accept.
Multi-plant edge infrastructure management
One operational view of every device at every site, with health, version and security state visible. This is what makes a fleet manageable by a small team.
The difficulty is named for each, because in this category the difficulty is almost always an operational constraint rather than a technical one.
Legacy machine connectivity
Getting usable data off equipment that was never designed to provide any.
Local machine condition monitoring
Condition assessment computed at the asset and available on the floor.
Edge-based equipment anomaly detection
Detecting abnormal behaviour locally so it is raised even with no link.
High-frequency sensor data processing
Reducing high-rate signals near the source into something transmittable.
Edge computer vision inference
Image capture and verdict at the line, at line rate.
Real-time production event processing
Production events detected and acted on locally within a shift.
Local energy and utility monitoring
Electricity, compressed air, water and gas measured at the point of use.
Network-disconnected data collection
Collection at sites with intermittent or no permanent connectivity.
Industrial data aggregation across production lines
One consistent feed from many lines and many machine types at a site.
Multi-plant edge deployment and management
Running the fleet as one estate rather than as a set of installations.
Variation across the fleet is the cost driver. Every permitted difference in hardware, image or configuration multiplies the testing, the patching and the troubleshooting. The architecture goal is a small number of standard builds, not an optimal build per site.
Industrial edge reference architecture
Device, gateway, local processing, buffer, transport and central platform, with the network zone each component sits in stated explicitly and every path marked read-only or read-write.
Industrial gateways and embedded computing
One hardware standard where the environment allows it, selected for availability over a multi-year life and for a supported update mechanism rather than for peak specification.
OPC UA, MQTT, Modbus and industrial protocols
OPC UA where equipment supports it, MQTT as transport, direct protocol reads where neither is available. Each protocol handled at the gateway so nothing downstream has to know which one a value came from.
PLC, SCADA, DCS and historian integration
Read-only, through a controlled conduit, with the polling rate set by the fastest thing that needs detecting and the load on the control system verified before go-live.
Edge containers and application runtimes
Containerised applications so deployment, versioning and rollback work the same way on every node. Rollback is the feature that matters most and the one most often absent.
Local time-series processing
Buffering, reduction and feature computation locally, with a reliable local clock and a time synchronisation source, since unsynchronised device clocks make cross-source data permanently unusable.
Edge AI and inference frameworks
Model packaging, deployment and versioning across the fleet, with the model version recorded alongside every inference so that a verdict can be traced to what produced it.
Cloud and hybrid IoT integration
Transport, authentication and the arrival semantics from section 5. Hybrid is the normal case rather than a transitional state, because the disconnection requirement does not disappear.
Secure event streaming and message brokers
Authenticated, encrypted transport with per-device credentials, delivery guarantees stated, and a dead letter path so an unprocessable record is visible rather than lost.
Edge fleet management and remote deployment
Inventory, health, configuration, software version and security state for every device, with staged rollout and automatic rollback on failure. This is the component that makes the fleet operable, and it is the one most often descoped to save money early.
Edge estates fail on security in a predictable way: a standard build with a standard credential, deployed everywhere, because per-device identity looked like unnecessary work during the pilot. The controls below exist to prevent that and to make the fleet patchable, which turns out to be the same problem.
IT and OT network segmentation
Devices placed in a defined zone with controlled conduits, never bridging the control network to the enterprise network. The zone model is agreed with your OT security function as a condition of the design.
Secure device identity and authentication
A unique credential per device, issued at provisioning, rotatable without a site visit, and revocable individually. No shared accounts and no default credentials in any environment.
Industrial edge access controls
Named individual accounts for human access, role-based, with privileged actions logged. Local console access controlled physically where the device is accessible on the floor.
Device hardening and patch management
A minimal image with unnecessary services removed, and a patching route that works within production windows. A device that cannot be patched remotely is an accumulating liability.
Secure software and firmware updates
Signed updates, staged rollout across the fleet, health verification after each stage and automatic rollback on failure. An update with no rollback is the mechanism by which a software change becomes a plant stoppage.
Edge data encryption and integrity
Encrypted in transit always, encrypted at rest where the device is physically accessible, and integrity checked so that a corrupted buffer is detected rather than delivered.
Local processing and operational safety boundaries
No write path from an edge application to a controller. Where a local decision has a physical consequence, that consequence is implemented in the control system under your engineering change process, not in software we deploy.
Device inventory and configuration management
A current inventory of every device, its location, its software version and its security state. Absence of this is the usual reason an estate cannot answer whether it is exposed to a given vulnerability.
Industrial cyber security standards alignment
The controls are built to be auditable against your chosen framework, with the control set documented per device class.
Secure remote monitoring and maintenance
Brokered remote access, time-bounded, approved per session and recorded. Permanent vendor tunnels into the control network are the single most common finding in an industrial security assessment.
Two hundred devices in plants around the world is a production infrastructure estate. It needs the measures any such estate needs, plus two that are specific to this context: data loss during disconnection, and patch currency across sites.
Edge device availability and health
Per device and per site, with a distinction between the device being down and the device being unreachable. They need different responses and are frequently confused.
Data processing latency
Locally, from signal to local decision, which is the figure that matters for anything the line depends on.
Gateway connectivity and reliability
Uplink availability, outage duration distribution and reconnection success. The distribution matters more than the average, since a single long outage is a different problem from many short ones.
Network bandwidth utilisation
Against the link capacity and against what is being charged for, which are different numbers and are managed differently.
Edge compute and storage utilisation
Including buffer headroom, because the buffer is only protective while it has capacity and exhausting it silently is a data loss event.
Data loss and buffering effectiveness
Records buffered, records delivered and records lost, per outage. This is the measure that tells you whether the disconnection design actually works, and it can only be collected if the recovery path reports it.
Edge application performance
Inference and processing performance per node, with the model or application version attached so that a regression can be traced to a deployment.
Device security and patch compliance
What share of the fleet is on the current version, and the age of the oldest. The oldest device is the one that matters, and reporting an average conceals it.
Edge deployment scalability
Effort and elapsed time per site, in rollout order. A flat line means there is no standard build, whatever the documentation says.
Infrastructure cost and operational optimisation
Total cost per device per year including site visits, ingestion and refresh, which is the figure that decides whether the estate can grow.
Improved industrial connectivity, with the share of the estate that needs added instrumentation quantified rather than discovered during rollout
Faster local data processing, for the functions that actually need it, which is fewer than usually assumed and non-negotiable for those few
Reduced network and cloud bandwidth dependency, with the reduction decided as a cost and information trade-off rather than applied uniformly
More resilient plant data collection, evidenced by a tested recovery from an induced full-shift outage rather than by a design claim
Improved edge application responsiveness where the function is genuinely latency-bound
Scalable multi-plant edge infrastructure, evidenced by per-site effort falling across the rollout and by a fleet a small team can actually operate
If you have a working edge pilot and a stalled rollout, the blocker is usually the update path, the device identity model or the absence of anybody named to operate the fleet. All three are fixable and none of them is an architecture problem.
CaliberFocus designs industrial connectivity and edge infrastructure from the disconnection case: what has to keep working when the link to the data centre is down. We build one standard build deployed everywhere, cost the fleet per site visit, handle store and forward properly downstream, and give every device its own identity with a remote update path and rollback.
- Every design tested against a full-shift loss of connectivity
- A standard build with remote update and automatic rollback
- Store and forward with event time, record identity and deduplication
- Per-device identity, read-only at the OT boundary
Security & Compliance
