ISO 22400 influences your MES and historian schemas mainly by shaping how you define, classify, and relate production events, states, time losses, and KPI inputs. It is best treated as a semantic reference model for manufacturing KPIs, not as a mandatory physical database design.
In practice, that means your schema should be able to support consistent definitions for things like equipment status, planned versus unplanned time, job or order context, material context, quality outcomes, and the timestamps needed to calculate performance metrics reproducibly. If your current MES or historian cannot represent those concepts cleanly, ISO 22400 will expose the gap.
What it usually changes
-
State and event modeling: You typically need clearer machine and line state codes, with governed mappings from PLC, SCADA, MES, or manual inputs into normalized status categories.
-
Time model structure: KPI calculations depend on consistent treatment of planned production time, downtime, idle time, interruptions, and changeovers. Many legacy historians capture raw tags but not the business meaning needed for comparable KPI rollups.
-
Context keys: Historian records become more useful when linked to work order, operation, part, serial or lot, resource, and revision context from MES or ERP. Without that linkage, ISO 22400 style KPIs may be mathematically possible but operationally weak.
-
Calculation provenance: You need traceable formulas, versioned mappings, and auditable assumptions for KPI derivation. In regulated aerospace environments, undocumented KPI logic is usually a governance problem even if the math is simple.
-
Master data alignment: Resource hierarchies, operation definitions, unit conventions, and reason codes often need cleanup before KPI standardization works across cells or plants.
What it usually does not mean
It usually does not mean redesigning your MES schema from scratch or forcing your historian into a fully ISO-shaped schema. That is often unnecessary and risky in brownfield aerospace environments.
Most plants already have mixed vendor systems, qualified interfaces, legacy tag structures, custom reason codes, and long-lived assets. Replacing or heavily restructuring those systems can trigger validation effort, reporting disruption, interface breakage, and change control overhead that outweigh the benefit.
A more realistic pattern is to keep existing schemas where they are stable, then add a governed semantic layer, mapping layer, or canonical KPI model above them. That allows you to normalize definitions without forcing wholesale replacement of MES, historian, ERP, PLM, or QMS structures.
MES versus historian impact
MES is usually where operational context, workflow state, genealogy links, labor transactions, and quality dispositions are managed. ISO 22400 pressure on MES tends to show up as better event capture, more disciplined status models, and more consistent production transaction semantics.
Historians usually store high-frequency time series and equipment signals. ISO 22400 pressure on historian design is more about ensuring the data can be mapped to governed states and time buckets, not about turning the historian into a full manufacturing context system. If your historian lacks reliable event boundaries or asset hierarchy discipline, KPI quality will be limited.
In short, the MES often owns business context, while the historian provides machine-time evidence. KPI standardization depends on both, and poor alignment between them is a common failure mode.
Key tradeoffs in aerospace manufacturing
-
Standardization versus local reality: A single enterprise KPI model improves comparability, but local cells and programs often have real process differences. Over-normalizing can hide important operational distinctions.
-
Granularity versus maintainability: Rich event models improve analysis, but they increase integration, data stewardship, and validation burden.
-
Historian purity versus MES enrichment: Calculating everything from raw historian tags may look objective, but without MES context the metrics may be incomplete or misleading.
-
Consistency versus retrofit cost: Mapping old reason codes and state models into a standard framework is usually cheaper than schema replacement, but it introduces translation logic that must be governed carefully.
Common failure modes
-
Assuming ISO 22400 provides a plug-and-play schema. It does not.
-
Trying to compute standardized KPIs from historian tags alone, without trusted order, operation, and quality context.
-
Leaving state mappings uncontrolled, so different lines report the same KPI with different underlying logic.
-
Ignoring revisioning of formulas, mappings, and reason-code taxonomies.
-
Launching enterprise dashboards before data readiness, time synchronization, and source reconciliation are mature enough.
Practical approach
-
Define the KPI semantics and calculation rules you actually need.
-
Map required inputs to current MES, historian, SCADA, and ERP sources.
-
Identify schema gaps in event capture, context keys, and status normalization.
-
Introduce a governed canonical model or semantic layer before considering major schema replacement.
-
Version-control mappings, formulas, and code lists under change control.
-
Validate KPI outputs against known production scenarios before broad rollout.
So the answer is yes: ISO 22400 should influence your MES and historian data schemas. But in aerospace manufacturing, it should usually influence them through governed semantics, mappings, and traceable calculation structures rather than through wholesale redesign. Whether that works depends heavily on your current data quality, asset model consistency, integration maturity, and ability to manage controlled change across legacy systems.