What's in a Qualification Test Guide (QTG) for Flight Simulators?
- Daniel de Vries
- Dec 20, 2025
- 9 min read
Every professional operating, engineering, or maintaining a flight simulator eventually faces up to the Qualification Test Guide (QTG). For many, it is the fundamental document in synthetic aviation training; for others, it's a necessary but demanding operational requirement. What defines a QTG, and why is this document non-negotiable for guaranteeing high-fidelity flight simulation quality?
The Core of Flight Simulator Validation
The QTG is the definitive document specifically developed to objectively verify that a particular Flight Simulation Training Device (FSTD) accurately replicates the real aircraft, and as such can be used for undertaking accredited training and certifying pilots - at least when it comes to civil and commercial aviation. Its primary function is to provide a conclusive process to prove that the FSTD's performance and handling qualities remain within the tight, prescribed limits when compared to the actual aircraft (or more specifically, the approved aircraft data), confirming compliance with applicable regulatory requirements.
Objective Assessment
The original idea behind a QTG was to address the unreliability of purely subjective assessments in determining a simulator's flight performance. Before we had QTGs, flight simulation training devices (FSTDs) were judged in purely subjective ways, and before that there weren't even any testing or assessing processes undertaken; it was simply assumed that the device was fit for purpose (but not relied on, as real flying was where the vast majority of training still occurred). The QTG established an objective (mostly) and repeatable methodology for validation (it also includes subjective elements). It confirms that the simulation model appropriately matches the simulated aircraft and is suitable for specific training sequences that it is endorsed to be used for. The objective and subjective elements include such things as flight dynamics, handling characteristics, and all integrated systems, such as environmental conditions, controls, sound, visual, and motion.
Military Applications
In some military contexts, the QTG proves that the performance, handling, and synthetic environment (inclusive of critical mission systems) of an Aircrew Training Device (ATD), Tactical/Operational Flight Trainer (T/OFT), Full Mission Simulator (FMS) or Weapons System Trainer (WST) are validated within specified operational limits. In some defence applications there is no requirement for the aircraft data to be validated, as the use of these devices is not for the certification of aircrew under civil regulations. With that being said, many military training simulators use civil standards as a baseline for developing their device specific QTGs.
Anatomy of the QTG
The QTG is not a checklist, far from it; it includes far more detailed information and is much more complex than a simple checklist. It is essentially a comprehensive technical data and testing document. The pages incorporate both the approved Validation Source Data (VSD) of the aircraft (or class/type) and the resulting FSTD data used to support the validation - this is the entire purpose of the QTG to confirm the source data is valid, and how the sim data is relative to the source data, and how it is tested to confirm its concurrence. This exhaustive list of requirements, each tied to a specific test, confirms the simulator's determined qualification level based on the initial evaluation, and is used to confirm during ongoing evaluations.
Key Elements Structuring the QTG
A QTG's structure ensures complete technical transparency and traceability:
Identification and Signatures
This includes the title page with necessary sign-offs from the FSTD operator and the approval authority (usually the relevant NAA), alongside a simulator information page detailing the FSTD identification number (part number, serial number, etc), the specific aeroplane or helicopter model, and all reference sources for aerodynamic, engine, and flight control data.
Documentation Control
Sections dedicated to a table of contents, a log of effective pages and revisions, and a complete listing of all reference source data.
Statements of Compliance (SOCs)
These are definitive declarations confirming that relevant regulatory requirements have been met. They mandate reference to source documents, explanation of the compliance rationale, may include relevant equations and parameter values, and clear conclusions. SOCs are fundamentally important for complex systems, including such elements as stick pusher logic, upset recovery scenarios, and detailed aerodynamic modelling, to name a few.
The VSD and the VDR
The Validation Source Data (VSD) is the most essential piece of the QTG puzzle. This is the aircraft reference data; composed of certified ground and flight test results, engineering data (where used), and supporting justifications. These data sets objectively confirm the FSTD's static and dynamic handling and relevant systems. The scope of VSD is dictated by applicable regulatory specifications and any additional Training Areas of Special Emphasis (TASE). The Validation Data Roadmap (VDR) clearly maps these sources and their validity.
The Two Core Parts of QTG Testing
The validation methodology within the QTG relies on two distinct and essential test categories:
Quantitative Validation Tests
These tests involve objective comparisons of recorded simulator data against the corresponding aeroplane or helicopter data within tolerance limits. These quantitative assessments are vital for proving the FSTD's adherence to real-world aircraft behaviour. Many of the tests are automated, and many make use of calibrated measurement equipment and specialised testing related software. In the field, these tests are typically run by the maintenance support team.
Qualitative Functions and Subjective Tests
These tests require a qualitative assessment conducted by a (usually) type rated pilot. Their function is to verify the correct operation and integration of controls, instruments, and systems, amongst other things. They also assess the simulator’s overall suitability for complex training tasks across all phases of flight - from ground operations and take-off to instrument approaches, landings, and system malfunctions to name a few.
The Master QTG (MQTG)
Once the initial or special evaluation is completed, all discrepancies are formally addressed, and the QTG receives approval from the relevant Civil Aviation Authority (CAA), it achieves the status of the Master Qualification Test Guide (MQTG). Thereafter, operators typically execute the complete QTG testing progressively (often in defined quarterly blocks) between annual ongoing evaluations to rigorously confirm the consistent maintenance of simulator standards.
Operational Necessity of Recurrent Testing
The MQTG becomes the primary reference document for the simulator's qualification status and all subsequent recurrent evaluations. Exceptions to this case include future major modifications requiring a special evaluation, and any recategorisation (i.e. level C to level D, etc) undertaken on the FSTD - both circumstances would require a new MQTG to be approved.
Degradation Monitoring
For military devices, progressive testing against the MQTG is often conducted over a rolling 12-month cycle to immediately identify and address any performance degradation. Even where military devices do not formally achieve a recognised FFS or FTD level, testing is often conducted against the baseline data from the MQTG to ensure that the fidelity of the system remains at the tested baseline levels and doesn't degrade with time.
The QTG in Quality Management
The QTG is integral to an FSTD operator's Quality System. It is the primary documentation for monitoring regulatory compliance and ensuring the qualification level of the FSTD is maintained.
Controlling Regression and System Integrity
The QTG is an indispensable tool for checking for regression following any software or hardware modifications, providing the only objective mechanism to identify unintended consequences of such changes. A well designed configuration control system is necessary to ensure the continued integrity of the qualified hardware and software.
The Industry Standard
While recognised as critical for high-quality training, the execution of the QTG process is often debated. Concerns over the required time investment and practices like running multiple tests to barely meet tolerance limits are common. Nonetheless, the QTG remains a validated methodology without a reliable alternative currently available. It provides the definitive consistency the industry mandates.
Summing Up
We've covered why the Qualification Test Guide (QTG) is the benchmark for high-fidelity simulation - it is the mandated tool for objective validation, managing regression, and upholding your simulator's qualification status. For FSTD operators executing this painstaking testing can be a significant operational drain. The QTG is the unavoidable standard, but managing it doesn't have to slow down your operation. By having a clear strategy for recurrent testing and leveraging expert support, you can maintain full compliance and focus on your core mission: delivering world-class training.
Frequently Asked Questions
What's the difference between a Qualification Test Guide (QTG) and a Master Qualification Test Guide (MQTG)?
QTG: This is the proposed document prepared by the simulator manufacturer before certification. It demonstrates how the simulator proposes to meet the requirements, but it has not yet been officially accepted by the relevant authorities.
MQTG: This is the approved document. Once the regulatory authority (e.g. the FAA) validates the QTG, approves, and signs it, it becomes the Master QTG. It is "locked", legally binding, and serves as the baseline for all future simulator tests.
In short: the MQTG is the approved document from a regulatory standpoint.
What is Validation Data and how does it relate to the QTG?
Validation Data is the set of objective parameters recorded directly from the real aircraft (although sometimes 'engineering data' is provided in lieu of recorded data), often provided by the aircraft manufacturer (OEM), but can also be recorded during a flight test campaign.
The QTG is the evidence that connects the simulator to that Validation Data.
The Reference: Validation Data acts as the legally required standard or "answer" that the simulator must replicate.
The Comparison: The QTG contains side-by-side plots where the Validation Data is overlaid with the Simulator's Data for specific manoeuvres (e.g., takeoff, stall, landing).
The Tolerance: The QTG defines the allowable margin of error. The simulator data doesn't have to match the Validation Data perfectly, but it must stay within a specific "tolerance corridor" (e.g. ±5%) defined in the QTG to be approved.
Validation Data provides the questions and correct answers, and the MQTG is the evidence showing the simulator passed.
What are tolerances in respect to a QTG?
Tolerances are the strict, regulatory limits that define how much the simulator is allowed to deviate from the Validation Data in testing.
They determine the Pass/Fail criteria for every objective test in the guide.
The "Corridor": Since no simulation can match reality 100% perfectly, regulators define a specific "margin of error" or corridor around the Validation Data.
The Compliance: On a QTG plot, the Simulator Data line must stay inside this defined tolerance band throughout the manoeuvre.
The Specificity: Tolerances vary based on the parameter. Critical flight controls might have very tight tolerances (e.g. ±2 lbs of force), while less critical systems might have looser ones (e.g. ±5% engine vibration).
Who approves a QTG?
A competent and relevant authority. This will vary based on which jurisdiction your simulator is based, and which jurisdictions are required to provide certified/endorsed training to. For example, if you're an FSTD operator in the U.S.A. your simulator will have it's QTG approved by the FAA. But if the same operator wants to provide training to pilots who will operate and are licensed in Europe, then that same simulator will also require a QTG that has been approved by EASA.
In the defence/military context, the approval authority may be any number of defence entities - oftentimes it is contracted out to a competent third party contractor who specialises in simulator evaluations.
What is the difference between Flight Test data and Engineering data in a QTG?
Flight Test Data and Engineering Data differ primarily in their source and their hierarchy of acceptance within a QTG.
Flight Test Data (The Gold Standard) is the empirical data recorded by sensors on a physical aircraft flying in the real world.
Source: Actual flights performed by the manufacturer (OEM), or flight test specialist during a campaign, specifically to gather data for simulation modelling.
Characteristics: It represents "truth," but it is often "noisy" (containing bumps from turbulence or sensor vibration and a noisy environment).
QTG Role: It is the primary requirement. Regulatory authorities mandate this data for the vast majority of validation tests (e.g., takeoffs, landings, cruise performance).
Engineering Data (The Alternative) is analytical or theoretical data derived from mathematical models, wind tunnel testing, or design predictions based on complex engineering and mathematics.
Source: The aircraft manufacturer's design software or simulator engineering tools.
Characteristics: It is more "smooth" and clean, as it lacks real-world noise.
QTG Role: It is a secondary option, used only when gathering Flight Test Data is:
Dangerous: (e.g., Minimum Control Speed on the Ground - Vmcg).
Impossible: (e.g., verifying a specific aerodynamic coefficient in isolation).
Unavailable: (e.g., for an aircraft still in early development, though this is rare for qualified sims).
Flight Test Data is what actually happened in the sky; Engineering Data is what physics says should happen and is used when flying the real plane is too risky.
Is it common for an FSTD to undergo recategorisation?
FSTD Recategorisation is the formal process of changing a simulator's qualification level (e.g., moving from Level D down to Level C).
Is it Common? No, it is relatively rare. Most simulators remain at their initial qualification level for their entire service life. However, when it does occur, it usually happens in one of two specific scenarios:
The Downgrade (Pragmatic): This is the most common scenario for recategorisation. If an older simulator suffers from mechanical wear or obsolete parts and can no longer pass the strict tolerances of its MQTG, the operator may voluntarily "downgrade" it. In this circumstance, the device stays qualified and can be used for certified training, but will likely lose some high-value training credits.
The Upgrade (Strategic): An operator invests in new hardware (like a new visual or motion system) to raise the level. The process is generally quite expensive and presents many technical complexities, as the old sim must now meet stricter validation data standards.
Any recategorisation voids the current MQTG. A new QTG must be written and a full initial evaluation performed by the regulator to issue a new certificate and have a new MQTG approved
What is the purpose of transport delay tests in a QTG?
Transport Delay (aka Latency, aka Throughput) is the time lag between a physical control input (e.g. yoke or side-stick deflection) and the simulator's perceptible response (motion and/or visual change).
It is a critical system test to ensure the simulator processing is fast enough to fool the human brain.
The Measurement: The QTG test measures the exact time from the electrical signal entering the computer to the reaction occurring in the visual or motion system.
The Tolerance: For Level D simulators, this delay must be < 100 milliseconds - however in some applications (e.g. military) this response threshold may be mandated to be lower.
The Consequence: If the delay is higher, it can cause Simulator Sickness (mostly nausea) and Pilot Induced Oscillation (PIO), where the pilot over-controls the aircraft because the response is late.
Comments