The project coordinator
Project map
Russian version
English version
Write the mail
Validation and Verification

Up-to-date design process of avionics/Supporting processes/Validation and Verification/

On-board equipment development process consists of mutually reinforcing planning/design/integration and verification/validation/certification stages. Each development stage is a part of on-board equipment (OBE) development process. The result of this process is a transition product (technical documentation, SW-HW OBE components and others). These products are input variables for the corresponding verification stage and further development stages at corresponding OBE development levels.

OBE validation process means compliance completeness assessment of developed on-board equipment (OBE) and its functional purpose. Requirements and assumptions validation represents process that guarantees their correctness and completeness providing compliance with the airworthiness standards. The validation process supports the development of requirements, which are determined by the need to perform functional tasks and safety.

Because of OBE development process complexity validation is held as multilevel process performed at all lifecycle stages including operation. At every stage of validation the increasing confidence in requirements correctness and completeness shall be provided.
Fig. 3.8. Validation process model.
Fig. 3.8. Validation process model.

Validation process goal is to check requirements correctness and completeness.

Also validation goal is to prevent abundant functions in systems that are being developed and in associated systems.

Validation and system design process interrelation is shown at fig. 3.8. Validation process input data may include system description (including expected operation conditions), system requirements, system architecture description and DAL. Methods used for system requirements and assumptions validation shall be set in the validation plan.

Required validation level is set by the DAL of the function to which the requirement is applied. >>>
>>>  Requirements correctness and completeness inspection may require peer review, analysis or test conduction. There are assumptions which correctness cannot be proven directly in the moment of their implementation in the most of design programs. In assumption validation process it shall be proven that assumptions are accurately represented, properly divided and assessed using submitted data. Assumptions must be identified and their reasonableness must be shown relating to the certain system and its DAL.

Validation process may be managed and controlled through the validation matrix. Requirements and validation results including HW, SW characteristics, derived requirements, external/operational conditions, assumptions and supporting data are used for the validation matrix arrangement. Each requirement source shall be specified. This matrix shall be updated during the development and its final form shall be put into the summarized report.

Validation summarized report (summary) shall guarantee that validation was held in proper way.

The following methods are used for validation process support: requirements traceability, analysis, modeling, tests, similarity analysis and peer review. Validation methods and data are chosen depending on the DAL (A — E). During some certain requirements validation you may use one method for correction assessment and for completeness inspection — another.

Requirements validation plan shall be implemented through the whole design process.

On-board equipment verification: it means actions assemblage (analysis, demonstration modeling and tests) aimed at the assessment and demonstration of OBE compliance to the functional, operation and certification requirements.

During OBE verification:
  • It’s confirmed that provided AC OBE functions are correctly implemented by components (systems, equipment);

  • It’s guaranteed that OBE safety requirements cumulatively and its components requirements are performed. >>>
Fig. 3.9. OBE specifications and benches equipment interrelation.
Fig. 3.9. OBE specifications and benches equipment interrelation.
>>>  AC system and equipment verification work depends on assigned DAL based on failsafe assessment (FHA, PASA and PSSA). OBE verification process is implemented by three level actions (fig. 3.9):
  • Aircraft Developer/OBE Integrator level — OBE requirements implementation is assessed cumulatively. Tests are carried out at the AC and at the Developer’s test facility under Developer’s management.

  • OBE system developer (supplier) level — system requirements implementation is assessed. Tests are carried out at the System Supplier’s development and test autonomous benches and at the integration OBE bench (under Integrator’s management).

  • Component developer level — each requirement to components implementation is assessed. Tests are carried out at the autonomous development and test benches for SW of applications (IMA platform functions) and autonomous development and test benches for HW and SW that are included into IMA under the components Developers’ management.
At each level of responsibility planning actions, requirements implementation verification (of proper level) and output data preparation shall be provided. Also certification, qualification tests of HW and systems (verification plans) programs shall be developed.

On-board equipment verification process goals are aimed at showing onboard equipment compliance to project requirements. >>>
>>>  Number of peer reviews and their transition criteria are stated by Aircraft Developer together with components Supplier in the boundaries of the certain project.

Aircraft Developer plans verification actions for the integrated OBE. Verification is performed at different levels.

System Developer is responsible for system verification. You have to put information regarding parties’ responsibilities in the corresponding system verification plan. System composition review at the aircraft is the system Developer responsibility.

HW verification is the HW Supplier responsibility. The HW Supplier shall provide the proper evidence for its product attestation and review.

SW verification process is carried out in compliance with KT-178C (part 6). It includes input data preparation for verification process (system requirements, SW LL and HL requirements, traceability data, source code, executable object code and SW verification plan), verification actions and also input data development (tests variants, tests procedures, requirements coverage analysis, structural coverage analysis, SW test results).

HW verification process is carried out in compliance with KT-254 requirements (part 6.2). Verification process actions shall be carried out in compliance with HW verification plan.

IMA system verification is carried out in the boundaries of system verification process and in compliance with IMA system v&v plan. Structure and content shall answer requirements of AR IAC R-297. IMA system verification process is compliance review of IMA system assigned requirements implementation. Main goal of IMA system verification process is to check that all level requirements are implemented correctly and completely and that verification methods used for this goal are correct. >>>
>>>  Aircraft integrated on-board equipment proof of requirements compliance is achieved by the following verification methods combination:
Fig. 3.10. OBE specifications and tests procedures.
Fig. 3.10. OBE specifications and tests procedures.

  • peer review;

  • analysis;

  • modeling;

  • requirements coverage analysis;

  • tests;

  • operation experience.
At every verification level requirements coverage analysis is carried out to determine level of requirements coverage in tests. Verification matrix and proper levels verification results are used for this analysis.

At fig. 3.10 you can see interrelation between OBE requirements and tests procedures for correctness of these requirements implementation.

The following data shall be formed at each verification level:
  1. system and OBE equipment verification plan (shall be developed in accordance with R-4754A, R-297, KT-254 and KT-178C);

  2. procedures and verification results;

  3. verification matrixes;

  4. verification summary. >>>
Fig. 3.11. Generic structure of OBE bench base.
Fig. 3.11. Generic structure of OBE bench base.
>>>  OBE bench base shall include bench system with unified HW-SW platform and open architecture based on unique general purpose COTS-components. Bench content shall comply with development technology, validation and verification of OBE SW and HW. Generic structure is shown at fig. 3.11.

The following principles shall be put at the basis of benches experimental capabilities:
  • open architecture;

  • SW/HW modularity;

  • SW/HW unification;

  • benches all levels components technological and structural compatibility;

  • benches protocols and interfaces informational compatibility;

  • benches unified component base;

  • wide-spread and approbated OS, programming languages and systems implementation;

  • implementation of standard, well-developed interfaces adopted as world standards for avionics devices commutation.
Search on the project
© 2021 State Research Institute of Aviation Systems. All rights reserved. Terms of Use.