Testing and investigation for safety-critical software
Midair keeps the evidence for one change in one place: the requirement it checks, the code findings, the test runs with expected verdicts and the logs from the device.
Your safety process decides what counts as evidence. Midair records it so that a reviewer can trace it.
- Requirement
- REQ-142 · sensor/out_of_range
- Code
- fw c07e5d2 · suite 9b1e04f (pinned)
- Static analysis
- visao.sarif · 0 new findings
- Tests
- 3 of 3 as expected
- Console
- saved · no watched pattern seen
- Delta
- 0 differences from the baseline
- Report
- results.html · results.pdf
Kept as it ran. Never overwritten.
What safety-critical software is.And what its verification must show.
Safety-critical software is software whose failure can injure people, damage equipment or harm the environment. Brake controllers, flight software, railway signalling and infusion pumps are examples.
Safety standards give each function an integrity level and set the verification work for that level. Higher levels ask for more methods, more independence and more evidence.
That evidence must be traceable from a requirement to the code, the tests and their results. It must also be repeatable: another engineer runs the same test on the same configuration and gets the same verdict.
The evidence trail of one change.From requirement to review.
Follow one example change through five stages. Choose a stage to see what happens there and what Midair records.
ChangeAn out-of-range sensor value must put the controller into its safe state.Example
01Requirement
What happens
The requirement says that a sensor value outside 0 to 4095 puts the controller into its safe state within 50 ms. An engineer writes a test for it with three values.
package.xml · sensor/out_of_range<req id="REQ-142"/> param value = 4095, 4096, 65535 trc.xmlexpect PASSED for each value
What Midair records
- The test names REQ-142 in the suite description, so the link sits in the suite repository with its history.
- The expected verdict of each value, written in the suite before the first run.
- Requirements stay in your requirements tool. Midair does not manage them.
02Code analysis
What happens
Visao analyzes the change with the project cross toolchain and a baseline from the main branch. It reports one new finding in the code that scales the raw sensor value.
visao · arm-none-eabi-gcc · baseline main.sarifsensor.c:88:14 error arithm/integer/overflow 1 new finding · visao.sarif
What Midair records
- Each finding with its rule, severity, file, line and the line of source.
- The SARIF report of the analysis and the baseline it was compared with.
- With the MISRA C:2012 profile, a compliance summary that names the rules it did not check.
03Test runs
What happens
The suite runs on the bench. Run 318 fails for the value 65535. After the code change, run 321 gives the expected verdict for all three values.
run 318 · fw a41f2c9 · bench-2value=4095 PASSED expected PASSED value=4096 PASSED expected PASSED value=65535 FAILED expected PASSED run 321 · fw c07e5d2 · bench-23 of 3 as expected
What Midair records
- Each start as a new record with its own configuration. Midair never writes over a run.
- For each test: the obtained verdict next to the expected one, the parameters, the error lines and the printouts.
- The exact commits of the suite and of the code under test, pinned in
builder.conf.lock.
04Runtime evidence
What happens
During each run, a host next to the controller saves its serial console. After the run, Delta compares the device with its baseline.
console · run 318sensor: raw=65535 scaled=-3 state: RUN console · run 321sensor: raw=65535 out of range state: SAFE after 12 ms delta · baseline golden.json0 differences · exit 0
What Midair records
- The serial console in the run log. Test Environment watches it for patterns such as a kernel panic and tells the running test.
- Delta's differences from the baseline: processes, ports, files and binaries, as JSON with an exit code.
05Review
What happens
A reviewer opens run 321 in Midair and reads the result tree, the failures list and the log of each test. The review decision stays in your own process.
te-doc report --log run321.xml --name resultsresults.html results.pdf sensor/out_of_range · 3 of 3 as expected
What Midair records
- A results report of the run and a catalogue of the suite, in HTML and PDF, made by te-doc.
- The run as it happened. The review reads the same record the test wrote.
- If you use Bublik, the run published next to earlier runs.
Standards and evidence.What Midair can feed, and what it cannot do.
Each standard sets its own lifecycle, integrity levels and evidence. Choose one to see the kind of verification evidence it asks for and which Midair records can feed it.
ISO 26262 Road vehicles
- Asks for
- ISO 26262 covers the functional safety of electrical and electronic systems in road vehicles. For software, it asks for verification and testing at unit, integration and software level, with methods chosen by ASIL, and for recorded results. A separate part covers confidence in software tools.
- Midair records that can feed it
- Test runs with expected and obtained verdicts, pinned configurations, static analysis findings with rule IDs and MISRA C:2012 summaries.
IEC 61508 Programmable safety systems
- Asks for
- IEC 61508 is the general functional safety standard that several sector standards build on. Its software part asks for verification at each lifecycle phase, with techniques recommended per SIL. It also classifies the tools used to build and verify the software.
- Midair records that can feed it
- Static analysis findings, test records with their configuration and console logs from the target.
DO-178C Airborne software
- Asks for
- DO-178C sets verification objectives for each software level, from A to E. It asks for reviews, analyses and tests of requirements, design and code, for structural coverage analysis and for records of the results. Tool qualification follows DO-330.
- Midair records that can feed it
- Requirement-based test results linked to requirement IDs in the suite, with pinned commits. Structural coverage needs a separate tool.
EN 50128 Railway control and protection
- Asks for
- EN 50128 sets software safety integrity levels from SIL 0 to SIL 4. It asks for verification and test plans, test reports, and more independence between roles at higher levels. EN 50716 (2023) replaces it, and many running projects still use it.
- Midair records that can feed it
- Test reports made by te-doc, run records that nobody overwrites and static analysis reports.
IEC 62304 Medical device software
- Asks for
- IEC 62304 sorts software into safety classes A, B and C. It asks for unit verification, integration and system testing with recorded results, and for a problem resolution process. Class C asks for the most.
- Midair records that can feed it
- Integration and system test runs with recorded verdicts, the configuration of each run and a failures list for your problem reports.
Midair does not certify or qualify anything.
Midair is not a qualified tool under any of these standards, and Visao has no tool qualification kit. Your safety plan and your assessor decide what counts as evidence. Midair keeps technical records that you can bring to that process.
Related pages.Capabilities and research.
Questions.Short answers.
What is safety-critical software?
Safety-critical software is software whose failure can injure people, damage equipment or harm the environment. Standards such as ISO 26262, IEC 61508, DO-178C, EN 50128 and IEC 62304 set how it is developed and verified.
Does Midair certify software or count as a qualified tool?
No. Midair does not certify or qualify anything, and Visao has no tool qualification kit. Midair records verification evidence. Your safety process and your assessor decide how to use it.
How does a test link to a requirement?
A Test Environment test can name requirement IDs in the suite description. The requirements themselves stay in your requirements tool.
Can we show that a run was not changed afterwards?
Midair stores every start as a new record with its own configuration and never writes over a run. builder.conf.lock pins the exact commits of the suite and the code under test.
Is MISRA support the same as functional safety certification?
No. MISRA is a set of coding guidelines. Functional safety standards ask for a whole lifecycle, process and evidence. A tool can check MISRA rules without giving you qualification material.
Can the evidence stay on our own servers?
Yes. The Business plan includes self-hosted Midair instances. Visao has no network client and sends nothing from a run.
Start with one requirement.Then follow its evidence trail.
Compare the plans on the pricing page. Prices are monthly, in euros.
Start your pilot