How does ISO 22400 relate to the ISA-95 and IEC 62264 hierarchy levels?

ISO 22400, ISA-95, and IEC 62264 are complementary, but they address different layers of the same problem:

• ISA-95 / IEC 62264: Define the functional model, data flows, and hierarchy levels (often described as Levels 0–4) for integrating enterprise and control systems.
• ISO 22400: Defines manufacturing KPIs, their terminology, and calculation methods for performance management (for example OEE, availability, performance, quality rate, and many others).

In practice, ISA-95 / IEC 62264 tell you where data and functions live and how systems should interact, while ISO 22400 tells you how to compute and interpret KPIs using that data.

How the hierarchy levels map to ISO 22400 KPIs

The well-known ISA-95 / IEC 62264 hierarchy (Levels 0–4) can be viewed as the “source” and “consumer” structure for ISO 22400 KPI data:

• Levels 0–2 (process, sensing, control)
  These levels generate the raw events and signals used by ISO 22400 KPIs:
  • Machine states (run, idle, down, setup, blocked, starved).
  • Counts (good parts, scrap, rework, cycles).
  • Process values (speed, temperature, pressure, cycle time).

  In an ISO 22400 view, this is the “fact” layer that feeds most time and quantity measures. Problems arise when control systems or historians do not provide clean, classified states or when event timestamps are inconsistent across assets.

• Level 3 (manufacturing operations / MES layer)
  This layer is usually where ISO 22400 KPIs are calculated and contextualized:
  • Assignment of events to orders, equipment, products, shifts, and operators.
  • Application of ISO 22400 definitions (planned vs unplanned downtime, operating time, net operating time).
  • Aggregation by line, cell, work center, area, or plant.

  Here ISA-95/IEC 62264 define what “operations” mean and where MES functions sit; ISO 22400 defines how to compute the KPIs for those operations. If the MES is weak, highly customized, or absent in a brownfield plant, you may need intermediate data layers or historian logic to approximate Level 3 behavior.

• Level 4 (business planning / ERP)
  At this level, ISO 22400 KPIs are typically consumed and sometimes further aggregated:
  • Plant- or network-level OEE, throughput, on-time delivery, and capacity utilization.
  • Linkage of ISO 22400 KPIs to cost, inventory, and service-level metrics.

  ISA-95 / IEC 62264 define how Level 4 systems exchange information with Level 3 (for example, work orders, production schedules, material movements). ISO 22400 provides a common language for the performance indicators surfaced into ERP, BI, and corporate dashboards.

Complementary roles and where they intersect

Viewed together:

• ISA-95 / IEC 62264 focus on system boundaries, responsibilities, and information flows between levels.
• ISO 22400 focuses on what to measure, how to calculate it, and how to structure KPI hierarchies.

Key intersections in real deployments include:

• Event definitions & state models: ISA-95-based equipment and operations models are often used to define the state categories and events that ISO 22400 KPIs depend on. If machine states are not standardized across lines or vendors, applying ISO 22400 consistently is difficult.
• Data ownership by level: ISA-95 / IEC 62264 suggest which level “owns” each kind of data (for example, schedule vs actual execution). ISO 22400 KPIs then specify how to combine these data sources without double-counting or mixing planned and actuals incorrectly.
• Aggregation logic: ISO 22400 distinguishes between base metrics (raw measures) and derived KPIs. ISA-95 / IEC 62264 models help you decide at which level to compute each step (edge device, line, area, site) and where the “system of record” should sit for each metric.

No 1:1 mapping: implementation details matter

There is no strict 1:1 mapping in the standards that says, for example, “OEE = Level 3 KPI” or “Availability = Level 2.” In practice:

• Some KPIs can be reliably computed at the line or cell (Level 2/3 boundary) if the PLCs and historians are mature and well integrated.
• Other KPIs require order, product, or quality context that only exists at Level 3 or in the MES/QMS integration.
• Corporate or multi-site KPIs are often computed in a data warehouse or analytics layer sitting logically above Level 4, using ISO 22400 as the harmonization framework.

How you apply ISO 22400 across the ISA-95 / IEC 62264 hierarchy will depend heavily on:

• The actual responsibilities of your ERP, MES, historians, and SCADA (which often diverge from the textbook ISA-95 model).
• The quality of timestamps, state models, and event definitions in your control systems.
• Your integration strategy (point-to-point vs message bus vs data lake), especially in brownfield environments with multiple MES or partial implementations.
• The level of validation and change control required, which may constrain where you can change KPI definitions or logic.

Regulated, brownfield reality and typical pitfalls

In regulated, long-lifecycle environments, integrating ISO 22400 with an ISA-95 / IEC 62264 architecture is rarely greenfield and rarely clean:

• Multiple MES/SCADA vendors: Different lines or plants may implement ISA-95 concepts differently. Applying ISO 22400 consistently requires explicit mapping layers and careful master data harmonization.
• Legacy or customized MES: Older systems may not align neatly to ISA-95 Level 3 functions, or may mix Level 2 and Level 3 logic. Retrofitting ISO 22400 KPIs can require intermediate data models or a separate performance layer to avoid revalidating core MES behavior.
• Validation burden: In aerospace and other regulated sectors, changing KPI logic in a validated Level 3 system can be costly. Many plants instead compute ISO 22400-style KPIs in a read-only analytics tier, using data extracted from ISA-95-aligned systems without altering their validated workflows.
• Downtime and integration risk: Full replacement of MES or control layers just to achieve clean ISO 22400 KPIs is usually not viable due to downtime, requalification, and integration risks. Incremental mapping and augmentation of existing systems is more common.

Practical way to connect them in your architecture

A pragmatic approach for most brownfield plants is:

1. Use ISA-95 / IEC 62264 as the reference for “who owns what”: Clarify which systems represent Level 2, Level 3, and Level 4 in your actual landscape, even if imperfect.
2. Inventory available measures by level: List what time-series, event, and transactional data you have at each level, and how trustworthy it is for KPI purposes (missing data, clock drift, inconsistent states).
3. Map ISO 22400 KPIs to specific data sources: For each KPI, define exactly which level and system provides the base measures (for example, machine state from SCADA, order context from MES, cost from ERP).
4. Define a “KPI system of record”: Decide where the ISO 22400 logic will live (MES, analytics platform, or data warehouse), balancing validation overhead, traceability, and maintainability.
5. Document and control changes: Treat the KPI catalog and mappings as controlled configuration. Changes to definitions or aggregations should follow your change control, particularly where KPIs are referenced in quality, regulatory, or customer reporting.

Used this way, ISO 22400 does not replace ISA-95 / IEC 62264. It sits on top of the hierarchy and information models they define, providing standardized performance indicators while respecting existing system boundaries, validation constraints, and long equipment lifecycles.