In regulated manufacturing, a concrete example of data interoperability is when production data created on one system can be consumed and trusted by other systems without manual rekeying, reformatting, or ad hoc interpretation.
Example: Test stand to MES, ERP, and QMS
Consider a calibrated test stand running on a vendor-specific controller in a brownfield plant. A single unit moves through this station and generates test data:
- The test stand records parameter values, limits, and pass/fail results, along with the serialized unit ID and equipment ID.
- Through a standardized interface (for example, OPC UA or a validated REST API), these results are pushed to the MES in a well-defined data structure that all parties have agreed on.
- The MES automatically attaches the results to the correct work order, operation, and serialized unit, using shared identifiers and data types that match the ERP and QMS.
- When a test fails, the MES creates a nonconformance record that the QMS can consume directly, including the same unit ID, lot/batch number, test limits, and timestamps.
- The ERP can then use the same data for WIP status and capacity reporting, without rebuilding logic to interpret the test stand’s native formats.
In this example, each system is using data generated elsewhere without:
- Manual copy/paste or CSV uploads.
- Custom, one-off scripts that reinterpret fields differently in each system.
- Loss of traceability from equipment and operator to unit, lot, and work order.
Data interoperability here means the test results preserve their meaning and structure as they move across equipment, MES, ERP, and QMS, so that quality, operations, and finance are all looking at the same underlying facts.
What this depends on in real plants
Whether this works reliably in your environment depends on:
- Common identifiers and data model: Shared definitions for unit IDs, lot numbers, operation codes, and test parameter names across systems, not just point-to-point mappings.
- Interface standards and protocols: Use of agreed protocols (for example, OPC UA, ISA-95 style models, structured APIs) instead of undocumented vendor-specific formats.
- Validation and change control: In regulated settings, integration logic, transformations, and mappings must be specified, tested, and controlled as they change over time.
- Integration quality: Robust error handling, retries, and monitoring so data loss, duplication, or silent failures are detectable and can be investigated.
- Data governance: Clear ownership of master data, naming conventions, and versioning, so systems stay aligned as processes and products evolve.
Brownfield realities and coexistence
In most regulated, long-lifecycle plants, data interoperability is achieved incrementally between existing systems rather than by replacing everything with a single new platform. Typical patterns include:
- Wrapping legacy equipment with a gateway that exposes standardized data while leaving the validated controller and code in place.
- Adding an integration layer between MES, ERP, and QMS that translates to a shared canonical model instead of building custom point-to-point mappings for each pair.
- Using a common serialization and genealogy scheme across new integrations, while leaving older systems in place until they can be retired without unacceptable downtime or requalification effort.
Full replacement of MES, ERP, or QMS to “solve interoperability” is rarely practical in aerospace-grade and similar environments because of validation cost, audit impact, downtime risk, integration complexity, and the need to preserve historical data and traceability. Most plants instead focus on carefully scoped, validated integrations that improve interoperability where it delivers clear operational and quality value.