# Edge and IoT Solution Architecture: [Solution name]

> Solution architecture for an industrial or commercial Internet of Things (IoT) system with edge computing: use cases, device fleet and lifecycle, edge compute, protocols (OPC UA, MQTT 5.0, Sparkplug 3.0), zones and conduits with target security levels, device identity and provisioning, over-the-air (OTA) updates, the data pipeline with sizing, offline operation, operations and the regulatory view. The level model follows the functional hierarchy of ANSI/ISA-95.00.01-2025 (IEC 62264-1 Mod); the security design follows the zone and conduit method of IEC 62443-3-2:2020 and the security levels of IEC 62443-3-3:2013, with component requirements from IEC 62443-4-2:2019. The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is covered for products with digital elements placed on the EU market. Replace every `[bracketed]` value and every row marked *Example*. The examples follow a manufacturer connecting three plants to a cloud analytics platform. This is a documentation format, not legal advice.

<!--
Guidance: How to use this template
- Write one document per IoT solution (one product line, one plant programme or one connected-product service). Plant-wide ERP and MES integration belongs in Manufacturing ISA-95 Integration (`industry/manufacturing-isa95-integration`); link it rather than repeating it.
- Settle the use cases and the latency and offline requirements first (sections 1 and 2). They decide what must run at the edge and what can run in the cloud; almost every later choice follows from them.
- Do the zone and conduit work (section 7) with the asset owner and the OT security lead before choosing products. Security levels are targets for zones; products are then chosen because they can meet them.
- Size the data pipeline with numbers (section 10). An IoT design without message rates, payload sizes and buffer sizes cannot be reviewed.
- If you build a connected product for the EU market, keep the CRA technical file in CRA Technical Documentation (`security/cra-technical-documentation`) and the vulnerability process in CRA Vulnerability Handling (`security/cra-vulnerability-handling`); this document holds the architecture evidence they point to.
- Related documents: Network Architecture Design (`architecture/network-architecture-design`), Streaming Solution Design (`architecture/streaming-solution-design`), PKI and Certificate Architecture (`security/pki-certificate-architecture`), Threat Model (`security/threat-model`), Observability Specification (`ops/observability-spec`), Resilience Tiering and HA/DR Design (`architecture/resilience-tiering-ha-dr-design`).
-->

## Document control

<!-- Guidance: Identify the solution, the sites or product lines in scope and the asset owner. The asset owner (for plants) or the manufacturer (for connected products) approves the zone model and the target security levels. A change to zones, conduits or target security levels is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [EIA-001] |
| Solution name | [Name] |
| Solution type | [Industrial monitoring / Connected product / Smart building / Fleet telematics / Other] |
| Sites or product lines in scope | [Plant A, Plant B / Product family and models] |
| Asset owner or manufacturer | [Organisation and role] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@iot-solution-architect] |
| Approvers/reviewers | [@ot-security-lead], [@plant-engineering-lead], [@cloud-platform-lead], [@product-security-officer] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Threat model], [Network design], [CRA technical file], [Site safety case] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Asset owner or product owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| OT security lead | [@name] | [Decision] | YYYY-MM-DD |
| Plant engineering or process safety | [@name] | [Decision] | YYYY-MM-DD |
| Cloud platform lead | [@name] | [Decision] | YYYY-MM-DD |
| Architecture board | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Zone model and target security levels agreed in workshop with plant A |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for pilot line; OTA rollout rings defined |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Scope, use cases and drivers](#1-scope-use-cases-and-drivers)
2. [Requirements](#2-requirements)
3. [Reference model and level mapping](#3-reference-model-and-level-mapping)
4. [Device fleet and lifecycle](#4-device-fleet-and-lifecycle)
5. [Edge compute design](#5-edge-compute-design)
6. [Connectivity and protocols](#6-connectivity-and-protocols)
7. [Zones, conduits and security levels](#7-zones-conduits-and-security-levels)
8. [Device identity and provisioning](#8-device-identity-and-provisioning)
9. [Software and firmware updates](#9-software-and-firmware-updates)
10. [Data pipeline and sizing](#10-data-pipeline-and-sizing)
11. [Offline operation and resilience](#11-offline-operation-and-resilience)
12. [Operations and support model](#12-operations-and-support-model)
13. [Regulatory and compliance view](#13-regulatory-and-compliance-view)
14. [Decisions, risks and roadmap](#14-decisions-risks-and-roadmap)
15. [Traceability matrix](#15-traceability-matrix)
16. [Glossary and references](#16-glossary-and-references)

## 1. Scope, use cases and drivers

<!-- Guidance: State what the solution does for whom, and what it must never do. Write each use case with its decision latency (how fast the result must act) because that decides edge or cloud placement. Common pitfall: listing "collect all data" as a use case; data collection is a means, not an outcome. -->

### 1.1 Scope

[Describe the business outcome, the physical scope (sites, lines, assets, products) and the boundary of this document.] *Example:* Condition monitoring and overall equipment effectiveness (OEE) for 1,200 assets per plant (3,600 across three plants), with cloud analytics for maintenance planning. In scope: sensors, PLC data access, edge gateways, plant edge servers, the site broker, the cloud ingestion and the device management service. Out of scope: changes to PLC control logic, the safety instrumented system (SIS) and the MES.

Hard boundary: [state what the solution must not do.] *Example:* The solution reads from control systems and never writes setpoints or commands to PLCs. Any future write path requires a separate safety and security review and a new major version of this document.

### 1.2 Use cases

| ID | Use case | Actor or consumer | Decision latency | Placement | Value measure |
|---|---|---|---|---|---|
| UC-001 *(Example)* | Vibration anomaly alert on critical pumps | Maintenance technician | Under 5 seconds at the line | Edge | Unplanned downtime hours |
| UC-002 *(Example)* | OEE dashboard per line and shift | Plant manager | Under 1 minute | Site edge server | OEE percentage points |
| UC-003 *(Example)* | Predictive maintenance model training | Reliability engineer | Days | Cloud | Maintenance cost per asset |
| UC-004 *(Example)* | Energy consumption per product | Sustainability lead | Daily | Cloud | kWh per unit produced |
| UC-005 *(Example)* | Remote fleet health for edge devices | OT support | Under 5 minutes | Cloud | Device availability |
| [UC-nnn] | [Use case] | [Actor] | [Latency] | [Edge / Site / Cloud] | [Measure] |

### 1.3 Drivers and constraints

| ID | Type | Statement | Source |
|---|---|---|---|
| DRV-01 *(Example)* | Business | Reduce unplanned downtime on critical assets | Operations strategy |
| CON-01 *(Example)* | Safety | No new path may reach the SIS network | Site safety case |
| CON-02 *(Example)* | Technical | Existing PLCs expose data only through OPC UA servers on Level 2 HMI hosts or through Modbus TCP | Plant survey |
| CON-03 *(Example)* | Connectivity | Plant C has a single WAN link with weekly maintenance outages | Network team |
| CON-04 *(Example)* | Regulatory | Gateways sold to customers as part of a service are products with digital elements under the CRA | Legal review |
| [ID] | [Type] | [Statement] | [Source] |

## 2. Requirements

<!-- Guidance: Separate the core requirements that drive the architecture from those that only need to be met. Give every non-functional requirement a measurable target and a verification method. Common pitfall: one availability figure for the whole system; the edge, the WAN and the cloud fail independently and need separate targets. -->

### 2.1 Functional requirements

| ID | Requirement | Priority | Verification |
|---|---|---|---|
| IOT-FR-001 *(Example)* | Collect configured tags from each asset at the configured rate or on change | Must | Integration test per asset class |
| IOT-FR-002 *(Example)* | Raise a local alert within the edge when a model score crosses a threshold | Must | Fault injection test |
| IOT-FR-003 *(Example)* | Buffer data locally during WAN loss and forward it in order when the link returns | Must | WAN cut test |
| IOT-FR-004 *(Example)* | Deploy signed software and models to selected device groups | Must | OTA pilot |
| IOT-FR-005 *(Example)* | Provide a per-asset data lineage from tag to cloud record | Should | Data audit |
| [IOT-FR-nnn] | [Requirement] | [Must / Should / Could] | [Method] |

### 2.2 Non-functional requirements

| ID | Quality | Target | Scope | Verification |
|---|---|---|---|---|
| IOT-NFR-001 *(Example)* | Latency | 95th percentile under 2 s from sensor change to edge alert | Edge | Timestamped test signal |
| IOT-NFR-002 *(Example)* | Availability | Edge alerting 99.9% per month, independent of WAN and cloud | Edge | Monitoring |
| IOT-NFR-003 *(Example)* | Offline autonomy | 72 hours of WAN loss with no data loss | Site | WAN cut test |
| IOT-NFR-004 *(Example)* | Throughput | 12,000 metric updates per second per plant at design load (section 10.2); site broker sized for 2x, that is 24,000 per second | Site broker | Load test |
| IOT-NFR-005 *(Example)* | Security | Every zone meets its target security level in section 7 | All | Assessment against IEC 62443-3-3 requirements |
| IOT-NFR-006 *(Example)* | Update | 95% of a ring updated within 7 days; failed update rolls back automatically | Fleet | OTA report |
| IOT-NFR-007 *(Example)* | Lifetime | Gateways supported for 10 years in the field | Fleet | Vendor contract |
| [IOT-NFR-nnn] | [Quality] | [Target] | [Scope] | [Method] |

Core requirements that drive the design: [list the 3 to 5 IDs]. *Example:* IOT-NFR-001, IOT-NFR-003 and IOT-NFR-005 decide edge placement, buffering and the zone model; the others are met within that design.

## 3. Reference model and level mapping

<!-- Guidance: Place every component on a level so that reviewers can see which boundary each data flow crosses. ISA-95 describes the functional hierarchy from the physical process up to business planning; use its level numbers and your own words. Common pitfall: treating the levels as network segments; they are functional levels, and zones (section 7) are drawn separately. -->

The level numbers below follow the functional hierarchy used by ANSI/ISA-95.00.01-2025 and IEC 62264-1. The descriptions are written for this template; obtain the standard for its normative models.

| Level | Functional role (summary) | Components in this solution |
|---|---|---|
| 4 | Business planning and logistics | *Example:* ERP, cloud analytics, data platform |
| 3 | Manufacturing operations management | *Example:* MES, historian, site edge server, site MQTT broker |
| 2 | Monitoring and supervisory control | *Example:* SCADA, HMI hosts with OPC UA servers, line edge gateways |
| 1 | Sensing and manipulating the process | *Example:* PLCs, remote I/O, wireless vibration sensors |
| 0 | The physical process | *Example:* Pumps, conveyors, compressors |
| Cloud | Outside the plant | *Example:* IoT ingestion, device management, model training |

```mermaid
flowchart TB
    subgraph CLOUD["Cloud (outside plant)"]
        ING["IoT ingestion and device management"]
        DP["Data platform and model training"]
    end
    subgraph L4["Level 4: enterprise"]
        ERP["ERP"]
    end
    subgraph DMZ["Industrial DMZ"]
        REL["MQTT bridge and update relay"]
    end
    subgraph L3["Level 3: site operations"]
        SB["Site broker (MQTT 5.0, Sparkplug)"]
        ES["Site edge server and historian"]
    end
    subgraph L2["Level 2: supervisory"]
        GW["Line edge gateways"]
        HMI["HMI hosts with OPC UA servers"]
    end
    subgraph L1["Level 1: control"]
        PLC["PLCs"]
        SEN["Wireless sensors"]
    end
    PLC --> HMI
    HMI -- "OPC UA, read only" --> GW
    SEN --> GW
    GW -- "MQTT over TLS" --> SB
    SB --> ES
    SB --> REL
    REL -- "MQTT over TLS, outbound only" --> ING
    ING --> DP
    DP --> ERP
```

## 4. Device fleet and lifecycle

<!-- Guidance: Inventory every device class, not every device. For each class record who owns it, how it is identified, how it is updated and when its support ends. Common pitfall: forgetting the end of the lifecycle; decommissioning must remove credentials and data, or the device becomes an open door. -->

### 4.1 Device classes

| Class ID | Device class | Quantity | Level | OS or firmware | Identity method | Update method | Support end | Owner |
|---|---|---|---|---|---|---|---|---|
| DEV-C01 *(Example)* | Wireless vibration sensor | 900 | 1 | Vendor firmware | Pre-provisioned key in gateway pairing | Vendor tool via gateway | 2033 | Reliability |
| DEV-C02 *(Example)* | Line edge gateway | 90 (30 per plant) | 2 | Hardened Linux, A/B partitions | X.509 certificate, key in TPM 2.0 | OTA, signed images | 2036 | OT platform |
| DEV-C03 *(Example)* | Site edge server | 6 (2 per plant) | 3 | Kubernetes distribution for edge | X.509 certificate, key in TPM 2.0 | GitOps and signed containers | 2031 | OT platform |
| DEV-C04 *(Example)* | Energy meter | 150 | 1 | Vendor firmware | None (Modbus TCP) | Manual, by vendor | 2030 | Facilities |
| [DEV-Cnn] | [Class] | [Qty] | [Level] | [OS] | [Identity] | [Update] | [Year] | [Owner] |

### 4.2 Lifecycle states

```mermaid
stateDiagram-v2
    [*] --> Manufactured
    Manufactured --> Provisioned: identity injected
    Provisioned --> Enrolled: claimed by tenant and site
    Enrolled --> Active: configuration applied
    Active --> Maintenance: update or repair
    Maintenance --> Active: health checks pass
    Active --> Quarantined: compromise suspected
    Quarantined --> Active: cleared and re-keyed
    Quarantined --> Decommissioned: not recoverable
    Active --> Decommissioned: end of life
    Decommissioned --> [*]: credentials revoked, storage wiped
```

| Transition | Control | Evidence |
|---|---|---|
| Provisioned to Enrolled | *Example:* Ownership claim with a one-time token bound to the device certificate | Enrolment log |
| Active to Quarantined | *Example:* Automatic on failed attestation or anomalous traffic; conduit rules block the device | Alert and ticket |
| Any to Decommissioned | *Example:* Certificate revoked, device removed from registry, local storage wiped or physically destroyed | Decommission record |
| [Transition] | [Control] | [Evidence] |

## 5. Edge compute design

<!-- Guidance: Explain what runs at the edge and why it cannot run elsewhere. Size the hardware from the workloads, keep the edge platform as small as the use cases allow, and decide how workloads are deployed and observed. Common pitfall: running a full cloud stack at every site; each extra service at the edge is another thing to patch for ten years. -->

### 5.1 Edge tiers and workloads

| Tier | Workload | Reason it runs here | Resource budget | Deployment unit |
|---|---|---|---|---|
| Line gateway *(Example)* | Protocol adapters (OPC UA client, Modbus), Sparkplug edge node, local buffer | Close to the source; survives site network loss | 2 vCPU, 4 GB RAM, 64 GB storage | Signed container |
| Line gateway *(Example)* | Vibration anomaly model (UC-001) | Latency under 2 s (IOT-NFR-001) | 1 vCPU | Signed container and model artefact |
| Site edge server *(Example)* | Site broker, historian, OEE calculation, store and forward | Site autonomy for 72 hours (IOT-NFR-003) | 16 vCPU, 64 GB RAM, 4 TB storage per node, 2 nodes | Kubernetes workloads via GitOps |
| Cloud *(Example)* | Model training, fleet analytics, long-term storage | Needs pooled data and elastic compute | Elastic | Cloud services |
| [Tier] | [Workload] | [Reason] | [Budget] | [Unit] |

### 5.2 Edge platform decisions

| Topic | Decision | Rationale |
|---|---|---|
| Operating system | *Example:* Minimal hardened Linux with read-only root and A/B partitions | Small attack surface; atomic updates |
| Workload runtime | *Example:* Containers on gateways; lightweight Kubernetes on site servers | Same packaging from development to plant |
| Configuration | *Example:* Declarative, pulled from a signed Git repository through the DMZ relay | No inbound connections to the plant |
| Local storage | *Example:* Encrypted at rest with keys sealed to the TPM | Theft of a gateway does not expose data |
| Time | *Example:* Site time source in Level 3 synchronised to an external reference through the DMZ | Event ordering across assets |
| [Topic] | [Decision] | [Rationale] |

## 6. Connectivity and protocols

<!-- Guidance: Choose protocols per hop, not one for the whole system. Record the data model and namespace design, the quality of service and how state is known after reconnects. Common pitfall: using MQTT without a namespace and payload convention; every team then invents its own topics and the data cannot be joined. -->

### 6.1 Protocol per hop

| Hop | Protocol | Version | Security | Reason |
|---|---|---|---|---|
| PLC or HMI to gateway *(Example)* | OPC UA client/server | Spec 1.05.x (IEC 62541) | Security mode SignAndEncrypt, certificate trust list per gateway | Rich information model; already exposed by HMI hosts |
| Energy meter to gateway *(Example)* | Modbus TCP | Legacy | No native security; isolated in its own zone (Z-06) | Device supports nothing else |
| Gateway to site broker *(Example)* | MQTT with Sparkplug | MQTT 5.0 (Sparkplug 3.0 is defined on MQTT 3.1.1 and 5.0) | TLS 1.3, mutual certificate authentication | Report by exception, birth and death state |
| Site broker to cloud *(Example)* | MQTT bridge | MQTT 5.0 | TLS 1.3, outbound only from the DMZ | Firewall friendly, single conduit |
| Cloud to downstream consumers *(Example)* | Event stream | Per platform | Platform identity | Fan-out to analytics |
| [Hop] | [Protocol] | [Version] | [Security] | [Reason] |

### 6.2 Protocol choice criteria

Use OPC UA where the data needs a typed information model, browsing, methods or companion specifications for a machine type, and where the client can hold a session to the server. Use MQTT where many producers publish to many consumers, links are intermittent and you want the broker to decouple them. Sparkplug adds what plain MQTT leaves open: a topic namespace, a payload encoding and session state, so that a host application knows whether an edge node and its devices are online and which metrics they publish. OPC UA PubSub is an alternative where an OPC UA information model must travel end to end; record why it was or was not chosen.

### 6.3 Namespace and payload design

| Item | Decision |
|---|---|
| Topic structure | *Example:* Sparkplug namespace `spBv1.0/[group_id]/[message_type]/[edge_node_id]/[device_id]` with group ID per plant and line, edge node per gateway, device per asset |
| Naming source | *Example:* Asset IDs from the enterprise asset register; no free-text names in topics |
| Payload | *Example:* Sparkplug B protobuf payload with metric names aligned to the asset model; units and engineering ranges sent in birth certificates |
| Quality of service | *Example:* QoS 0 for Sparkplug data messages as the specification expects, with store and forward on the edge node; QoS 1 for alerts on a separate application topic |
| State | *Example:* Primary host application publishes its state; edge nodes buffer data when the primary host is offline |
| Session settings | *Example:* MQTT 5.0 session expiry 3,600 s for application clients; message expiry on alerts 300 s |
| Unified namespace | *Example:* Site broker is the single place where current state of the plant is published; consumers subscribe and never poll devices directly |
| [Item] | [Decision] |

## 7. Zones, conduits and security levels

<!-- Guidance: Partition the system under consideration into zones of assets with common security requirements, connect them only through defined conduits, and give each zone a target security level (SL-T). IEC 62443-3-2 numbers its zone and conduit requirements ZCR 1 to ZCR 7; follow their order but write your own content. Common pitfall: one flat "OT zone" with SL-T 2; it hides the paths an attacker would use. -->

### 7.1 Method

The steps follow the order of the zone and conduit requirements in IEC 62443-3-2:2020 (ZCR 1 to ZCR 7). The step names below are short paraphrases written for this template.

| Step | Work in this solution | Output | Status |
|---|---|---|---|
| ZCR 1 | Define the system under consideration (SUC) and its boundary | SUC diagram and asset list | [Done / Open] |
| ZCR 2 | Initial, high-level risk assessment of worst-case consequences | Unmitigated risk per SUC | [Status] |
| ZCR 3 | Partition into zones and conduits | Tables 7.2 and 7.3 | [Status] |
| ZCR 4 | Compare initial risk with tolerable risk to decide where detail is needed | Decision record | [Status] |
| ZCR 5 | Detailed risk assessment per zone and conduit, including SL-T | Threat model (`security/threat-model`) | [Status] |
| ZCR 6 | Document cybersecurity requirements, assumptions and constraints | Cybersecurity requirements specification | [Status] |
| ZCR 7 | Obtain asset owner approval | Signed approval in Document control | [Status] |

Security levels run from SL 1 (protection against casual or coincidental violation) to SL 4 (protection against intentional violation by sophisticated means with extended resources). For each zone record the target level (SL-T), the capability of the chosen components (SL-C, from IEC 62443-4-2 component certificates or vendor statements) and, after commissioning, the achieved level (SL-A). Where SL-C is below SL-T, record compensating countermeasures.

### 7.2 Zones

| Zone ID | Zone | Assets | Level | SL-T | SL-C of components | Compensating measures | Owner |
|---|---|---|---|---|---|---|---|
| Z-01 *(Example)* | Safety instrumented system | SIS controllers | 1 | 3 | 3 | None; no conduit to this solution | Process safety |
| Z-02 *(Example)* | Basic control, line N | PLCs, remote I/O | 1 | 2 | 1 to 2 | Read-only access through Z-03 only | Plant engineering |
| Z-03 *(Example)* | Supervisory, line N | HMI hosts, OPC UA servers, line gateways | 2 | 2 | 2 | Application allow-listing on HMI hosts | OT platform |
| Z-04 *(Example)* | Site operations | Site edge servers, site broker, historian | 3 | 2 | 2 | None | OT platform |
| Z-05 *(Example)* | Industrial DMZ | MQTT bridge, update relay, jump host | 3.5 | 3 | 3 | None | OT security |
| Z-06 *(Example)* | Legacy meters | Modbus energy meters | 1 | 2 | 0 to 1 | Dedicated VLAN, one-way read via gateway, port and function code filtering | Facilities |
| Z-07 *(Example)* | Cloud IoT | Ingestion, device management | Cloud | Per cloud security baseline | Provider attested | Landing zone guardrails | Cloud platform |
| [Z-nn] | [Zone] | [Assets] | [Level] | [SL] | [SL] | [Measures] | [Owner] |

### 7.3 Conduits

| Conduit ID | From zone | To zone | Direction | Protocols and ports | Controls | SL-T |
|---|---|---|---|---|---|---|
| C-01 *(Example)* | Z-02 | Z-03 | Z-03 reads from Z-02 | Vendor protocol to HMI hosts only | Industrial firewall, protocol allow-list | 2 |
| C-02 *(Example)* | Z-03 | Z-04 | Outbound from Z-03 | MQTT over TLS 8883 | Mutual TLS, broker ACL per edge node | 2 |
| C-03 *(Example)* | Z-04 | Z-05 | Outbound from Z-04 | MQTT over TLS 8883; HTTPS 443 to update relay | Firewall, deep packet inspection, logging | 3 |
| C-04 *(Example)* | Z-05 | Z-07 | Outbound from Z-05 only | MQTT over TLS 8883; HTTPS 443 | Egress allow-list by FQDN, no inbound sessions | 3 |
| C-05 *(Example)* | Z-06 | Z-03 | Gateway polls Z-06 | Modbus TCP 502 | Read function codes only | 2 |
| [C-nn] | [Zone] | [Zone] | [Direction] | [Ports] | [Controls] | [SL] |

```mermaid
flowchart LR
    Z02["Z-02 Basic control"] -- "C-01" --> Z03["Z-03 Supervisory"]
    Z06["Z-06 Legacy meters"] -- "C-05" --> Z03
    Z03 -- "C-02" --> Z04["Z-04 Site operations"]
    Z04 -- "C-03" --> Z05["Z-05 Industrial DMZ"]
    Z05 -- "C-04" --> Z07["Z-07 Cloud IoT"]
    Z01["Z-01 SIS (no conduit)"]
```

### 7.4 Foundational requirement coverage

IEC 62443 groups its system and component requirements under seven foundational requirements. Record how the design addresses each one.

| FR | Area | How this design meets it | Evidence |
|---|---|---|---|
| FR 1 | Identification and authentication control | *Example:* Device certificates, named accounts on HMI hosts, central identity for engineers | Section 8 |
| FR 2 | Use control | *Example:* Broker ACLs per edge node; role-based access to device management | ACL export |
| FR 3 | System integrity | *Example:* Signed images, secure boot, measured boot attestation | Section 9 |
| FR 4 | Data confidentiality | *Example:* TLS 1.3 on C-02 to C-04; C-01 and C-05 carry unencrypted legacy protocols, compensated by zone isolation and protocol allow-lists; encryption at rest on edge storage | Configuration review |
| FR 5 | Restricted data flow | *Example:* Zones and conduits in 7.2 and 7.3; outbound-only DMZ | Firewall rule review |
| FR 6 | Timely response to events | *Example:* Edge and conduit logs to the OT security monitoring service | Section 12 |
| FR 7 | Resource availability | *Example:* Local buffering, rate limits on broker, edge autonomy | Section 11 |

## 8. Device identity and provisioning

<!-- Guidance: Describe how a device gets its identity, proves it, renews it and loses it. Prefer identities that are created in hardware at manufacture and never leave it. Common pitfall: a shared key or default password across a device class; one extracted secret then opens the fleet. -->

| Topic | Decision | Rationale |
|---|---|---|
| Root of trust | *Example:* TPM 2.0 on gateways and servers; secure element on new sensors | Private keys are non-exportable |
| Identity type | *Example:* X.509 device certificate issued by the manufacturing CA at production; operational certificate issued at enrolment | Separates proof of origin from operational trust |
| Enrolment | *Example:* Zero-touch: device presents manufacturing certificate to the provisioning service through the DMZ relay; claim token from the work order binds it to site and group | No manual key handling at the plant |
| Certificate lifetime | *Example:* Operational certificates 90 days, renewed automatically at 60 days | Limits exposure of a stolen key |
| Revocation | *Example:* Broker and device management check status at connection; revocation on quarantine and decommission | Section 4.2 transitions |
| Human access to devices | *Example:* No local accounts; break-glass via jump host in Z-05 with session recording | FR 1 and FR 2 |
| Legacy devices without identity | *Example:* Identity held by the gateway that polls them; zone Z-06 compensates | Documented in 7.2 |
| [Topic] | [Decision] | [Rationale] |

Link the certificate hierarchy, issuance profiles and key ceremonies to PKI and Certificate Architecture (`security/pki-certificate-architecture`).

## 9. Software and firmware updates

<!-- Guidance: Updates are both the main security control and the main source of outages in a fleet. Define signing, staging, rollout rings, health checks and rollback, and say how long each class receives security updates. Common pitfall: an OTA mechanism that can brick a device with no physical access; every update path needs an automatic fallback. -->

| Topic | Decision |
|---|---|
| Artefacts | *Example:* OS images, container images, models and configuration, each with a version and a software bill of materials |
| Signing | *Example:* Images signed in the release pipeline with keys in a hardware security module; devices verify before install and at boot |
| Distribution | *Example:* Devices pull from the update relay in Z-05; the relay caches from the cloud repository |
| Install method | *Example:* A/B partitions on gateways; the new slot boots once on trial and is committed only after health checks pass |
| Health checks | *Example:* Process liveness, broker connection, data rate within 20% of baseline for 30 minutes |
| Rollback | *Example:* Automatic to the previous slot on failed health checks or three failed boots |
| Rollout rings | *Example:* Ring 0 lab, ring 1 one line per plant (5%), ring 2 one plant (33%), ring 3 all; promotion after 72 hours without regression |
| Maintenance windows | *Example:* Gateway updates only during planned line stops agreed with production |
| Security update period | *Example:* Gateways and servers receive security updates for at least the support period in section 13 |
| [Topic] | [Decision] |

```mermaid
sequenceDiagram
    participant P as Release pipeline
    participant R as Update relay (DMZ)
    participant D as Edge gateway
    P->>R: Signed image and SBOM published
    D->>R: Poll for assigned version
    R-->>D: Image and signature
    D->>D: Verify signature, install to inactive slot
    D->>D: Trial boot and health checks
    alt Checks pass
        D->>R: Report committed version
    else Checks fail
        D->>D: Roll back to previous slot
        D->>R: Report failure and logs
    end
```

## 10. Data pipeline and sizing

<!-- Guidance: Follow one metric from the sensor to its consumer and size every hop. End each estimate with the consequence for the design (broker size, link capacity, buffer size, storage cost). Common pitfall: sizing for average rates; size for the burst after a reconnect, when buffered data and live data arrive together. -->

### 10.1 Flow

[Describe the path from source to consumer.] *Example:* Tags are read by the gateway, published as Sparkplug data messages to the site broker, stored in the site historian and forwarded through the DMZ bridge to cloud ingestion. The cloud writes raw data to a time-series store for 30 days and to the data lake for 7 years; aggregates feed dashboards and model training. Streaming design detail is held in Streaming Solution Design (`architecture/streaming-solution-design`).

### 10.2 Sizing per plant

| Quantity | Value | Basis |
|---|---|---|
| Assets | 1,200 | *Example:* Section 1.1 (per plant; 3,600 in total) |
| Tags per asset | 40 | *Example:* Asset model |
| Tags | 48,000 | 1,200 x 40 |
| Average change rate per tag | 0.25 per second | *Example:* Report by exception with deadbands |
| Metric updates | 12,000 per second | 48,000 x 0.25 |
| Metrics per Sparkplug message | 25 | *Example:* Batching on the edge node |
| Messages | 480 per second | 12,000 / 25 |
| Bytes per message on the wire | 550 | *Example:* Protobuf payload plus MQTT and TLS overhead |
| Throughput | 264,000 B/s (about 2.11 Mbit/s) | 480 x 550 |
| Daily volume | about 22.81 GB per day | 264,000 x 86,400 |
| 72-hour buffer at site | about 68.43 GB | 264,000 x 259,200 |
| Buffer per gateway (30 gateways per plant, about 40 assets each) | about 2.28 GB | 68.43 / 30 |

Consequences: [state what follows.] *Example:* The site WAN link needs at least 2.11 Mbit/s sustained for this solution, and about 8.4 Mbit/s to drain a 72-hour backlog in 24 hours while live data continues (2.11 x (72 + 24) / 24). The 64 GB gateway storage holds the 2.28 GB buffer with room for images and logs. The site edge servers need about 68 GB of buffer per plant, which fits on the 4 TB nodes alongside the historian. Cloud ingestion receives the three plants together: about 6.34 Mbit/s (3 x 2.112) and 68.43 GB per day (3 x 22.81) in steady state, and up to about 25.3 Mbit/s (3 x 8.45) if all three plants drain a backlog at once; size ingestion quotas and the raw time-series store from these totals.

### 10.3 Edge reduction option

*Example:* Keep raw data for 10% of tags (those used by UC-001 and model training) and send one-minute aggregates (minimum, maximum, average and count, 18 bytes each) for the other 90%. Raw part: 0.1 x 12,000 x 22 bytes = 26,400 B/s. Aggregate part: 0.9 x 48,000 x 4 x 18 / 60 = 51,840 B/s. Total 78,240 B/s, about 6.76 GB per day, a reduction of about 70% against 22.81 GB. Decision: [accept / reject and why]. Record that aggregation loses information the data science team may later want, and keep raw data in the site historian for [N] days so that it can be replayed.

## 11. Offline operation and resilience

<!-- Guidance: State what keeps working when each dependency fails, for how long, and how the system recovers. Test every row. Common pitfall: alerts that depend on the cloud; if the use case has a latency of seconds at the line, the decision must be made at the edge. -->

| Failure | Detection | Behaviour during failure | Recovery | Data impact | Test |
|---|---|---|---|---|---|
| WAN link down *(Example)* | Bridge disconnect; host state message | Edge alerting and OEE continue; data buffered at site | Bridge drains backlog at limited rate to protect live data | None within 72 h | Quarterly WAN cut |
| Site broker node fails *(Example)* | Broker cluster health | Second node takes over; gateways reconnect | Replace node; rejoin cluster | Gateways buffer during reconnect | Node kill test |
| Gateway fails *(Example)* | Sparkplug death certificate; host marks node offline | Assets on that gateway stop reporting; alert to OT support | Spare gateway enrolled; configuration pulled automatically | Gap for that line until replaced | Spare swap drill |
| Cloud ingestion degraded *(Example)* | Ingestion lag metric | Site keeps buffering; dashboards in cloud stale | Backpressure clears | None within buffer limit | Game day (`ops/game-day-plan`) |
| Certificate authority unreachable *(Example)* | Renewal failures | Existing certificates valid until expiry | Renewal retries; 30-day margin | None | Renewal outage test |
| Clock drift *(Example)* | Time source monitoring | Events flagged with quality bit | Resynchronise | Ordering errors flagged | Drift injection |
| [Failure] | [Detection] | [Behaviour] | [Recovery] | [Impact] | [Test] |

Link resilience tiers and recovery objectives to Resilience Tiering and HA/DR Design (`architecture/resilience-tiering-ha-dr-design`).

## 12. Operations and support model

<!-- Guidance: A fleet in the field is operated for a decade. Define who monitors it, who can touch it, how incidents flow between IT, OT and vendors, and which metrics show fleet health. Common pitfall: no owner for the gateways between plant engineering and IT; nobody patches them. -->

### 12.1 Fleet health metrics

| Metric | Target | Source |
|---|---|---|
| Devices online | *Example:* 99% of active devices during production hours | Host state and device management |
| Data completeness | *Example:* 99.5% of expected metric updates received per day | Pipeline counters |
| Update compliance | *Example:* 95% of devices on the approved version within 30 days | OTA reports |
| Certificate health | *Example:* 0 certificates within 14 days of expiry | PKI monitoring |
| Security events | *Example:* Every high-severity event triaged within 1 hour | OT security monitoring |
| [Metric] | [Target] | [Source] |

### 12.2 RACI

| Activity | OT platform | Plant engineering | OT security | Cloud platform | Vendor |
|---|---|---|---|---|---|
| Gateway patching and OTA | R/A | C | C | I | C |
| Zone and conduit changes | R | C | A | C | I |
| Asset onboarding (tags, models) | R | A | I | C | I |
| Cloud ingestion operations | I | I | C | R/A | I |
| Security incident response | R | C | A | R | C |
| Device replacement in the field | C | R/A | I | I | C |

Observability details (signals, retention, dashboards) belong in Observability Specification (`ops/observability-spec`).

## 13. Regulatory and compliance view

<!-- Guidance: Decide which laws and standards apply to the solution and to each device class, then point to where the evidence lives. For connected products sold in the EU, the CRA applies to the product and its remote data processing; for in-house plant systems it usually does not apply to the operator, but bought components carry the manufacturer's obligations. Check the consolidated text; this section is a format, not legal advice. -->

| Obligation or standard | Applies to | Status in this design | Evidence location |
|---|---|---|---|
| EU Cyber Resilience Act, Regulation (EU) 2024/2847 | *Example:* Gateways and cloud service sold to customers as a connected product | Product category assessed; essential requirements of Annex I mapped | CRA Technical Documentation (`security/cra-technical-documentation`) |
| CRA reporting of actively exploited vulnerabilities and severe incidents (Article 14) | *Example:* Same products, including those already on the market | Reporting process live | CRA Vulnerability Handling (`security/cra-vulnerability-handling`) |
| CRA support period (Article 13) | *Example:* Gateways | Support period set to 10 years, published with the product | Section 4.1 and product documentation |
| IEC 62443-3-2 and 62443-3-3 | *Example:* Plant installations | Zones, conduits and SL-T in section 7 | This document and threat model |
| IEC 62443-4-2 | *Example:* Procured gateways and switches | Component certificates or capability statements per SL-T | Procurement file |
| NIS2 national transposition | *Example:* The manufacturer as an essential or important entity, if in scope | Security measures reviewed | NIS2 Security Measures (`compliance/nis2-security-measures`) |
| [Obligation] | [Scope] | [Status] | [Location] |

CRA timeline to record (check the consolidated text on EUR-Lex): the Regulation entered into force on 10 December 2024; the notification of conformity assessment bodies (Chapter IV) applies from 11 June 2026; the reporting obligations of Article 14 apply from 11 September 2026; the Regulation applies in full from 11 December 2027. Article 14 sets an early warning within 24 hours, a notification within 72 hours and a final report later, and covers products already on the market. Article 13 requires the manufacturer to set a support period that reflects the expected use time, with a minimum of five years unless the product is expected to be used for less.

## 14. Decisions, risks and roadmap

<!-- Guidance: Record the decisions a reviewer would challenge, the main risks with owners, and the rollout sequence. Keep full decision records in an ADR log. Common pitfall: rolling out to all plants before the pilot has run through a WAN outage, an OTA cycle and a certificate renewal. -->

### 14.1 Key decisions

| ID | Decision | Options considered | Choice and reason |
|---|---|---|---|
| EIA-ADR-001 *(Example)* | Site broker pattern | Direct gateway to cloud; site broker with bridge | Site broker: site autonomy, one conduit through the DMZ, unified namespace for local consumers |
| EIA-ADR-002 *(Example)* | Payload convention | Custom JSON; Sparkplug B; OPC UA PubSub JSON | Sparkplug B: state awareness and an open specification supported by many vendors |
| EIA-ADR-003 *(Example)* | Edge orchestration | None; vendor gateway manager; lightweight Kubernetes | Containers on gateways with vendor manager; Kubernetes only on site servers |
| [EIA-ADR-nnn] | [Decision] | [Options] | [Choice] |

Keep the full records in Architecture Decision Log (`architecture/architecture-decision-log`).

### 14.2 Risks

| ID | Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| EIA-RSK-01 *(Example)* | Legacy PLCs cannot meet SL-T 2 | High | Medium | Read-only conduit through HMI hosts; replacement plan by 2029 | Plant engineering |
| EIA-RSK-02 *(Example)* | Gateway vendor ends support before 2036 | Medium | High | Contractual support period; escrow of build scripts; second source qualified | Procurement |
| EIA-RSK-03 *(Example)* | OTA failure stops a line | Low | High | A/B install, rings, updates only during line stops | OT platform |
| EIA-RSK-04 *(Example)* | Backlog drain saturates WAN after outage | Medium | Medium | Rate-limited drain, priority for live data | OT platform |
| [ID] | [Risk] | [L] | [I] | [Mitigation] | [@owner] |

### 14.3 Roadmap

| Phase | Scope | Exit criteria | Target date |
|---|---|---|---|
| Pilot *(Example)* | One line at plant A | WAN cut, OTA cycle and certificate renewal tested; UC-001 alerts validated | YYYY-MM-DD |
| Plant A *(Example)* | All lines at plant A | Fleet metrics in 12.1 met for 60 days | YYYY-MM-DD |
| Plants B and C *(Example)* | Remaining plants | Zone assessment approved per site | YYYY-MM-DD |
| [Phase] | [Scope] | [Criteria] | YYYY-MM-DD |

## 15. Traceability matrix

<!-- Guidance: Trace each core requirement to the design element that meets it and the test that proves it. Reviewers use this table to find gaps. Common pitfall: requirements with no test; mark them and plan one. -->

| Requirement | Use case | Design element | Zone or conduit | Test | Status |
|---|---|---|---|---|---|
| IOT-NFR-001 *(Example)* | UC-001 | Section 5.1 edge model on gateway | Z-03 | Timestamped test signal | [Planned / Passed / Failed] |
| IOT-NFR-003 *(Example)* | UC-002 | Section 10.2 buffer; section 11 WAN row | Z-04, C-03 | Quarterly WAN cut | [Status] |
| IOT-NFR-005 *(Example)* | All | Sections 7.2 and 7.3 | All | SL-A assessment | [Status] |
| IOT-NFR-006 *(Example)* | UC-005 | Section 9 rings and rollback | C-03, C-04 | OTA pilot | [Status] |
| IOT-FR-003 *(Example)* | UC-002 | Sparkplug store and forward | Z-03, Z-04 | WAN cut test | [Status] |
| [ID] | [UC] | [Element] | [Zone] | [Test] | [Status] |

## 16. Glossary and references

<!-- Guidance: Define terms the readers of both worlds (IT and OT) may not share, and list every source with the version you checked. -->

### 16.1 Glossary

| Term | Meaning in this document |
|---|---|
| Asset owner | Organisation accountable for the plant or system and its risks |
| Conduit | Defined communication path between zones, with its own controls |
| Edge node | Device that publishes data for one or more field devices to the broker |
| Primary host application | Consumer whose online state tells edge nodes whether to send live data or buffer it |
| Report by exception | Publishing a value only when it changes beyond a deadband |
| SL-T, SL-C, SL-A | Target, capability and achieved security level |
| System under consideration (SUC) | The set of assets assessed together for security risk |
| Unified namespace | One broker hierarchy that holds the current state of the site for all consumers |
| Zone | Group of assets with common security requirements |

### 16.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| ANSI/ISA-95.00.01-2025, Enterprise-Control System Integration, Part 1: Models and Terminology (IEC 62264-1 Mod), isa.org | Announced 2025-04-10 | Level numbering, structure only |
| IEC 62443-3-2:2020, Security risk assessment for system design, webstore.iec.ch | Edition 1.0, 2020-06-24 | Zone and conduit steps ZCR 1 to ZCR 7 |
| IEC 62443-3-3:2013, System security requirements and security levels, webstore.iec.ch | Edition 1.0, 2013-08-07 (corrigendum 2014); check for a new edition | Security levels and foundational requirements |
| IEC 62443-4-2:2019, Technical security requirements for IACS components, webstore.iec.ch | Edition 1.0, 2019-02-27 (corrigendum 2022) | Component capability levels |
| MQTT Version 5.0, OASIS Standard, docs.oasis-open.org | 2019-03-07 | QoS, session and message expiry |
| Sparkplug 3.0.0, Eclipse Foundation, sparkplug.eclipse.org; published as ISO/IEC 20237:2023 | 2022-10-21 | Namespace, payload, state |
| OPC Unified Architecture (IEC 62541), OPC Foundation reference, reference.opcfoundation.org | Part 1 release 1.05.06, 2025-10-22; some parts at 1.05.07 | Protocol and security modes |
| Regulation (EU) 2024/2847 (Cyber Resilience Act), eur-lex.europa.eu; Commission CRA summary, digital-strategy.ec.europa.eu | OJ 2024-11-20; checked YYYY-MM-DD | Section 13 |
| [Internal OT security standard] | [Version] | [Use] |

## Standard and licence note

Structure aligned with the functional hierarchy of ANSI/ISA-95.00.01-2025 (IEC 62264-1), the zone and conduit requirements ZCR 1 to ZCR 7 of IEC 62443-3-2:2020, the security levels and foundational requirements of IEC 62443-3-3:2013 and the component requirements of IEC 62443-4-2:2019. Only level numbers, requirement numbers and short original paraphrases are used; no text, tables or definitions from ISA or IEC publications are reproduced. Obtain the standards for normative requirements. Based on the public specifications MQTT Version 5.0 (OASIS), Sparkplug 3.0 (Eclipse Foundation) and OPC UA (OPC Foundation), cited by name and version, and on Regulation (EU) 2024/2847, summarised in original words with dates to be checked against the consolidated text on EUR-Lex. This is a documentation format, not legal advice. Sparkplug is a trademark of the Eclipse Foundation and OPC UA is a trademark of the OPC Foundation; this template is not affiliated with or endorsed by them. This template is original text written for this collection; examples and figures are illustrative. Check the current official versions before use. Template licence: MIT.