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.