avionics

How it is built

Architecture overview

Integrated modular avionics (IMA) replaces a rack of single-purpose "black boxes" with a few shared computing cabinets that host many aircraft functions at once. The FAA's advisory circular defines an IMA as a "shared set of flexible, reusable, and interoperable hardware and software resources" that form a platform hosting applications, and stresses that an IMA is defined by its architecture, not by the function it serves: it may run displays and navigation, but also flight controls or electrical-power control (FAA AC 20-170). The one idea that makes it work is robust partitioning: every application gets a guaranteed slice of CPU time, memory and network bandwidth, enforced by the platform, so that a failure in one function cannot reach another and each can be certified on its own.

A cabinet runs a partitioning kernel (an ARINC 653 style operating system) with a fixed, repeating time schedule. Partitions talk through typed ports and over a deterministic switched network (AFDX, ARINC 664 Part 7). A health monitor and watchdogs detect faults; redundancy and restart policies recover from them. On top sit the functions themselves: here a flight-management and navigation function and a cockpit display, as in the commercial IMA families named in the goal (Airbus, Honeywell Primus Epic, Garmin G3000). Those products are closed; this page describes the shared design, not any one of them.

Parts:

• Partitioned kernel — fixed time windows, memory isolation, traps and dispatch — time-triggered-scheduling (no page yet), Preemptive priority scheduling, Virtual memory and the TLB, Context switching, Interrupt handling
• Health and recovery — detect, contain, restart, switch over — Watchdog timer, fault-detection-isolation-recovery (no page yet), redundancy-voting (no page yet), Hot-standby redundancy, safety-monitor-architecture (no page yet)
• Deterministic network and data integrity — bounded-latency links between cabinets and sensors — Token bucket, end-to-end-protection-e2e (no page yet)
• Navigation function — estimates position and builds the lateral path — sensor-fusion (no page yet), Extended Kalman filter, Geodesic distance, leg-based-path-construction (no page yet), pure-pursuit-path-tracking (no page yet), Runge-Kutta 4
• Cockpit display — draws what the crew sees — retained-mode-ui-tree (no page yet), gpu-vector-rendering (no page yet)
• Assurance — the evidence that the above is safe — Safety-critical coding standards, Code coverage instrumentation, Model checking and formal proof, Fault tree analysis

 sensors (IRS, GPS, air data) ──AFDX / ARINC 429──┐
                                                  ▼
 ┌────────────── IMA cabinet (one or several, dual-redundant) ─────────────┐
 │ module: CPU + MMU + timer                                               │
 │  ┌ partition: nav / FMS ─┐ ┌ partition: display ─┐ ┌ partition: other ─┐│
 │  │ fusion, EKF, legs     │ │ widget tree, draw   │ │ …                 ││
 │  └──── ports (sampling, queuing) ───┴──────────────┴───────────────────┘│
 │  partitioning kernel: major frame = [win A][win B][win C]… (repeats)    │
 │  health monitor ◄── faults, watchdog ──► restart / switch to standby    │
 └───────────────▲──────────────────────────────────────┬──────────────────┘
                 │ virtual links (BAG + max frame size) │
                 └──────────── AFDX switches ◄──────────┘

How the parts fit together

Partitioned kernel

The kernel gives each partition spatial isolation (its own address space, enforced by the MMU, see Virtual memory and the TLB) and temporal isolation (a fixed execution window inside a repeating major frame). The window schedule is static, set at configuration time, which keeps execution deterministic (SYSGO's ARINC 653 overview). The window table is a time-triggered schedule (time-triggered-scheduling, no page yet); inside a window the partition's own processes are scheduled by priority with preemption (Preemptive priority scheduling). The two levels are why a runaway partition loses only its own window, which a single priority scheduler across all applications could not guarantee.

Switching between windows is a Context switching step that also swaps the memory map and flushes or tags TLB entries; its cost is paid at every window boundary, so windows are sized to amortise it. Interrupt handling is the awkward part: a device interrupt must not run another partition's code during your window. Kernels either keep interrupt handlers minimal (they record and defer) or route the work to the partition that owns the device in its next window.

Partitions exchange data over ports. ARINC 653 names two kinds, sampling (latest value wins, for periodic state) and queuing (ordered messages, for events) (SYSGO overview). Communication is declared in configuration, never discovered at run time, so the platform can check bandwidth and memory before the aircraft flies.

Health and recovery

The standard also covers health monitoring: failures are detected and handled at process, partition or module level so they do not cascade (SYSGO overview). A Watchdog timer catches a partition that stops making progress; a fault handler then applies a configured action such as restarting the partition or the module. fault-detection-isolation-recovery (no page yet) names the whole loop. The FAA circular asks IMA systems to restart any hosted function whose continued operation the safety assessment requires, preferably automatically so that crew-initiated recovery is not needed (AC 20-170, ch. 6).

For functions that must keep running, the cabinet pair is redundant. Hot-standby redundancy keeps a second channel with current state so a switch-over loses no more than one frame. Where three channels compute the same value, redundancy-voting (no page yet) masks a single wrong one; a safety-monitor-architecture (no page yet) places a simple independent checker beside a complex function so a wrong output is blocked rather than trusted. These choices come out of Fault tree analysis: each top event (loss of function, misleading data) is traced to the failures that cause it, which shows where redundancy or a monitor is required.

Deterministic network and data integrity

AFDX is full-duplex switched Ethernet with static routing tables, two redundant links, and traffic regulated at the sender by virtual links (Gutiérrez et al.). Each virtual link has a largest frame size and a bandwidth allocation gap (BAG): a power of two between 1 and 128 ms, the minimum interval between frames on that link. A sender may emit a frame only when its allowance permits, which is the same rate-limiting idea as a Token bucket, and switches police the same contract. Because every flow has a known maximum rate, worst-case latency and jitter can be calculated, which is the proof an authority wants. The cost is that unused bandwidth stays reserved.

end-to-end-protection-e2e (no page yet) wraps safety data (a counter, a checksum, sometimes a timeout) so that a receiver detects loss, repetition, reordering or corruption introduced anywhere between application and application, including inside the partitioning kernel or switches. It sits above the network because the network is not the only thing that can fail.

Navigation function

The navigation function runs in its own partition. sensor-fusion (no page yet) combines inertial, satellite and air-data inputs; the workhorse is an Extended Kalman filter that propagates the state with the inertial model and corrects it with each measurement, with Runge-Kutta 4 as a typical integrator for the propagation step. PX4 and ArduPilot, open autopilots, use the same filter family for their state estimators (PX4 EKF2 guide; ArduPilot EKF overview).

Given a position, the flight plan is turned into a path. Procedures are coded as legs, such as "track to a fix" or "constant-radius arc to a fix"; leg-based-path-construction (no page yet) joins them with turn transitions into one lateral path, using Geodesic distance for distances and bearings along the ellipsoid. pure-pursuit-path-tracking (no page yet) then turns "where am I against the path" into a roll or heading command for the autopilot. The contract with the platform is only its inputs and outputs: it reads sampling ports at a fixed rate and writes its command, so it can be tested on a desktop with the same data.

Cockpit display

The display partition draws the crew's view. A retained-mode scene tree (retained-mode-ui-tree, no page yet) lets the display application change a widget's data while a separate renderer owns drawing, which also fits partitioning: the application and the renderer are separate parties talking over defined messages. gpu-vector-rendering (no page yet) draws maps, symbols and text from vector data on a GPU. Display integrity (the pixels must match the data) is a safety property, so monitors compare rendered output.

Assurance

All of the above is built to the airborne software standard of the day (DO-178 series, cited by AC 20-170 as DO-178B at its publication). Safety-critical coding standards restrict the language to analysable constructs; Code coverage instrumentation shows the tests exercised the code to the required depth; Model checking and formal proof proves properties of the scheduler or protocol that tests cannot reach. Because IMA components come from many suppliers, DO-297 and the AC define incremental acceptance: a module, platform or application is accepted once and later reused, so adding one application does not reopen the whole cabinet (AC 20-170, ch. 2).

Data and control flow

One navigation update through the cabinet:

1. The inertial and satellite units send data frames over their virtual links, one frame per BAG at most, to both redundant network planes.
2. The network driver in the nav partition's window delivers the first valid copy of each frame to a sampling port; the E2E check rejects stale or corrupted data.
3. In its window the nav partition fuses the new measurements, propagates the filter state, and updates the estimated position and uncertainty. If a sensor is flagged invalid, it drops out of the fusion.
4. The path logic compares the position with the active leg and writes a steering command and the next-waypoint data to its output ports.
5. The kernel moves port data between partitions at window boundaries; the display partition reads the position and the path in its next window and redraws.
6. A monitor compares the two cabinet channels; on disagreement the safety logic selects the channel flagged healthy.

One fault, one recovery:

1. A partition misses its progress report; the watchdog expires at the end of its window.
2. The health monitor classifies the fault and looks up the configured action for that partition.
3. The kernel restarts the partition in a defined mode and re-initialises its ports; other partitions keep their windows and never see a pause.
4. If restart fails or the fault is module-level, the standby channel takes over and a maintenance message is raised.

Scaling

1. Schedule capacity. Time in the major frame is the scarce resource. Levers: shorten window overheads, move rarely needed work to a slower rate, give a function more windows, add a core or a second module.
2. Network bandwidth. Virtual links reserve bandwidth, so the sum of maximum rates bounds the link. Levers: larger BAG for slow data, merge related messages into one frame, add switches or cabinets.
3. Latency. The worst case is the sum of waiting for a window, the virtual-link gap and the switch queues. Levers: align producer and consumer windows, choose a shorter major frame, shorten BAGs on critical links.
4. Certification effort. Often the real limit. Levers: incremental acceptance, reuse of accepted modules, and keeping each function small enough to test to coverage.

Failure modes

Real implementations

Sources

• FAA Advisory Circular 20-170, Integrated Modular Avionics Development, Verification, Integration, and Approval using RTCA/DO-297 and TSO-C153 (with change 1): definitions of IMA, platform, robust partitioning, incremental acceptance; restart features (ch. 6). FAA
• J. J. Gutiérrez, J. C. Palencia, M. González Harbour, Response time analysis in AFDX networks: virtual links, BAG, redundancy and determinism of ARINC 664 Part 7. paper
• SYSGO, ARINC and ARINC 653 in embedded software: APEX, fixed windows in a major frame, ports, health monitoring. article
• Xen source, xen/common/sched/arinc653.c: ARINC 653 compatible scheduler. source
• PX4 Guide, Using PX4's Navigation Filter (EKF2). docs
• ArduPilot Copter docs, Extended Kalman Filter (EKF). docs
• NASA cFS repository README. repo