Simulation should reduce uncertainty
A useful simulator is not a polished animation. It is an inspectable engineering environment with known interfaces, repeatable initial conditions, measurable timing, and logs that allow a result to be challenged.
For autonomous aviation, this matters because failures often appear between components: coordinate frames, sensor timing, vehicle configuration, networking, operator commands, and recovery behavior. These interactions are expensive and sometimes unsafe to discover first in real flight.
Validation needs layers
I prefer a progression from unit tests and deterministic software checks, through software-in-the-loop scenarios, to hardware-aware integration and supervised field tests. Each layer should have an explicit question and acceptance criteria.
The goal is not to prove that a system can never fail. The goal is to understand how it fails, whether the operator can recognize the state, and whether the system moves toward a controlled outcome.
The operator remains part of the system
Dashboards, alerts, mission tools, and emergency actions deserve the same validation discipline as vehicle algorithms. A technically correct system can still be operationally weak if it hides state, overloads the operator, or makes recovery ambiguous.
That is why my simulation work increasingly connects vehicle dynamics, telemetry, software architecture, logging, and human factors rather than treating them as separate disciplines.