Sparx EA governs the IIoT architecture stack: from sensor edge to cloud platform to enterprise applications: through a governed Technology layer model that keeps pace with fast-moving IIoT technology, supported by MDG stereotypes for IIoT components and EA GraphLink-driven Power BI dashboards for operations visibility.
The Industrial Internet of Things is not a product you buy: it is an architecture you design, implement, and govern. From the sensors on the production line floor to the cloud analytics platforms that turn sensor data into operational insights, every layer of the IIoT stack presents integration challenges, security decisions, and technology choices that must be governed at the enterprise level. Without architectural governance, IIoT deployments fragment: incompatible sensor platforms, redundant edge computing nodes, inconsistent data models, and security gaps at the device-to-cloud boundary. Sparx EA provides the modeling environment to document the full IIoT stack, encode IIoT architectural patterns using MDG Technology, govern the fast-moving technology portfolio, and connect the architecture to operational dashboards via EA GraphLink. This article is a practical implementation guide for IIoT architecture in Sparx EA.
Key Takeaways
- The IIoT architecture stack (sensors → edge → connectivity → platform → applications) maps directly to the ArchiMate Technology layer in Sparx EA.
- Key IIoT protocols: MQTT, OPC-UA, AMQP: are modeled as Communication Network elements with security and latency tagged values.
- Edge vs cloud processing decisions are architectural decisions in Sparx EA, with rationale and constraints documented alongside the architecture.
- The digital twin architecture (asset shadow model) is modeled as an Application Component with Technology layer connections to sensor devices.
- MDG Technology encodes IIoT platform component stereotypes, making the technology portfolio governable and comparable across sites.
The IIoT Architecture Stack
IIoT architecture is typically described as a five-layer stack, each with its own technology choices, integration patterns, and security concerns.
Layer 1: Devices and Sensors The physical layer: the machines, sensors, actuators, and controllers that interact with the physical world. This includes: production line sensors (temperature, pressure, vibration, flow), vision systems (cameras for quality inspection), RFID readers for asset tracking, condition monitoring sensors on rotating equipment, energy meters, and the existing OT equipment (PLCs, SCADA) that exposes operational data.
At this layer, the key architectural decisions are: which sensors are needed and where, what communication protocol each device supports, whether legacy OT equipment (PLCs, legacy sensors with proprietary protocols) can be integrated directly or requires protocol conversion, and what device identity and authentication mechanism is used.
Layer 2: Edge Computing Edge computing platforms process data close to its source, before it reaches the cloud or enterprise network. The case for edge processing is compelling in manufacturing: high-frequency sensor data (vibration analysis may require 20kHz sampling) cannot be streamed to the cloud efficiently; real-time control decisions (quality reject signals, predictive maintenance alerts that must stop a machine) cannot tolerate cloud round-trip latency; regulatory or data sovereignty requirements may prevent operational data from leaving the plant.
Edge platforms include: industrial edge servers (Siemens Industrial Edge, Rockwell Edge Compute, Dell EMC Embedded Box PC), intelligent gateway devices (Advantech WebAccess, PTC ThingWorx Edge), and containerized edge runtimes (Azure IoT Edge, AWS Greengrass, Google Cloud IoT Edge) that run cloud-native workloads at the edge.
Layer 3: Connectivity The communication layer connecting devices and edge nodes to the central platform. This encompasses: plant floor industrial networks (OPC-UA, Modbus/TCP, Profinet), site-to-cloud WAN connectivity (MPLS, SD-WAN, cellular/5G for remote sites), and the messaging protocols used to move data from edge to cloud (MQTT, AMQP, HTTPS).
Layer 4: IIoT Platform The central data ingestion, storage, and processing platform. Major IIoT platforms include Azure IoT Hub (Microsoft), AWS IoT Core (Amazon), Google Cloud IoT Core, PTC ThingWorx, Siemens MindSphere (now Siemens Xcelerator), and open-source platforms (Eclipse Ditto for digital twins, Apache Kafka for event streaming). The platform handles: device registration and authentication, message ingestion at scale, time-series data storage, stream processing for real-time analytics, and REST APIs for application consumption.
Layer 5: Applications The enterprise and operational applications that consume IIoT data: OEE dashboards, predictive maintenance applications, quality analytics, energy management systems, and supply chain visibility platforms. These applications may be deployed on the IIoT platform, in the enterprise cloud environment, or as on-premises applications consuming APIs.
Modeling the IIoT Stack in Sparx EA
The five-layer IIoT stack maps to the ArchiMate Technology layer with some Application layer elements for platform services and enterprise applications.
Layer 1 (Devices): Device elements in ArchiMate represent sensors, PLCs, and edge controllers. A «IIoT Sensor» stereotype records: Manufacturer, Model, Protocol (OPC-UA/Modbus/MQTT/Profinet), Data Rate (samples per second), Power Supply (mains/battery/PoE), Location (production line/asset), and Identity Method (X.509 certificate/pre-shared key/no authentication).
Layer 2 (Edge): Node elements represent edge computing platforms. A «IIoT Edge Node» stereotype records: Platform Type (Industrial Edge Server/IoT Gateway/Containerised Edge), Runtime (Azure IoT Edge/AWS Greengrass/Custom), Processing Capacity (CPU/RAM), Local Storage, and Edge Functions deployed (protocol conversion, time-series buffering, ML inference, quality detection).
Layer 3 (Connectivity): Communication Network elements represent the network segments with protocol and security tagged values. Three distinct network segments are typically modeled: the Device Network (plant floor, OPC-UA or Modbus), the Edge-to-Cloud Network (plant WAN, TLS-encrypted MQTT or AMQP), and the Cloud Internal Network (within the cloud platform VNet/VPC).
Layer 4 (Platform): Platform services split between Technology layer (infrastructure: Kubernetes clusters, message brokers, time-series databases) and Application layer (platform services: IoT Hub, stream processing, REST APIs). A «IIoT Platform Service» stereotype on Application Service elements records the platform vendor, service tier, SLA, and data retention policy.
Layer 5 (Applications): Standard ArchiMate Application Components with «IIoT Consumer» stereotype, linked to the Platform Service elements they consume via Application Interface relationships.
Key IIoT Protocols in Sparx EA
Protocol selection is one of the most consequential IIoT architecture decisions. Three protocols dominate IIoT connectivity:
MQTT (Message Queuing Telemetry Transport): A lightweight publish-subscribe protocol designed for constrained devices and unreliable networks. MQTT uses a broker architecture (devices publish to topics; subscribers receive messages from topics). Its small packet overhead makes it ideal for high-frequency sensor data. MQTT 5.0 adds quality-of-service improvements and session management. Security requires TLS (for transport encryption) and authentication (username/password or X.509 certificates). In Sparx EA, MQTT is modeled as a Communication Network element with a Protocol = MQTT 5.0, Security = TLS 1.3 + X.509, and Broker = Azure IoT Hub / AWS IoT Core / Mosquitto tagged values.
OPC-UA (Unified Architecture): The modern industrial standard for secure, platform-independent data exchange between OT and IT systems. OPC-UA supports both client-server (for direct device communication) and publish-subscribe (for high-performance data distribution, via OPC-UA PubSub over MQTT or UDP). Built-in security: X.509 certificates, message signing and encryption, role-based access control. OPC-UA is the preferred protocol for PLM-MES integration and for accessing structured data from PLCs. In Sparx EA, OPC-UA servers on PLCs and SCADA systems are modeled as Application Interfaces with Protocol = OPC-UA, Security Profile = Basic256Sha256, and Supported Services tagged values.
AMQP (Advanced Message Queuing Protocol): An enterprise messaging protocol designed for reliable, high-throughput message delivery. Used by Azure IoT Hub for device-to-cloud and cloud-to-device messaging in enterprise IIoT scenarios. More resource-intensive than MQTT but provides stronger delivery guarantees. In Sparx EA, AMQP is modeled where reliable message delivery between edge and cloud is a specific requirement, typically for event-driven architectures where message loss is unacceptable.
Edge vs Cloud Processing: The Architectural Decision
The edge vs cloud processing decision is one of the most important architecture decisions in an IIoT implementation. It belongs in Sparx EA as a formal Architecture Decision element.
Process at the edge when:
- Real-time control response is required (sub-second latency from detection to action)
- Data volume is too high to stream efficiently (vibration analysis, high-resolution video)
- Data sovereignty or regulatory requirements prohibit cloud transmission
- Network connectivity is unreliable (remote sites, mobile assets)
- The cost of cloud processing at volume is prohibitive
Process in the cloud when:
- Aggregation across multiple sites or assets is needed for the analysis
- Historical data volumes require elastic cloud storage
- ML model training on large datasets is required
- The analysis is not time-critical
- IT operations prefers centralized platform management
In Sparx EA, the edge/cloud decision for each data processing function is documented as an Architecture Decision with the decision outcome (Edge/Cloud/Hybrid), the key decision criteria, the alternatives considered, and the decision rationale. This makes the decisions auditable and revisitable as the architecture evolves.
The Digital Twin Architecture
The digital twin is the most architecturally significant IIoT application pattern. A digital twin is a virtual representation of a physical asset: a software model that receives real-time data from the physical asset and reflects its current state.
In Sparx EA, the digital twin architecture is modeled across multiple layers:
Physical asset (Technology layer): The production machine, equipment unit, or infrastructure asset: modeled as a Device or Node element with associated sensors.
Edge data collection (Technology layer): The edge node that collects sensor data from the physical asset, performs local processing (filtering, aggregation, anomaly detection), and forwards to the platform.
Digital twin platform (Application layer): The twin management service: Azure Digital Twins, AWS IoT TwinMaker, PTC ThingWorx, or Eclipse Ditto: that maintains the current-state model of each asset. The platform is modeled as an Application Component with interfaces consuming data from the edge and exposing APIs to consuming applications.
Twin model (Information layer): The data model of the digital twin: which properties are captured (temperature, vibration, speed, cycle count, energy consumption), how they are structured, and how they relate to the asset’s physical hierarchy (machine → line → plant).
Consuming applications (Application layer): The OEE dashboard, predictive maintenance application, remote diagnostic portal: Application Components connected to the digital twin platform via Application Interfaces.
The «Digital Twin» stereotype on the Application Component element records: Asset Class (what type of physical asset this twin represents), Twin Fidelity Level (1=Basic telemetry, 2=Dynamic simulation, 3=Predictive model), Update Frequency, and Physical Asset Count (how many physical assets this twin template applies to).
Security Architecture for IIoT
IIoT security architecture is a specialized domain with concerns at every layer:
Device identity and authentication: Every IIoT device must have a unique identity and authenticate to the platform before sending data. X.509 certificates (provisioned through a PKI or a cloud IoT provisioning service) are the recommended approach. In Sparx EA, certificate-based authentication is modeled as a security requirement on the «IIoT Sensor» stereotype, with the PKI infrastructure modeled as a Technology Node providing certificate management services.
TLS encryption in transit: All IIoT data in transit must be encrypted. TLS 1.2 minimum, TLS 1.3 preferred. In Sparx EA, TLS is recorded as a tagged value on Communication Network elements. Model validation rules flag any Communication Network element carrying production IIoT data without TLS.
OT/IT zone separation: IIoT connectivity introduces a path from the cloud into the OT environment. Zone separation per ISA-99 (Level 0-3 OT zones separated from Level 4 enterprise by a DMZ) must be maintained: IIoT edge nodes should sit in the OT DMZ or at a designated IIoT gateway zone, not directly bridging OT to enterprise networks.
Certificate lifecycle management: Certificate expiry is a significant operational risk in large IIoT deployments. The certificate management architecture: automated renewal, revocation capability, monitoring: is modeled as an Application Component (certificate management service) with governance relationships to all «IIoT Sensor» elements.
MDG for IIoT Platform Governance
As IIoT platforms evolve rapidly, MDG Technology keeps the Sparx EA model aligned with the current technology portfolio:
«IIoT Sensor»: tagged with Protocol, Security, Data Rate, Location«IIoT Edge Node»: tagged with Platform Type, Runtime, Edge Functions«IIoT Platform Service»: tagged with Vendor, Service Tier, SLA, Data Retention«Digital Twin»: tagged with Asset Class, Fidelity Level, Update Frequency«IIoT Consumer»: tagged with Consumption Pattern (API/Stream/Batch), Latency Requirement
Model validation rules enforce: all sensors must have a defined Security protocol; all Communication Networks carrying IIoT data must specify TLS version; all Digital Twin elements must have a corresponding Physical Asset Device element.
FAQ
Q1: What is the difference between IIoT and IoT, and does it matter for architecture? IIoT (Industrial IoT) is the application of IoT concepts to industrial and manufacturing environments. The key architectural differences from consumer IoT: IIoT devices typically have longer lifespans (10–20 years vs 2–5 years for consumer devices), operate in harsh environments (high temperature, vibration, EMI), must meet stringent real-time performance requirements, and exist alongside OT systems that have their own safety and reliability requirements. These differences affect the protocol choices, security architecture, edge vs cloud balance, and governance model: all of which Sparx EA captures.
Q2: How do we handle IIoT integration with legacy OT equipment that has no IP connectivity? Legacy OT equipment (pre-IP PLCs, legacy sensors with serial interfaces) requires protocol conversion at the edge. An OPC-UA server or industrial gateway (Kepware, Matrikon, Cogent DataHub) translates legacy protocols (Modbus RTU, PROFIBUS, DNP3, proprietary serial) to OPC-UA or MQTT. In Sparx EA, the protocol gateway is modeled as an Edge Node with transformation relationships between the legacy device’s proprietary protocol interface and the OPC-UA/MQTT interface presented to the IIoT platform.
Q3: What time-series database should we use for IIoT data, and how does this affect the architecture model? Common time-series databases for IIoT include: InfluxDB (open-source, high ingestion performance), TimescaleDB (PostgreSQL-based, SQL-compatible), Azure Data Explorer (managed cloud service with high query performance), AWS Timestream, and OSIsoft PI (now AVEVA PI System: widely used in process industries). The choice depends on query patterns, existing cloud platform, and integration requirements. In Sparx EA, the time-series database is modeled as a Technology Node (or Application Component for managed cloud services) within the IIoT platform layer, with specific tagged values for write throughput, retention policy, and query latency.
Q4: How do we govern IIoT architecture as technology evolves rapidly? IIoT technology changes faster than most enterprise architecture domains. MDG Technology in Sparx EA provides the governance mechanism: when a new platform version or protocol standard is adopted, the stereotype tagged values are updated and model validation rules are revised. New technology elements are added to the approved MDG toolbox, making them the selectable options for new architecture designs. The Sparx EA model becomes the governing registry for approved IIoT technology choices.
Q5: What is the architectural difference between an IIoT platform and a traditional SCADA historian? Traditional SCADA historians (OSIsoft PI, Wonderware Historian, Ignition Historian) are purpose-built time-series databases designed for OT data: they prioritize high-frequency data ingestion, data compression, and process data retrieval. IIoT platforms add: scalable cloud architecture (elastic ingestion), device management (registration, provisioning, firmware updates), stream processing (real-time analytics on incoming data), digital twin management, and integration with AI/ML platforms. The historian is part of the IIoT platform picture but not equivalent to it. Both can be modeled in Sparx EA as distinct Application Components within the platform layer.
Q6: How does 5G connectivity change the IIoT architecture model? 5G (particularly private 5G networks deployed within a manufacturing facility) enables IIoT connectivity for mobile assets, harsh RF environments, and latency-sensitive applications that WiFi and wired Ethernet cannot serve reliably. In Sparx EA, a private 5G network is modeled as a Communication Network element at Layer 3 (connectivity), with specific latency, bandwidth, and coverage area tagged values. 5G also changes the edge architecture: with reliable low-latency connectivity, some processing functions that were edge-resident can migrate to cloud platforms without sacrificing real-time performance.
Q7: How does Sparx EA handle the IIoT security architecture for a multi-site manufacturing organization? Multi-site IIoT security architecture is managed through Sparx EA’s package structure: a global security architecture package defines the standards (TLS requirements, certificate management, zone separation), and site-specific packages document the implementation at each facility. Model validation rules applied globally enforce the security standards across all sites. EA GraphLink surfaces the site-by-site security compliance status in a Power BI dashboard: giving the global CISO visibility of which sites are compliant and which have outstanding security gaps.
Q8: What does Sparx Services’ Connect engagement deliver for an IIoT architecture program? The Connect engagement for IIoT architecture delivers: a complete IIoT stack architecture model in Sparx EA (all five layers, with MDG stereotypes for IIoT components), an EA GraphLink connection to Power BI for live operations dashboards (OEE by line, sensor connectivity status, data ingestion health), the IIoT MDG configuration, and the security architecture model aligned to ISA-99. This gives operations and IT leadership a governed, queryable IIoT architecture for the first time. Connect starts at $50,000.
Work With Sparx Services
IIoT architecture is too consequential to leave ungoverned. Sparx Services’ Connect engagement delivers your IIoT architecture in Sparx EA and surfaces operational data to Power BI via EA GraphLink: giving your operations and IT teams a shared, live view of the IIoT stack that runs your plant.
Connect from $50,000. Contact us to discuss your IIoT architecture requirements.