# Manufacturing Integration Design (ISA-95): [Plant or programme name]

> Solution design for integrating enterprise systems (ERP, PLM, quality,
> maintenance) with manufacturing operations management (MES, LIMS,
> warehouse, historian) and the shop floor (SCADA, PLC, machines). The
> structure follows the functional hierarchy and object models of the
> ANSI/ISA-95 series (Part 1: ANSI/ISA-95.00.01-2025, IEC 62264-1
> modified), uses B2MML V0700 (MESA) or OPC UA (OPC UA 1.05, IEC 62541)
> for information exchange, offers a unified namespace option on MQTT
> 5.0 and Sparkplug 3.0, and partitions the OT/IT boundary into zones
> and conduits as described in IEC 62443-3-2. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write one design per plant, or one per programme with a section 13
  rollout table that lists each plant and its deviations.
- Fill section 3 (level mapping) and section 4 (functional scope split)
  first. Most integration disputes in manufacturing are really disputes
  about which system owns a function: ERP or MES, MES or SCADA.
- Every exchange in section 6 must name its ISA-95 object, its
  transaction verb, its latency class and its owner. An exchange that
  has no owner is the one that breaks during the first shift change.
- Device fleet, edge compute, OTA updates and device identity belong in
  Edge and IoT Solution Architecture
  (`architecture/edge-iot-solution-architecture`). This document covers
  level 3 and level 4 integration and the OT/IT boundary.
- Related documents: Integration Design (`architecture/integration-design`),
  Event-Driven Architecture Design
  (`architecture/event-driven-architecture-design`), Data Platform
  Architecture (`architecture/data-platform-architecture`), SAP S/4HANA
  Solution Design (`architecture/sap-s4hana-solution-design`), Network
  Architecture Design (`architecture/network-architecture-design`),
  Cutover Plan (`project/cutover-plan`).
- ISA-95 and IEC 62443 are copyrighted. This template uses level
  numbers, part numbers and model names only; obtain the standards for
  their normative content.
-->

## Document control

<!-- Guidance: Identify the plant or plants, the systems in scope and the owners on both the IT and OT side. A change to the level 3 / level 4 split or to the zone model is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [MFG-INT-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@manufacturing-solution-architect] |
| Approvers/reviewers | [@plant-manager], [@ot-security-lead], [@erp-architect], [@mes-product-owner], [@quality-lead] |
| Plants in scope | [Plant code, site name, country] |
| Industry and production type | [Discrete / Batch / Continuous / Mixed], [regulated: GMP, IATF 16949, AS9100, none] |
| ERP and MES products | [ERP product and release], [MES product and release] |
| Standards basis | ANSI/ISA-95.00.01-2025 and Parts 2 to 8, B2MML V0700, OPC UA 1.05, MQTT 5.0, Sparkplug 3.0.0, IEC 62443-3-2:2020 and 62443-3-3:2013 |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Plant manager | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| OT security | [@name] | [Decision] | YYYY-MM-DD |
| Enterprise architecture | [@name] | [Decision] | YYYY-MM-DD |
| Quality (validated systems) | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for pilot plant P01 |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added unified namespace for line telemetry; plant P02 deviations |

## Contents

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

1. [Scope, drivers and constraints](#1-scope-drivers-and-constraints)
2. [Requirements](#2-requirements)
3. [Level mapping](#3-level-mapping)
4. [Functional scope split](#4-functional-scope-split)
5. [Information model](#5-information-model)
6. [Information exchanges](#6-information-exchanges)
7. [Integration architecture and unified namespace option](#7-integration-architecture-and-unified-namespace-option)
8. [OPC UA design](#8-opc-ua-design)
9. [Historian and operational data](#9-historian-and-operational-data)
10. [OT/IT boundary: zones, conduits and security levels](#10-otit-boundary-zones-conduits-and-security-levels)
11. [Latency, availability and offline operation](#11-latency-availability-and-offline-operation)
12. [Testing, validation and acceptance](#12-testing-validation-and-acceptance)
13. [Rollout per plant](#13-rollout-per-plant)
14. [Operations, risks and decisions](#14-operations-risks-and-decisions)
15. [Glossary and references](#15-glossary-and-references)

## 1. Scope, drivers and constraints

<!-- Guidance: Say which plants, lines and systems are in scope and why the programme exists. Questions: is the driver traceability, OEE, paperless batch records, ERP replacement or a new plant? Pitfall: a scope that lists systems but not the business processes that cross them. -->

### 1.1 Scope

| In scope | Out of scope |
|---|---|
| *Example:* Order release from ERP to MES, production confirmation and goods movement back to ERP for plant P01 | Finance and sales processes inside ERP |
| *Example:* Material genealogy from goods receipt to finished goods | Machine control logic in PLCs |
| *Example:* Line telemetry to the historian and the data platform | Device provisioning and firmware updates (see edge and IoT design) |
| [Item] | [Item] |

### 1.2 Business drivers

| ID | Driver | Measure | Target |
|---|---|---|---|
| DRV-001 *(Example)* | End-to-end lot traceability for recalls | Time to produce a forward and backward genealogy report | Under [15 minutes] |
| DRV-002 *(Example)* | Remove manual re-keying of production confirmations | Share of confirmations posted automatically | [98 %] |
| DRV-003 *(Example)* | Reliable OEE per line | Lines with automated availability, performance and quality data | [All lines in P01] |
| [DRV-NNN] | [Driver] | [Measure] | [Target] |

### 1.3 Constraints and assumptions

- *Example:* The ERP remains the system of record for material master, bills of materials and routings; MES receives them and never edits them.
- *Example:* Production must continue for [8 hours] without ERP connectivity.
- *Example:* The MES is a validated system under [GMP regulation]; any interface change follows change control.
- [Constraint or assumption]

## 2. Requirements

<!-- Guidance: Separate functional integration requirements from quality attributes. Give each a verifiable acceptance criterion. Pitfall: copying the MES vendor's feature list instead of stating what the plant needs. -->

### 2.1 Functional requirements

| ID | Requirement | Priority | Acceptance criterion |
|---|---|---|---|
| FR-001 *(Example)* | Released production orders reach MES with material list, routing and target quantity | Must | Order visible in MES within [2 minutes] of release in 100 % of test cases |
| FR-002 *(Example)* | MES reports operation confirmations, scrap and consumed lots back to ERP | Must | ERP stock and order status match MES at end of shift |
| FR-003 *(Example)* | Quality results from LIMS gate the release of a batch in MES and ERP | Must | A batch with a failed result cannot be released in either system |
| FR-004 *(Example)* | Maintenance work orders raised from machine alarms | Should | Alarm class A creates a work order with equipment ID and fault code |
| FR-005 *(Example)* | Equipment state and counts published per line for OEE | Must | State changes visible to OEE within [5 seconds] |
| [FR-NNN] | [Requirement] | [Must / Should / Could] | [Criterion] |

### 2.2 Quality attributes

| ID | Attribute | Requirement | Verification |
|---|---|---|---|
| NFR-001 *(Example)* | Availability | Shop floor execution continues during ERP or WAN outage for [8 hours] | Planned outage test in section 12 |
| NFR-002 *(Example)* | Data integrity | No production confirmation lost or duplicated | Idempotency and reconciliation tests |
| NFR-003 *(Example)* | Latency | Telemetry from line to site broker under [1 second] at the 95th percentile | Load test with [n] tags |
| NFR-004 *(Example)* | Security | Conduits meet the target security level in section 10 | Zone and conduit review, penetration test |
| NFR-005 *(Example)* | Auditability | Electronic records keep who, what and when for [regulated] data | Audit trail review by quality |
| [NFR-NNN] | [Attribute] | [Requirement] | [Verification] |

## 3. Level mapping

<!-- Guidance: Place every system on an ISA-95 functional level. The levels are functional, not network segments: zones are drawn separately in section 10. Pitfall: putting MES at level 2 because it runs on a server in the plant. -->

The level numbers follow the functional hierarchy of ANSI/ISA-95.00.01-2025 (IEC 62264-1). The descriptions are original summaries; obtain the standard for its normative models.

| Level | Functional role (summary) | Time frame (typical) | Systems in this plant |
|---|---|---|---|
| 4 | Business planning and logistics: plant schedule, material use, delivery, shipping | Months, weeks, days | *Example:* ERP, PLM, advanced planning |
| 3 | Manufacturing operations management: dispatching, detailed scheduling, execution tracking, quality, maintenance and inventory operations | Days, shifts, hours, minutes | *Example:* MES, LIMS, warehouse management, historian, CMMS on site |
| 2 | Monitoring and supervisory control | Minutes, seconds | *Example:* SCADA, HMI, batch control system |
| 1 | Sensing and manipulating the process | Seconds, milliseconds | *Example:* PLCs, drives, remote I/O |
| 0 | The physical process | Continuous | *Example:* Filling line, mixer, packer |

```mermaid
flowchart TB
    subgraph L4["Level 4: business planning and logistics"]
        ERP["ERP"]
        PLM["PLM"]
    end
    subgraph L3["Level 3: manufacturing operations management"]
        MES["MES"]
        LIMS["LIMS"]
        WMS["Warehouse management"]
        HIS["Historian"]
    end
    subgraph L2["Level 2: supervisory control"]
        SCADA["SCADA and HMI"]
        BATCH["Batch control"]
    end
    subgraph L1["Level 1: control"]
        PLC["PLCs and drives"]
    end
    ERP -- "orders, materials, BOM, routings" --> MES
    MES -- "confirmations, consumption, genealogy" --> ERP
    PLM -- "work instructions, specifications" --> MES
    MES <--> LIMS
    MES <--> WMS
    MES -- "recipes, setpoints" --> BATCH
    SCADA -- "OPC UA" --> HIS
    BATCH --> PLC
    SCADA --> PLC
```

## 4. Functional scope split

<!-- Guidance: Decide which system performs each operations management activity. ISA-95 Part 3 groups level 3 activities into production, quality, maintenance and inventory operations management; use those four names and your own breakdown. Pitfall: the same function configured in both ERP and MES, for example two schedulers that disagree. -->

Use the four categories of operations management named in ANSI/ISA-95.00.03 (production, quality, maintenance, inventory). For each activity, mark the owning system (O), the systems that consume its result (C) and any system that must not perform it (X).

| Activity | ERP | MES | LIMS | WMS | CMMS | SCADA | Decision note |
|---|---|---|---|---|---|---|---|
| Plant master schedule *(Example)* | O | C | | | | | ERP plans to the day |
| Detailed scheduling and sequencing *(Example)* | X | O | | | | C | MES sequences per line and shift |
| Dispatching work to lines *(Example)* | | O | | | | C | |
| Execution tracking and confirmations *(Example)* | C | O | | | | C | |
| Material genealogy *(Example)* | C | O | C | C | | | MES is the genealogy record |
| Quality test execution and results *(Example)* | C | C | O | | | | |
| Batch disposition and release *(Example)* | C | C | O | | | | Quality person signs in LIMS |
| Maintenance work order management *(Example)* | C | C | | | O | C | |
| Inventory movements inside the plant *(Example)* | C | C | | O | | | |
| [Activity] | [O / C / X] | | | | | | [Note] |

Decision criteria for borderline functions:

- Place a function at level 3 when it must keep running during a level 4 outage or needs decisions in minutes rather than hours.
- Place a function at level 4 when it needs data from several plants or drives financial postings.
- Never let two systems hold writable copies of the same master record. Name one system of record per object in section 5.

## 5. Information model

<!-- Guidance: Name the ISA-95 objects you exchange and the system of record for each. ISA-95 Parts 2 and 4 define the object models; list their names and your attribute decisions, not the standard's attribute tables. Pitfall: inventing a private model and mapping to B2MML only at the edge, which loses the shared vocabulary. -->

### 5.1 Objects and system of record

| Object (ISA-95 model name) | System of record | Key identifiers | Notes |
|---|---|---|---|
| Material definition, material lot *(Example)* | ERP for definition, MES for lots created in production | Material number, lot ID | Lot IDs unique across plants: prefix with plant code |
| Equipment and equipment hierarchy *(Example)* | MES, synchronised from CMMS functional locations | Enterprise, site, area, work centre, work unit | Hierarchy is the basis of the namespace in section 7 |
| Physical asset *(Example)* | CMMS | Serial number, asset tag | Linked to equipment by asset mapping |
| Personnel class and person *(Example)* | HR system via identity provider | Employee ID, qualification | Qualifications gate operations in MES |
| Process segment *(Example)* | PLM | Segment ID, version | |
| Product definition (BOM, routing) *(Example)* | ERP and PLM | Material, BOM and routing version | MES holds read-only copies |
| Operations schedule and operations request *(Example)* | ERP to MES | Order number | |
| Operations performance and response *(Example)* | MES to ERP | Order number, confirmation counter | |
| [Object] | [System] | [Identifiers] | [Notes] |

### 5.2 Identifier and versioning rules

| ID | Rule | Rationale |
|---|---|---|
| IDR-001 *(Example)* | Equipment IDs follow `site.area.workcentre.unit`, lower case, no spaces | Same path in MES, historian and namespace |
| IDR-002 *(Example)* | Every master data message carries a version and effective date | MES can hold the next version before it applies |
| IDR-003 *(Example)* | Units of measure use the ERP unit codes, converted only in one mapping service | Avoids silent rounding differences |
| [IDR-NNN] | [Rule] | [Rationale] |

## 6. Information exchanges

<!-- Guidance: List every exchange between levels and between level 3 systems. ISA-95 Part 5 defines transaction verbs for business-to-manufacturing messages (for example GET, SHOW, PROCESS, ACKNOWLEDGE, CHANGE, CANCEL, SYNC, RESPOND); B2MML implements Parts 2, 4 and 5 as XML schemas. Pitfall: using SYNC for everything, which hides who is the system of record. -->

### 6.1 Exchange catalogue

| ID | From | To | ISA-95 object | Verb pattern | Format and transport | Trigger | Latency class | Owner |
|---|---|---|---|---|---|---|---|---|
| MX-001 *(Example)* | ERP | MES | Material definition | SYNC (ERP is record) | B2MML V0700 over integration platform queue | Master data change | Near real time (minutes) | @erp-integration |
| MX-002 *(Example)* | ERP | MES | Operations schedule | PROCESS, then ACKNOWLEDGE | B2MML over queue | Order release | Near real time | @erp-integration |
| MX-003 *(Example)* | MES | ERP | Operations performance | PROCESS, then ACKNOWLEDGE | B2MML or ERP API via integration platform | Operation complete, end of shift | Near real time with end-of-shift reconciliation | @mes-team |
| MX-004 *(Example)* | MES | LIMS | Sample request | PROCESS | REST API | Sampling point reached | Seconds | @mes-team |
| MX-005 *(Example)* | LIMS | MES, ERP | Quality result and disposition | SHOW, CHANGE | REST and B2MML | Result approved | Minutes | @quality-it |
| MX-006 *(Example)* | SCADA | Historian, MES | Equipment state, counts, process values | Publish | OPC UA subscription or MQTT Sparkplug | Value change | Sub-second | @ot-engineering |
| MX-007 *(Example)* | MES | Batch control | Recipe and setpoints | Write with confirmation | OPC UA methods | Batch start | Seconds | @ot-engineering |
| MX-008 *(Example)* | SCADA alarm service | CMMS | Maintenance request | PROCESS, then ACKNOWLEDGE | REST API via integration platform | Class A alarm | Minutes | @maintenance-it |
| [MX-NNN] | [From] | [To] | [Object] | [Verb] | [Format] | [Trigger] | [Class] | [@owner] |

### 6.2 Order-to-confirmation sequence

The sequence shows exchanges MX-002 and MX-003 for one production order, including the acknowledgement path that tells MES whether ERP accepted each confirmation.

```mermaid
sequenceDiagram
    participant ERP
    participant IP as Integration platform
    participant MES
    participant LINE as SCADA and line
    ERP->>IP: Operations schedule (PROCESS)
    IP->>MES: Transformed order
    MES-->>IP: ACKNOWLEDGE (accepted)
    IP-->>ERP: ACKNOWLEDGE
    MES->>LINE: Dispatch to work unit
    LINE-->>MES: Counts, states, consumed lots
    MES->>IP: Operations performance (PROCESS)
    IP->>ERP: Confirmation and goods movements
    ERP-->>IP: ACKNOWLEDGE or error
    IP-->>MES: Status, error to retry queue if rejected
```

### 6.3 Message rules

- Give every transactional message a unique message ID and a business key (order and confirmation counter) so the receiver can discard duplicates.
- Queue outbound confirmations in MES while ERP is unreachable; replay them in order per order number when it returns.
- Reject, never silently correct, a message with an unknown material or equipment ID; route it to an error queue with an owner and a response time.
- Reconcile ERP stock and order status against MES at the end of each shift; report differences to the shift lead.
- Version the schema used on each interface and record it in the exchange catalogue. B2MML V0700 is not fully backward compatible with V0600, so plan the upgrade per interface.

## 7. Integration architecture and unified namespace option

<!-- Guidance: Choose how level 3 and level 4 connect (point to point, integration platform, event broker) and whether shop floor data uses a unified namespace. Pitfall: treating a unified namespace as a replacement for transactional integration; it carries state and events well, but orders and confirmations still need acknowledgements and reconciliation. -->

### 7.1 Options

| Option | Description | Strengths | Weaknesses | Fit |
|---|---|---|---|---|
| A. Point to point *(Example)* | ERP connector in MES, direct OPC UA reads | Fast to start | Every new consumer adds a connection; hard to monitor | One line, one MES |
| B. Integration platform plus OPC UA *(Example)* | Transactions through an integration platform; telemetry through OPC UA to historian | Clear ownership, mature tooling | Telemetry consumers each need OPC UA access | Most single-plant programmes |
| C. Integration platform plus unified namespace *(Example)* | Transactions as in B; telemetry and state on an MQTT broker in a site hierarchy, Sparkplug payloads | One place to discover current state; consumers decoupled | Needs namespace governance; broker becomes critical | Multi-plant, many data consumers |

Chosen option: [*Example:* C]. Reason: [*Example:* six consumers of line data are planned, and two more plants follow in 18 months].

### 7.2 Unified namespace design (if option C)

A unified namespace (industry practice, not a formal standard) is a broker-hosted topic hierarchy that mirrors the equipment hierarchy and holds the current state of the operation. Design rules:

| ID | Rule |
|---|---|
| UNS-001 *(Example)* | Topic root follows the equipment hierarchy: `enterprise/site/area/line/cell` |
| UNS-002 *(Example)* | Line telemetry uses Sparkplug 3.0.0 topics and payloads; MES events use plain MQTT 5.0 with JSON payloads under a separate `events` branch |
| UNS-003 *(Example)* | Retained messages hold the last known state; birth and death certificates mark edge node health |
| UNS-004 *(Example)* | Each branch has a named owner and a published schema in the data catalogue |
| UNS-005 *(Example)* | Transactions with ERP stay on the integration platform; the namespace only publishes their outcome |
| UNS-006 *(Example)* | Brokers are clustered per site; a bridge to the enterprise broker crosses the DMZ outbound only |
| [UNS-NNN] | [Rule] |

### 7.3 Integration components

| Component | Product or service | Level and zone | Owner |
|---|---|---|---|
| Integration platform *(Example)* | [Product] | Level 4, enterprise zone | @integration-team |
| Site MQTT broker cluster *(Example)* | [Product] | Level 3, site operations zone | @ot-engineering |
| OPC UA aggregation server *(Example)* | [Product] | Level 3, site operations zone | @ot-engineering |
| Historian *(Example)* | [Product] | Level 3, with replica in DMZ | @ot-engineering |
| [Component] | [Product] | [Level, zone] | [@owner] |

## 8. OPC UA design

<!-- Guidance: Specify how OPC UA is used: client/server or PubSub, information models, security modes and certificate handling. OPC UA is published by the OPC Foundation and as IEC 62541. Pitfall: running with security mode None in production because certificate management was never designed. -->

| Topic | Decision |
|---|---|
| Specification baseline | *Example:* OPC UA 1.05 (parts at 1.05.0x on reference.opcfoundation.org); check each server's supported profiles |
| Communication pattern | *Example:* Client/server subscriptions from aggregation server to SCADA; PubSub over MQTT for new lines |
| Information models | *Example:* OPC UA for Machinery (Part 1 building blocks) for machine identification and state; OPC 10030 ISA-95 Common Object Model for equipment and material classes where the MES supports it |
| Address space naming | *Example:* Browse paths match equipment IDs in section 5.2 |
| Security mode and policy | *Example:* Sign and encrypt, with the strongest policy supported by every server; no None endpoints outside commissioning |
| Certificates | *Example:* Plant certificate authority, 2-year validity, renewal [60 days] before expiry, trust lists managed centrally |
| User authorisation | *Example:* Role-based: read-only for historian, write only for MES service account on recipe nodes |
| Write access | *Example:* Writes to level 1 only through batch control or MES methods that confirm the result |
| [Topic] | [Decision] |

## 9. Historian and operational data

<!-- Guidance: Decide where time-series data is stored, how long, and how it reaches enterprise analytics. Pitfall: letting analytics query the plant historian directly across the boundary. -->

| Item | Decision |
|---|---|
| Data captured | *Example:* [n] tags across [m] lines: process values, states, counts, alarms |
| Sampling and compression | *Example:* Exception-based capture with deadband per tag class |
| Retention | *Example:* [2 years] raw at site, [10 years] aggregates in the data platform |
| Context | *Example:* Each value tagged with equipment ID, order and lot from MES |
| Path to enterprise | *Example:* Historian replica in DMZ, then batch and streaming feeds to the data platform |
| Data quality | *Example:* Quality flag on every value; stale data alarm after [5 minutes] |
| Regulated records | *Example:* Electronic batch records kept in MES with audit trail, not in the historian |

Details of the analytical platform belong in Data Platform Architecture (`architecture/data-platform-architecture`).

## 10. OT/IT boundary: zones, conduits and security levels

<!-- Guidance: Partition the system under consideration into zones and conduits and assign a target security level to each, following the method of IEC 62443-3-2; IEC 62443-3-3 defines the system security requirements per security level (SL 1 to SL 4). Use your own descriptions. Pitfall: one flat "OT network" zone with a single firewall rule set. -->

### 10.1 Zones

| Zone ID | Zone | Assets | Target security level (SL-T) | Owner |
|---|---|---|---|---|
| Z-ENT *(Example)* | Enterprise | ERP, integration platform, data platform | Per IT policy | @it-security |
| Z-DMZ *(Example)* | Industrial DMZ | Historian replica, MQTT bridge, patch and AV relay, remote access gateway | SL 3 | @ot-security-lead |
| Z-OPS *(Example)* | Site operations (level 3) | MES, LIMS client servers, site broker, OPC UA aggregation server | SL 2 | @ot-security-lead |
| Z-CTL-L1 *(Example)* | Line 1 control (levels 1 and 2) | SCADA, HMI, PLCs of line 1 | SL 2 | @ot-engineering |
| Z-SIS *(Example)* | Safety instrumented systems | Safety PLCs | SL 3, no conduit to Z-ENT | @process-safety |
| [Z-NNN] | [Zone] | [Assets] | [SL] | [@owner] |

### 10.2 Conduits

| Conduit ID | Between | Allowed flows | Direction | Controls |
|---|---|---|---|---|
| C-01 *(Example)* | Z-ENT and Z-DMZ | MX-001 to MX-003 via integration platform; analytics reads of historian replica | Initiated from DMZ where possible | Firewall allow list, TLS, mutual authentication |
| C-02 *(Example)* | Z-DMZ and Z-OPS | Historian replication, broker bridge, MES web services | Initiated from Z-OPS outbound | Firewall, no direct enterprise to level 3 sessions |
| C-03 *(Example)* | Z-OPS and Z-CTL-L1 | OPC UA subscriptions, recipe writes, alarm events for MX-008 | OPC UA client in Z-OPS | Sign and encrypt, write allow list per node |
| C-04 *(Example)* | Remote access | Vendor support to Z-CTL-L1 | Brokered session from DMZ gateway | Multi-factor, time-boxed approval, session recording |
| [C-NN] | [Zones] | [Flows] | [Direction] | [Controls] |

Rules: no flow crosses more than one zone boundary without terminating in the DMZ; every exchange in section 6 maps to exactly one conduit path; the safety zone has no conduit to the enterprise. Device-level controls and patching are covered by the edge and IoT design and the plant OT security programme.

## 11. Latency, availability and offline operation

<!-- Guidance: Assign each exchange a latency class and state what happens when each upstream system is unavailable. Pitfall: an MES that stops dispatching because it cannot reach ERP for a material check. -->

### 11.1 Latency classes

| Class | Target | Exchanges |
|---|---|---|
| Control *(Example)* | Milliseconds, stays inside level 1 and 2 | None in this design |
| Supervisory *(Example)* | Under 1 second | MX-006 |
| Operations *(Example)* | Seconds to minutes | MX-004, MX-005, MX-007, MX-008 |
| Business *(Example)* | Minutes, with reconciliation per shift | MX-001 to MX-003 |

### 11.2 Degraded modes

| Failure | Effect | Behaviour | Recovery |
|---|---|---|---|
| ERP or WAN down *(Example)* | No new orders, no postings | MES runs released orders for up to [8 hours]; confirmations queue locally | Replay in order; shift reconciliation |
| MES down *(Example)* | No dispatching or genealogy | Paper or local HMI fallback procedure [SOP-ID]; lines continue current orders | Back-entry of records, quality review |
| Site broker down *(Example)* | Telemetry consumers stale | Edge nodes buffer [n hours]; historian keeps OPC UA path | Broker cluster failover, store and forward |
| Historian down *(Example)* | Gaps in trends | OPC UA server buffers; data backfilled | Backfill and data quality flag |
| [Failure] | [Effect] | [Behaviour] | [Recovery] |

Availability targets and recovery objectives per system: [*Example:* MES 99.9 % during production hours, RTO 1 hour, RPO 5 minutes]. Use Resilience Tiering and HA/DR Design (`architecture/resilience-tiering-ha-dr-design`) for the tier definitions.

## 12. Testing, validation and acceptance

<!-- Guidance: Plan interface tests, end-to-end process tests on a pilot line, outage tests and, for regulated plants, validation evidence. Pitfall: testing interfaces with clean master data only. -->

| ID | Test | Scope | Pass criterion | Evidence |
|---|---|---|---|---|
| TST-001 *(Example)* | Interface contract tests | MX-001 to MX-008 | Valid and invalid messages handled as specified | Test report per interface |
| TST-002 *(Example)* | End-to-end order to stock | Pilot line, three products | ERP stock equals MES after five shifts | Reconciliation report |
| TST-003 *(Example)* | ERP outage | Pilot line | Production continues 8 hours; zero lost confirmations | Outage test record |
| TST-004 *(Example)* | Genealogy | Forward and backward trace of a finished lot | Report complete within target in DRV-001 | Trace report |
| TST-005 *(Example)* | Zone and conduit verification | All conduits | Only flows in section 10.2 pass | Firewall rule review, scan results |
| TST-006 *(Example)* | Computer system validation | Regulated interfaces | Approved IQ, OQ, PQ protocols executed | Validation summary report |
| TST-007 *(Example)* | Telemetry load | Site broker and OPC UA path with [n] tags | NFR-003 met at the 95th percentile | Load test report |
| [TST-NNN] | [Test] | [Scope] | [Criterion] | [Evidence] |

### 12.1 Traceability

| Requirement | Exchange or design element | Test |
|---|---|---|
| FR-001 *(Example)* | MX-002 | TST-001, TST-002 |
| FR-002 *(Example)* | MX-003 | TST-001, TST-002, TST-003 |
| FR-003 *(Example)* | MX-004, MX-005 | TST-001, TST-002 |
| FR-004 *(Example)* | MX-008 | TST-001 |
| FR-005 *(Example)* | MX-006, section 7.2 | TST-001 |
| NFR-001 *(Example)* | Section 11.2 | TST-003 |
| NFR-002 *(Example)* | Section 6.3 message rules | TST-002, TST-003 |
| NFR-003 *(Example)* | MX-006, section 11.1 | TST-007 |
| NFR-004 *(Example)* | Section 10 | TST-005 |
| NFR-005 *(Example)* | Section 9, regulated records | TST-006 |
| [ID] | [Element] | [Test] |

## 13. Rollout per plant

<!-- Guidance: Roll out a template design to one pilot plant, then replicate with recorded deviations. Pitfall: each plant customising its MES, so the second plant costs as much as the first. -->

| Wave | Plant | Lines | Go-live | Deviations from template | Readiness owner |
|---|---|---|---|---|---|
| 1 *(Example)* | P01 pilot | 2 of 6 | YYYY-MM-DD | None | @plant-p01 |
| 2 *(Example)* | P01 remainder | 4 | YYYY-MM-DD | Line 5 uses legacy SCADA without OPC UA: gateway required | @plant-p01 |
| 3 *(Example)* | P02 | 8 | YYYY-MM-DD | Batch process: recipe exchange MX-007 extended | @plant-p02 |
| [Wave] | [Plant] | [Lines] | YYYY-MM-DD | [Deviations] | [@owner] |

Plant readiness checklist (original wording):

- Equipment hierarchy loaded and agreed with maintenance.
- Master data for the first products synchronised and checked by the plant.
- Zone and conduit rules implemented and tested.
- Operators and shift leads trained on normal and degraded modes.
- Hypercare roster agreed; see Hypercare Plan (`ops/hypercare-plan`) and Cutover Plan (`project/cutover-plan`).

## 14. Operations, risks and decisions

<!-- Guidance: Name who runs each interface, how incidents cross the IT and OT teams, and the main risks and decisions. Pitfall: IT support desks that cannot reach OT engineers at night. -->

### 14.1 RACI

| Activity | Plant OT engineering | IT integration team | MES product owner | OT security | Quality |
|---|---|---|---|---|---|
| Interface monitoring *(Example)* | C | R/A | I | I | I |
| Error queue handling *(Example)* | C | R | A | | C |
| Namespace governance *(Example)* | R | C | A | C | |
| Conduit rule changes *(Example)* | C | C | I | R/A | |
| Validated interface change *(Example)* | C | R | C | C | A |

### 14.2 Risks

| ID | Risk | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|
| RSK-001 *(Example)* | Master data quality blocks order release | High | High | Data cleansing before wave 1, MX-001 validation rules | @erp-architect |
| RSK-002 *(Example)* | Legacy SCADA lacks secure OPC UA | Medium | Medium | Protocol gateway in the line control zone (Z-CTL-L1 pattern), compensating controls | @ot-engineering |
| RSK-003 *(Example)* | Namespace grows without governance | Medium | Medium | UNS-004 ownership, schema registry | @mes-product-owner |
| [RSK-NNN] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [@owner] |

### 14.3 Decisions

| ID | Decision | Alternatives considered | Date |
|---|---|---|---|
| DEC-001 *(Example)* | MES owns detailed scheduling | ERP finite scheduling | YYYY-MM-DD |
| DEC-002 *(Example)* | Unified namespace for telemetry, integration platform for transactions | Namespace for everything | YYYY-MM-DD |
| [DEC-NNN] | [Decision] | [Alternatives] | YYYY-MM-DD |

Record significant decisions in full in an Architecture Decision Log (`architecture/architecture-decision-log`).

## 15. Glossary and references

<!-- Guidance: Define terms for IT readers who are new to manufacturing, and list the editions you used with the date checked. -->

### 15.1 Glossary

| Term | Meaning |
|---|---|
| MES | Manufacturing execution system: the level 3 system that dispatches and tracks production |
| B2MML | Business To Manufacturing Markup Language: XML schemas from MESA that implement ISA-95 models |
| Unified namespace | Broker topic hierarchy that mirrors the plant structure and holds current state |
| Sparkplug | Eclipse specification for MQTT topics, payloads and state management in industrial systems |
| Zone | Group of assets that share security requirements |
| Conduit | Controlled communication path between zones |
| SL-T | Target security level for a zone or conduit |
| Genealogy | Record of which material lots went into which produced lots |

### 15.2 References

| Reference | Version or date | Use |
|---|---|---|
| ANSI/ISA-95.00.01-2025 (IEC 62264-1 Mod), Enterprise-Control System Integration Part 1: Models and Terminology, isa.org | 2025 (announced 2025-04-10) | Levels, functional model |
| ANSI/ISA-95.00.02-2018, .03-2013, .04-2018, .05-2018, .06-2014, .07-2017, .08-2020, isa.org | As listed on the ISA-95 page; check current editions | Objects, activities, transactions, messaging, profiles |
| B2MML V0700, MESA International, mesa.org | V0700 (announced December 2020) | Message schemas |
| OPC UA specification, OPC Foundation, reference.opcfoundation.org; IEC 62541 series | 1.05 (parts at 1.05.0x) | OPC UA design |
| OPC 10030 ISA-95 Common Object Model; OPC 10031-4 ISA-95 Job Control | Current OPC Foundation releases | Information models |
| MQTT Version 5.0, OASIS Standard | 2019-03-07 | Broker transport |
| Sparkplug 3.0.0, Eclipse Foundation (also ISO/IEC 20237) | 3.0.0 (2022) | Namespace payloads |
| IEC 62443-3-2:2020, IEC 62443-3-3:2013, webstore.iec.ch | Editions as listed; check for newer editions | Zones, conduits, security levels |
| [Internal OT security standard] | [Version] | [Use] |

## Standard and licence note

Structure aligned with the ANSI/ISA-95 series (Part 1: ANSI/ISA-95.00.01-2025, IEC 62264-1 modified, and Parts 2 to 8), the IEC 62443-3-2 zone and conduit method and IEC 62443-3-3 security levels; based on the public OPC UA specification (OPC Foundation, release 1.05), MQTT 5.0 (OASIS) and Sparkplug 3.0.0 (Eclipse Foundation), with B2MML V0700 named as the MESA implementation of ISA-95. ISA and IEC standards are copyrighted: this template uses only part numbers, level numbers and model names, and all descriptions are original text written for this collection; obtain the standards for normative requirements. The unified namespace is described as industry practice, not as a standard. Check the current official editions before use. OPC UA is a trademark of the OPC Foundation and Sparkplug is a trademark of the Eclipse Foundation; this template is not affiliated with or endorsed by them. Template licence: MIT.