What shipping software on an LRU actually changes

Most software development rests on a set of assumptions so common that nobody states them: you can ship a fix tomorrow, the hardware will get faster, and if something goes wrong the user can reload. Build an application that installs into an aircraft as a line-replaceable unit and all three disappear at once.

An LRU is a module designed to be swapped out on the flight line rather than repaired in place. For a cabin display, that means the software ships with the airframe. It boots when the aircraft powers up, runs for the service life of the installation, and has no app store standing behind it.

The update channel is not a channel

The habit that takes longest to unlearn is treating “we can patch it” as an engineering strategy. A great deal of modern practice is quietly downstream of cheap deployment: ship the 90% case, watch the error tracker, iterate. That loop does not exist here. Getting new software onto an installed unit is a maintenance event with paperwork attached, scheduled against aircraft availability rather than sprint boundaries.

So the cost curve inverts. Work that feels excessive in a web application — exhaustive failure-mode analysis, defensive handling of every input and state, testing built around how the hardware actually behaves rather than how an emulator does — becomes the cheap option, because the alternative is not a hotfix. It is a truck.

Fixed hardware is a design input, not a constraint to route around

You do not get to assume next year's chipset. The unit you target is the unit that will be in the aircraft for the life of the installation, and its memory and compute budget are what they are. That changes decisions you would normally make on autopilot:

• Memory is a budget, not a resource. Steady-state footprint matters more than peak allocation speed. A slow leak that a server process would never notice before its next deploy will surface on a unit that has been powered for months.
• Rendering has to be deterministic. Frame timing that varies with content is a defect, not a performance characteristic. The display is part of the cabin, and cabins do not stutter.
• Dependencies are liabilities you cannot drop later. Every library is code you are committing to support for the installation lifetime, without the option of a major-version bump next quarter.

Boot-to-ready is the headline number

There is no “refresh the page.” The display must come up ready, every power cycle, and stay responsive for the full duration of every flight. That makes the boot sequence a first-class piece of engineering rather than an afterthought: what initialises in what order, what happens when a dependency is not there yet, and what the unit shows while it is still coming up.

The useful discipline is to enumerate every state the unit can reach and decide, deliberately, what it does in each one. Not the states you expect. Every state. Power interrupted mid-write. A peripheral that answers late. A configuration that is valid but unusual.

A phone app can ask the user to try again. A display bolted into the aircraft cannot. Every state the unit can reach is a state we designed for.

Fleet consistency is the real acceptance criterion

A web application can behave slightly differently across browsers and nobody dies of it. An LRU cannot behave differently unit to unit. Two aircraft off the same line must present identical behaviour, because crews are trained once and the training has to hold across the fleet.

Practically, that means eliminating sources of environmental variance that most codebases tolerate happily: timing assumptions, locale-derived formatting, anything that reads differently depending on what the unit was doing five minutes ago. Determinism is the feature.

Why this travels

None of this is exotic once you have done it, and very little of it is actually specific to aircraft. Enumerate your states. Treat memory as a budget. Assume you cannot patch it. Make behaviour reproducible rather than merely correct on the happy path.

We apply the same discipline to systems that could be patched tomorrow, on the theory that the ones which never need it are cheaper to run. On embedded aviation hardware, “it usually works”isn't a spec. It is a defect. That turns out to be a good standard for software that never leaves the ground, too.