Verification and Validation of Control Software
Control software must be shown correct before it commands a machine; verification checks the code, validation checks it against reality.
Two distinct questions
Verification asks: does the software correctly implement its specification? Validation asks: does the specification, once implemented, produce the right behavior on the real system? Both are needed. Correct code implementing a wrong control law is verified but not valid; a good control law with a coding bug is valid in design but fails in verification.
Verification methods
- Code review and coding standards that keep control code simple
- Unit tests of each function against expected outputs
- Static analysis to catch overflow, timing, and memory faults
- Bounded-execution proofs that loops meet their deadlines
Validation methods
Validation uses the flight simulator and hardware-in-the-loop testing to run the software against a model of the machine, then against the machine itself during commissioning. A control design is validated when it produces the intended plasma behavior across the operating range and handles the fault scenarios in the exception matrix.
Why simplicity is a virtue
Safety-critical control code is kept deliberately simple because simple code is easier to verify. Complex, clever algorithms may perform better on average but are harder to prove correct and harder to trust in the rare fault conditions where correctness matters most. The fastest protection loops favor analyzable simplicity over sophistication.
In the Kronos program
Kronos verifies and validates the control software for the Hyperion breeder and the burner generators against their reduced models and exception matrices in the flight simulator before any hardware exists. Because construction begins in the second quarter of 2027, this pre-hardware validation carries much of the burden, and on-machine commissioning confirms the remaining model-versus-reality differences.