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.
Document control
| 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
1. Scope, drivers and constraints
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
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
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 |
4. Functional scope split
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
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
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.
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
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
| 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
| 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
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
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
| 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
| 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
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
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.