INDUSTRIAL IoT and Industry 4.
Topics Covered
1. Introduction to IIoT
2. Industrial Internet Architecture Framework (IIAF)
3. Layers in IIoT – Sensing Layer
4. IIoT Processing Layer
5. IIoT Communication Layer
6. IIoT Networking Layer
7. Industry 4.0
8. Software Defined Networking (SDN)
9. Wireless Sensor Networks (WSN)
1. Introduction to IIoT
Industrial Internet of Things — Concepts, Characteristics & Applications
1.1 What is IIoT?
The Industrial Internet of Things (IIoT) refers to the extension and use of the Internet of Things (IoT)
in industrial sectors. It involves interconnecting machines, instruments, sensors, actuators, and
industrial equipment through the internet, enabling them to collect, exchange, and analyse data for
intelligent industrial decision-making, automation, and efficiency gains.
IIoT is the convergence of Information Technology (IT) and Operational Technology (OT). IT covers
enterprise systems (ERP, MES, databases, cloud), while OT covers industrial control systems
(PLCs, SCADA, DCS, sensors). IIoT bridges these two traditionally separate worlds to create a
unified, data-driven industrial enterprise.
Term Definition
IoT Internet of Things — general consumer and enterprise device
connectivity
IIoT Industrial IoT — IoT applied specifically in manufacturing,
utilities, logistics, energy
OT Operational Technology — hardware/software that controls
physical industrial processes
IT Information Technology — enterprise data, networking,
software, cloud systems
IT/OT Convergence Integration of enterprise IT with industrial OT for seamless
data flow
CPS Cyber-Physical Systems — tight coupling of computational
elements with physical processes
M2M Machine-to-Machine — direct communication between
industrial devices without human intervention
1.2 Key Characteristics of IIoT
Massive Connectivity: Thousands to millions of heterogeneous devices, sensors, and
machines connected across sites.
Real-Time Data Acquisition: Continuous, high-frequency data collection from physical
processes.
Edge Intelligence: Local processing and decision-making at the point of data generation,
reducing latency and bandwidth.
Interoperability: Devices and systems from different vendors communicate using standard
protocols (OPC-UA, MQTT).
Reliability & Safety: Industrial systems demand 99.999% uptime; failures can cause safety
incidents and production loss.
Security: Critical infrastructure requires strong device authentication, encryption, and
network segmentation.
Scalability: Architecture must scale from dozens to millions of devices without redesign.
Latency Requirements: Time-critical applications (robotic control) need sub-millisecond
latency; analytics can tolerate seconds.
1.3 IIoT vs. Consumer IoT
Aspect Consumer IoT IIoT
Environment Homes, offices, wearables Factories, plants, grids, mines
Reliability Best-effort acceptable 99.999% uptime required
Safety Inconvenience if fails Physical harm if fails
Latency Seconds acceptable Microseconds–milliseconds needed
Data Volume Low–moderate Very high (high-frequency sensors)
Device Lifespan 1–5 years 10–30+ years (legacy equipment)
Security Priority Privacy-focused Safety and availability-focused
Standards Wi-Fi, Bluetooth, Zigbee PROFINET, Modbus, OPC-UA,
HART
Protocol Simple (HTTP, MQTT) Complex (IEC 61131, PROFIBUS,
Complexity DNP3)
1.4 IIoT Application Domains
1.4.1 Smart Manufacturing
IIoT enables the connected factory by integrating production machines, quality systems, material
handling, and enterprise software into a single data fabric. Applications include:
Predictive Maintenance: Vibration, temperature, and acoustic sensors on motors/pumps
detect early-stage faults, allowing maintenance before failure. Example: A bearing vibration
sensor triggers an alert 2 weeks before failure, saving £200,000 in unplanned downtime.
Quality Control: Vision systems and in-line sensors monitor product dimensions, surface
defects, and chemical composition in real time, rejecting defects before assembly.
Overall Equipment Effectiveness (OEE): Real-time tracking of availability, performance,
and quality to identify bottlenecks.
Digital Twin: Virtual replica of a machine or process fed by live IIoT sensor data for
simulation, optimisation, and remote monitoring.
1.4.2 Energy & Utilities
Smart Grid: Advanced metering infrastructure (AMI), grid sensors, and SCADA systems
enable two-way energy flow management, demand response, and fault isolation.
Oil & Gas: Pipeline monitoring (pressure, flow, leaks), remote wellhead monitoring, and
offshore platform condition monitoring.
Water Treatment: pH, turbidity, chlorine, and flow sensors enable automated, safe water
treatment with remote monitoring.
1.4.3 Logistics & Supply Chain
Asset Tracking: RFID, GPS, BLE tags on containers, vehicles, and pallets provide real-
time location and condition (temperature, humidity for cold chain).
Warehouse Automation: Autonomous Mobile Robots (AMRs), conveyor sensors, and
barcode/RFID systems for inventory management.
1.4.4 Healthcare & Pharmaceuticals
Environmental Monitoring: Temperature, humidity, and CO2 sensors in GMP
manufacturing facilities and cold storage.
Medical Device Monitoring: Remote monitoring of life-critical medical equipment for uptime
and calibration.
Example: Automotive Plant IIoT Deployment
A major automotive manufacturer deploys 12,000 vibration sensors on CNC machines,
welding robots, and conveyor drives across a single plant. Each sensor node transmits
data at 1kHz via WirelessHART to factory-floor gateways. Edge AI running on the
gateways processes FFT spectra in real time to detect early bearing and gear-mesh
faults. Predicted maintenance alerts are forwarded via MQTT over PROFINET to the MES
system, which auto-generates work orders in SAP. The plant achieved a 35% reduction in
unplanned downtime in the first year.
1.5 Benefits and Challenges of IIoT
Aspect Benefits Challenges
Operations Reduced downtime, higher OEE Integration with legacy brownfield
equipment
Maintenance Predictive → proactive → no Sensor calibration, false alarm
unplanned failure management
Energy 15–30% energy savings through High upfront investment
optimisation
Quality Real-time defect detection, zero- Data quality from harsh environment
defect goals sensors
Safety Remote monitoring of hazardous Cybersecurity vulnerabilities from
processes connectivity
Business New service models (outcome-based Skills gap — OT engineers lack
contracts) IT/data skills
2. Industrial Internet Architecture Framework
(IIAF)
IIC Reference Architecture — The Blueprint for IIoT System Design
2.1 What is IIAF?
The Industrial Internet Architecture Framework (IIAF) — formally the Industrial Internet Reference
Architecture (IIRA) — is published by the Industrial Internet Consortium (IIC). It provides a standard,
vendor-neutral architectural framework and reference model for designing, deploying, and operating
IIoT systems across all industries.
The IIAF is not a single architecture but a framework of viewpoints and concerns, each addressing
a different set of stakeholders and design decisions. It enables system architects to reason about
IIoT systems at multiple levels — from the business goals down to the individual component
interactions.
2.2 Four Architectural Viewpoints
The IIAF defines four key architectural viewpoints, each answering a different fundamental
question:
Viewpoint Purpose & Key Questions
Business Viewpoint Why? — Business vision, values, stakeholders, objectives.
What business outcomes does the IIoT system achieve? Who
are the stakeholders? What KPIs matter?
Usage Viewpoint What? — Expected system behaviour from a user/operator
perspective. What tasks are performed? What activities flow
through the system? How do humans interact?
Functional Viewpoint How? — Functional components and their interactions. What
software and hardware functions are required? How do
components communicate and integrate?
Implementation With What? — Technologies, products, standards, and
Viewpoint lifecycles. How is the system implemented, deployed, managed,
and decommissioned? What technologies are selected?
2.3 IIAF Functional Domains
The Functional Viewpoint decomposes an IIoT system into five functional domains. These form the
backbone of the functional architecture:
IIAF Five Functional Domains
Layer / Component Description / Function
Real-time sensing and actuation of physical processes. PLCs,
Control Domain DCS, RTUs, safety systems. Latency: microseconds–
milliseconds.
Operational management, monitoring, and optimisation.
Operations Domain
SCADA, MES, maintenance systems, OEE dashboards.
Data collection, aggregation, transformation, and analytics.
Information Domain
Historians, data lakes, stream processors, ML inference.
Business-facing applications: ERP, supply chain, enterprise
Application Domain
reporting, digital twin visualisation.
Strategic business processes, decision-making, financial
Business Domain
systems, and external ecosystem integration.
Figure: IIAF Five Functional Domains
2.4 Three-Tier Architecture
Within the IIAF, a three-tier hierarchy organises the physical structure of IIoT deployments:
IIAF Three-Tier Deployment Architecture
Layer / Component Description / Function
Centralised cloud or data centre. Global analytics, AI/ML model
Cloud Tier (Tier 3) training, enterprise integration, long-term storage. Latency-
tolerant workloads.
Edge gateways, fog nodes, on-premises servers. Data
Edge Tier (Tier 2) aggregation, filtering, real-time analytics, protocol translation.
Moderate latency.
Field-level physical devices: sensors, actuators, PLCs, RTUs.
Device Tier (Tier 1) Raw data collection, real-time control. Ultra-low latency
required.
Figure: IIAF Three-Tier Deployment Architecture
Data flows upward through the tiers — from physical devices through the edge for real-time
processing, to the cloud for long-term analytics and enterprise integration. Control commands flow
downward. This bidirectional data flow is a hallmark of IIoT systems.
2.5 IIAF Crosscutting Concerns
Crosscutting concerns span all viewpoints and domains. They must be addressed at every layer of
the architecture:
Security: End-to-end protection including device identity, authentication, encryption,
network segmentation (IEC 62443 standard). Security must be built in from the start — not
bolted on.
Safety: Functional safety standards (IEC 61508, IEC 61511) ensuring the system does not
endanger people, equipment, or environment. Safety-critical systems require certified
hardware and software.
Resilience: System ability to withstand failures, cyber attacks, and environmental
conditions. Includes redundancy, failover, offline operation capability.
Interoperability: Ability of diverse devices, systems, and organisations to exchange and
use information. Requires standard protocols (OPC-UA, MQTT), data models, and APIs.
Connectivity: Reliable, managed connections between all system tiers using appropriate
wired and wireless technologies.
Data Management: Lifecycle management of data: acquisition, quality, storage, access,
retention, and disposal.
Analytics: Processing data to extract insight — descriptive (what happened?), diagnostic
(why?), predictive (what will happen?), prescriptive (what should we do?).
Operations & Mgmt: System-wide monitoring, configuration, software updates, fault
management, and performance management.
2.6 IIAF System Characteristics
Characteristic Description
Connectivity All IIoT components — devices, systems, people — must be
reliably connected, discoverable, and addressable.
Intelligence Data-driven decision-making enabled by analytics and AI, from
simple threshold alerts to machine learning predictions.
Operational Agility Ability to rapidly adapt processes, configurations, and
deployments to meet changing business needs.
Resilience Maintain core functions under failure conditions; graceful
degradation rather than complete system failure.
Interoperability Systems from different vendors, protocols, and generations must
work together without custom integration work.
Example: IIAF in a Smart Water Utility
A water utility applies IIAF to design their IIoT system. Business Viewpoint: Reduce water
loss (non-revenue water) from 25% to below 12% within 3 years. Usage Viewpoint:
Operations team monitors pressure zones and flow balance on a SCADA dashboard;
alarms trigger field engineer dispatch. Functional Viewpoint: 4,000 pressure/flow sensors
(Device Tier) feed edge gateways (Edge Tier) that run hydraulic model-based leak
detection algorithms; results flow to the control room SCADA (Operations Domain) and a
cloud analytics platform (Information Domain) for long-term trend analysis. Implementation
Viewpoint: NB-IoT for remote sensor connectivity; InfluxDB time-series historian; Azure
IoT Hub; OPC-UA for SCADA integration.
3. IIoT Sensing Layer
Physical Data Acquisition — Sensors, Actuators, Signal Conditioning & Interfaces
3.1 Role of the Sensing Layer
The Sensing Layer is the foundational tier of every IIoT system — it is the physical interface
between the digital world and the real industrial environment. Without reliable, accurate sensing, the
rest of the architecture has no meaningful data to process. The sensing layer continuously monitors
physical quantities such as temperature, pressure, vibration, flow, and chemical concentration,
converting them into electrical or digital signals that upper layers can act upon.
Data Acquisition: Continuously or periodically sample physical quantities from the industrial
environment.
Signal Conditioning: Amplify, filter, and compensate raw sensor signals to remove noise
and measurement errors.
Analog-to-Digital Conversion: Convert continuous analog voltages/currents to discrete
digital values for processing.
Actuation: On command from the control/processing layer, drive actuators to effect physical
change (open a valve, start a motor).
Local Intelligence: Modern smart sensor nodes include microcontrollers that pre-process
data, apply calibration curves, detect local alarms, and manage power states.
Sensing Layer Internal Architecture
Layer / Component Description / Function
Industrial process: temperature, pressure, flow, vibration,
Physical World
chemical concentration, position, current, voltage
Converts physical quantity ↔ electrical signal. Sensor: physical
Transducer
→ electrical. Actuator: electrical → physical action.
Amplification (op-amp), filtering (low-pass/band-pass), isolation
Signal Conditioning
(galvanic), offset/gain compensation.
Analog-to-Digital Converter: samples signal at rate fₛ ≥ 2f_max
ADC / DAC
(Nyquist). DAC for actuator drive signals.
Microcontroller (STM32, ESP32, MSP430): applies calibration,
Sensor Node / MCU
manages sampling, handles power modes, buffers data.
Wired: 4-20mA, Modbus RTU, HART, IO-Link, I²C, SPI.
Local Interface
Wireless: WirelessHART, Zigbee, BLE to field gateway.
Figure: Sensing Layer Internal Architecture
3.2 Types of Sensors in IIoT
Sensor Type Technology & IIoT Applications
Temperature Thermocouple (K-type: −200°C to 1260°C), RTD (Pt100/Pt1000,
high accuracy), NTC thermistor (PCB monitoring). Used in:
furnaces, HVAC, chemical reactors, food processing.
Pressure Piezoelectric (dynamic pressure, vibration), capacitive (differential
pressure), strain-gauge (absolute/gauge). Used in: pipelines,
hydraulics, compressors, pneumatics.
Flow Coriolis (mass flow, high accuracy), ultrasonic (clamp-on, non-
invasive), electromagnetic (conductive fluids), turbine. Used in:
water/gas utilities, chemical dosing, fuel management.
Vibration / MEMS accelerometer (±2g to ±200g), piezoelectric ICP sensor.
Acceleration Used in: predictive maintenance of motors, pumps, fans,
compressors, gearboxes.
Level Ultrasonic (non-contact), radar (guided wave), float, hydrostatic
pressure. Used in: tanks, silos, reservoirs, chemical storage.
Proximity / Position Inductive (metallic targets, 0–30mm), capacitive (any material),
ultrasonic, photoelectric (long range). Used in: assembly lines,
robotics, conveyor position detection.
Current / Voltage Hall-effect sensor (non-contact DC/AC current), shunt resistor,
current transformer (CT). Used in: motor current monitoring, power
quality, energy metering.
Gas / Chemical Electrochemical (O₂, CO, H₂S), infrared (CO₂, CH₄),
photoionisation detector (VOCs). Used in: industrial safety, leak
detection, air quality, combustion control.
Image / Vision CMOS/CCD industrial cameras, hyperspectral, LiDAR. Used in:
visual inspection, dimensional measurement, robot guidance,
access control.
RFID / NFC 125kHz (LF) passive RFID, 13.56MHz (HF) NFC, 860-960MHz
(UHF) long-range RFID. Used in: asset tracking, WIP tracking,
access control, anti-counterfeiting.
3.3 Actuators
Actuators receive electrical control signals and produce a physical action, completing the closed-
loop control cycle. Key actuator types in IIoT:
Electric Motors (AC/DC, servo, stepper): Drive conveyors, pumps, compressors, CNC
axes, robotic joints. Controlled via VFDs (Variable Frequency Drives) for speed and torque.
Solenoid Valves: Electromagnetic coil opens/closes fluid or gas flow. Used in pneumatics,
hydraulics, process piping.
Proportional/Control Valves: Continuous positioning for precise flow or pressure
regulation. Driven by 4–20mA or digital position feedback.
Pneumatic / Hydraulic Cylinders: Linear or rotary motion for heavy-duty industrial
movement. Used in presses, clamps, and heavy equipment.
Relays & Contactors: Switching large electrical loads (motors, heaters) from low-level
control signals.
Heaters & Cooling Elements: Resistance heaters, Peltier modules, heat exchangers
driven by PID controllers for thermal management.
3.4 Sensing Protocols and Interfaces
Sensors connect to PLCs, gateways, and control systems via standardised hardware interfaces and
protocols:
Interface / Protocol Description & Usage
4–20 mA Current Loop Oldest and most robust analog standard. Current is proportional
to the measured value (4mA=0%, 20mA=100%). Immune to cable
resistance and voltage noise. Used for process sensors over long
runs (up to 1000m).
HART (Highway Adds digital FSK communication on top of the 4–20mA signal
Addressable Remote simultaneously. Allows device configuration, diagnostics, and
Transducer) secondary variables without additional wiring.
Modbus RTU/ASCII RS-485 serial protocol. Master-slave, simple register-based data
model. Universally supported in PLCs and field devices. 9600–
115200 baud, up to 247 nodes.
Modbus TCP/IP Modbus over Ethernet. Simple integration with industrial Ethernet
networks. Widely used in SCADA-to-PLC communication.
IO-Link (IEC 61131-9) Point-to-point digital communication standard for smart sensors
and actuators. 3-wire unshielded cable, up to 20m. Replaces
discrete wiring with serial digital interface. Enables sensor
parameterisation and diagnostics.
PROFIBUS DP/PA RS-485 based fieldbus (DP: factory automation) and MBP current
loop (PA: process automation/intrinsically safe). Up to 12 Mbit/s
(DP), 126 nodes.
Foundation Fieldbus IEC/ISA fieldbus for process automation. Carries power and data
(FF) on same 2-wire cable. Supports function blocks running in field
devices.
I²C / SPI / UART Low-level chip-to-chip interfaces used within sensor nodes and
between sensor modules and MCUs. I²C: 2-wire, up to 3.4 Mbps;
SPI: 4-wire, up to 50 Mbps; UART: 2-wire async serial.
Example: Smart Sensor Node for Predictive Maintenance
A wireless vibration sensor node (e.g., SKF Enlight Collect IMx-16) is bolted to a pump
motor bearing housing. The MEMS accelerometer samples at 25.6 kHz. The onboard
STM32 MCU computes FFT spectra every 10 seconds, extracts RMS, kurtosis, and
bearing defect frequency amplitudes, and applies ISO 10816 severity thresholds. When a
broadband vibration rise is detected, the node transmits an alert via WirelessHART to the
plant gateway. The gateway forwards the event and trend data via MQTT to the cloud-
based CMMS (Computerised Maintenance Management System), which auto-schedules a
maintenance work order.
3.5 Key Challenges in the Sensing Layer
Harsh Environments: Industrial sensors face extreme temperatures (−40°C to +200°C),
vibration, chemical exposure, dust, and humidity. IP67/IP68 and ATEX (explosive
atmosphere) ratings are critical.
Calibration Drift: Sensors degrade and drift over time. Regular calibration with traceable
standards is essential for measurement integrity.
Power Supply: Remote sensors in the field may need battery power, energy harvesting
(solar, vibration, thermal), or long-distance loop power.
Signal Noise: Industrial environments (welding, VFDs, motors) generate intense
electromagnetic interference. Shielding, galvanic isolation, and differential signalling mitigate
this.
Data Density: High-frequency sensors (vibration at 25kHz, cameras at 60fps) generate
enormous data volumes. Edge processing to extract features before transmission is
essential.
Legacy Integration: Millions of installed sensors use 4–20mA, HART, and Modbus. IIoT
gateways must support these alongside modern wireless protocols.
4. IIoT Processing Layer
Edge, Fog & Cloud Computing — Data Analytics, AI/ML & Industrial Control
4.1 Role of the Processing Layer
The Processing Layer is the intelligence engine of IIoT. It receives raw data from the Sensing
Layer, transforms it into meaningful information, and generates decisions or commands. Processing
can occur at three tiers: the Edge (at or near the sensor), the Fog (intermediate regional nodes),
and the Cloud (centralised remote servers). The key design challenge is deciding which processing
belongs at which tier, balancing latency, bandwidth, reliability, and cost requirements.
Processing Layer Architecture — Edge, Fog, and Cloud Tiers
Layer / Component Description / Function
Global analytics, AI/ML model training, ERP/MES integration,
Cloud Tier long-term data storage, fleet-wide insights. Latency: 100ms–
10s.
Site/zone-level aggregation, complex analytics, OPC-UA server,
Fog / Edge Server SCADA historian, multi-machine correlation. Latency: 10–
500ms.
Protocol translation, data filtering, local threshold alarms, edge
Edge Gateway
AI inference, store-and-forward buffering. Latency: 1–50ms.
Real-time control loops (PID), local ADC processing, safety
Smart Sensor / PLC
interlock logic, on-node anomaly detection. Latency: <1ms.
Figure: Processing Layer Architecture — Edge, Fog, and Cloud Tiers
4.2 Edge Computing
Edge computing places computation at the data source — on the sensor node, machine controller,
or local gateway. This eliminates the need to send raw data to the cloud before making a decision,
enabling real-time response, reduced bandwidth costs, and autonomous operation when cloud
connectivity is unavailable.
4.2.1 Why Edge?
Latency: Safety-critical and real-time control decisions cannot wait for a round-trip to the
cloud (100ms+). Edge processes in microseconds to milliseconds.
Bandwidth: A vibration sensor sampling at 25 kHz generates ~50MB/sec. Edge FFT
processing reduces this to <1KB/sec of trend data sent to cloud.
Reliability: Edge processing continues during network outages with store-and-forward data
buffering.
Privacy: Sensitive production data (recipes, IP-protected process parameters) stays on-
premises.
4.2.2 Edge Computing Devices
Device Examples & Capabilities
Industrial IoT Advantech ECU-1251, Siemens IoT2050, Moxa UC-8112. ARM/x86
Gateway CPU, Linux OS, multi-protocol support, local storage, VPN.
Embedded AI NVIDIA Jetson Nano/Orin (GPU edge AI for vision), Google Coral
Accelerators Edge TPU, Intel Movidius (neural network inference at <5W).
Industrial PCs (IPCs) Fanless, ruggedised x86 PCs running real-time Linux or Windows
for more complex edge analytics.
Smart PLCs Siemens S7-1500 with Edge Module, Rockwell Logix with Analytics
— run IEC 61131 control alongside OPC-UA and edge analytics.
4.3 Fog Computing
Fog computing (defined by OpenFog Consortium / IEEE 1934) extends cloud computing
capabilities to the network edge through a distributed, hierarchical computing infrastructure. Fog
nodes sit between the edge devices and the cloud, aggregating data from multiple machines or
zones, running more complex analytics, and reducing the data volume forwarded to the cloud.
Multi-source data fusion: Correlates data from multiple machines to detect systemic
process issues.
Pre-processing and aggregation: Computes statistics (min/max/mean/std) over time
windows before cloud upload.
Latency reduction: Serves local applications with lower latency than cloud.
Offline resilience: Maintains local dashboards and alarms even during cloud connectivity
loss.
Example: Fog Node in an Automotive Paint Shop
A fog server in the paint shop aggregates data from 120 sensors monitoring oven
temperatures, paint viscosity, conveyor speed, and exhaust fan currents. It runs a
multivariate SPC (Statistical Process Control) model that correlates paint film thickness
deviations with upstream process variables. This correlation analysis is too data-intensive
for individual edge gateways. The fog server sends only out-of-spec events and daily KPI
summaries to the cloud ERP system, reducing cloud data transfer by 98%.
4.4 Cloud Computing in IIoT
Cloud computing provides virtually unlimited, elastic compute and storage resources for workloads
that are not time-critical. Its role in IIoT:
AI/ML Model Training: Large historical datasets (years of sensor data) are used to train
predictive models. Trained models are then deployed back to edge devices.
Cross-site Analytics: Compare performance KPIs across all manufacturing sites globally to
identify best practices.
Long-Term Data Storage: Compliance archiving, warranty data, traceability records.
Enterprise Integration: Connect IIoT data to ERP (SAP, Oracle), MES, PLM, and supply
chain systems.
Digital Twin Platforms: Synchronise live sensor data with 3D physics models for remote
monitoring and simulation.
Cloud Platform Key IIoT Features
AWS IoT Core Managed MQTT broker, rules engine, IoT SiteWise (asset
modelling), SageMaker (ML), Timestream (time-series DB)
Azure IoT Hub Device twins, IoT Edge (containerised edge modules), Stream
Analytics, Azure Digital Twins, Defender for IoT
GCP IoT Core Pub/Sub, Dataflow (stream processing), BigQuery (analytics),
Vertex AI (ML), Cloud IoT Edge
Siemens Industrial-specific, OPC-UA native, Insights Hub for asset analytics,
MindSphere integration with Siemens PLM
PTC ThingWorx Industrial IoT platform, Kepware OPC connectivity, AR-enabled
operator guidance, Windchill PLM integration
4.5 Data Processing Pipeline
IIoT Data Processing Pipeline
Layer / Component Description / Function
Unprocessed sensor readings — noisy, in raw engineering units
1. Raw Data
(e.g., 2481 ADC counts, 4.73mA)
Collected via MQTT/OPC-UA into a message broker (Kafka,
2. Ingestion
RabbitMQ) or time-series DB buffer
Remove outliers (3-sigma filter), handle missing values
3. Cleansing
(interpolation), de-noise (moving average, Kalman filter)
Unit conversion (ADC → °C using calibration polynomial),
4. Transformation
normalisation, unit alignment
RMS, peak, kurtosis, FFT spectrum, STFT, statistical features
5. Feature Extraction
for ML models
Rule-based threshold alerts, anomaly detection (Isolation
6. Analytics / ML Forest, Autoencoder), fault classification (CNN/LSTM),
remaining useful life (RUL) prediction
Alert generation, actuator command, maintenance work order in
7. Decision / Action
CMMS, dashboard update, ERP integration
Figure: IIoT Data Processing Pipeline
4.6 Industrial Control — PLC & DCS
PLCs and DCS are the real-time control processors at the base of the processing layer. They
execute deterministic control cycles, often at 1–10ms cycle times.
4.6.1 PLC (Programmable Logic Controller)
Architecture: CPU, I/O modules (DI/DO/AI/AO), communication modules, power supply in a
modular rack.
Programming: IEC 61131-3 languages: Ladder Diagram (LD), Function Block Diagram
(FBD), Structured Text (ST), Sequential Function Chart (SFC), Instruction List (IL).
Examples: Siemens S7-1200/S7-1500, Allen-Bradley CompactLogix/ControlLogix,
Mitsubishi MELSEC iQ-R, Schneider Modicon M340.
IIoT Integration: Modern PLCs include built-in OPC-UA servers, MQTT clients, and
PROFINET/EtherNet/IP connectivity.
4.6.2 DCS (Distributed Control System)
DCS manages continuous and batch process control for large-scale plants (refineries, power
stations, chemical plants). It distributes control across multiple field controllers, all connected to a
centralised operator station.
Examples: Honeywell Experion PKS, ABB System 800xA, Emerson DeltaV, Siemens
SIMATIC PCS 7.
IIoT Integration: OPC-DA/OPC-UA historians export process data to IIoT analytics
platforms.
4.7 Time-Series Databases
Sensor data is inherently time-stamped and sequential. Specialised time-series databases provide
efficient write throughput, compressed storage, and fast time-range queries:
Database Key Features
InfluxDB Open-source, purpose-built for IoT. Flux query language. High write
throughput. Cloud-hosted InfluxDB Cloud available.
TimescaleDB PostgreSQL extension. Automatic time partitioning. Full SQL support.
Best for mixed time-series + relational queries.
OSIsoft PI Industry-standard process historian. PI Asset Framework (AF) for
(AVEVA) asset modelling. Widely used in oil & gas, utilities.
Apache Distributed NoSQL. Massive write scalability across datacentres.
Cassandra Used by large-scale IIoT data lakes.
QuestDB Extremely high-performance columnar time-series DB. Supports
InfluxDB line protocol and PostgreSQL wire.
5. IIoT Communication Layer
Protocols, Standards & Wireless Technologies for IIoT Data Exchange
5.1 Role of the Communication Layer
The Communication Layer defines how data is encoded, addressed, routed, and reliably exchanged
between IIoT devices, gateways, and cloud systems. While the Networking Layer provides the
physical infrastructure (cables, radios, routers), the Communication Layer defines the message
format, delivery semantics, security mechanisms, and interaction patterns (publish-subscribe,
request-response, peer-to-peer) used by applications.
Serialisation: Encoding sensor data into transmittable formats: JSON (human-readable),
Protobuf (compact binary), CBOR (IoT binary), raw binary.
Message Routing: Getting data from source to destination reliably — through brokers,
direct connections, or peer-to-peer.
Quality of Service: Guaranteeing delivery semantics: at-most-once, at-least-once, exactly-
once.
Security: Encrypting data in transit (TLS/DTLS), authenticating devices (X.509, PSK),
authorising access (RBAC).
Interoperability: Standard protocols enable multi-vendor IIoT ecosystems without custom
integration.
5.2 MQTT — Message Queuing Telemetry Transport
MQTT is the dominant IIoT messaging protocol. Designed in 1999 for oil pipeline monitoring over
satellite links, it is ideal for constrained devices, low-bandwidth networks, and high-latency
connections.
MQTT Publish-Subscribe Architecture
Layer / Component Description / Function
Devices publish messages to named topics. Example:
Publishers (Sensors)
factory/line1/press3/temperature
Central message router (Mosquitto, HiveMQ, AWS IoT Core).
MQTT Broker Manages topic subscriptions, message queuing, retained
messages, LWT.
Cloud applications, dashboards, analytics engines subscribe to
Subscribers (Apps)
topics and receive all matching published messages.
Figure: MQTT Publish-Subscribe Architecture
MQTT Property Detail
Transport TCP/IP. Port 1883 (plain), 8883 (TLS/SSL)
QoS 0 At most once — fire and forget. Fastest, no guarantee.
QoS 1 At least once — acknowledged delivery. Message may be
duplicated.
QoS 2 Exactly once — 4-way handshake. Slowest, guaranteed unique
delivery.
Retained Messages Broker stores last message per topic; new subscribers receive it
immediately on connection.
Last Will & Client pre-registers a message the broker will publish on
Testament unexpected disconnection — used for device offline detection.
MQTT 5.0 Additions Message expiry, shared subscriptions, user properties, reason
codes for better error handling.
Use Cases Sensor telemetry, remote device monitoring, industrial gateways,
mobile asset tracking.
5.3 OPC-UA — OPC Unified Architecture
OPC-UA (IEC 62541) is the premier industrial interoperability standard. It provides a platform-
independent, service-oriented architecture for communicating process data, alarms, historical data,
and programs between industrial systems. Unlike MQTT (data-agnostic), OPC-UA includes a rich
semantic information model.
OPC-UA Feature Detail
Architecture Client-Server (polling/subscription) + Pub/Sub extension
(MQTT/UDP transport)
Transport OPC-UA TCP (port 4840), HTTPS (port 443), WebSockets
Security Built-in: TLS/SSL, X.509 certificates, role-based access control
(RBAC), message signing & encryption
Information Model Object-oriented node graph: Variables, Objects, Methods, Events,
References, Types. Self-describing data.
Companion Specs Industry-specific information models: OPC-UA for PLCopen
(motion), EUROMAP 83 (injection moulding), PackML
(packaging), umati (machine tools).
UA over MQTT OPC-UA PubSub extension publishes OPC-UA data over MQTT
brokers for scalable cloud integration.
Use Cases PLC/DCS/SCADA data access, machine builder open interfaces,
cloud integration for production data.
5.4 Other Key IIoT Communication Protocols
5.4.1 CoAP — Constrained Application Protocol
CoAP (RFC 7252) is a RESTful protocol for resource-constrained IoT devices. It mirrors HTTP
semantics but uses UDP, making it extremely lightweight (4-byte fixed header vs. HTTP's hundreds
of bytes).
Transport: UDP (DTLS for security). Also TCP variant for NAT traversal.
Methods: GET, POST, PUT, DELETE — RESTful like HTTP.
Observe: Clients subscribe to resource updates — avoids polling.
Multicast: Supports UDP multicast for group operations.
Use Cases: Battery-powered remote sensors, embedded microcontrollers, smart metering.
5.4.2 AMQP — Advanced Message Queuing Protocol
AMQP (ISO/IEC 19464) is an enterprise-grade, open messaging protocol with advanced routing,
guaranteed delivery, and transactional semantics. Heavier than MQTT but suited for enterprise
integration.
Features: Exchanges (routing), queues (durable storage), bindings (routing rules),
transactional messaging.
Use Cases: IoT data pipelines into enterprise systems (ERP, MES), Azure IoT Hub
integration, RabbitMQ.
5.4.3 DDS — Data Distribution Service
DDS (OMG standard) is a data-centric publish-subscribe standard for real-time, mission-critical
distributed systems. It is broker-less — devices communicate peer-to-peer using a shared data
space.
No Broker: True decentralised peer-to-peer. Extremely low, deterministic latency.
QoS Policies: Reliability, history depth, deadline, latency budget, durability, lifespan — fine-
grained control.
Use Cases: ROS 2 (robot middleware), autonomous vehicles, military/defence, aerospace,
power grid control (IEC 61968).
5.4.4 Sparkplug B
Sparkplug B (Eclipse Foundation) is an MQTT-based open specification that adds a standardised
topic namespace and data encoding (Protobuf) on top of MQTT for SCADA and IIoT applications. It
enables true interoperability between SCADA systems, gateways, and cloud platforms.
5.5 Wireless Communication Technologies
Technology Range / Data Rate / Power IIoT Use Cases
Wi-Fi (802.11ax Wi- 100m / up to 9.6Gbps / medium Factory floor APs, camera feeds,
Fi 6) power HMI tablets, AGVs with high data
needs
Bluetooth 5 / BLE ~100m / 2Mbps / ultra-low power Condition monitoring tags,
wearables, proximity beacons, asset
tracking
Zigbee (802.15.4) ~100m / 250kbps / low power, mesh Building automation, smart metering,
factory sensor mesh networks
WirelessHART (IEC ~100m / 250kbps / low power, mesh Process industry sensors, brownfield
62591) HART upgrade to wireless, FHSS
mesh
ISA-100.11a (IEC ~100m / 250kbps / low power IEC standard wireless for process
62734) automation, time-slotted channel
hopping
LoRaWAN 2–15km / 0.3–50kbps / ultra-low Remote asset tracking, smart
power agriculture, utilities, oil & gas remote
monitoring
NB-IoT (4G LTE-M) Wide area / 200kbps / low power Smart metering, logistics tracking,
geographically dispersed remote
sensors
5G (SA/URLLC) Wide area / >1Gbps / medium / Private 5G for AGVs, mobile robots,
<1ms latency video analytics, time-critical wireless
control
DECT-ULE ~50m / 1.15Mbps / low power Smart home and light industrial
sensor networks, European standard
Thread (802.15.4) ~50m / 250kbps / low power, IPv6 Building automation, smart facilities,
mesh Matter protocol transport layer
5.6 Communication Security
Industrial communication security is non-negotiable. Cyber attacks on communication channels can
result in data theft, process disruption, or physical damage.
TLS 1.3 / DTLS 1.3: Encrypts data in transit for MQTT-TLS, OPC-UA, HTTPS, and CoAPS.
Mandatory for any internet-connected IIoT endpoint.
X.509 Certificates: Device identity certificates for mutual TLS authentication. Each IIoT
device has a unique certificate signed by an industrial PKI.
RBAC: Role-Based Access Control limits what each device or user can read, write, or
execute on the MQTT broker or OPC-UA server.
HMAC / Digital Signatures: Message integrity verification — ensures data has not been
tampered with in transit.
VPN / IPsec: Encrypted tunnels for site-to-cloud communication and secure remote access.
IEC 62443: Industrial cybersecurity standard covering all communication security
requirements for industrial automation systems.
Example: MQTT Security in a Smart Factory
A smart factory uses AWS IoT Core as its MQTT broker. Each of 3,000 sensor gateways
has a unique X.509 client certificate provisioned at manufacture via AWS IoT Fleet
Provisioning. All MQTT connections use TLS 1.3. IoT policies limit each gateway to
publish only to its own device-specific topic (factory/<plant-id>/<device-id>/#) and
subscribe only to its command topic. AWS IoT Defender monitors for anomalous
behaviour (unusual publish rates, connections from unexpected IPs). All data at rest in
Timestream is encrypted with AES-256.
6. IIoT Networking Layer
Physical & Logical Infrastructure — OT Networks, IT Networks & Cloud Connectivity
6.1 Role of the Networking Layer
The Networking Layer provides the physical and logical infrastructure over which IIoT
communications are carried. It defines how devices are connected, addressed via IP, routed
between network segments, and managed across local (field/plant), wide-area, and cloud networks.
This layer is the foundation on which the communication protocols run.
Physical Connectivity: Ethernet cables, fibre optics, cellular antennas, Wi-Fi access points,
fieldbus wiring.
IP Addressing & Routing: Assigning IPv4/IPv6 addresses; routing packets between OT
zones, enterprise LAN, and cloud WAN.
Network Segmentation: VLANs, firewalls, DMZ to isolate OT from IT and control data
flows.
QoS: Traffic prioritisation ensures safety-critical PROFINET RT traffic is not preempted by
bulk data transfers.
Network Management: SNMP, NETCONF/YANG, vendor NMS tools for monitoring, fault
detection, and configuration.
6.2 Purdue Reference Model (ISA-95 / IEC 62443)
The Purdue Model is the traditional hierarchical reference architecture for industrial network
segmentation. It was developed by Theodore Williams at Purdue University and has become the de
facto model for OT/IT security zone design in IEC 62443.
Purdue Reference Model — ISA-95 Industrial Network Architecture
Layer / Component Description / Function
Level 5: Enterprise Internet, corporate WAN, cloud. External partners, remote
WAN access. Managed by IT.
ERP (SAP), MES, corporate IT, business applications, email.
Level 4: Business LAN
Managed by IT. Connected to DMZ.
DEMILITARISED ZONE — Firewalls on both sides. Historian
DMZ mirrors, data diodes, integration services. OT/IT security
boundary.
Plant-wide SCADA servers, engineering workstations, MES
Level 3: Site OT LAN
servers, OPC-UA servers. Managed by OT.
HMI workstations, SCADA clients, area-level supervisory
Level 2: Cell/Area LAN
control. One per production zone.
PLCs, DCS controllers, safety systems (SIS). Real-time
Level 1: Control LAN
deterministic industrial Ethernet.
Sensors, actuators, transmitters, drives directly connected to
Level 0: Field Devices
the physical process.
Figure: Purdue Reference Model — ISA-95 Industrial Network Architecture
The DMZ (Demilitarised Zone) between Level 3 (OT) and Level 4 (IT) is the most critical security
boundary in the Purdue Model. Data diodes allow one-way data flow from OT to IT (historian →
ERP), preventing any IT-originated traffic from reaching field devices. All IIoT cloud connectivity
must be routed through this DMZ with appropriate security controls.
6.3 Industrial Ethernet Protocols
Standard Ethernet (IEEE 802.3) has been adapted for industrial real-time requirements. Industrial
Ethernet protocols add determinism, synchronisation, and isochronous data transfer on top of
standard Ethernet hardware:
Protocol Speed / Cycle Time / Features / Users
PROFINET (PI) 100Mbps/1Gbps. RT (<1ms), IRT (<250μs isochronous). Motion
control, process automation. Siemens, ~75% European market.
EtherNet/IP (ODVA) 100Mbps/1Gbps. CIP over UDP/TCP. Implicit (I/O) + Explicit
(config) messaging. Popular in North America. Rockwell
Automation.
EtherCAT (Beckhoff) 100Mbps. <100μs cycle time. Processing-on-the-fly in each node.
Extremely fast for motion control and robotics.
Powerlink (B&R) 100Mbps. Polling-based time slicing. Hard real-time, open standard.
B&R Automation, Vienna-based.
SERCOS III 100Mbps. Ring topology. Motion control and drives. Deterministic
for CNC and robotics.
CC-Link IE 1Gbps. Open network for Japan/Asia manufacturing. CLPA-
(Mitsubishi) managed, deterministic.
PROFIBUS DP/PA RS-485 (DP: 12Mbps) / MBP (PA: 31.25kbps). Legacy fieldbus, still
widely deployed. IEC 61158.
Modbus TCP 10/100Mbps. Simple, no real-time. Master-slave. Universal support
in all PLCs and SCADA systems.
TSN (IEEE 802.1 Up to 10Gbps. 802.1AS time sync, 802.1Qbv scheduled traffic,
suite) 802.1CB frame replication. Merges OT and IT on single Ethernet.
6.4 Wide Area Network Technologies
WAN Technology IIoT Characteristics
4G LTE Wide coverage, 100Mbps down, ~50ms latency. Reliable mobile
connectivity for remote sites, mobile assets (trucks, trains).
5G SA (Standalone) 1Gbps+, <1ms URLLC latency, network slicing. Private 5G for
factory floor replacing cable; supports massive IoT (mMTC) and
URLLC.
Private 5G Dedicated 5G network on industrial campus. Guaranteed QoS,
security isolation, no shared spectrum with public. Replaces Wi-Fi
for AGVs, robots.
MPLS Private WAN circuits with guaranteed bandwidth and QoS. Used for
connecting factory sites to corporate data centres. Expensive.
SD-WAN Intelligently routes traffic over MPLS, broadband, LTE based on
policy. Cost-effective with high resilience for multi-site IIoT.
LEO Satellite Low Earth Orbit broadband, 20–100ms latency, ~200Mbps. Viable
(Starlink) for oil & gas remote sites, mining, maritime, where cellular
unavailable.
LoRaWAN 1–15km range, 0.3–50kbps, years battery life. City/campus-scale
sensor networks. Parking sensors, waste management, agriculture.
NB-IoT (LTE Cat-NB) Licensed spectrum, deep building penetration, 10-year battery life.
Smart utility metering at scale (millions of meters).
6.5 Network Topologies
Topology Description & Industrial Use
Star All devices connect to a central switch. Simple management. Central
switch is single point of failure. Common in office-style Ethernet
segments.
Ring Devices in a loop with redundant path. Media Redundancy Protocol
(MRP/RSTP) (MRP) recovers from single link failure in <200ms. Widely used in
PROFINET, EtherNet/IP.
Mesh Each device has multiple paths to others. Self-healing. Used in
WirelessHART, Zigbee, LoRa mesh — high resilience for field devices.
Bus (Linear) Daisy-chain. Simple, low cable cost. Used in PROFIBUS, Modbus RS-
485. No redundancy — any break isolates downstream devices.
Tree Tiered star: access layer → distribution layer → core. Standard design
(Hierarchical) for large plant Ethernet networks.
Hybrid Combination of above. Typical IIoT deployment: ring topology for critical
PLC networks, star for HMI/SCADA LAN, mesh for wireless sensors.
6.6 IT/OT Convergence Security
The biggest networking challenge in IIoT is safely converging OT and IT networks. OT equipment
was designed for air-gapped isolation; IIoT requires cloud connectivity. Major attacks (Stuxnet
2010, TRITON/TRISIS 2017, Colonial Pipeline 2021) have demonstrated catastrophic
consequences when OT networks are compromised.
6.6.1 Key Security Measures
Network Segmentation: VLANs and firewalls create security zones. OT never directly
accessible from the internet.
Data Diodes: Hardware-enforced one-way data flow from OT to DMZ. Physically impossible
to send data from IT to OT.
Zero Trust Architecture: No implicit trust based on network location. Every device and user
is verified before access. Micro-segmentation limits lateral movement.
Industrial IDS/IPS: Passive network monitoring tools (Claroty, Dragos, Nozomi Networks)
that understand OT protocols and detect anomalies without disrupting live processes.
Secure Remote Access: VPN, jump servers, Privileged Access Management (PAM) for
vendor and remote technician access. Session recording and MFA mandatory.
PKI / Certificate Management: X.509 device certificates for all IIoT endpoints. Certificate
lifecycle management (issuance, renewal, revocation).
IEC 62443 Compliance: Industrial cybersecurity standard defining Security Levels (SL 1–4)
for zones and conduits. Mandatory for critical infrastructure in many jurisdictions.
Example: Private 5G in a Semiconductor Fab
A semiconductor manufacturer deploys a private 5G network (3.5 GHz CBRS band)
across a 50,000 m² cleanroom facility. 450 AGVs (Automated Guided Vehicles)
transporting wafer cassettes migrate from Wi-Fi to 5G for guaranteed <5ms handover
latency between base stations. 1,200 process tool sensors stream 4K inspection video
and inline metrology data over 5G directly to edge servers. The private 5G core (deployed
on-premises) is isolated from the internet by a next-generation firewall. Network slicing
provides separate guaranteed QoS for AGV control traffic (URLLC), sensor telemetry
(mMTC), and video inspection (eMBB).
7. Industry 4.0
The Fourth Industrial Revolution — Cyber-Physical Systems, Smart Factories & Digital Transformation
7.1 What is Industry 4.0?
Industry 4.0 (Industrie 4.0) is the fourth industrial revolution, characterised by the fusion of physical
manufacturing with digital technologies. The term was coined by the German government in 2011
as part of their high-tech strategy. While the First Industrial Revolution used steam power, the
Second used electricity/mass production, and the Third used electronics/IT automation, Industry 4.0
uses Cyber-Physical Systems (CPS), IIoT, AI, big data, cloud computing, and advanced robotics to
create smart, self-optimising factories.
IIoT is the technological backbone of Industry 4.0 — it provides the data connectivity infrastructure
that makes the vision of the smart factory possible.
7.2 The Four Industrial Revolutions
Revolution Period & Driver Key Technologies
Industry 1.0 1760–1840 — Mechanisation Steam engine, water power,
mechanical looms
Industry 2.0 1870–1970 — Mass Production Electricity, assembly line, steel
manufacturing, chemical industries
Industry 3.0 1970–2000 — Automation PLCs, robots, computers,
electronics, CNC machining
Industry 4.0 2011–present — Cyber-Physical IIoT, AI/ML, cloud, 3D printing,
AR/VR, digital twin, 5G, big data
7.3 Nine Pillars of Industry 4.0
McKinsey and the World Economic Forum identify nine key enabling technologies that define
Industry 4.0:
Pillar Description & Examples
1. Industrial IoT Connected sensors, devices, and machines generating real-time
(IIoT) operational data. Foundation of all other pillars.
2. Big Data & Collecting and analysing large volumes of structured and
Analytics unstructured data from machines, processes, and supply chains to
discover patterns and optimise performance.
3. Artificial Machine learning for predictive maintenance, quality inspection,
Intelligence & ML demand forecasting, process optimisation, and autonomous
decision-making.
4. Cloud Computing Elastic, on-demand compute and storage for IIoT data platforms,
analytics workloads, and enterprise applications. Enables pay-per-
use operational model.
5. Additive Producing complex geometries on demand, enabling mass
Manufacturing (3D customisation and distributed manufacturing without tooling.
Printing)
6. Autonomous Collaborative robots (cobots), AMRs, drone inspection, AI-guided
Robots robotic assembly lines with vision and force sensing.
7. Augmented AR headsets (Microsoft HoloLens) for step-by-step maintenance
Reality (AR/VR) guidance, remote expert assistance, and operator training overlaid
on real equipment.
8. Simulation & Real-time virtual replicas of machines, processes, and entire
Digital Twin factories fed by live IIoT sensor data for optimisation, predictive
what-if analysis, and operator training.
9. Horizontal & Vertical: connecting OT field devices to enterprise ERP/cloud
Vertical Integration (Purdue model). Horizontal: integrating supply chain partners into a
shared data ecosystem.
7.4 Smart Factory Architecture
The smart factory is Industry 4.0 realised in a manufacturing environment. It is a cyber-physical
production system (CPPS) where physical machines and processes are fully integrated with their
digital representations, enabling real-time monitoring, autonomous optimisation, and flexible
production.
Smart Factory — Industry 4.0 Architecture
Layer / Component Description / Function
ERP (SAP S/4HANA), PLM, supply chain integration, AI model
Cloud / Enterprise
training, global KPI dashboards, Digital Twin cloud
Manufacturing Execution System: production scheduling, quality
MES / MOM Layer
management, OEE, traceability, work orders, operator guidance
Plant-wide supervisory control, OPC-UA data server, process
SCADA / Historian
historian, alarm management, energy monitoring
Real-time analytics, local AI inference, digital twin
Edge & Fog Servers
synchronisation, data aggregation from all shop floor machines
PROFINET/EtherNet/IP ring LAN + Wi-Fi 6 + Private 5G for
Industrial Network
mobile assets. TSN for time-critical traffic.
CNC machines, welding robots, assembly cells, conveyor
Production Equipment
systems, AGVs — all connected via OPC-UA or IO-Link
Vibration, temperature, force, vision, RFID — IIoT sensing layer
Sensors & Actuators
feeding all digital systems with live process data
Figure: Smart Factory — Industry 4.0 Architecture
7.5 Digital Twin
A Digital Twin is a dynamic virtual replica of a physical asset, process, or system that is
continuously synchronised with real-world data from IIoT sensors. It is one of the most powerful
Industry 4.0 concepts.
7.5.1 Types of Digital Twin
Component Twin: Virtual model of a single component (bearing, pump impeller). Used for
structural analysis and condition monitoring.
Asset Twin: Virtual model of a complete machine (CNC machine, robot, compressor).
Includes process parameters, historical data, maintenance records.
System Twin: Digital replica of an entire production line or plant section. Used for line
balancing and bottleneck analysis.
Process Twin: Models an entire production process from raw material to finished product.
Used for yield optimisation and quality prediction.
7.5.2 Digital Twin Architecture
Digital Twin Architecture
Layer / Component Description / Function
Real machine/process with IIoT sensors streaming live data
Physical Asset
(temperature, vibration, power, speed, dimensions)
OPC-UA/MQTT data pipeline → time-series historian → digital
Data Integration
twin platform data ingestion API
3D CAD model + physics simulation (FEA, CFD) + ML model +
Twin Model
live sensor data overlay. Runs in simulation engine.
Anomaly detection comparing twin simulation vs. physical
Analytics Engine
behaviour. RUL prediction. What-if scenario simulation.
Remote monitoring dashboard, AR operator interface,
Applications maintenance planning, design optimisation, operator training
simulator
Figure: Digital Twin Architecture
Example: Digital Twin — Siemens Gas Turbine
Siemens creates a digital twin for each gas turbine it sells. The turbine has 500+ sensors
measuring temperatures, pressures, vibration, and fuel consumption at 1-second intervals.
Data streams via MQTT to MindSphere IoT cloud. The digital twin runs a validated physics
model of the turbine in parallel with the real machine. When sensor data deviates from the
twin's predictions, an anomaly is flagged for engineering review. The twin also runs
accelerated simulation to predict the remaining useful life of hot-section components
(turbine blades), enabling Siemens to offer outcome-based 'power-by-the-hour'
maintenance contracts with guaranteed availability.
7.6 Industry 4.0 Standards and Frameworks
Standard / Framework Description
RAMI 4.0 (Reference German Industry 4.0 architecture model — 3D cube with three
Architecture Model axes: Life Cycle, Hierarchy, and Layers (Asset, Integration,
Industry 4.0) Communication, Information, Functional, Business).
Asset Administration Digital representation of an Industry 4.0 asset containing all its
Shell (AAS) properties, capabilities, documentation, and interfaces. Enables
interoperable digital passport for any industrial asset.
IEC 62264 (ISA-95) Standard for integration of enterprise and control systems —
defines MES/ERP data models and interface layers.
ISA-88 Batch process control standard — modular equipment and
procedural models used in pharma, food, and chemical
manufacturing.
OPC-UA Companion Semantic interoperability standards for specific industry domains:
Specs umati (machine tools), EUROMAP 83 (plastics), PackML
(packaging), Weihenstephan (food/beverage).
NAMUR Open Process industry supplement to Purdue Model — adds a secure
Architecture (NOA) monitoring and optimisation channel for IIoT access to process
data without modifying live control systems.
8. Software Defined Networking (SDN)
Programmable Network Infrastructure — Decoupling Control and Data Planes
8.1 What is SDN?
Software Defined Networking (SDN) is a networking architecture approach that decouples the
network control plane (the logic that decides where traffic goes) from the data plane (the hardware
that forwards packets). In traditional networking, every switch and router makes its own forwarding
decisions using embedded software. In SDN, a centralised software controller makes all forwarding
decisions and programs the underlying network hardware dynamically.
SDN was pioneered at Stanford and UC Berkeley (OpenFlow protocol, 2008) and has since
expanded from data centres into enterprise, WAN, and industrial networks. In IIoT, SDN enables
flexible, programmable, and automated network management across complex multi-protocol
industrial environments.
8.2 Traditional Networking vs. SDN
Aspect Traditional Networking SDN
Control Plane Distributed — each device runs its Centralised — SDN controller
own routing protocol (OSPF, STP) manages all devices
Data Plane Tightly coupled with control in same Decoupled — dumb forwarding
hardware hardware programmed by controller
Configuration Device-by-device CLI commands Centralised API — one change
(error-prone, slow) propagates to all devices
Flexibility Fixed hardware-based forwarding Dynamic flow rules installable in
tables milliseconds
Vendor Lock-in Proprietary CLIs and protocols per Open standards (OpenFlow,
vendor NETCONF/YANG) enable multi-
vendor
Visibility Limited, per-device SNMP Holistic, network-wide real-time
telemetry
Traffic Engineering Complex, manual MPLS TE Dynamic, automated path
configuration computation and optimisation
IIoT Fit Poor — can't dynamically prioritise Excellent — real-time QoS
IIoT traffic programming per application
8.3 SDN Architecture
SDN Three-Layer Architecture
Layer / Component Description / Function
Network applications using the northbound API: traffic
Application Layer engineering, security policies, load balancing, QoS
management, network analytics, IIoT orchestration.
Centralised brain of the network. Computes forwarding paths,
Control Layer (SDN installs flow rules, monitors topology, exposes REST/gRPC
Controller) northbound API. Examples: OpenDaylight, ONOS, Floodlight,
Cisco ACI, VMware NSX.
Physical or virtual switches/routers that execute forwarding
Infrastructure Layer
decisions. Receive flow table rules from controller via
(Data Plane)
southbound API (OpenFlow, NETCONF, P4).
Figure: SDN Three-Layer Architecture
8.4 SDN Interfaces
Interface Direction
Northbound API Controller → Applications
Southbound API Controller → Switches
East-West API Controller ↔ Controller
8.5 OpenFlow Protocol
OpenFlow (IEEE/ONF standard) is the most widely implemented southbound API. It allows the SDN
controller to directly manage the flow tables in network switches:
Flow Table: Table of (match fields, actions) rules installed by controller. Match: Ethernet
src/dst, VLAN, IP src/dst, TCP/UDP port, ingress port. Actions: forward to port, drop, modify
headers, send to controller.
Pipeline Processing: Packets traverse multiple flow tables in sequence. Each table applies
match-action rules.
Controller Communication: Switches communicate via OpenFlow channel (TLS
connection) to the controller. Unknown flows are sent to controller for decision.
Versions: OpenFlow 1.0 (2009) to 1.5 (2014). OpenFlow 1.3 is the most deployed version.
8.6 SDN Controllers
Controller Description
OpenDaylight Linux Foundation project. Java-based. Highly modular, plugin
(ODL) architecture. Supports OpenFlow, NETCONF, BGP, PCEP. Widely used
in telco and enterprise.
ONOS (Open Carrier-grade SDN OS. Built for high availability and scale. Used by
Network OS) AT&T, NTT, Comcast for WAN and edge SDN.
Ryu Python-based, lightweight OpenFlow controller. Popular for research
and testing. Easy to develop custom applications.
Cisco ACI Commercial SDN for data centre. Uses APIC controller, spine-leaf
fabric, policy-driven intent-based networking.
VMware NSX Network virtualisation platform. Software-defined networking for data
centres — micro-segmentation, distributed firewalling.
Floodlight Java-based open-source controller. Simple REST API. Good starting
point for SDN application development.
8.7 SDN in IIoT
SDN offers significant advantages for managing the complex, heterogeneous networks of IIoT
deployments:
8.7.1 Dynamic QoS for Industrial Traffic
In a smart factory, different types of traffic have very different latency requirements. SDN can
dynamically install flow rules that guarantee low-latency paths for safety-critical PROFINET IRT
traffic while limiting bandwidth for bulk historian uploads.
Example: SDN QoS in a Smart Factory
A factory network uses an ONOS SDN controller. The IIoT orchestration application
configures the following flow policies: (1) All EtherType 0x8892 (PROFINET RT) traffic is
forwarded with queue priority 7 (highest) on all switches with <500μs end-to-end latency
guarantee. (2) MQTT broker traffic (TCP 8883) gets queue priority 4 with 10Mbps
guaranteed bandwidth. (3) Backup/historian traffic (TCP 2222) gets queue priority 1 with
strict 100Mbps rate limit. When a new machine is added to the network, the IIoT
orchestration app automatically installs the correct QoS rules without any manual switch
configuration.
8.7.2 Network Segmentation and Security
SDN enables micro-segmentation — each IIoT device or device group is placed in its own logical
network segment, preventing lateral movement if one device is compromised. Security policies are
centrally defined and uniformly enforced across all switches.
8.7.3 Network Programmability for IIoT Orchestration
As IIoT deployments scale to thousands of devices, manually configuring VLANs, ACLs, and
routing is impractical. SDN automates network provisioning: when a new sensor node is deployed,
the IIoT platform calls the SDN controller API to automatically provision the correct VLAN, route,
and firewall policy.
8.7.4 Network Telemetry and Visibility
SDN controllers can collect per-flow traffic statistics from all switches. This provides unprecedented
visibility into IIoT traffic patterns, enabling rapid diagnosis of network-related issues affecting
industrial systems.
8.8 SD-WAN (Software Defined WAN)
SD-WAN extends SDN principles to wide-area networks. It intelligently routes IIoT traffic across
multiple WAN links (MPLS, broadband, LTE, 5G) based on application-aware policies:
Application-Aware Routing: SCADA traffic is routed over the most reliable MPLS link; bulk
data uses cheaper broadband.
Dynamic Path Selection: If primary link degrades, SD-WAN fails over to LTE in <1 second,
maintaining IIoT connectivity.
Zero-Touch Provisioning: New remote sites are brought online without manual
configuration — controller pushes all policies automatically.
Integrated Security: Built-in VPN, firewall, and URL filtering on the SD-WAN appliance.
Examples: Cisco Viptela/SD-WAN, VMware VeloCloud, Silver Peak (HPE Aruba), Fortinet
Secure SD-WAN.
9. Wireless Sensor Networks (WSN)
Distributed Wireless Sensing — Architecture, Protocols, Topologies & IIoT Integration
9.1 What is a WSN?
A Wireless Sensor Network (WSN) is a distributed network of spatially dispersed, autonomous
sensor nodes that wirelessly sense physical or environmental conditions — temperature, pressure,
humidity, light, vibration, chemical concentrations — and cooperatively route the collected data
through the network to a central base station or gateway for processing and analysis.
WSNs form the foundational sensing infrastructure for many IIoT deployments, particularly where
wiring is impractical — large outdoor areas, legacy equipment with no cabling provisions,
hazardous or rotating machinery, and temporary deployments.
9.2 WSN Architecture
WSN System Architecture
Layer / Component Description / Function
Cloud/enterprise application that stores, processes, and
Back-End System visualises data. Runs analytics, dashboards, and alerts.
Communicates with gateway via internet/WAN.
Gateway node that receives all sensor data from the WSN and
Base Station / Sink
forwards to the back-end. May be wired to internet. Often acts
Node
as a PAN coordinator (Zigbee) or network manager.
Higher-capability nodes that aggregate data from surrounding
Cluster Head Nodes cluster members, run local processing, and route to base
station. Reduces multi-hop communication overhead.
Battery-powered or energy-harvesting nodes with sensor, MCU,
Sensor Nodes (Motes) radio, and power management. Deploy in large numbers. Self-
organise into the network mesh.
The industrial or environmental space being monitored: factory
Physical Environment floor, pipeline right-of-way, building, agricultural field, water
body, bridge structure.
Figure: WSN System Architecture
9.3 WSN Node Architecture
Each sensor node (also called a 'mote') has four key subsystems:
WSN Sensor Node Internal Architecture
Layer / Component Description / Function
One or more sensors + ADC. Converts physical quantities to
Sensing Unit digital data. MEMS sensors preferred for compact size and low
power.
Microcontroller (MSP430, ARM Cortex-M0+, nRF52) running
Processing Unit node software: data sampling, filtering, MAC protocol, routing.
Operates in ultra-low-power sleep modes.
Radio transceiver (IEEE 802.15.4 at 2.4GHz, sub-GHz for long
Communication Unit range). Responsible for transmitting/receiving packets and
media access control.
Primary battery (AA lithium), secondary (rechargeable LiPo),
Power Unit and/or energy harvester (solar cell, thermoelectric generator,
vibration harvester). Power management IC.
Figure: WSN Sensor Node Internal Architecture
9.4 WSN Topologies
Topology Description & Characteristics
Star Each sensor node communicates directly with a central base station.
Simple, low power per node (single hop). Range limited by direct
communication distance. No routing complexity. Used in small
deployments with dense base station coverage.
Mesh Each node can communicate with multiple neighbours. Multi-hop
routing extends range far beyond single-node radio range. Self-
healing — if one node fails, traffic re-routes. High resilience. Used in
WirelessHART, Zigbee. Higher energy per forwarding node.
Cluster Tree Nodes grouped into clusters, each with a cluster head. Data
aggregated at cluster head before forwarding to base station.
Reduces total transmissions. Used in hierarchical large-scale
deployments.
Hybrid Star-Mesh Nodes connect in star to cluster heads; cluster heads form a mesh to
the base station. Balances energy efficiency (star at leaf level) with
range and resilience (mesh at backbone level).
9.5 WSN Protocols and Standards
9.5.1 IEEE 802.15.4
IEEE 802.15.4 is the dominant PHY/MAC standard for low-power, low-rate wireless personal area
networks (LR-WPAN). It is the foundation for Zigbee, WirelessHART, ISA-100.11a, 6LoWPAN, and
Thread.
Parameter Specification
Frequency Bands 2.4GHz (global, 16 channels), 868MHz (Europe, 1 channel), 915MHz
(North America, 10 channels)
Data Rate 250kbps (2.4GHz), 20–40kbps (sub-GHz)
Modulation O-QPSK (2.4GHz), BPSK (sub-GHz)
Range 10–100m (indoor), up to 1km (sub-GHz with clear LOS)
MAC Modes Beacon-enabled (time-slotted, power-saving) and non-beacon
(CSMA-CA)
Addressing 16-bit short address + 64-bit IEEE EUI-64 address
Security AES-128 encryption at MAC layer
9.5.2 Zigbee (IEEE 802.15.4 + Zigbee Network Layer)
Zigbee (IEEE 802.15.4 MAC/PHY + Zigbee Alliance network/application layers) is the most widely
deployed WSN protocol. It adds mesh networking, self-organisation, and application profiles on top
of 802.15.4.
Device Types: Coordinator (one per network, manages), Router (full-function, forwards
packets), End Device (reduced-function, sleeps most of the time for battery saving)
Addressing: 16-bit network address assigned by coordinator. PAN ID distinguishes
networks.
Routing: AODV (Ad-hoc On-demand Distance Vector) for mesh routing. Tree routing as
fallback.
Application Profiles: Zigbee Home Automation (HA), Zigbee Light Link (ZLL), Zigbee
Building Automation (BA), Zigbee Smart Energy (SE).
Range Extension: Mesh routing — each router node extends network range. Typical
industrial mesh: 20–50 hops.
Security: Network-level AES-128 encryption. Trust Centre manages key distribution.
Example: Zigbee Industrial Mesh — Chemical Plant
A chemical plant deploys 250 Zigbee temperature and pressure sensors across a
sprawling process area. 8 Zigbee routers (mains-powered, mounted on pipe racks) form
the mesh backbone. 242 battery-powered end devices (ZED) sleep 99.7% of the time,
waking every 30 seconds to take a reading and transmit it to the nearest router. The
Zigbee coordinator (co-located with the SCADA system gateway) manages PAN
association and AES-128 key distribution. Expected battery life is 5 years on a pair of AA
lithium cells. The SCADA gateway converts Zigbee application-layer data to Modbus TCP
for integration with the existing DCS historian.
9.5.3 WirelessHART (IEC 62591)
WirelessHART is the industrial wireless extension of the HART protocol, designed specifically for
process industry sensor networks. It runs over IEEE 802.15.4 with a time-slotted channel-hopping
(TSCH) MAC for reliability and determinism.
Feature WirelessHART Detail
MAC Protocol TDMA (Time Division Multiple Access) + FHSS (Frequency
Hopping Spread Spectrum) — time-slotted channel hopping for
reliable industrial mesh
Frequency 2.4GHz, 15 channels (802.15.4), hops between channels to avoid
interference
Latency Deterministic — slots allocated by network manager for each link.
Typical end-to-end: 1–10 seconds.
Reliability >99.9% message delivery. Redundant paths, graph routing,
automatic re-routing.
Security AES-128 at all layers, unique join keys, network-wide session
keys, message counters (anti-replay).
Network Manager Central entity (in gateway) manages all slot/channel assignments,
routing graphs, and device joining.
Coexistence Blacklist channels to avoid interference from Wi-Fi, Bluetooth.
Adaptive frequency hopping.
Use Cases Process sensors (temperature, pressure, flow, level) in oil & gas,
chemical, refinery, pharmaceutical plants.
9.5.4 6LoWPAN — IPv6 over Low-Power Wireless
6LoWPAN (RFC 4944, RFC 6282) is an IETF adaptation layer that enables IPv6 packets to be sent
and received over IEEE 802.15.4 networks. It compresses IPv6/UDP headers (from 48 bytes to 2–6
bytes) to fit within the 802.15.4 payload limit (127 bytes MTU).
Header Compression: IPv6 40-byte header + UDP 8-byte header → 2–6 bytes using IPHC
and NHC compression.
Fragmentation: Splits large IPv6 packets across multiple 802.15.4 frames; reassembles at
destination.
Routing: RPL (Routing Protocol for Low-Power Lossy Networks, RFC 6550) builds a
DODAG tree for IPv6 routing in WSN.
Significance: Allows WSN sensor nodes to be fully addressable IPv6 hosts, enabling direct
internet connectivity and RESTful CoAP communication.
Use Cases: Smart grid AMI mesh networks, smart city sensor networks, Thread-based
building automation.
9.5.5 LoRaWAN
LoRaWAN (Long Range Wide Area Network) uses LoRa (Chirp Spread Spectrum modulation by
Semtech) at the PHY layer and adds a network/application layer for large-scale, wide-area WSN
deployments.
Feature LoRaWAN Detail
Range 2–5km (urban), 5–15km (rural/line-of-sight), 30km+ (elevated
gateway)
Data Rate 0.3kbps to 50kbps (adaptive data rate, ADR)
Power Ultra-low — Class A devices: <1mA average, >10-year battery life
Frequency Sub-GHz ISM bands: 868MHz (EU), 915MHz (US/AU), 433MHz
(Asia)
Network End nodes → LoRa gateways (star) → LoRaWAN network server
Architecture → application server
Device Classes Class A (lowest power, uplink-triggered downlink), Class B
(scheduled receive windows), Class C (always-on downlink)
Security AES-128 MIC for message integrity, AES-128 payload encryption.
Separate network and application session keys.
Use Cases Remote asset monitoring, smart agriculture, utility metering, city-
wide air quality, oil & gas remote sites
9.6 WSN Energy Management
Energy management is the defining design challenge of WSN. Most nodes are battery-powered and
must operate for years without maintenance.
9.6.1 Duty Cycling
Duty cycling is the practice of turning the radio (and other components) off for most of the time,
waking up only to transmit or receive. Since the radio consumes 10–100x more power than the
MCU:
Sleep/Wake Schedule: Node sleeps for 29.9 seconds, wakes to sample sensor (20ms),
transmit (15ms), listen for ACK (15ms), then sleeps again. Duty cycle = 0.17%.
Beacon-Enabled 802.15.4: Coordinator broadcasts beacons. Nodes wake up only during
guaranteed time slots. Enables synchronised sleep for all nodes.
TSCH (WirelessHART/6TiSCH): Time-Slotted Channel Hopping — pre-scheduled
communication slots allow all nodes to sleep except during their allocated transmission slot.
9.6.2 Energy Harvesting
Solar Cell: Best for outdoor or well-lit industrial environments. 50–500mW from a 10×10cm
cell.
Thermoelectric Generator (TEG): Converts temperature gradient (e.g., hot pipe surface
vs. ambient air) into electricity. Useful on hot process piping.
Vibration Harvester (Piezoelectric): Converts mechanical vibration from machinery into
electricity. Self-powered vibration sensor — no battery needed!
RF Energy Harvesting: Captures ambient RF energy from Wi-Fi/cellular signals. Very low
power but zero maintenance.
9.7 WSN Challenges
Limited Resources: Tiny MCUs (8–32-bit, <1MHz–64MHz), small RAM (2–256KB), small
flash, small battery. Every byte and every microsecond counts.
Wireless Reliability: Industrial environments have RF interference from motors, VFDs,
welding, and metallic structures causing multipath fading. FHSS and link-layer
retransmissions mitigate this.
Scalability: A large WSN may have thousands of nodes. Routing overhead, collision
avoidance, and time synchronisation must all scale.
Security: Wireless nodes are physically accessible — tamper resistance, secure boot,
encrypted storage of keys are essential.
Time Synchronisation: Time-stamping sensor readings accurately requires network-wide
time sync. IEEE 1588 PTP or TSCH scheduling provides μs-accurate sync across the WSN.
Data Aggregation: In-network processing reduces transmission count. Cluster heads
compute min/max/mean locally, sending summaries rather than raw readings.
Mobility: Moving sensor nodes (on robots, vehicles, workers) require dynamic routing
updates. AODV and RPL handle topology changes but with overhead.
9.8 WSN Protocol Comparison
Protocol Key Parameters Best IIoT Use Case
Zigbee 250kbps, 100m, mesh, 802.15.4, Factory automation, building
AES-128 automation, dense sensor meshes
WirelessHART 250kbps, 100m, TSCH mesh, Process industry: chemical, oil &
>99.9% reliable gas, pharma sensor retrofits
ISA-100.11a 250kbps, 100m, TSCH, IEC 62734 Process automation — alternative to
WirelessHART in IEC standard
environments
6LoWPAN/Thread 250kbps, 100m, IPv6 mesh, Matter Smart buildings, IoT devices
requiring native IPv6
LoRaWAN 0.3–50kbps, 2–15km, star, ADR Wide-area remote monitoring, smart
agriculture, utilities, very long battery
life
NB-IoT 200kbps, wide area, LTE licensed City-scale utility metering, massive
deployment with existing cellular
infra
Bluetooth 5 / BLE 2Mbps, 100m, star/mesh, low Condition monitoring tags,
latency wearables, short-range high-data
asset tracking
Example: WSN for Bridge Structural Health Monitoring
Singapore's Land Transport Authority deploys a WSN for structural health monitoring of 12
MRT viaduct bridges. Each bridge has 30 sensor nodes (Crossbow MICAz motes with
triaxial accelerometers and tiltmeters) attached to bridge decks, piers, and bearings.
Nodes form a Zigbee mesh with 2 mains-powered coordinators per bridge. Each node
samples at 100Hz during train crossings (triggered by a vibration threshold), computes
local statistics, and transmits 5 features (peak acceleration, RMS, dominant frequency,
settlement, tilt) to the coordinator. The coordinator uploads data via 3G to a structural
analysis server that runs FEA model correlation. Alerts are generated if settlement
exceeds 5mm or natural frequency shifts by more than 2%. Battery life: 3 years on 4×AA
lithium cells due to event-triggered sampling.