No. You do not need to upgrade every system just to “support ISO 22400.” ISO 22400 defines manufacturing operations KPIs and terminology, not a mandatory software feature set or certification scheme. In most regulated, brownfield environments, you align data and reporting to ISO 22400 across your existing stack, and only change or upgrade systems where it is necessary and justified.
What ISO 22400 actually requires
ISO 22400 focuses on:
- Common definitions for KPIs such as OEE, availability, performance, and quality
- Standardized naming for states, quantities, and time categories
- Conceptual models of how metrics should be derived from production data
It does not require that each MES, historian, PLC, or ERP module be “ISO 22400 certified” or upgraded to a specific version. Compliance is mainly about how you define, calculate, document, and use metrics.
Typical brownfield approach
In a mixed-vendor, long-lived environment, the practical path is usually:
- Define your target ISO 22400 model
Document exactly how your organization will interpret the ISO 22400 KPIs, time categories, and states. This should be under change control and traceable.
- Map existing data sources to the model
Identify where needed data currently resides (PLCs, SCADA, MES, historian, manual logs, ERP). Create a mapping showing how each source contributes to each metric and what translation is required.
- Standardize calculations in one or a few layers
Instead of upgrading every system, centralize calculations where feasible: in MES, a data warehouse, or an analytics layer. Legacy systems can continue to produce their native tags and states, which are translated to ISO 22400 semantics downstream.
- Use adapters and integration, not wholesale replacement
For older equipment or software that cannot be changed easily, use integration logic or middleware to normalize signals, event codes, and time categories into the ISO 22400 model.
- Adjust or upgrade selectively
Only upgrade or reconfigure systems that are:
- Producing ambiguous or conflicting definitions that cannot be mapped cleanly
- Missing critical data required for key KPIs
- So fragile that adding mapping logic elsewhere creates unacceptable risk
When system upgrades are actually justified
Upgrades or replacements become necessary when:
- Data granularity is insufficient: For example, PLCs or SCADA only log binary “run/stop” events, but you need distinct reason codes and time categories for planned/unplanned stops, minor stops, changeovers, etc.
- Time stamping and sequence accuracy are too poor: If the clocks, sampling rates, or buffering behavior make precise allocation of time losses impossible, some layer may need modernization.
- Legacy systems are closed: If a critical system cannot expose its data at all, or only via manual exports, you may eventually need an upgrade or sidecar solution to support reliable, validated metrics.
- Validation and change control are unmanageable: If workarounds and mappings become more complex than a controlled system upgrade, a targeted upgrade can actually reduce long-term compliance risk.
Even in these cases, changes should be targeted, planned with minimal downtime, and justified by a clear link to metrics quality, regulatory expectations, or business impact. Full platform replacement purely for ISO 22400 alignment is rarely warranted in aerospace-grade or similar environments because of qualification burden, revalidation cost, and integration risk.
Key constraints in regulated, long-lifecycle plants
In regulated industries, “upgrade everything” is usually not viable because:
- Validation and qualification: Each change to MES, SCADA, data models, or calculations can trigger revalidation, documentation updates, and potential re-training.
- Traceability of metric definitions: You must be able to show how KPIs are defined, where each input comes from, and how changes were governed. This often favors leaving legacy systems stable and documenting mappings rather than changing every component.
- Downtime and integration risk: Replacing multiple systems at once significantly increases the probability of prolonged downtime and integration defects that can corrupt or misalign metrics data.
- Lifecycle and supplier constraints: Many control systems and equipment controllers have 10–20+ year lifecycles. Forcing upgrades purely for metric semantics can conflict with OEM support strategies or internal engineering bandwidth.
Practical implementation pattern
A pragmatic ISO 22400 implementation usually looks like this:
- Establish a single, controlled specification for how ISO 22400 KPIs are calculated at your site or across sites.
- Implement standardized calculations in a limited set of systems (for example, MES and an analytics/data platform).
- Use integration, mapping, and business rules to translate legacy states, codes, and tags into the ISO 22400 model.
- Upgrade or reconfigure individual systems only where mapping is not technically or operationally credible.
- Maintain documentation and audit trails so that metric changes are visible and explainable during audits and investigations.
In summary, ISO 22400 adoption is mostly a data, semantics, and governance problem, not a universal software upgrade mandate. The goal is consistent, traceable metrics across your brownfield environment, achieved through selective changes, controlled mappings, and careful validation.
