Aircraft OEM Manufacturers · Certification
The training device tied to your type is a data product; qualification is where that becomes visible to authority.
validation and qualification packages anchored in your OEM flight data; the fourth layer of the four-layer stack: compliance documentation delivered with the platform, not a brochure compiled after franchised hardware lands
Structured VDR thinking, EQTG/QTG-native discipline, and test artefacts produced alongside VOA simulation software, type-specific cockpit hardware, and in-house avionics electronics; so the configuration states EASA/FAA-oriented reviewers correlate are the same ones your programme controls when post-certification updates must be filed for the life of the aircraft, not re-negotiated across an external maintainer on every LRU or loadable revision.
Discuss Your RequirementsWhen the binder and the device diverge, your type-cert narrative carries the professional risk.
Authorities correlate QTG outputs to the flight test envelope and avionics behaviour you own. If validation evidence is assembled downstream of a closed stack, findings land on the signatories who must explain gaps they cannot close without vendor intervention; the inverse of the in-house programme control the OEM pitch promises.
EASA and FAA frameworks expect configuration changes after qualification to be managed transparently; sometimes including re-qualification. If the organisation that holds revision history and test baselines is not yours, every field update queues behind another company's service calendar for the multi-decade life of the programme.
The OEM discovery warning is precise: undocumented electrical or loadable deltas leave the simulator different from the VDR/QTG baseline; exactly the discrepancy pattern regulators target when customers train for credit on a device associated with your aircraft type.
Certification as architecture; the fourth OEM layer delivered with the same team as your executable, metal, and buses.
VOA treats EASA/FAA-oriented documentation and validation discipline as a design input for Production Custom FFS: evidence threads that trace your OEM datasets through software, hardware, and electronics; with roles split explicitly between baseline artefacts VOA engineers with the stack and programme-specific submissions your organisation originates for its certification context.
VDR and validation planning scoped early; CS-FSTD-oriented thinking where the training device follows civil rules, not a documentation sprint after iron arrives
EQTG/QTG-native exports and automated test structures where applicable; reducing manual transcription from runtimes your team cannot audit
Flight and ground data acquisition, calibration hooks, and cross-checks aligned with the same validation rigour used when certifiability is specified from layout
Change control mapped to software builds, BOMs, and PCB revisions; configuration states the qualification package can name when post-certification updates are filed
Engagement paths from discovery: technical meeting, workshop, or architecture assessment; qualification structure discussed before programme commitment hardens
Proof-aligned narrative: OEM-data-validated software and ARINC-capable in-house electronics cited in the OEM deck sit under one documentation thread, not three subcontractors' PDFs
Certification pillar in the civil reference architecture: Solutions → Certification
