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.

Document control

Approvals

Revision history

Contents

1. Scope, use cases and drivers
2. Requirements
3. Reference model and level mapping
4. Device fleet and lifecycle
5. Edge compute design
6. Connectivity and protocols
7. Zones, conduits and security levels
8. Device identity and provisioning
9. Software and firmware updates
10. Data pipeline and sizing
11. Offline operation and resilience
12. Operations and support model
13. Regulatory and compliance view
14. Decisions, risks and roadmap
15. Traceability matrix
16. Glossary and references

1. Scope, use cases and drivers

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

1.3 Drivers and constraints

2. Requirements

2.1 Functional requirements

2.2 Non-functional requirements

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

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.

4. Device fleet and lifecycle

4.1 Device classes

4.2 Lifecycle states

5. Edge compute design

5.1 Edge tiers and workloads

5.2 Edge platform decisions

6. Connectivity and protocols

6.1 Protocol per hop

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

7. Zones, conduits and security levels

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.

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

7.3 Conduits

7.4 Foundational requirement coverage

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

8. Device identity and provisioning

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

9. Software and firmware updates

10. Data pipeline and sizing

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

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

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

12. Operations and support model

12.1 Fleet health metrics

12.2 RACI

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

13. Regulatory and compliance view

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

14.1 Key decisions

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

14.2 Risks

14.3 Roadmap

15. Traceability matrix

16. Glossary and references

16.1 Glossary

16.2 References

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.