This project simulates the Angle Of Attack (AOA) system of the Phantom F-4E fighter jet.
It comes as an interactive console application with a simple text-based GUI. For the best experience, it should be viewed on an ANSI-compatible console. As of now, only Windows is supported.
The simulation can be interacted with, by using keys. The controls are as follows:
The aircraft's position in relation to the flight path (which is kept stationary in the simulation), can be changed by holding down the following keys
- ↑ pitch down (drop nose)
- ↓ pitch up (lift nose)
- → rudder right (changes yaw, not roll)
- ← rudder left (changes yaw, not roll)
All buses are powered by default already, their state can be toggled with
- Q Essential 28V DC
- W Right Main 115/200V AC
- E Instrument 115/200V AC
- R Left Main 115/200V AC
Circuit breakers are, by default, pushed in. Their state can be toggled with
- A AOA PROBE HTR PWR (power to the AOA sensor)
- S AOA PROBE HTR CONT (power to the other components of the AOA system)
- D ESS DC CADC (whether the central computer receives power through the essential bus)
- F INSTR AC CADC (whether the central computer receives power through the instrument bus)
- G RM VAC AC CADC PWR 1 (whether the central computer receives power through the right main bus)
- H RM VAC AC CADC PWR 2 (whether the central computer receives power through the right main bus)
- J RM VAC AC CADC PWR 3 (whether the central computer receives power through the right main bus)
The aircraft has a few knobs that can be rotated to decrease or increase their value respectively
- TZ Instrument Panel light intensity
- UI Emergency Floodlight (technically a 3-way switch, increase beyond 0.3 and 0.6 respectively)
- OP AOA indexer light intensity
- KL Aural Stall Warning Tone volume
Further, there are certain states, provided as simple boolean flags, which can be toggled.
- Y Nose-Wheel (extend/retract)
- X Weight On Wheel (on-ground/in-flight)
- C Gear (extend/retract)
- V Slats (in/out)
- B AGM-45 mode (select/unselect)
- N AOA sensor icing (freeze/not frozen)
For simplicity, the gear flags all act independently of each other. For example, applying the gear flag will not apply the nose-wheel flag as well.
The aircraft's AOA system consists of the following components:
- sensor
- indicator
- indexer
- stall warning vibrator
- aural tone system
For which, the simulated features are:
- measure AOA based on aircraft's 3 axis (pitch, roll, yaw) and the flight path vector
- (also measure side-slip angle in a similar way)
- power based on bus and circuit breakers
- warmup-time based on outside temperature
- error induced by an extended nose-wheel
- error induced by side-slip
- error induced by a frozen sensor
- display the AOA received by sensor
- power based on bus and circuit breakers
- needle is stuck if no power
- shows OFF-flag if no power
- shows AOA within limits of 0-30°
- needle dampening to prevent jitter
- needle lag (does not catch up to the sensor reading immediately)
- has 3 lamps
- illuminate based on AOA reading
- either red or white, depending on knobs
- power based on bus and circuit breakers
- white, red BRT and red DIM are energized differently
- light intensity based on knob
- illuminate 3 lamps based on AOA received by sensor
- power based on bus and circuit breakers
- lamp status based on AOA ranges
- light intensity based on knob
- power based on bus and circuit breakers
- knob can not turn them off, only dim them
- special AGM-45 mode
- lamps then indicate AGM-45 cues instead of AOA
- vibrates based on AOA received by sensor (vibration is just visualized)
- power based on bus and circuit breakers
- only active if no weight on wheels (in-air)
- emits tones based on AOA received by sensor (tones are just visualized)
- power based on bus and circuit breakers
- different tone profiles based on slats and gear status
- tones have a frequency, volume and can be either steady or interrupted (pulse per second)
- volume based on knob
- tone profile can prevent muting in certain situations
Sensor measurements:
Warmup:
Nose-wheel error:
Side-slip error:
Frozen sensor error:
Indicator:
Power off, needle stuck:
Indicator is limited:
Needle lags:
Medium-AOA white lamp with intensity
High-AOA red lamp with intensity
Indexer lamps:
No power:
Light intensity:
AGM-45 mode:
Stall-warning:
Inactive on ground:
Emits tones:
No power:
Muted with knob:
Prevents muting in critical situation:
At the moment, only Windows is supported. This is due to how the system reads keyboard input.
The flow starts with main.cpp, which simply starts Simulation.
Simulation consists of a simple game loop that controls logical updates and rendering using TPS and FPS
respectively.
It maintains a list of Entity, for which it will call update(double deltaTime) during a logical update (tick)
and render() when rendering the next frame.
As of now, update and render can not be called in-parallel, since state changes in update
are not all synchronized/guarded yet.
The list of entities consists of Engine and Phantom (the aircraft and all its components).
The Engine class represents all external inputs which are out of the scope for this simulation.
For example measuring the outside temperature or maintaining the aircraft's position.
It also handles all user inputs and maintains the states of all corresponding knobs and similar.
Other classes will use it as main source for external input.
The way the engine handles input, right now, is a bit over the place and grew organically. It consists of a few enums:
BusCircuitBreakerFlagKnob
and Controls. Since enums can not hold other state or properties, they are represented with multiple maps.
Each of them has a map to represent:
entrytonamefor visual display (render)keytoentry(to map controls to the corresponding system)
and further possible extra state, such as activatedFlags, poweredBuses, knobToValue, pushedCircuitBreakers.
Phantom represents the aircraft itself. It maintains a list of all its own entities,
such as the AOASensor, AOAIndicator and more.
It essentially just forwards all calls, like update or render to all its components.
All relevant logic for math and physics can be found in Math and Vector3.
Given that the atmosphere is already fully simulated, how would you simulate the AOA system?
In reality, the sensor measures the AOA with a slotted probe. The probe has two holes that allow air to stream in. Difference in air pressure between the areas behind those two holes, created by a change of AOA, physically move a surface within the probe. This movement then induces changes in electrical resistance, which is translated into the sensors signal.
Simulating it that way requires that the engine is capable of providing precise atmospheric pressure readings for a given 3D position. The advantage of that would be that the system behaves as close to reality as possible, and would naturally support edge cases that can occur when, for example flying through clouds or other environments with rapidly changing air pressure.
In practice, however, such a deep simulation is often not applicable and for most engines likely also not feasible.
Another option is to just measure the AOA based on the aircraft's position and attitude in space, together with its flight path vector. This information can typically be provided by engines more easily.
The AOA can then be computed by basic means of 3D geometry:
This approach will provide an accurate AOA reading in all situations, attitudes and motions. While this sounds great, it is also a disadvantage at the same time. It implies that more effects have to be simulated manually, such as errors induced by side-slip, or by an extended gear that changes the air-flow in front of the probe.
Once the sensor is simulated, it can simply forward its readings to all other components that rely on it.
Code-wise, it is likely meaningful to employ OOP here and represent each component in the system as its own individual class, which possibly has dependencies on other classes. For example, the AOA system consists of components, like:
- sensor
- heaters
- circuit breakers
- indicator
- indexer
- stall warning vibrator
- aural tone system
That way, each component can simulate its own quirks individually. It also allows us to create multiple, individual instances per component. For example, the aircraft has 2 indicators and 4 indexers. Each of them could then exist individually, allowing individual interaction.
Some things likely do not need to be represented as individual components in the simulation, such as the heaters. The heaters can not be interacted with individually and only influence the sensors capability to measure accurately. It may or may not be feasible to just represent this effect within the sensor itself, depending on outside conditions, such as the temperature. This could change if the environment allows for more detailed simulation, such as combat-damage of the heater unit itself.
What simulation outputs are necessary and for which systems are they critical?
The AOA system is a core component of the aircraft system. Its data is not only relevant for its own components, such as:
- indicator
- indexer
- stall warning vibrator
- aural tone system
But is also fed directly into the Central Aircraft Data Computer (CADC), from which it is forwarded to all other systems that need it.
Some systems that rely on it are:
- HUD
- navigation system (INS, ...)
- flight control system (slats, engine inlets, ...)
- weapon system (lead computation, CCIP, AGM-45, ...)
- tests (BITs and test switches might spin the needles around and light all lamps)
Further, there are also systems that should be given access to the true physical AOA, without any simulation effects applied by the sensor. The simulation of the flight model or engine performance needs access to the real AOA in order to simulate changes during extreme conditions. As an example, the aircraft starts rolling to the side under very high AOAs, or the engines may flame-out.
The core data that has to be exposed to other systems is essentially the AOA reading of the sensor itself.
Further, some systems, such as the AGM-45, requires control of the AOA indexer. It can override the lamp states to indicate cues.
Apart from that, the AOA system mostly just has to expose its data for display/rendering in the cockpit. For example, the AOA indicator has to move the needle to the indicated position.
The components also need to be able to read certain data from the system, such as the state of relevant buses or circuit breakers, as well as all knobs and switches that can be used to control them. For example the light intensity knobs for the AOA indexers.
What kind of basic failures in the AOA system would you simulate?
The most obvious failures are related to the system not having power. Some reasons could be:
- engines out, battery out, no external power
- circuit breaker pulled
- generator out
- combat damage
Further, the sensor can become iced if flying in cold conditions and the heaters are turned off or damaged.
But there are also failures that are just unrealistic to happen within the context of the simulation. It is not necessary to simulate those. For example:
- mean operating time between failures (1500 hours)
- minimum operating life (6000 hours)
- error induced by voltage spikes
- errors when applying very high or low temperatures
- applying force to the probe until it bends
Relevant failures that could potentially be simulated are combat damage in the corresponding areas on the aircraft where the systems are located at. For example, when receiving gun fire near the probe, it could get damaged, disabling the sensor and everything that relies on it.