The following describes the verification and validation plan and the structure of the documentation for a MOBA development according to functional safety.
For all verification and validation activities, the described methods are used at MOBA.
checks wether a product or parts of a product meet the specified requirements and are implemented correctly according to the applicable guidelines and standards.
Veritas can be translated as Truth.
checks wether the set requirements and their correct implementation also fullfill the intended benefit required in the specifications.
Validus can be translated as Effectiveness.
Done the right thing?
The MOBA product development process follows the V-model withe the associated documentation guide, decribed in my last post "The MOBA development process"
Requirements for the listed documents
All documents contain a creation date or a version number. The author of the document is named on the title page.
For documents, which require a review, the reviewer is name on the title page.
All documents contain a history of revisions and additions.
There is always a concept phase to start the development
In the concept phase of each development project, a risk analysis (system FMEA) and a functional safety concept are created based on the requirements specification.
The content of the safety concept are a grey box of the product/system being developed, the definition of the safety function and a module FMEA.
Furthermore, all safety parameters required by 13849 (CCF, MTTFd, DC) are calculated and the measures for controlling and avoiding systematic errors are considered.
An important part of the development is beside the specification also the verification and the validation
Verification measures for the software, hardware and mechanics
The unit test is used to check the individual software functions, hardware modules or mechanical components for compliance with the specification, functional correctness, compliance with standards/rules, comprehensibility and verifiability
All software functions involved in the safety function are tested by an automated unit test.
For very simple software functions, or if an automated unit test is not possible, the software function is reviewed by an independent software developer.
The schematic is broken down in individual function blocks and a hardware description is created.
The hardware description and the schematic are checked by an independent hardware developer for functionality and required component limits.
The mechanical components involved in the safety function are designed and finally checked by an independent mechanical developer.
Integration- and System Test
After merging hardware, software and mechanics, integrated software functions are tested on the target hardware for functional correctness and all measures from the module FMEA are checked.
Finally, a complete system test is performed with all components and, in addition to the required functionality, compliance with the safety function is also checked.
All qualification measures required in the requirements specification are carried out either internally or in external test laboratories and documented in corresponding protocol templates.
For all tests, the tested hardware and software version must be noted in the test protocol.
Validation of the Requirements Specification
All requirements from the Requirements Specification are marked with unique IDs.
Validation is performed in 3 steps.
Release of the Requirements Specification
Release of the prototype
Completion of the development project
When all these verification and validation measures have been successfully performed, it is possible to ensure that the requirements from the specification have been fully and correctly implemented.