Considerations for Multiple-Version Dissimilar Software Verification

Guidelines follow concerning the software verification process as it applies to multiple-version dissimilar software. If the software verification process is modified because of the use of multiple- version dissimilar software, evidence should be provided that the software verification process objectives are satisfied and that equivalent error detection is achieved for each software version. Multiple, dissimilar versions of the software are produced using combinations of these techniques: • The Source Code is implemented in two or more different programming languages. • The object code is generated using two or more different compilers.

• Each software version of Executable Object Code executes on a separate, dissimilar processor, or on a single processor with the means to provide partitioning between the software versions.

• The software requirements, software design, and/or Source Code are developed by two or more development teams whose interactions are managed.

• The software requirements, software design, and/or Source Code are developed on two or more software development environments, and/or each version is verified using separate test environments.

• The Executable Object Code is linked and loaded using two or more different linkage editors and two or more different loaders.

• The software requirements, software design, and/or Source Code are developed in conformance with two or more different Software Requirements Standards, Software Design Standards, and/or Software Code Standards, respectively.

When multiple versions of software are used, the software verification methods may be modified from those used to verify single version software. They will apply to software development process activities that are multi-thread, such as separate, multiple development teams. The software verification process is dependent on the combined hardware and software architectures since this affects the dissimilarity of the multiple software versions. Additional software verification process objectives to be satisfied are:

a. To demonstrate that the inter-version compatibility requirements are satisfied, including compatibility during normal and abnormal operations and state transitions.

b. To demonstrate that equivalent error detection is achieved.

Other changes in software verification process activities may be agreed with by the certification authority, if the changes are substantiated by rationale that confirms equivalent software verification coverage.

12.3.3.1 Independence of Multiple-Version Dissimilar Software

When multiple-version dissimilar software versions are developed independently using a managed method, the development processes have the potential to reveal certain classes of errors such that verification of each software version is equivalent to independent verification of the software development processes. To realize the advantage of this potential, guidance for independence includes:

a. The applicant should demonstrate that different teams with limited interaction developed each software version’s software requirements, software design and Source Code.

b. Independent test coverage analyses should still be performed as with a single version. 12.3.3.2 Multiple Processor-Related Verification

When each version of dissimilar software executes on a different type of processor, the verification of some aspects of compatibility of the code with the processor (paragraph 6.4.3, item a) may be replaced by verification to ensure that the multiple types of processor produce the correct outputs. This verification consists of integration tests in which the outputs of the multiple versions are cross-compared in requirements-based test cases. The applicant should show that:

a. Equivalent error detection is achieved.

b. Each processor was designed by a different developer. c. The outputs of the multiple versions are equivalent. 12.3.3.3 Multiple-Version Source Code Verification

The guidelines for structural coverage analysis (subparagraph 6.4.4.2) may be modified for airborne systems or equipment using multiple-version dissimilar software. Structural coverage analysis may be performed at the Source Code level even if the object code is not directly traceable to Source Code statements provided that the applicant shows that:

a. Each version of software is coded using a different programming language. b. Each compiler used is from a different developer.

12.3.3.4 Tool Qualification for Multiple-Version Dissimilar Software

If multiple-version dissimilar software is used, the tool qualification process may be modified, if evidence is available that the multiple software development tools are dissimilar. This depends on the demonstration of equivalent software verification process activity in the development of the multiple software versions using dissimilar software development tools. The applicant should show that:

a. Each tool was obtained from a different developer. b. Each tool has a dissimilar design.

12.3.3.5 Multiple Simulators and Verification

If separate, dissimilar simulators are used to verify multiple-version dissimilar software versions, then tool qualification of the simulators may be modified. This depends on the demonstration of equivalent software verification process activity in the simulation of the multiple software versions using multiple simulators. Unless it can be justified as unnecessary, for multiple simulators to be dissimilar, evidence should be available that:

a. Each simulator was developed by a different team.

w

b. Each simulator has different requirements, a different design and a different programming language.

c. Each simulator executes on a different processor.

Note: When a multiple processor system using multiple, dissimilar versions of software are executing on identical processors, it may be difficult to demonstrate dissimilarity of simulators because of the reliance on information obtained from a common source, the processor manufacturer.