Building ISO 22400-Aligned Data Models for Connected Manufacturing

For aerospace and defense manufacturers, ISO 22400 is most powerful when it is implemented in the data model, not just referenced in a specification. The standard defines how manufacturing KPIs should be structured conceptually, but engineering teams still must decide how to represent those concepts in databases, event streams, and integrations across ERP, MES, SCADA, historians, PLM, and QMS. When this is done well, a multi-plant aerospace operation can compare KPIs with confidence, and a platform such as Connect 981 can present standardized manufacturing KPI views without forcing a single vendor stack.

This article explains how ISO 22400 influences data modeling and system integration across typical aerospace digital infrastructure. It focuses on representing equipment states, orders, and time categories in a coherent KPI layer, while remaining vendor- and technology-agnostic. The goal is to give architects and data engineers a clear blueprint for aligning heterogeneous systems with ISO 22400 semantics.

Why ISO 22400 Needs a Thoughtful Data Model

From conceptual definitions to database structures

ISO 22400 is intentionally conceptual. It defines KPIs, time categories, and objects such as work units and production orders, but it does not dictate how these elements should be stored in tables, topics, or data lakes. In an aerospace environment, however, KPIs must be auditable, traceable to underlying events, and reproducible across program lifecycles. That requires explicit data modeling decisions.

At minimum, an ISO 22400-aware model needs to capture three layers:

• Raw signals and events from equipment, test stands, and assembly stations (e.g., PLC tags, NC program events, manual inspection start/stop).
• Derived states and time segments, where each contiguous period is labeled with an ISO 22400-relevant state such as RUN, STOP, IDLE, or SLOW.
• Aggregated indicators and KPIs that combine time segments and quantities into ISO 22400-defined concepts such as availability or equipment utilization.

These layers can live in different systems: SCADA for signals, MES for high-level events, a historian for dense time-series data, and a cloud data platform for aggregation. The data model is the glue that ensures a KPI such as “availability” has the same meaning no matter where it is queried.

Ensuring consistency across heterogeneous systems

Aerospace production and MRO facilities frequently operate with a heterogeneous stack: a legacy MES on the shop floor, a modern PLM system defining configurations, ERP managing orders, plus multiple historians and test data repositories. Without a shared semantic model, every integration becomes a custom mapping exercise, and KPI definitions drift over time.

ISO 22400 provides a reference vocabulary, but the implementation must resolve several practical questions:

• How do we map proprietary equipment states from different machine vendors to a common RUN/STOP/IDLE/SLOW model?
• How do we consistently connect production orders from ERP to work centers and work units in MES and SCADA?
• How do we represent planned vs. unplanned downtime in a way that supports audit-friendly reporting in AS9100 environments?

The answer is a shared, ISO 22400-aligned data model—often implemented as a semantic layer or KPI store—that sits above plant-specific systems. Connect 981 and similar platforms can then consume this layer to power cross-site aerospace KPI reporting, while respecting the constraints of each site’s local systems.

Representing Equipment States and Time Categories

Capturing RUN, STOP, IDLE, SLOW in event data

ISO 22400 treats equipment states as the foundation for many equipment-related KPIs. For aerospace machining centers, autoclaves, composite layup machines, test cells, and assembly stations, these states are typically derived from a combination of:

• Control system tags (e.g., cycle active, alarm active, manual mode).
• Operator input (e.g., downtime reason codes captured at the MES terminal).
• Schedule context (e.g., whether the current time is within planned production time for that resource).

A robust event model represents state transitions explicitly. A common pattern is an equipment_state_event structure with fields such as:

• equipment_id (work unit identifier, aligned with IEC 62264 levels).
• state_code (normalized to RUN, STOP, IDLE, SLOW, or other ISO 22400-related states).
• reason_code (plant-specific detail, e.g., TOOL_CHANGE, PROGRAM_LOAD, QUALITY_HOLD).
• start_time and end_time (or start time plus duration).
• source_system (SCADA, MES, manual entry, etc.).

The raw machine or SCADA events can be noisy, with rapid transitions and transient conditions. A normalization pipeline should consolidate these into clean, non-overlapping time segments associated with a single state. This is where an ISO 22400 mapping table is valuable: it expresses how vendor-specific signals map to a standard state_code.

Aggregating state data into indicator-friendly structures

Once states are modeled as time segments, KPI-oriented aggregation becomes straightforward. ISO 22400 relies heavily on time categories—such as operating time, busy time, planned downtime, and unplanned downtime—that are built from these state segments.

For aerospace plants, a daily or shift-level equipment_time_summary structure is useful. It can include:

• equipment_id and time_bucket (e.g., day, shift, or custom period).
• Durations by normalized state (RUN, STOP, IDLE, SLOW).
• Durations by downtime category (planned vs. unplanned, safety-related, quality-related, maintenance).
• Flags for special conditions (e.g., new program introduction, first article inspection periods).

These summaries serve two purposes. First, they support ISO 22400-aligned KPIs such as utilization and availability. Second, they provide traceability: when a program-level performance review questions an equipment KPI, engineers can drill back from a KPI to a time summary and then to the underlying state events and SCADA signals.

Modeling Orders, Lots, and Production Events

Linking production orders to equipment and time

In aerospace manufacturing, performance is often evaluated by program, configuration, or serialized asset rather than only by equipment. ISO 22400 addresses this by defining objects like production orders and lots that can be associated with work units and time periods. To align with this, the data model should represent the relationship among:

• ERP orders (e.g., production orders, shop orders, repair orders).
• MES operations (routing steps, work instructions, NC programs).
• Work units and work centers (machines, cells, bays, test stands).

A typical pattern uses a production_operation_execution entity with:

• order_id and operation_id (from ERP/MES).
• equipment_id and optionally work_center_id.
• start_time, end_time, and scheduled_time.
• good_quantity, rework_quantity, scrap_quantity, with units.
• configuration_id or effectivity link for configuration-controlled parts.

This entity provides the bridge between time-based equipment behavior and order-level KPIs. It allows ISO 22400 concepts such as production time structure and order execution reliability to be computed consistently, even when the underlying orders originate from multiple ERP instances or legacy planning tools.

Handling batch, continuous, and discrete processes

Aerospace workflows span multiple process types: discrete assembly of airframe structures, batch processes in special processing and coatings, and quasi-continuous operation in test facilities. ISO 22400 is designed to cover batch, continuous, and discrete industries; the data model should therefore avoid assuming a single process type.

Practical strategies include:

• Using a common lot_or_batch_id attribute to represent material groupings, whether they are heat lots, composite layup kits, or engine modules.
• Capturing start/stop events for material independently from equipment state events, so that KPIs can distinguish equipment availability from material availability.
• Allowing overlapping operations on the same order (e.g., parallel test cycles, multiple stations working on different sections of the same fuselage).

This flexibility ensures that ISO 22400 KPIs retain their meaning across the breadth of aerospace operations—from precision machining to environmental testing—without requiring separate definitions per process family.

Integrating ERP, MES, SCADA, and Historians

Common integration patterns and interfaces

ISO 22400 does not prescribe any transport protocols or message formats, but certain integration patterns appear repeatedly in aerospace digital environments:

• Order and master data from ERP to MES, where order hierarchies, routings, and work centers are synchronized, providing the structural context for ISO 22400 KPIs.
• Event and state data from SCADA and equipment controllers into a historian or event hub, which is then normalized to ISO 22400-like states for KPI computation.
• Quality results from QMS and inspection systems feeding into the same semantic layer so that scrap, rework, and nonconformance time are consistently categorized.

Interfaces may be implemented via OPC UA, file-based transfers, REST APIs, or message queues, but the key is that each system provides sufficient identifiers to be bound to the ISO 22400 objects in the semantic model (equipment IDs, order IDs, lot IDs, time stamps, and reason codes).

Using ISO 22400 as a semantic layer for data exchange

Instead of directly wiring every system to every other system, many aerospace organizations adopt a semantic layer that mediates integrations. ISO 22400 concepts become the vocabulary of that layer. For example:

• Rather than sending raw tag names, SCADA publishes normalized equipment_state_event messages with ISO 22400-style state codes.
• MES publishes operation_execution events using consistent order and equipment identifiers that match the semantic model.
• QMS publishes quality_event messages that refer to the same operations and lots, allowing scrap-related time to be tied to downtime and performance KPIs.

Platforms like Connect 981 can then subscribe to these normalized feeds and provide cross-plant KPI dashboards and analytics without having to interpret plant-specific codes each time. This approach is especially valuable when working with a distributed aerospace supply base, where primary OEM sites and tiered suppliers need to exchange KPI information in a comparable way.

Designing an ISO 22400-Aligned KPI Store or Data Lake

Schema considerations for KPI queries

An ISO 22400-aware KPI store or data lake is typically organized around a small set of core dimensions and fact-like structures. For aerospace manufacturing, those dimension tables often include:

• Equipment and work units, including mappings to physical assets, locations, and responsibility centers.
• Orders and operations, aligned with ERP and MES, with attributes such as program, platform, and customer contract.
• Time, including calendar, shifts, and production calendars with holidays and planned shutdowns.
• Material and configurations, tying KPIs back to part numbers, revisions, and configuration baselines.

The fact structures then contain normalized event-level and aggregated data:

• fact_equipment_state for state segments.
• fact_operation_execution for order-related production events.
• fact_quality_outcome for inspection and test results.
• fact_kpi_snapshot for pre-computed ISO 22400 KPI values by period and level (equipment, line, plant, program).

By keeping the schema technology-agnostic (star schema, wide tables, or lakehouse-style parquet datasets), organizations retain freedom in their storage and query engines while still honoring the ISO 22400 semantic structure.

Managing metadata, units, and logical ranges

ISO 22400 emphasizes metadata such as units of measure, applicable logical ranges, and expected trend directions. Aerospace programs often require this information for documentation, internal standards, and customer reporting. In the KPI store, this suggests explicit metadata structures:

• A kpi_definition table that lists each KPI, its ISO 22400 reference, unit, typical consumers (operator, supervisor, management), and whether higher values are considered good or bad.
• Optional kpi_threshold or kpi_target tables that capture plant- or program-specific goals without conflating them with the standardized KPI definition.
• Unit conversion logic that aligns energy, throughput, and time units across sites (e.g., standardizing on hours even if some systems report minutes or seconds).

This metadata makes it easier to build dashboards, automated checks, and alerts in aerospace environments where KPI interpretation must be consistent across programs and subject to audit or regulatory review. It also prevents accidental redefinition of KPIs when sites introduce new visualization tools or reports.

Examples of ISO 22400-Ready Data Pipelines

Event ingestion and transformation flows

Consider a composite manufacturing cell producing critical flight structures. SCADA systems capture autoclave cycle data and layup station states; MES manages work instructions and order status; ERP owns the overall production order and schedule. An ISO 22400-ready pipeline might look like this:

1. Ingest raw events from SCADA (cycle start/stop, alarm events), MES (operation start/complete), and QMS (nonconformance creation) into a central event hub or streaming platform.
2. Normalize equipment states by applying mapping rules to SCADA tags to derive RUN/STOP/IDLE/SLOW segments with clean start/end times.
3. Enrich events with order and configuration context by joining to ERP and PLM data, ensuring each event is associated with the correct order, configuration, and program.
4. Compute time categories and indicators such as operating time, planned downtime, and unplanned downtime at shift and daily levels.
5. Persist aggregates and KPIs in the KPI store, including availability, utilization, and order-related indicators as defined by ISO 22400.

The result is an auditable pipeline from raw sensor data to standardized KPIs, suitable for cross-plant comparison and customer-facing performance reports when needed.

Feeding dashboards and analytics tools consistently

On the consumption side, aerospace organizations may use a mix of tools: in-house portals, commercial BI platforms, engineering analytics notebooks, and specialized dashboards for program reviews. By exposing KPIs through a common ISO 2240-aligned semantic layer, these tools all draw from the same source of truth.

Key practices include:

• Providing a stable, documented API or SQL interface for KPI access, with KPIs described in terms of ISO 22400 concepts rather than tool-specific naming conventions.
• Ensuring that drill-down paths from KPI to underlying events are preserved, supporting root-cause analysis of availability or performance issues in high-value assets such as engine test cells or structural assembly jigs.
• Allowing program-specific slices (e.g., by platform or customer) without redefining the KPIs themselves, only the filters applied.

In this model, Connect 981 or a similar digital manufacturing platform can coordinate KPI reporting across the aerospace enterprise, while the ISO 22400-aligned data model ensures that every plant, supplier, and program interprets those KPIs the same way.

Putting ISO 22400 Data Modeling into Practice in Aerospace

ISO 22400 does not dictate how to architect your MES, historian, or data lake. It does, however, define a shared language of states, time categories, orders, and KPIs that can guide architecture decisions. In regulated aerospace environments, where traceability, configuration control, and cross-site comparability matter, implementing that language in the data model provides tangible benefits.

By representing equipment states as normalized events, linking orders and operations across ERP and MES, and consolidating heterogeneous system data into an ISO 22400-aligned KPI store, aerospace manufacturers can achieve consistent, audit-ready performance reporting. Platforms like Connect 981 can then leverage this foundation to support digital thread initiatives, supplier visibility, and standards-aligned KPI frameworks without forcing a single technology stack. The standard provides the semantics; the data model turns those semantics into operational reality.

ISO 22400 changes how manufacturing organizations think about KPIs without forcing them to throw away everything they already have. For aerospace, defense, and space hardware producers operating in AS9100-regulated environments, the standard offers a common language for performance indicators across plants, suppliers, and digital systems. The main shift is moving from locally defined KPIs to a shared conceptual framework grounded in ISO 22400 while preserving the domain-specific metrics that matter for complex aerospace programs.

On platforms such as Connect 981, ISO 22400 concepts underpin cross-plant performance reporting, helping align MES, ERP, QMS, PLM, and supplier portals. The ISO 22400 manufacturing KPI standard becomes the backbone for consistent definitions, while existing KPI practices are mapped, reconciled, and gradually harmonized.

How Manufacturers Historically Built KPI Sets

Plant-specific metrics and naming conventions

Before ISO 22400, most aerospace factories built KPI landscapes organically. Each site or program team defined its own dashboards for throughput, scrap, rework, and equipment utilization. Naming and structure grew out of local practices, legacy MES configurations, or what specific leaders wanted to see. A fuselage assembly line might track “uptime,” an avionics cell might track “available hours,” and an MRO shop might track “bay occupancy,” all describing similar underlying concepts using different terms.

These local KPI sets often reflected genuine operational needs: qualification test labs needed different indicators than composite layup cells or precision machining centers. Over time, however, mergers, global sourcing, and outsourced work packages created networks of plants and suppliers where each node spoke a different KPI dialect. Enterprise teams stitched together Excel aggregations, translation tables, and custom reports to compare sites, but the meaning behind the numbers was not always clear.

Common issues with non-standard KPIs

Non-standard KPI landscapes create several recurring problems in aerospace manufacturing and MRO operations:

• Poor comparability across sites and suppliers: Two facilities may both report “availability,” yet one excludes planned maintenance while the other includes it. Consolidated dashboards hide apples-to-oranges comparisons.
• Ambiguous performance narratives: When a program review shows a drop in “efficiency” at a tier-1 supplier, engineering and procurement teams must first clarify how the metric is defined before deciding what to do.
• Integration friction: When integrating new MES, OEE, or analytics tools, IT and operations teams spend significant effort mapping bespoke KPI definitions instead of focusing on data quality and process insights.
• Audit and compliance risk: In AS9100 environments, inconsistent meaning across sites complicates evidence trails. When quality metrics support risk-based thinking and supplier approval, auditors expect clarity on what is measured and how.

These issues do not mean traditional KPI frameworks are wrong; they simply lack a shared reference model. ISO 22400 was created to provide that reference, especially in multi-site and multi-supplier manufacturing ecosystems.

What ISO 22400 Adds to Traditional KPI Practices

Standardized terminology and structures

ISO 22400 defines how manufacturing KPIs should be conceptualized, named, and structured. Instead of each site deciding what “utilization” means, the standard specifies the concept, its attributes, and its relationship to underlying time and quantity elements. For aerospace manufacturers, this makes it possible to compare similar assembly lines, test stations, or repair bays even when they run different products and operate under different regulatory regimes.

The standard distinguishes between performance indicators in general and key performance indicators (KPIs) as the subset considered critical for operations and decision-making. It gives precise definitions for concepts such as availability, utilization, work unit, state, and production order, so that an indicator like “equipment utilization” has a uniform meaning regardless of whether the data originates from a machining center, an autoclave, or an avionics test bench.

Alignment with integration standards like IEC 62264

ISO 22400 aligns with IEC 62264, which describes the hierarchy of enterprise and control system levels. Most ISO 22400 KPIs live at the manufacturing operations management (MOM) layer—Level 3—bridging between enterprise planning (Level 4) and basic control systems (Levels 0–2). For aerospace and defense, this is the level where MES, QMS, and planning systems converge to manage work orders, inspection results, and resource usage.

By using the same hierarchy and concepts, ISO 22400 helps ensure that KPIs can be exchanged consistently between ERP, MES, PLM, and specialized systems like NDT reporting tools. A digital manufacturing platform can treat KPIs as standardized objects linked to orders, resources, and time periods, rather than as isolated dashboard labels. This is particularly valuable when deploying a common KPI model across multiple certified sites or onboarding suppliers into a shared reporting environment.

Comparing OEE and Equipment KPIs Before and After ISO 22400

Typical OEE implementations vs. ISO 22400 models

Overall Equipment Effectiveness (OEE) has long been used in aerospace machining, forming, and surface treatment to understand how effectively assets are used. Traditionally, plants implemented OEE according to local interpretations of availability, performance, and quality, often based on continuous improvement programs or vendor templates. One factory might include certain setup times in OEE; another might exclude them. The label was the same, but the underlying logic was not.

ISO 22400 addresses OEE at a conceptual level. It defines equipment states (such as RUN, STOP, IDLE, SLOW), time categories, and quantity-based indicators, then shows how OEE-type measures can be composed from these elements. It introduces models such as OEEA and OEEB that represent coherent ways to relate busy time, operating time, good quantities, and defect rates. The intent is not to dictate one true OEE formula, but to ensure that when a model is chosen, its components are clearly defined and consistently applied.

Reconciling local OEE with standardized definitions

Adopting ISO 22400 does not require abandoning existing OEE calculations that already support meaningful decisions. Instead, aerospace plants can map their current practices into the ISO 22400 framework:

• Identify how local OEE uses time categories such as planned downtime, changeover, maintenance, and unplanned stops.
• Express these categories in terms of ISO 22400 time and state concepts.
• Document how good quantity, scrap, and rework feed the quality component compared to the standard’s definitions.

Once this mapping exists, plants can keep their familiar OEE dashboard while exposing ISO 22400-aligned indicators in parallel for cross-site and supplier comparisons. A platform like Connect 981 can calculate both the legacy OEE view and the ISO 22400-derived equipment KPIs from the same underlying event stream, allowing gradual convergence rather than a disruptive cut-over.

Handling Custom and Industry-Specific KPIs

Where ISO 22400 intentionally stays neutral

ISO 22400 is deliberately industry neutral. It defines a catalog of 34 KPIs focused on production, maintenance, and quality, but it does not attempt to encode aerospace-specific concerns such as airworthiness-critical defect rates, concession processing times, or configuration change cycle time. The standard focuses on foundational concepts that can apply equally to a composite curing oven or a precision machining center, irrespective of sector.

This neutrality is a strength in regulated aerospace manufacturing. It keeps the standard lean and stable while leaving room for standards like AS9100 and internal engineering procedures to define domain-specific indicators. ISO 22400 clarifies how core time, quantity, and state concepts should be named and exchanged; organizations retain control over which additional KPIs they need to satisfy design assurance, traceability, and customer contract requirements.

Combining ISO 22400 KPIs with domain-specific metrics

Aerospace organizations typically operate three overlapping KPI layers:

1. ISO 22400-aligned KPIs for equipment, orders, and resources, used for cross-site comparability and integration.
2. Program and configuration-driven KPIs such as build-to-config completeness, engineering change cycle time, or deviation closure aging.
3. Regulatory and quality KPIs aligned with AS9100 and customer requirements, such as first-pass yield for safety-critical features, escape rates, or audit finding recurrence.

Rather than replacing these layers, ISO 22400 provides a consistent lower layer. For example, a metric like “nonconforming units per operating hour” in a particular work cell can be grounded in ISO 22400 time structures while still serving AS9100 risk-based thinking. A digital thread connecting engineering, production, and quality can then carry both standardized KPIs and specialized indicators, tagged so users understand which are ISO 22400-based and which are domain-specific.

Migration Strategies: Incremental vs. Big-Bang

Running old and new KPIs in parallel

Moving from traditional KPI sets to an ISO 22400-aligned model is not purely a technical exercise; it also affects how people interpret performance. For that reason, many aerospace manufacturers favor incremental migration rather than a big-bang switchover. One effective pattern is parallel reporting:

• Keep existing KPI reports intact for line supervisors and program managers.
• Introduce ISO 22400-aligned indicators alongside them, using a shared data model.
• Highlight where values diverge materially and document the definitional differences.

This dual-view period helps build trust and allows teams to refine mappings. For example, a nacelle assembly line may discover that its legacy “uptime” metric included certain planned inspections that ISO 22400 would categorize differently. Seeing both views on a single dashboard helps operations, engineering, and quality teams agree on the most appropriate interpretation for their context.

Communicating changes to management and operators

Changing KPI definitions without clear communication can undermine confidence in performance reporting. In aerospace programs, where KPIs influence customer perception and contractual commitments, definition changes must be transparent. Effective communication typically includes:

• Definition sheets that show, for each KPI, the ISO 22400 concept, formula elements, units, and example interpretations.
• Change logs explaining how a KPI’s definition differs from its previous form, and whether historical data has been restated.
• Role-specific guidance so operators, cell leaders, quality engineers, and executives understand what has changed in the signals they monitor.

On a platform level, tooltips, in-dashboard documentation, and drill-downs to time and state structures help reinforce that ISO 22400 focuses on definitional clarity and comparability. It does not, by itself, change improvement priorities or performance expectations.

Measuring the Benefits of Standardized KPI Definitions

Comparability across sites and suppliers

The most visible benefit of moving from ad-hoc KPIs to ISO 22400-aligned definitions is improved comparability. When two composite manufacturing facilities report equipment utilization or order execution reliability based on the same standard concepts, enterprise teams can analyze variation without first decoding local semantics. This is especially important in aerospace supply chains where subassemblies and major structures are produced across multiple approved sites.

Standardized definitions also support supplier development. Contracts and supplier quality requirements can reference ISO 22400 concepts for specific KPIs, reducing ambiguity about how performance will be measured. A tier-1 supplier and an OEM can each use their own MES, but still present KPIs that map to the same structures when shared through a supply chain visibility system.

Improved data quality and integration outcomes

Beyond comparability, ISO 22400 provides a reference model for data integration. When MES, QMS, and historian systems are configured around the same time categories, equipment states, and order concepts, integration efforts can focus less on translation and more on validation and enrichment. This is critical in digital thread initiatives that connect engineering changes, process parameters, and resulting KPI shifts across the product lifecycle.

For regulated environments, better structure also strengthens evidence chains. When a major nonconformance triggers a root-cause investigation, teams can reconstruct the relevant equipment states, order history, and quality indicators with confidence that terms mean the same thing across all data sources. While ISO 22400 does not guarantee good data governance, it provides a stable vocabulary that governance processes can rely on.

Summary: ISO 22400 as a Harmonizing Layer, Not a Replacement

ISO 22400 does not aim to replace existing aerospace KPI practices or dictate which metrics matter most. Instead, it introduces a harmonizing layer: standardized terminology, structures, and conceptual models for time-, quantity-, and state-based indicators. By aligning equipment and order KPIs to this framework, organizations gain clearer comparisons across plants and suppliers, smoother integration among digital systems, and stronger underpinnings for audit-ready performance reporting.

In an aerospace context, the practical path is to map legacy KPIs to ISO 22400, run both in parallel where needed, and progressively shift cross-site and supplier reporting to the standardized view. Domain-specific metrics for configuration control, traceability, and program performance remain essential; they simply sit on top of a more coherent foundation. Platforms like Connect 981 can implement this foundation as part of a broader digital manufacturing infrastructure, enabling a consistent performance language across complex, regulated production networks.