What is “verification” in the context of DO-254 (Avionics) programs?
Every engineer knows that today’s designs are very complex and “testing” them usually involves simulation.
Verification and Validation
First, the term “verification” must be understood alongside the synergistic term “validation.” Next, in a DO-254 context, verification spans a wider scope than it does traditionally, so understanding this is crucial. Also, while “advanced verification” is required for the more safety-critical designs, it might not mean what you think it means. Add to this DO-254 terms and concepts like requirements-based testing, elemental analysis, robustness testing, target testing, and independence, and suddenly the realm of verification might feel quite foreign. If DO-254 verification is on your horizon, keep reading to understand the scope, expectations, and nuances of DO-254 verification.
One of the first clarifications you need when under-standing “verification” in the scope of DO-254, is how verification and validation are both intricately synergistic and yet subtly different. RTCA/DO-254 defines validation as “The process of determining that the requirements are the correct requirements and that they are complete” and defines verification as “The evaluation of an implementation of requirements to determine that they have been met.” In simple terms, validation ensures the item is correctly defined while verification ensures the item operates as per its (validated) definition. Together, validation and verification (referred to as V&V) ensure the hardware item is what it is supposed to be and does what it should do.
Verification Objectives & Activities
The next step in understanding verification (and how it is distinct from, yet related to, validation) is to under-stand the DO-254 objectives related to V&V. DO-254 Section 6.0 covers the “Validation and Verification Process”, which is a supporting process (meaning it occurs throughout and alongside the development life cycle, as opposed to being its own unique development phase). The primary objectives of validation are to ensure the hardware requirements are correct and complete, and to evaluate their impact on safety. (To muddy the waters, these objectives are often met via reviews, analysis or test, which are considered to be verification activities). The primary objectives of verification are to provide evidence (usually achieved through reviews, analysis and/or test) that the hardware implementation meets the (validated) requirements, and that the requirements are traceable to their implementation as well as the tests and results that demonstrate compliance.
The activities that formally roll up under verification to meet the primary objectives include identifying the requirements that must be verified, identifying one or more methods of verification (usually reviews, analysis or test) for each, holding the reviews and/or analysis, creating and performing the tests (and/or simulations), establishing traceability between all these elements, and ensuring that every requirement has been sufficiently covered. Of course, all of this needs to be documented and reviewed (which is another facet of verification).