Level D Simulator Data Packages and SIMD Compliance

A Level D simulator data package is the technical foundation used to build, validate, qualify, and maintain a high-fidelity full flight simulator. It connects the simulator to the actual aircraft configuration it represents and provides the evidence needed to prove that the simulator behaves like the aircraft across the required training envelope. For Level D qualification, this goes far beyond basic performance data. The simulator must reproduce flight dynamics, control feel, cockpit systems, visual cues, motion response, sound, vibration, engine behaviour, ground handling, and other aircraft-specific characteristics.

Aeroset supports Level D data package development through controlled flight test campaigns, aircraft instrumentation planning, simulator-relevant parameter definition, data acquisition, and post-flight data preparation. The goal is to generate data that is not only accurate, but usable for simulator development, validation, QTG preparation, and qualification review. For business jets, normal-category aircraft, and commuter aircraft, this requires a strong understanding of aircraft configuration, test conditions, measurement quality, and downstream simulator use. A well-structured Level D data package gives simulator manufacturers and qualification teams a defensible basis for building, tuning, validating, and maintaining a qualified training device.

SIMD compliance sits within the broader Operational Suitability Data framework. Under EASA logic, OSD connects the approved aircraft design with the way the aircraft is trained, dispatched, maintained, and operated. The five OSD pillars are flight crew data, cabin crew data, MMEL, maintenance certifying staff data, and simulator data. Simulator data is therefore not an isolated technical appendix; it is part of the aircraft’s operational suitability structure and must be aligned with training needs, certification logic, and FSTD qualification requirements.

This is where CS-SIMD and CS-FSTD connect. CS-SIMD defines the simulator-data approval logic, including Validation Source Data, Validation Data, and the Validation Data Roadmap. CS-FSTD defines the qualification target for the Flight Simulation Training Device itself. Aeroset supports customers by helping translate this regulatory structure into practical data activities: defining what aircraft data is required, how it should be captured, how it should be structured, and how it can support simulator qualification. This is particularly important where a program involves a new aircraft type, a derivative configuration, an STC-driven modification, or an update to an existing simulator data package.

Validation Source Data, or VSD, is the aircraft reference data used to support objective simulator qualification. It may include ground test data, flight test data, engineering data, and justified supplemental sources. In a Level D or SIMD context, VSD must show what data was collected, where it came from, which aircraft configuration it represents, and how it supports simulator validation. It is not enough to provide raw plots or measurement files. The data must be organized, traceable, reviewable, and linked to the relevant simulator qualification purpose.

Validation Data, or VD, is the subset of that source data actually used in the qualification process and referenced in the QTG or MQTG. Aeroset supports this process by generating and preparing aircraft data in a way that preserves test conditions, units, parameter definitions, aircraft states, configuration references, and processing logic. Where engineering data or alternative sources supplement flight-derived evidence, the rationale must be clear. This allows simulator manufacturers, DOA partners, and certification stakeholders to understand how the selected data supports the qualification basis. The result is a simulator data package that can support objective comparison, authority review, and future reuse.

A simulator data package is only as strong as the flight test campaign behind it. For Level D simulator data capture, each maneuver, test condition, aircraft configuration, and recorded parameter must be planned around the downstream validation objective. Aeroset supports this process by helping define simulator-relevant test points, required parameters, aircraft states, instrumentation needs, data quality expectations, and operational constraints before the aircraft is flown. This reduces the risk of missing data, unusable measurements, or repeated flights.

During execution, Aeroset focuses on capturing controlled aircraft behaviour under the right conditions. This may include performance, stability and control, engine response, ground handling, control positions, flight control behaviour, system states, and other parameters required for simulator development and validation. For business jet and commuter-category aircraft programs, practical constraints such as aircraft availability, airport limitations, operator requirements, and instrumentation access must be managed carefully. Aeroset’s value lies in connecting flight test engineering discipline with the final simulator qualification objective, so that the collected data can support aerodynamic models, engine models, QTG evidence, and long-term simulator configuration control.

The Qualification Test Guide is where aircraft reference data becomes structured simulator qualification evidence. A strong QTG connects objective tests, source references, simulator results, tolerances, test conditions, procedures, and supporting material into a format that can be reviewed efficiently. The Master Qualification Test Guide then becomes the controlled baseline after evaluation results are incorporated. For this reason, QTG and MQTG support should not be treated as document assembly at the end of a program. The structure must be anticipated from the data planning phase.

The Validation Data Roadmap, or VDR, is the control mechanism that connects the scope of required validation data with the qualification tests it supports. It identifies which tests require aircraft source data, which may be supported by engineering simulation or other accepted sources, and where justifications are required. Aeroset supports VDR-related workflows by helping customers structure the relationship between aircraft data, validation logic, simulator tests, and future updates. This improves traceability, reduces clarification loops, and helps keep the simulator data package aligned with CS-FSTD and SIMD expectations from initial qualification through later modifications.

Level D simulator qualification depends on more than baseline aircraft performance points. A high-fidelity simulator must reproduce aircraft behaviour in a way that supports the intended training tasks, including aerodynamic response, propulsion behaviour, control feel, ground handling, and selected special conditions. This may include data or justified evidence for ground effect, runway contact reactions, braking, steering, thrust reversing, stall-related behaviour, windshear, upset scenarios, icing effects, or other condition-specific requirements depending on the qualification scope.

Aeroset supports these areas by helping define, capture, process, and structure the aircraft data needed for model development and validation. For aerodynamic and engine models, the data package must explain what aircraft data, engineering source material, or accepted supplemental evidence was used to build, tune, or validate the simulator model. For special conditions, the package must show what source basis or justification supports the simulated behaviour. This is particularly important when aircraft variants, engine options, avionics revisions, aerodynamic modifications, or STC-driven changes affect the simulated configuration. Properly handled, these data areas become part of a defensible simulator qualification package rather than isolated engineering assumptions.

Simulator data compliance does not end with initial qualification. Aircraft configurations change, avionics are updated, engine variants are introduced, training requirements evolve, and simulators are modified over time. This means the simulator data package must remain controlled, traceable, and maintainable throughout the lifecycle of the training device. Aeroset supports this by helping structure data as a controlled technical asset, with clear configuration references, revision logic, source traceability, update paths, and reusable evidence for future simulator changes or recurrent qualification needs.

This lifecycle view is especially important for SIMD and OSD work. Where simulator data is linked to an approved aircraft configuration, the data must remain aligned with the relevant TC, STC, DOA, or approved design framework. The independent STC path may also become relevant where simulator-relevant data does not come directly from the original TC holder, but from an approved STC-related route. In such cases, technical data generation, DOA coordination, Part 21 logic, and certification traceability must be handled carefully. Aeroset supports this environment by providing the flight test execution, data preparation, and technical structuring needed to help qualified partners turn aircraft reference data into regulator-ready simulator evidence.