The sector challenge
A successful transfer does not necessarily preserve meaning.
Engineering, manufacturing and maintenance systems can describe the same component in different ways. An identifier, revision, unit or approval state may survive a file transfer while acquiring a different interpretation. These mismatches weaken the digital thread and can make later records difficult to trust.
The programme is developing controlled exchange methods using synthetic or explicitly authorized datasets. Semantics, configuration and provenance are considered alongside transport so that a successful message transfer also preserves the engineering meaning of the record.
Programme development priorities
- Define an exchange contract with explicit field meanings and version rules.
- Test data integrity and traceability across two independent system boundaries.
- Make rejection, correction and audit behavior part of the demonstration.
Technical scope & method
A structured approach to the question.
- 01Information model
- Define identifiers, units, mandatory fields, revision states and relationships for a bounded engineering or MRO record. Document the meaning of each field, not just its format.
- 02Interface and mapping
- Specify the API or message exchange, mapping rules, validation behavior and configuration baseline. Identify transformations that lose information or require human review.
- 03Provenance and security
- Record source, version and authorized changes. Define access controls, permitted uses and audit events for the synthetic exchange; consider relevant digital-twin and PLM information dependencies.
- 04Demonstration and testing
- Exercise valid, incomplete, inconsistent and duplicate records. Compare the receiving interpretation with the source meaning, including failure and recovery behavior.
- 01System ASynthetic manufacturing record
- 02Exchange contractSchema, mappings and access rules
- 03System BMaintenance information model
- 04Validation evidenceIntegrity, provenance and errors
Pilot development & application
A manufacturing record exchanged with a maintenance information system.
The exchange-development framework connects a manufacturing record model with a maintenance information model through a defined interface contract. Synthetic component data covers identity, configuration, a manufacturing event and a maintenance-relevant attribute. Positive and negative test cases assess mapping, integrity, rejection, retry and audit behavior.
Define the contract
Agree field definitions, identifier rules, units, configuration state and permitted operations. Establish synthetic test data and expected receiving behavior.
Exercise the exchange
Run baseline and negative cases, including an unknown revision, missing mandatory data and a repeated message. Record rejection or reconciliation decisions.
Evaluate interpretation
Compare source and receiving records, audit provenance and identify manual exceptions. Report the limits of any interoperability claim.
Development connects a defined application, measurable criteria and a traceable technical review.
Technical deliverables
Outputs and evaluation.
The development workstreams connect these deliverables to reviewable evidence and application-specific evaluation criteria.
- Data model
- Interface control specification
- Mapping rules
- Sample synthetic dataset
- Exchange demonstrator
- Validation test cases
- Interoperability evaluation report
Evaluation priorities
- Semantic consistency
- Fields retain their intended meaning, units and configuration context.
- Integrity and reliability
- Records are complete, traceable and handled predictably during errors or retries.
- Auditability
- A reviewer can reconstruct origins, transformations and authorized changes.
Participation & boundaries
The right expertise. Clear responsibilities.
The participation framework connects engineering-data expertise, software development, PLM and MRO practice, cybersecurity and data governance. Each contribution addresses the meaning, configuration, security or verification of an exchange.
Scope and safeguards
Datasets require synthetic content or explicit authorization, with access controls and permitted uses recorded. Personal data, credentials and proprietary operational records are protected throughout development and demonstration.
Reference frameworks inform interface design and review. Interoperability evidence is evaluated independently from certification, accreditation or approval of a participating system.
Participation and technical decisions remain separate.
Participation does not automatically confer membership rights, AF Recognition, accreditation, certification, standards-setting authority or procurement preference. Sponsorship must not determine technical conclusions, evaluation results or governance decisions.
Development pathway
Development, grounded in evidence.
Technical objectives, responsible coordination and application needs shape the development process. Resources, safety, confidentiality, data protection, intellectual property and reporting arrangements are reviewed alongside the methods and deliverables, keeping progress focused and accountable.
A structured development pathwayExplore the seven connected development stages
Programme development connects technical requirements, responsible coordination and reviewable evidence. Each stage informs the next, while review findings refine the scope, methods and priorities.
- Requirements & Objectives
Define the technical problem, user need and scope.
- Feasibility & Evidence
Examine methods, resources, interfaces and dependencies.
- Scope & Responsibilities
Align workstreams, coordination and review arrangements.
- Pilot Development
Connect the evaluation plan to funding, safety, data and intellectual-property controls.
- Controlled Implementation
Maintain the agreed technical boundary and responsible delivery arrangements.
- Technical Evaluation
Review evidence and outcomes against application-specific criteria.
- Knowledge & Further Development
Translate reviewed findings into useful outputs and the next development priorities.