Safety & Mission-Critical V&V
Verification for systems where the cost of being wrong is not measured in downtime.
At the higher assurance levels the standards stop suggesting independence and start requiring it. DO-178C expects verification independence for the objectives that carry the most weight; ISO 26262 asks for it by ASIL; EN 50716 by SIL. The question is rarely whether someone reviews the work. It is whether the reviewer is independent in a way the authority will accept.
We have no delivery arm, no products inside your supply chain and no revenue that depends on your program being approved. That is the difference between a second opinion and independent verification.
Four activities, run on their own or as a continuous engagement alongside the program.
Every requirement traced to its source and to the test that demonstrates it. Ambiguity found at requirement level costs a fraction of what the same ambiguity costs at integration.
Verification against the objectives your assurance level carries, including the structural coverage your tests never reach and the justification for whatever remains uncovered.
Tests designed and run by people outside the delivery organization, against the requirement as written rather than as remembered.
Artifacts assembled, traced and defended in the form the certification or qualification authority will ask for, not in the form your tooling happens to produce.
DO-178C / ED-12C for software, DO-254 / ED-80 for complex electronic hardware, and DO-330 for the tools the process depends on.
ARP4754B for development assurance and ARP4761A for safety assessment — where most of the argument is actually decided.
ISO 26262 at the ASIL the function carries, with ISO 21448 where the hazard is the intended behavior rather than a fault.
EN 50716 for software and EN 50129 for safety-related electronic systems, read together with CLC/TS 50701 for cybersecurity.
IEC 62304 for the software lifecycle and ISO 14971 for the risk controls that lifecycle has to implement.
DO-326A / ED-202A and EASA Part-IS in aviation, ISO/SAE 21434 in automotive, IEC 62443 in industrial control.
Described by what the systems had to do and at what level, rather than by client name.
Systems taken from requirements through to certification evidence at the higher design assurance levels, with the hardware verified alongside the software that runs on it.
Safety-related software and electronic systems at the integrity levels where an assessor is part of the process.
Device software in classes where a notified body reads the technical file rather than taking it on trust.
Defense and public programs where the acceptance decision sat with an authority rather than with the supplier.