IIoT Edge Computing: Deploying Industrial Edge Nodes on the Plant Floor

Edge computing brings data processing close to where data is generated: the plant floor. Instead of sending every sensor reading to the cloud, edge nodes process, filter, and analyse data locally, sending only actionable insights upstream. This reduces bandwidth, improves latency, and enables local autonomy when cloud connectivity is unavailable.

What Problems Edge Computing Solves

• Bandwidth constraints: A refinery may have 50,000+ sensor points. Streaming all data at 1-second resolution to the cloud would require enormous bandwidth. Edge aggregation reduces this by 90%+ by sending only exceptions, averages, and key performance indicators.
• Latency: Real-time analytics (vibration anomaly detection, predictive maintenance triggers) cannot wait for a cloud round-trip. Edge processing enables sub-second response.
• Resilience: Edge nodes continue operating during WAN outages, ensuring local monitoring and control continuity.

Common Edge Hardware

• Industrial PCs (IPCs): Ruggedised x86 platforms (Beckhoff, Moxa, Advantech) running Windows 10 IoT or Linux
• ARM-based gateways: Lower power consumption, suitable for remote sites. Raspberry Pi Compute Module in hardened enclosures.
• PLC-integrated edge: Siemens SIMATIC ET 200SP Open Controller, Rockwell Logix with FactoryTalk Edge, Emerson PACSystems with edge analytics

Edge Software Stack

A typical industrial edge node runs:

• OPC UA server/client: Collects data from PLCs and field devices
• MQTT broker: Local message routing (Mosquitto)
• Stream processing: Node-RED, Apache Kafka, or AVEVA Edge for data transformation
• Container runtime: Docker or K3s for deploying microservices
• Time-series database: InfluxDB or TimescaleDB for local storage

Ignition Edge

Inductive Automation’s Ignition Edge is the most widely deployed industrial edge platform. It runs on any hardware capable of running Java, collects data from any OPC UA or legacy device, and syncs data to a central Ignition server using Store and Forward – ensuring no data is lost during connectivity outages.

Security at the Edge

Edge nodes are often more exposed than centralised systems. Security requirements:

• Hardware security module (TPM 2.0) for key storage
• Signed software images and verified boot
• Minimal attack surface: disable unused ports, services, and user accounts
• Out-of-band management for remote access to edge nodes

Edge Node Hardware: What to Deploy

Industrial edge nodes run on hardened hardware designed to survive plant floor conditions: wide temperature range, vibration resistance, DIN rail mounting, and fanless operation for low-maintenance environments. Common hardware platforms:

• Fanless industrial PCs: Beckhoff CX series, Advantech ARK series, Moxa V2600 series. Run full Linux or Windows IoT operating systems. Support any edge software stack. Most flexible option, highest initial cost.
• ARM-based edge gateways: Siemens SIMATIC IOT2050, Phoenix Contact PLCnext, Advantech WISE series. Lower power, lower cost than industrial PCs. Run Linux. Good fit for data collection and lightweight analytics.
• Vendor-specific edge hardware: Emerson Edge Computing Node, Honeywell Forge Edge Devices, ABB Ability Edge. Tightly integrated with the vendor’s cloud platform. Lowest integration effort when staying within one vendor ecosystem; creates lock-in.
• Ruggedised server appliances: Dell PowerEdge XE series, HPE Edgeline EL300. More computing power for AI inference and high-bandwidth data processing at the edge. Used when the edge node needs to run complex models or process video from multiple cameras.

Edge Software Stacks

The software on an industrial edge node typically has three layers:

• Connectivity layer: Reads data from OT systems via OPC UA, Modbus TCP, PROFINET, EtherNet/IP, or MQTT. Kepware, Ignition Edge (Inductive Automation), and Softing dataFEED are common connectivity platforms. This layer abstracts the protocol diversity of the plant floor into a consistent data model.
• Processing layer: Transforms, filters, and analyses data locally. May run rules engines (Node-RED, Azure Stream Analytics Edge), machine learning models (TensorFlow Lite, ONNX Runtime), or statistical processing algorithms. The processing layer is what distinguishes a smart edge node from a dumb data forwarder.
• Communication layer: Transmits results upstream to cloud or on-premise systems via MQTT, OPC UA Pub/Sub, REST APIs, or vendor-specific protocols. Handles connection management, message buffering during network outages, and security (TLS, certificate management).

Data Reduction: Why It Matters

A single process plant with 10,000 instruments reporting every second generates approximately 10,000 data points per second, or 864 million data points per day. Sending all of this to the cloud is technically possible but economically impractical at scale — cloud data ingestion and storage costs accumulate rapidly.

Edge nodes reduce data volume through:

• Report-by-exception: Only transmit when a value changes beyond a configured deadband. A stable temperature transmitter reading 150°C with a 0.5°C deadband reports only when the value crosses 150.5°C or 149.5°C — potentially saving thousands of transmissions per hour.
• Aggregation: Instead of sending 3,600 individual readings per hour, send one record per hour containing min, max, average, and standard deviation. Sufficient for most trending and performance monitoring applications.
• Event detection: Run a pattern detection algorithm at the edge that detects the start and end of a process event (pump starts, batch starts, equipment fault onset) and send only the event record, not the raw time series.

Edge Security Considerations

Edge nodes introduce new attack surfaces. They connect to both the OT network (reading field data) and the IT network or internet (sending data upstream). This dual-homed position must be secured carefully:

• Edge nodes should have read-only access to the OT network — they read data but cannot issue control commands. Verify that the connectivity layer software does not expose write-capable OPC UA or Modbus server endpoints on the OT network interface.
• The uplink connection (to cloud or corporate network) should use TLS with certificate pinning. Edge nodes should authenticate to cloud services using unique device certificates, not shared passwords.
• Edge nodes must be included in the OT patching programme. An unpatched Linux edge node connected to both the OT and cloud networks is a potential lateral movement path between IT and OT environments.
• Apply the principle of least privilege to the OT connectivity configuration — the edge node should only have access to the specific tags it needs to collect, not to the entire controller data space.

Getting Started: A Practical Deployment Approach

Successful edge computing deployments follow a staged approach rather than plant-wide big-bang deployments:

1. Identify a single high-value use case — predictive maintenance on a critical pump, energy monitoring for a major consumer, quality correlation for a key process parameter
2. Deploy one edge node connected to the relevant data sources for that use case
3. Validate the data pipeline end-to-end: connectivity to the field device, processing on the edge node, transmission to the target system, visualisation at the receiving end
4. Measure the value delivered (reduced downtime, energy savings, quality improvement) against the deployment cost
5. If the value case is proven, scale the deployment using the same architecture and tools, not a new platform for each use case

The trap is buying a platform before proving the use case. Edge computing platforms are sold with compelling dashboards and demos that are easy to generate. The hard part is connecting them to real OT data sources, maintaining them through plant network changes, and deriving consistent value from the data they collect. Prove that on a small scale first.