FlightLab: building a traceable SITL platform for Kestrel development

Zephyra Dynamics has spent the last development cycle building the tooling layer around our Kestrel X2 flight control stack. That tooling is FlightLab, a simulation engineering application that brings the flight simulation engine, software-in-the-loop testing and our ground control interface into a single, repeatable workflow. This article explains what it does, how it is structured and what it deliberately does not claim to do.

What FlightLab actually is

FlightLab is an orchestration and evidence layer, not a flight controller. Its role is to make the wider simulation environment practical for daily engineering work by coordinating test sessions, defining missions, applying conditions, introducing controlled scenarios, capturing flight data and assembling the results into a reviewable record.

A favourable trajectory or passing result is only one observation. Its value depends on the quality of the model, the definition of the inputs, the completeness of the captured data, repeatability and traceability to a real requirement. FlightLab is designed around that principle. The workflow exists to produce evidence, not simply a demonstration.

How the workflow fits together

FlightLab coordinates the aircraft simulation, flight control environment and ground control interface while keeping their responsibilities separate. Simulated aircraft behaviour and sensor information move through the test environment, while telemetry supports mission review, observation and analysis.

Mission construction, flight monitoring, controlled test scenarios and evidence reporting are handled as distinct parts of the workflow. Connections are established for each session so that a previous setup is not silently treated as the current test configuration. This matters when repeatability is the objective.

Core capabilities

Mission definition. A library of mission presets supports repeatable flight profiles, while custom routes allow engineers to investigate specific operating cases.

Trajectory evaluation. Engineers can compare changes in aircraft response, path tracking and flight smoothness across controlled simulation runs.

Operating conditions. Loading and environmental inputs can be varied, with requested and confirmed conditions recorded separately so an unconfirmed setup is not treated as a successful test.

Controlled scenarios. The platform supports repeatable investigation of selected system and sensor conditions, followed by recorded recovery observations.

Campaign management. Related cases can be organised into persistent test campaigns with their objectives, conditions, repetitions and results kept together.

Analysis and comparison. Flight records can be reviewed against defined criteria and compared with earlier runs to identify changes that need engineering attention.

Evidence management. Each session produces a structured record containing the test context, relevant artifacts and report references so that the work can be reviewed later.

Where we have drawn the line deliberately

Simulation evidence must be interpreted within the limits of the model and the test setup. A successful scenario does not, by itself, establish the behaviour of every physical aircraft system or prove readiness for operation.

A passing recovery test records the outcome of that defined test sequence. It does not, on its own, demonstrate complete autonomous fault detection and response. Claims of that kind require separate tests designed specifically to establish the behaviour without imposing the result.

FlightLab does not establish regulatory compliance, assign development assurance levels or replace formal safety assessment. It produces simulation evidence that can support those processes when suitable model validation, acceptance criteria and independent review are in place.

Why we built it this way

Simulation tooling is easy to over-trust. A polished interface and a passing result can appear to provide more assurance than they actually do. FlightLab is built to resist that tendency by keeping each result connected to a specific test, preserving the context around the run and leaving a record that another engineer can review.

That is the engineering philosophy behind FlightLab. It is a tool for building trustworthy evidence, not a shortcut around the work required to earn that trust.