ISO 22400 is a KPI and terminology standard, not an integration protocol. To make it useful in real plants, you typically pair it with standards that define data models, interfaces, and messaging between ERP, MES, SCADA/DCS, historians, and IIoT platforms.
Core standards that commonly pair with ISO 22400
The combinations below are what most regulated manufacturers use to operationalize ISO 22400 KPIs in mixed-vendor environments.
- ISA-95 / IEC 62264 (enterprise-to-control models)
- Why it pairs well: ISA-95 defines the information model and level boundaries between ERP (Level 4), MES (Level 3), and control (Levels 1–2). ISO 22400 defines how you calculate KPIs like OEE, availability, and performance. Mapping ISO 22400 KPIs onto ISA-95 entities (equipment, work centers, orders, materials) gives you a consistent, traceable KPI stack.
- Typical use: Define data ownership and interfaces (e.g., where run time, downtime, and good/scrap counts are mastered), then implement ISO 22400 calculations on top of that model.
- Constraints: Older MES or ERP systems may only partially align with ISA-95. You may end up with “hybrid” models and have to document deliberate deviations for validation and auditability.
- OPC UA (OT connectivity and semantics)
- Why it pairs well: OPC UA provides standardized, secure access to equipment data. ISO 22400 needs trustworthy event and state data (start/stop, speed, counts, states) to compute KPIs. OPC UA can expose this in a structured way, sometimes with companion specs.
- Typical use: Use OPC UA to collect machine signals and state transitions, then apply ISO 22400 state models and KPI formulas in the MES, historian, or analytics layer.
- Constraints: Many brownfield assets lack native OPC UA; you may need gateways, which introduce cost, security considerations, and validation overhead. Semantics still need to be aligned to ISO 22400 and ISA-95 manually.
- B2MML (Business To Manufacturing Markup Language)
- Why it pairs well: B2MML is an XML implementation of ISA-95 models. It is useful when you need more formal, standards-based data exchange between ERP, MES, and planning tools, and want ISO 22400 KPIs to be traceable to those models.
- Typical use: Use B2MML schemas for order, production schedule, and material messages; align ISO 22400 KPI dimensions (e.g., by product, order, equipment) with the same identifiers used in B2MML.
- Constraints: Many vendors only partially implement B2MML, or use proprietary variants. Validation teams often require clear documentation of which schema elements are used and how they relate to KPI definitions.
- AutomationML and related engineering data standards
- Why it pairs well: AutomationML can describe equipment, production resources, and topology. This can provide a single source of truth for the equipment hierarchy that ISO 22400 KPIs reference.
- Typical use: Use AutomationML to define equipment hierarchies and capabilities, then map ISO 22400 KPIs (e.g., OEE per line, cell, machine) to that same hierarchy across MES and analytics.
- Constraints: Adoption is uneven, especially in older aerospace and defense lines. Managing AutomationML as a controlled engineering artifact requires mature configuration and change management.
- ISO 9506 (MMS) and legacy OT protocols (OPC Classic, Modbus, proprietary)
- Why they matter in brownfield plants: Many existing lines expose data through legacy protocols. These are not ideal, but in long-lifecycle assets they are often the only realistic way to access the signals needed for ISO 22400 KPIs without major requalification.
- Typical use: Wrap legacy protocols behind an OPC UA gateway or custom collector, normalize tag names and states, then map them to ISO 22400 state models and ISA-95 equipment models upstream.
- Constraints: Additional conversion layers increase failure modes, latency, and cybersecurity exposure. Every mapping layer must be documented, version-controlled, and validated, especially when KPIs feed into quality or capacity decisions.
Standards and patterns at the application / API layer
Beyond OT protocols, several integration approaches can support ISO 22400 adoption between higher-level systems.
- REST / GraphQL APIs with an ISA-95–aligned data model
- Why it pairs well: Many modern MES, historians, and analytics tools expose REST APIs. If those APIs are designed around ISA-95/IEC 62264 concepts, it becomes much easier to define ISO 22400 KPIs consistently across tools.
- Constraints: Vendor APIs are rarely fully ISA-95-compliant. You usually end up with a hybrid model in an integration layer or data warehouse. This is workable but needs strong governance and documentation.
- Event streaming standards (e.g., Kafka with schema registry)
- Why it pairs well: ISO 22400 KPIs depend on time-series and event data. Event streaming can centralize these events and apply consistent KPI logic. Schema governance can align topics with ISA-95 and ISO 22400 entities.
- Constraints: Streaming platforms do not provide semantics by default. If topic and schema design are ad hoc, you simply move the inconsistency problem to a different layer. Regulated environments also need controls around schema changes and replay behavior.
- OPAF / RAMI 4.0 reference architectures (where adopted)
- Why they matter: Reference architectures can help position where ISO 22400 KPIs live (edge vs. plant vs. enterprise) and which integration standards apply at each layer.
- Constraints: Adoption in aerospace and other heavily regulated sectors is still emerging. Do not expect out-of-the-box vendor alignment.
Tradeoffs and failure modes in regulated, brownfield environments
Choosing “what pairs well” with ISO 22400 is less about a perfect combination of standards and more about what is realistic to deploy and validate on your existing stack.
- Full replacement vs. coexistence: Attempting to replace legacy MES/SCADA solely to get cleaner KPI integration frequently fails in aerospace-grade environments. The qualification burden, validation cost, downtime risk, and integration complexity usually outweigh the KPI benefits. Layered, coexisting solutions are more common.
- Semantic alignment is the hard part: Most plants can move data, but aligning equipment models, order identifiers, product definitions, and state models to ISO 22400 is the larger effort. This is where ISA-95, B2MML, and controlled reference data are critical.
- Validation and change control: When ISO 22400 KPIs affect released capacity, release-to-production decisions, or quality thresholds, the calculation logic and integration mappings become subject to validation and change control. Standards help, but they do not remove that burden.
- Long equipment lifecycles: You are often constrained to what legacy controllers and gateways can practically expose. In many cases, the optimal pattern is to standardize semantics and KPI logic in an intermediate layer (MES, data hub, or historian) rather than forcing every asset to be “fully standard.”
Practical pairing patterns
In real programs, the following combinations are common and maintainable:
- ERP–MES–shop floor: ISA-95 / IEC 62264 models, partial B2MML for key flows, OPC UA or gateways for OT, ISO 22400 KPI logic in MES or analytics.
- MES overlay on legacy lines: Legacy protocols into collectors, normalized to an ISA-95-like equipment model in an integration layer, KPIs defined per ISO 22400 in a central KPI engine or data warehouse.
- New line or greenfield cell inside brownfield plant: OPC UA-native equipment, ISA-95-aligned MES, ISO 22400 KPIs implemented at the line and exposed upstream via APIs; slow, controlled replication of successful patterns to other cells.
Across all these, the integration standards that pair best with ISO 22400 are the ones that give you stable identifiers, clear ownership of data, and consistent semantics for the entities your KPIs reference, without forcing disruptive system replacements that are difficult to validate and sustain.
