Flight Software
Configuration, autonomy and failure behaviour treated as engineering artefacts: versioned, reviewable and testable before they fly.
Configuration and build provenance
Operators running PX4 or ArduPilot across several airframe types need to know which firmware and parameter set is on which aircraft, and to prove the build flying today is the build that was tested.
Parameters live in spreadsheets and operator memory. A tuning change made on a customer's flight line rarely returns to the baseline. After an incident, reconstructing the exact airborne configuration is often impossible, which is when it matters most.
Configuration as versioned data rather than files. Every parameter set is signed against a firmware hash and airframe identity, differences between any two aircraft render side by side, and field changes sync back on reconnection.
A fleet of fourteen aircraft where three had silently diverged from baseline tuning after field servicing, surfaced by routine comparison rather than by an incident.
Autonomy and mission behaviour
Search patterns, contingency behaviour, payload triggering and geofence responses have to be authored, reviewed and tested as engineering artefacts.
Autonomy behaviour is usually expressed as flight-controller parameters and scattered scripts. It cannot be reviewed by anyone who is not already an expert in that stack, cannot be diffed between revisions, and cannot be tested except by flying it.
Behaviours are authored as explicit state machines with declared transitions and preconditions, versioned like code and reviewable by an engineer who does not know the underlying autopilot. Each compiles to the target stack and runs unchanged inside Crosswind.
A BVLOS corridor operation where link-loss behaviour was validated across four hundred simulated failure points, including timing windows flight testing would be unlikely to reach.
Fault detection, isolation and recovery
Aircraft must detect faults, decide what they mean and act, with reasoning demonstrable to a regulator.
Failsafe logic accretes. A response is added after each incident until nobody can state what the aircraft will do given two simultaneous faults. Interaction between failsafes is rarely analysed and almost never tested.
An explicit fault tree with detection, isolation and recovery as separate declared stages. Combinations are enumerated automatically and exercised in simulation, and the analysis exports in a form suited to a safety case.
A fault interaction study that found GPS-degraded plus low-battery triggering two responses that opposed each other, a case with no incident history precisely because it had never been flown.
Tell us what you are flying and where the programme is losing time. We will tell you honestly which of these helps and which does not.