Flight simulation has come a long way since we were supposed to suspend our disbelief enough to believe that untextured boxes would pass for realistic buildings or a largely shapeless mat of colour for terrain. Nevertheless, many of the key components of flight simulation platforms have remained largely unchanged since the inception of modern civilian flight simulation in the 1960s – largely the same technologies apply regardless of whether one discusses professional or consumer implementations. X-Plane is a particularly interesting example in that it positions itself between consumer-exclusive and professional-exclusive applications.

The Flight Model

        Arguably, the most important part of a flight simulation is the flight dynamics model (FDM), which is a set of algorithms that determines the change in the aircraft position, attitude, airspeed, and acceleration as a result of changes in either control inputs or external conditions. These are described by equations called control derivatives and stability derivatives, respectively. These are simplifications of the full equations of motion in 6 degrees of freedom, and are needed because computing the full equations would be too resource-intensive even for modern hardware.

        The flight model must also contain a description of the airfoil geometry, lift behavior, stall dynamics, and a host of other factors, many of which, in X-Plane’s case, are directly editable in PlaneMaker and AirfoilMaker. Many developers, such as IXEG, have chosen regardless to forego the X-Plane flight model and supplement it with their own data. In the case of the 737-300, this has allowed for more realistic single-engine and inertial behavior, among other factors.

        In practice, builders of consumer (and most professional) simulations are hampered by the lack of reliable performance data. Some developers have claimed that that aircraft perform within 5% of manufacturer specifications in the nominal flight envelope, which would have them meet the ICAO standards for full flight simulator (FFS) flight models in many respects. Unless they truly have access to performance data packages for FFSes, which, while not impossible, would represent a hitherto unseen level of co-operation from manufacturers, it is indeed more likely that this is just one part of a marketing strategy which I will dissect for you in future articles. 

The Systems Model

        Early PC aircraft simulations had almost no systems modeling beyond the base sim’s capabilities. Indeed, the Dreamfleet 737CL as well as the 767 Pilot in Command, by the team now known as Level-D Simulations, are usually considered early study-level simulations. Thus, conservatively speaking, the current high-end desktop simulation concept is only about 20 years old and has seen exponential progress with the explosion in computing power – the 767PIC was released on 4 March 2001, the 737 in November that same year.

        If the flight and engine performance models are your sim aircraft’s skeleton and heart, respectively, then the systems model would amount to its brain. There are, in principle, two approaches to modeling systems, both of which are employed by developers to varying degrees – emulation and simulation. Emulation involves replicating the internal structure of a system at a chosen level of granularity, such as electrical buses and generators. This usually requires an underlying physics model. An extreme example of emulation, also known as ecological modeling, would be the FlightFactor A320, or, indeed, the FSLabs A320 in FSX and Prepar3D.

        Emulation has two main advantages – first, it supports a wider range of interactions between the aircraft and its environment. For example, many of the ECAM messages you will see in the aforementioned A320 simulations arise simply from the simulated ECAM logic interacting with the rest of the systems – when you have recreated the airplane component-by-component, there is little need to “fake” anything, which explains why you experience real-world nuisance failures when operating these aircraft – they occur spontaneously, because the replicated systems exhibit identical glitches to the real aircraft, without hard-coded triggers.

        The other advantage has to do with easier and more realistic failures: the only thing you have to do is tell the simulation a component has failed – in an ideal case, the systems model will predict consequences identical to the real aircraft – because the aircraft will react as in reality. For example, in the B777 by PMDG, when an electrical source fails, the simulated electrical systems controller will reconfigure the systems just as the real thing would, without pilot intervention.

        The diametric opposite of emulation is simulation. Simulation, as the word suggests, aims to achieve behavior roughly similar to the real-world equivalent, but restricts itself to only reproducing the overt behavior of its simulandum. In the context of a study-level airliner, for example, the key to good performance lies in finding an optimum balance of emulation and simulation. In contrast to our desktop sims though, in an FFS performance is usually no obstacle at all, as FFSes use real components: the only thing you have to do is fake the inputs to those components, and you’re in business.

In the next part of this series, we will address two additional components of a flight simulation: the visuals and the atmosphere, and discuss their evolution on the personal computer, with, again, some full-flight simulator comparisons for your pleasure. Until later!