DO Qualification Kit

Polyspace Code ProverTM

Tool Qualification Plan
R2015b, September 2015

How to Contact MathWorks

Latest news:

www.mathworks.com

Sales and services:

www.mathworks.com/sales_and_services

User community:

www.mathworks.com/matlabcentral

Technical support:

www.mathworks.com/support/contact_us

Phone:

508-647-7000

The MathWorks, Inc.

3 Apple Hill Drive
Natick, MA 01760-2098
DO Qualification Kit: Polyspace Code ProverTM Tool Qualification Plan

COPYRIGHT 20132015 by The MathWorks, Inc.

The software described in this document is furnished under a license agreement. The software may be used or copied only under
the terms of the license agreement. No part of this manual may be photocopied or reproduced in any form without prior written
consent from The MathWorks, Inc.
FEDERAL ACQUISITION: This provision applies to all acquisitions of the Program and Documentation by, for, or through the
federal government of the United States. By accepting delivery of the Program or Documentation, the government hereby agrees
that this software or documentation qualifies as commercial computer software or commercial computer software documentation
as such terms are used or defined in FAR 12.212, DFARS Part 227.72, and DFARS 252.227-7014. Accordingly, the terms and
conditions of this Agreement and only those rights specified in this Agreement, shall pertain to and govern the use, modification,
reproduction, release, performance, display, and disclosure of the Program and Documentation by the federal government (or
other entity acquiring for or through the federal government)and shall supersede any conflicting contractual terms or conditions.
If this License fails to meet the governments needs or is inconsistent in any respect with federal procurement law, the
government agrees to return the Program and Documentation, unused, to The MathWorks, Inc.
Trademarks
MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See www.mathworks.com/trademarks for a
list of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respective
holders.
Patents
MathWorks products are protected by one or more U.S. patents. Please see www.mathworks.com/patents for more
information.

Revision History
September 2013
March 2014
October 2014
March 2015
September 2015

New for Version 2.2 (Applies to Release 2013b)

Revised for Version 2.3 (Applies to Release 2014a)
Revised for Version 2.4 (Applies to Release 2014b)
Revised for Version 2.5 (Applies to Release 2015a)
Revised for DO Qualification Kit Version 3.0 (Applies to Release 2015b)

Contents
1 Introduction ...................................................................................................................................... 1-1
2 Tool Overview and Identification .................................................................................................... 2-1
2.1 Polyspace Code Prover Product Description ........................................................................... 2-2
2.2 Polyspace Code Prover Product Identifier............................................................................... 2-3
3 Tool Operational Requirements ....................................................................................................... 3-1
4 Certification Considerations ............................................................................................................. 4-1
4.1 Requirements for Qualification ............................................................................................... 4-2
4.2 Certification Credit .................................................................................................................. 4-3
Table FM.A-5, OO.A-5, MB.A-5 (2) Source Code Complies with Software Architecture .... 4-5
Table FM.A-5, OO.A-5, MB.A-5 (3) Source Code Is Verifiable ............................................ 4-6
Table FM.A-5, OO.A-5, MB.A-5 (6) Source Code Is Accurate and Consistent ..................... 4-6
Table FM.A-6 (1) Executable Object Code Complies with High-Level Requirements .......... 4-8
Table FM.A-6 (2) Executable Object Code Is Robust with High-Level Requirements .......... 4-9
Table FM.A-6 (3) Executable Object Code Complies with Low-Level Requirements ......... 4-10
Table FM.A-6 (4) Executable Object Code Is Robust with Low-Level Requirements ......... 4-11
Table FM.A-7 (5-8) Verification Coverage of Software Structure is Achieved ................... 4-13
Table FM.A-7 (9) Verification of Property Preservation between Source Code and Object
Code ...................................................................................................................................... 4-13
5 Tool Development Life Cycle Tool Developer ............................................................................. 5-1
6 Tool Development Life Cycle Tool User ...................................................................................... 6-1
6.1 Planning................................................................................................................................... 6-2
6.2 Requirements ........................................................................................................................... 6-3
6.3 Verification ............................................................................................................................. 6-4
7 Additional Considerations ................................................................................................................ 7-1
7.1 Independence ........................................................................................................................... 7-2
7.2 Customer Bug Reporting ......................................................................................................... 7-3
7.3 Protection Mechanisms ........................................................................................................... 7-4
8 Tool Life Cycle Data ........................................................................................................................ 8-1
9 Schedule ........................................................................................................................................... 9-1

vi

1 Introduction
This document is the Tool Qualification Plan (reference DO-330 Section 10.1.2) for the
following capabilities of the Polyspace Code Prover Criteria 2 TQL-4 tool.

Prove absence of certain run-time errors and dead code in C and C++ code
Calculation of range information for variables and function return values
Identification of variables that exceed specified range limits
Identified shared variables and protected variables

1-2

2 Tool Overview and Identification

2.1 Polyspace Code Prover Product Description

Prove the absence of run-time errors in software

Polyspace Code Prover proves the absence of overflow, divide-by-zero, out-of-bounds array
access, and certain other run-time errors in C and C++ source code. It produces results without
requiring program execution, code instrumentation, or test cases. Polyspace Code Prover uses
static analysis and abstract interpretation based on formal methods. You can use it on
handwritten code, generated code, or a combination of the two. Each operation is color-coded to
indicate whether it is free of run-time errors, proven to fail, unreachable, or unproven.
Polyspace Code Prover also displays range information for variables and function return values,
and can prove conditions under which variables exceed specified range limits. Results can be
published to a dashboard to track quality metrics and ensure conformance with software quality
objectives. Polyspace Code Prover can be integrated into build systems for automated
verification.
Key Features

Proven absence of certain run-time errors in C and C++ code

Color-coding of run-time errors directly in code
Calculation of range information for variables and function return values
Identification of conditions under which variables that exceed specified range limits
Quality metrics for tracking conformance with software quality objectives
Web-based dashboard providing code metrics and quality status
Guided review-checking process for classifying results and run-time error status
Graphical display of variable reads and writes

Additionally, you can use Polyspace Code Prover to check coding rules. The coding rules
qualification credit taken for Polyspace Bug Finder applies to Polyspace Code Prover because
both products use the same components.
Given a source program P written in source programming language L, you want to compute
statically (without specific input data) and automatically a conservative model of the future
dynamic, run-time behavior of P. You also want to extract from this model predictions about the
possible occurrences of run-time errors and sources of nondeterminism (for static verification)
as well as data and control flow information.
The present document is derived from the High-Level Specification of Polyspace Code Prover,
and serves as a criterion for functional validation testing.

2-2

2.2 Polyspace Code Prover Product Identifier

Software Tool

Version (Release)

Tool Vendor

Polyspace Code Prover

Version 9.4 (R2015b)

DO Qualification Kit

Version 3.0 (R2015b)

The MathWorks, Inc.

3 Apple Hill Drive
Natick, MA, 01760-2098 USA

2-3

2-4

3 Tool Operational Requirements

The Tool Requirements for the Polyspace Code Prover are defined as the Operational
Requirements (ORs) and Language Specific Requirements (LSRs) in:
Polyspace Code Prover Tool Requirements, R2015b
The Tool Operational Requirements for the Polyspace Code Prover are defined as HLRs in:
Polyspace Code Prover Tool Operational Requirements, R2015b
The Polyspace Code Prover Theoretical Foundation is described in:
Polyspace Code Theoretical Foundation, R2015b
For traceability between the High-Level Requirements (HLRs), Operational Requirements
(ORs) and Language Specific Requirements (LSRs), see:
qualkitdo_codeprover_HLR_OR_LSR_Trace.xlsx
To access the documents, on the MATLAB command line, type qualkitdo to open the
Artifacts Explorer. The reference workflow document is in Polyspace Code Prover.

3-2

4 Certification Considerations
This section describes certification considerations for the Polyspace Code Prover verification
tool.

4.1 Requirements for Qualification

To determine whether a tool must be qualified, you must answer the following questions. If you
answer yes to all three questions, you must qualify the tool.
Question

SDD Report

Can the tool insert an error into the airborne software or fail to detect an
Yes1
existing error in the software within the scope of its intended usage?
Will the output of the tool not be verified as specified in Section 6 of DO-178C, Yes
DO-278A, DO-331, DO-332 or DO-333?
Are processes of DO-178C, DO-278A, DO-331, DO-332 or DO-333
Yes
eliminated, reduced, or automated by the use of the tool? Will you use output
from the tool to meet an objective or replace an objective of DO-178C, DO278A, DO-331, DO-332 or DO-333, Annex A or Annex C?
1 The

Polyspace Code Prover might fail to detect an error.

Given that the answer to all the preceding questions is yes, Polyspace Code Prover must be
qualified.
To determine the qualification type (Criteria 1, Criteria 2, or Criteria 3), you must answer the
following questions about the tool.
Question
1.
2.

Is the tool output part of the airborne software, such that the output can
insert an error into the software?
Could the tool fail to detect an error in the airborne software and is the
tool also used to justify the elimination or reduction of either of the
following:
Verification processes other than that automated by the tool.

SDD Report
No
Yes

Development processes that could have an impact on the airborne

software.
3.

Could the tool fail to detect an error in the airborne software?

Yes

The Polyspace Code Prover will be used to reduce object code verification processes in addition
to automating source code verification processes, thus eliminating a verification process not
automated by the tool. Because the answer to the preceding first question is no and the second
question is yes, it must be qualified as a Criteria 2 tool following the DO-330 tool qualification
process for TQL-4.

4-2

4.2 Certification Credit

The certification credit for the Polyspace Code Prover will depend on the exact usage of the tool
and also the application of the various supplements to DO-178C or DO-278A. Some general
applicability:

Because Polyspace Code Prover is a formal methods tool, as defined in DO-333, that
supplement becomes applicable for Tables FM.A-5, FM.A-6, and FM1-7 objectives.
When using Polyspace Code Prover to verify code developed from a Design Model, as
defined in DO-331, that supplement becomes applicable for Table MB.A-5 objectives.
When using Polyspace Code Prover to verify C++ code that uses object-oriented
techniques, as defined in DO-332, that supplement becomes applicable for Table
OO.A-5 objectives.

The following table lists the certification credit (see DO-331, DO-332, or DO-333 Annex A or
Annex C Objectives) required for the Polyspace Code Prover. The table and section references
are:

DO-331
DO-332
DO-333

MB prefix
OO prefix
FM prefix

Certification Credit for Polyspace Code Prover

Annex A
or C
Table

Objective

DO-331,
DO-332 or
DO-333
Reference

Credit Taken
(in conjunction with other tools)

Table
FM.A-5
MB.C-5
Table
FM.A-5
MB.C-5
Table
FM.A-5
MB.C-5
Table
FM.A-5
MB.C-5
Table
FM.A-5
MB.C-5

(2) Source code complies with

software architecture

FM.6.3.4.a
FM.6.3.4.b

Partial see Table FM.A-5, OO.A-5, MB.A-5 (2)

Source Code Complies with Software Architecture

(3) Source code is verifiable

FM.6.3.4.e
FM.6.3.4.c

Partial see Table FM.A-5, OO.A-5, MB.A-5 (3)

Source Code Is Verifiable

(6) Source code is accurate and FM.6.3.4.b

consistent
FM.6.3.c
FM.6.3.4.f
(10) Formal analysis cases and FM.6.3.6.a
procedures are correct
FM.6.3.6.b

Partial see Table FM.A-5, OO.A-5, MB.A-5 (6)

Source Code Is Accurate and Consistent

(11) Formal analysis results are FM.6.3.6.c

correct and discrepancies
explained

Partial Polyspace Code Prover performs the

analysis but the user must explain discrepancies
found by the analysis

Full this is accomplished as part of the Polyspace

Code Prover tool qualification

4-3

Annex A
or C
Table

Objective

DO-331,
DO-332 or
DO-333
Reference

Table
FM.A-5
MB.C-5
Table
FM.A-5
MB.C-5
Table
FM.A-6
MB.C-6
Table
FM.A-6
MB.C-6
Table
FM.A-6
MB.C-6
Table
FM.A-6
MB.C-6
Table
FM.A-7
MB.C-7
Table
FM.A-7
MB.C-7
Table
FM.A-7
MB.C-7
Table
FM.A-7
MB.C-7
Table
FM.A-7
MB.C-7
Table
OO.A-5
OO.C-5
Table
OO.A-5
OO.C-5
Table
OO.A-5
OO.C-5

(12) Requirements formalization FM.6.3.i

is correct

Full this is accomplished as part of the Polyspace

Code Prover tool qualification

(13) Formal method is correctly

defined, justified, and
appropriate
(1) Executable Object Code
complies with high-level
requirements
(2) Executable Object Code is
robust with high-level
requirements
(3) Executable Object Code
complies with low-level
requirements
(4) Executable Object Code is
robust with low-level
requirements
(1) Formal analysis cases and
procedures are correct

FM.6.2.1

Full this is satisfied by the Polyspace Code

Prover Theoretical Foundation document

FM.6.7.c

Partial see Table FM.A-6 (1) Executable Object

Code Complies with High-Level Requirements

FM.6.7.b
FM.6.7.c

Partial see Table FM.A-6 (2) Executable Object

Code Is Robust with High-Level Requirements

FM.6.7.d
FM.6.7.c

Partial see Table FM.A-6 (3) Executable Object

Code Complies with Low-Level Requirements

FM.6.7.b
FM.6.7.c

Partial see Table FM.A-6 (4) Executable Object

Code Is Robust with Low-Level Requirements

FM.6.7.2.a
FM.6.7.2.b

Full this objective is accomplished as part of the

Polyspace Code Prover tool qualification

(2) Formal analysis results are

correct and discrepancies
explained
(5-8) Verification coverage of
software structure is achieved

FM.6.7.2.c

Partial Polyspace Code Prover performs the

analysis but the user must explain discrepancies
found by the analysis
Partial see Table FM.A-7 (5-8) Verification
Coverage of Software Structure is Achieved

FM.6.7.1.c

Credit Taken
(in conjunction with other tools)

(9) Verification of property

FM.6.3.i
preservation between source
code and object code
(10) Formal method is correctly FM.6.2.1
defined, justified, and
appropriate
(2) Source code complies with OO.6.3.4.b
software architecture

Partial see Table FM.A-7 (9) Verification of

Property Preservation between Source Code and
Object Code
Full this objective is satisfied by the Polyspace
Code Prover Theoretical Foundation document

(3) Source code is verifiable

OO.6.3.4.c

Partial see Table FM.A-5, OO.A-5, MB.A-5 (3)

Source Code Is Verifiable

(6) Source code is accurate and OO.6.3.4.f

consistent

Partial see Table FM.A-5, OO.A-5, MB.A-5 (6)

Source Code Is Accurate and Consistent

Partial see Table FM.A-5, OO.A-5, MB.A-5 (2)

Source Code Complies with Software Architecture

4-4

Annex A
or C
Table

Objective

DO-331,
DO-332 or
DO-333
Reference

Credit Taken
(in conjunction with other tools)

Table
MB.A-5
MB.C-5
Table
MB.A-5
MB.C-5
Table
MB.A-5
MB.C-5

(2) Source code complies with

software architecture

MB.6.3.4.b

Partial see Table FM.A-5, OO.A-5, MB.A-5 (2)

Source Code Complies with Software Architecture

(3) Source code is verifiable

MB.6.3.4.c

Partial see Table FM.A-5, OO.A-5, MB.A-5 (3)

Source Code Is Verifiable

(6) Source code is accurate and MB.6.3.4.f

consistent

Partial see Table FM.A-5, OO.A-5, MB.A-5 (6)

Source Code Is Accurate and Consistent

The following sections describe how the listed objectives can be partially or totally achieved
using Polyspace Code Prover results.

Table FM.A-5, OO.A-5, MB.A-5 (2) Source Code Complies with

Software Architecture
FM.6.3.4.b: Compliance with the software architecture: The objective is to ensure that the
source code matches the data flow and control flow defined in the software architecture. If the
software architecture is formally modeled and the formal source code semantics exist, then
formal analysis can be used to show compliance.
OO.6.3.4.b: Compliance with the software architecture: The objective is to ensure that the
source code matches the data flow, control flow, and class hierarchy defined in the software
architecture.
MB.6.3.4.b: Compliance with the software architecture: The objective is to ensure that the
source code matches the data flow and control flow defined in the software architecture.
Data Flows: Design document should include the input/output description, for example, data
dictionary, both internally and externally, throughout the software architecture.
Polyspace Code Prover is able to prove adherence to this aspect of the standard, as it
automatically builds a global data dictionary and identification of shared data reading and
writing accesses.
Control Flows: Design documents should include data flow and control flow of the design.
Polyspace Code Prover automatically and independently provides the documentation of those
activities.

4-5

Table FM.A-5, OO.A-5, MB.A-5 (3) Source Code Is Verifiable

FM.6.3.4.c: The objective is to ensure that the source code does not contain statements and
structures that cannot be verified and that the code does not have to be altered to verify it. When
source code has mathematically defined syntax and semantics, and is consistent with the formal
analysis defined in the Software Verification Plan, this objective is satisfied.
OO.6.3.4.c: The objective is to ensure that the source code does not contain statements and
structures that cannot be verified and that the code does not have to be altered to test it.
MB.6.3.4.c: The objective is to ensure that the source code does not contain statements and
structures that cannot be verified and that the code does not have to be altered to test it.
Dead code falls under the first part of this objective; that is, statements and structures that cannot
be verified. Polyspace Code Prover helps partially by identifying unreachable code.

Table FM.A-5, OO.A-5, MB.A-5 (6) Source Code Is Accurate and

Consistent
FM.6.3.4.f: Accuracy and consistency: The objective is to determine the correctness and
consistency of the source code, including stack usage, memory usage, fixed-point arithmetic
overflow and resolution, floating-point arithmetic, resource contention and limitations, worstcase execution timing, exception handling, use of uninitialized variables, cache management,
unused variables, and data corruption due to task or interrupt conflicts. The compiler (including
its options), the linker (including its options), and some hardware features may have an impact
on the worst-case execution timing and this impact should be assessed. If mathematically
defined syntax and semantics exist for source code, then these characteristics can be checked
using formal analysis. The mathematically defined syntax and semantics may need to take into
account the programming language standards, compiler information (for example default
behavior and configuration options), and characteristics of the target compiler.
OO.6.3.4.f: Accuracy and consistency: The objective is to determine the correctness and
consistency of the source code, including stack usage, memory usage, fixed-point arithmetic
overflow and resolution, floating-point arithmetic, resource contention and limitations, worstcase execution timing, exception handling, use of uninitialized variables, cache management,
unused variables, and data corruption due to task or interrupt conflicts. The compiler (including
its options), the linker (including its options), and some hardware features may have an impact
on the worst-case execution timing and this impact should be assessed.

4-6

MB.6.3.4.f: Accuracy and consistency: The objective is to determine the correctness and
consistency of the source code, including stack usage, memory usage, fixed-point arithmetic
overflow and resolution, floating-point arithmetic, resource contention and limitations, worstcase execution timing, exception handling, use of uninitialized variables, cache management,
unused variables, and data corruption due to task or interrupt conflicts. The compiler (including
its options), the linker (including its options), and some hardware features may have an impact
on the worst-case execution timing and this impact should be assessed.
Polyspace Code Prover helps to identify exhaustively:

Fixed point arithmetic overflows

Use of uninitialized variables
Use of uninitialized constants
Data corruption due to tasks or interrupts conflicts

Polyspace Code Prover helps to identify partially:

Unused variables
Unused constants
Type consistency issues
Type conversions leading to underflow or overflow

4-7

Table FM.A-6 (1) Executable Object Code Complies with High-Level

Requirements
FM.6.7.a: Compliance with high-level requirements: the objective is to demonstrate the ability
of the software to respond to normal inputs and conditions. Activities for normal range testing
include:

Real and integer input variables should be considered using valid boundary values.
For time-related functions, such as filters, integrators, and delays, multiple iterations of
the code should be performed to check the characteristics of the function in context.
For state transitions, analyses should be developed to consider the transitions possible
during normal operation.
For software requirements expressed by logic equations, the normal range cases should
verify the variable usage and the Boolean operators.

Formal methods can be used to satisfy this objective as described in FM.6.7.f.

Polyspace Code Prover does not assist in the satisfaction of the objective defined in FM.6.7.a.
FM.6.7.c: Verification of software integration: this verification activity should concentrate on
the inter-relationships between the software requirements, and on the implementation of
requirements by the software architecture. The objective is to ensure that the software
components interact correctly with each other and satisfy the software requirements and
software architecture. Typical errors to consider include:

Incorrect initialization of variables and constants

Parameter passing errors
Data corruption, especially global data
Inadequate end-to-end numerical resolution
Incorrect sequencing of events and operations

Formal methods can be used to verify the absence of some error types listed above, as described
in FM.6.7, item f. Additionally, testing will be required to verify the software integration in
target hardware.
With respect to objective FM.6.7.c, Polyspace Code Prover helps to identify exhaustively:

Uninitialized variables
Parameter passing errors
Data corruption, especially global data
Inadequate end-to-end numerical resolution

4-8

With respect to objective FM.6.7.c, Polyspace Code Prover helps partially to identify:

Incorrect initialization of variables and constants

Incorrect initialization of variables and constants leading to an underflow/overflow
Global data corruption of shared variables without protection mechanism
Incorrect sequencing of events and operations

Table FM.A-6 (2) Executable Object Code Is Robust with High-Level

Requirements
FM.6.7.b: Robustness for high- and low-level requirements: The objective is to demonstrate the
ability of the software to respond to abnormal inputs and conditions. Activities for robustness
cases include:

Real and integer variables should be considered.

System initialization should be considered during abnormal conditions.
The possible failure modes of incoming data should be determined, especially complex,
digital data strings from an external system.
For loops where the loop count is a computed value, formal analysis cases should be
developed to attempt to compute out-of-range loop count values, and thus demonstrate
the robustness of the loop-related code.
A check should be made to ensure that protection mechanisms for exceeded frame times
respond correctly.
For time-related functions such as filters, integrators and delays, formal analysis case
should be developed for arithmetic overflow mechanisms.
For state transitions, formal analysis cases should be developed to provoke transitions
that are not allowed by the software requirements.

With respect to objective FM.6.7.b, Polyspace Code Prover helps to identify exhaustively:

Detection of arithmetic faults (see details in the Polyspace Code Prover documentation)
Detection of violation of array limits
Detection of overflows

4-9

With respect to objective FM.6.7.b, Polyspace Code Prover helps to identify partially:

Detection of loops leading to run-time error

Detection of incorrect logic decision leading to reachable code or run-time errors

FM.6.7.c: Verification of software integration: The verification activity should concentrate of

the inter-relationships between the software requirements, and on the implementation of the
software requirements by the software architecture. The objective is to ensure that the software
components interact correctly with each other and satisfy the software requirements and
software architecture. Typical errors to consider include:

Incorrect initialization of variables and constants.

Parameter passing errors.
Data corruption, especially global data.
Inadequate end-to-end numerical resolution.
Incorrect sequencing of events and operations.

With respect to objective FM.6.7.c, Polyspace Code Prover helps to identify exhaustively:

Uninitialized variables
Parameter passing errors
Data corruption, especially global data
Inadequate end-to-end numerical resolution

With respect to objective FM.6.7.c, Polyspace Code Prover helps partially to identify:

Incorrect initialization of variables and constants

Incorrect initialization of variables and constants leading to an underflow/overflow
Global data corruption of shared variables without protection mechanism
Incorrect sequencing of events and operations

Table FM.A-6 (3) Executable Object Code Complies with Low-Level

Requirements
FM.6.7.d: compliance with the low-level requirements: The objective is to demonstrate the
ability of the software to respond to normal inputs and conditions. Activities for normal range
testing include:

Real and integer input variables should be considered using valid boundary values.
For time-related functions, such as filters, integrators, and delays, multiple iterations of
the code should be performed to check the characteristics of the function in context.

4-10

For state transitions, analyses should be developed to consider the transitions possible
during normal operation.
For software requirements expressed by logic equations, the normal range cases should
verify the variable usage and the Boolean operators.

Formal methods can be used to satisfy this objective, as described in FM.6.7.f. Typical errors to
consider include:

Failure of an algorithm to satisfy a software requirement.

Incorrect loop operations.
Incorrect logic decisions.
Failure to process correctly legitimate combinations of input conditions.
Incorrect responses to missing or corrupted input data.
Incorrect handling of exceptions, such as arithmetic faults or violations of array limits.
Incorrect computation sequence.
Inadequate algorithm precision, accuracy, or performance.

With respect to objective FM.6.7.d, Polyspace Code Prover helps to identify exhaustively:

Detection of arithmetic faults (see details in the Polyspace Code Prover documentation)
Detection of violation of array limits
Detection of overflows
Inadequate end-to-end numerical resolution

With respect to objective FM.6.7.d, Polyspace Code Prover helps to identify partially:

Detection of loops leading to run-time error

Detection of incorrect logic decision leading to unreachable code or run-time errors
Incorrect sequencing of events and operations

Table FM.A-6 (4) Executable Object Code Is Robust with Low-Level

Requirements
FM.6.7.b: Robustness for high- and low-level requirements: The objective is to demonstrate the
ability of the software to respond to abnormal inputs and conditions. Activities for robustness
cases include:

Real and integer variables should be considered.

System initialization should be considered during abnormal conditions.
The possible failure modes of incoming data should be determined, especially complex,
digital data strings from and external system.

4-11

For loops where the loop count is a computed value, formal analysis cases should be
developed to attempt to compute out-of-range loop count values, and thus demonstrate
the robustness of the loop-related code.
A check should be made to ensure that protection mechanisms for exceeded frame times
respond correctly.
For time-related functions such as filters, integrators and delays, formal analysis case
should be developed for arithmetic overflow mechanisms.
For state transitions, formal analysis cases should be developed to provoke transitions
that are not allowed by the software requirements.

With respect to objective FM.6.7.b, Polyspace Code Prover helps to identify exhaustively:

Detection of arithmetic faults (see details in the Polyspace Code Prover documentation)
Detection of violation of array limits
Detection of overflows

With respect to objective FM.6.7.b, Polyspace Code Prover helps to identify partially:

Detection of loops leading to run-time error

Detection of incorrect logic decision leading to unreachable code or run-time errors

FM.6.7.c: Verification of software integration: the verification activity should concentrate on

the inter-relationships between the software requirements, and on the implementation of the
software requirements by the software architecture. The objective is to ensure that the software
components interact correctly with each other and satisfy the software requirements and
software architecture. Typical errors to consider include:

Incorrect initialization of variables and constants.

Parameter passing errors.
Data corruption, especially global data.
Inadequate end-to-end numerical resolution.
Incorrect sequencing of events and operations.

With respect to objective FM.6.7.c, Polyspace Code Prover helps to identify exhaustively:

Uninitialized variables
Parameter passing errors
Data corruption, especially global data
Inadequate end-to-end numerical resolution

4-12

With respect to objective FM.6.7.c, Polyspace Code Prover helps to identify partially:

Incorrect initialization of variables and constants

Incorrect initialization of variables and constants leading to an underflow/overflow
Global data corruption of shared variables without protection mechanism
Incorrect sequencing of events and operations

Table FM.A-7 (5-8) Verification Coverage of Software Structure is

Achieved
FM.6.7.1.c: Verification coverage of software structure is achieved: structural coverage
analysis is a notion strongly connected with testing and execution of code and is designed
primarily to detect shortcomings in test. Verification by formal methods can be complete and
exhaustive; hence equivalence to structural coverage is required rather than the analysis of how
much structural coverage has been achieved. This equivalence is obtained by combining the
activities described in sections FM.6.7.1.2 to FM.6.7.1.5 to detect:

Shortcomings in requirements-based verification cases or procedures (covered in

FM.6.7.1.2).
Inadequacies in software requirements (covered in FM.6.7.1.3 and FM.6.7.1.4).
Extraneous code, including dead code, and deactivated code (covered in FM.6.7.1.5).

Polyspace Code Prover helps by detecting unreachable (not exhaustive).

Table FM.A-7 (9) Verification of Property Preservation between

Source Code and Object Code
FM.6.7.f: Verification of Property Preservation between Source and Executable Object Code.
Options for verification activities of Executable Object code include:

(2) Formal analysis of Executable Object code can be used to satisfy the objectives if
the following conditions are satisfied:

The requirements are formally expressed.

A formal model of the source code is defined.

Formal evidence demonstrates that the formal model of the source code satisfies
the requirements.

4-13

Complimentary analysis shows the property preservation between the source code
and the EOC. By verifying the correctness of the translation of source to object
code, formal analysis performed at the source code level against high or low-level
requirements can be used to infer correctness of the Executable Object code
against high- or low-level requirements. This is similar to the way coverage metrics
gained from source code can be used to establish the adequacy of tests to verify the
target system. If directly traceable to source code statements, then additional
verification should performed to establish property preservation.

Polyspace Code Prover analysis is used only to take credit for detection of specific error types,
as described in the previous sections. Testing of the executable object code against the high- and
low-level requirements is still required to fully satisfy the objectives of FM.A-6. To demonstrate
preservation of properties between the source and object code, a traceability analysis between
the source and object code needs to be accomplished to demonstrate that additional code that is
not directly traceable to source code is not inserted. Additionally, tests can be used to show that
properties are preserved between low-level requirements and executable object code.

4-14

5 Tool Development Life Cycle

Tool Developer
The DO Qualification Kit: Tool Life Cycle Process document comprises the:

Tool Development Plan (DO-330, Section 10.1.3)

Tool Verification Plan (DO-330, Section 10.1.4)

Tool Configuration Management Plan (DO-330, Section 10.1.5)

Tool Quality Assurance Plan (DO-330, Section 10.1.6)

for MathWorks tools being qualified to TQL-4, as defined in DO-178C and DO-330. The DO
Qualification Kit: Tool Life Cycle Process document provides information about the tool
development life cycle, including:

Development and verification activities

Organizational responsibilities, configuration management and quality assurance

processes

5-2

6 Tool Development Life Cycle

Tool User

6.1 Planning
The Plan for Software Aspects of Certification (PSAC) or Plan for Software Aspects of
Approval (PSAA) for TBD Project calls out that Polyspace Code Prover will be qualified as a
Criteria 2 TQL-4 tool, as defined in DO-178C and DO-330.
This document provides the Tool Qualification Plan for Polyspace Code Prover.

6-2

6.2 Requirements

The Tool Requirements for the Polyspace Code Prover are defined as the Operational
Requirements (ORs) and Language Specific Requirements (LSRs) in:
Polyspace Code Prover Tool Requirements, R2015b
The Tool Operational Requirements for the Polyspace Code Prover are defined as HLRs in:
Polyspace Code Prover Tool Operational Requirements, R2015b
The Polyspace Code Prover Theoretical Foundation is described in:
Polyspace Code Theoretical Foundation, R2015b
For traceability between the High-Level Requirements (HLRs), Operational Requirements
(ORs) and Language Specific Requirements (LSRs), see:
qualkitdo_codeprover_HLR_OR_LSR_Trace.xlsx

To access the requirements documents, on the MATLAB command line, type

qualkitdo to open the Artifacts Explorer. The documents are in Polyspace Code
Prover.

The tool-user will:

- Review the theoretical foundation and the tool operational requirements for
applicability to the project under consideration.
- Configure the theoretical foundation and the tool operational requirements in a
configuration management system

Tool user information for Polyspace Code Prover is documented in:

Polyspace Code Prover Users Guide, R2015b

Instructions for installing the tool and minimum hardware requirements are at the
MathWorks Documentation Center, R2015b.
Installation

6-3

6.3 Verification
Requirements-based test procedures will be developed from the Tool Operational Requirements
by MathWorks. A subset of these tests will be provided to the tool user to execute in the
installed environment. This subset of tests partially covers each requirement of the tool, and
provides confidence in the tool operation in the installed environment.
The test cases and procedures for Polyspace Code Prover are documented in:
Polyspace Code Prover Test Cases and Procedures, R2015b
To access the theoretical foundation and tool operational requirements documents, on the
MATLAB command line, type qualkitdo to open the Artifacts Explorer. The documents
are in Polyspace Code Prover.
The tool-user will:

Review the test cases and procedures and the corresponding documentation for
applicability to the project under consideration
Configure the test cases and procedures and the corresponding documentation in a
configuration management system
Run the test cases and procedures in the installed environment
Review the test results
Configure the test results and the corresponding documentation in a configuration
management system

6-4

7 Additional Considerations

7.1 Independence
Polyspace Code Prover is used to verify the output of an unqualified development tool,
Embedded Coder. Therefore, for Polyspace Code Prover qualification, the user needs to
demonstrate the independence of Polyspace Code Prover and Embedded Coder development
(DO-330, FAQ D.7).
The DO Qualification Kit: Polyspace Code Prover Independence Analysis document provides
an independence analysis, including:

Development team independence

Requirements, design and code independence

Dissimilarities in technical approaches

7-2

7.2 Customer Bug Reporting

MathWorks reports known critical bugs brought to its attention on its bug report system at
www.mathworks.com/support/bugreports. The bug reports are an integral part of the
documentation for each release.
The bug report system provides an interface for customers to view and submit bug reports. Users
can track the status of open bugs. Users can choose to receive notifications for new or updated
bug reports. The bug reports on this web site include internally and externally nominated bugs.
If applicable, bug reports include provisions for known workarounds or file replacements.
Customers can use the bug report mechanism to nominate bugs. These nominations are
processed and evaluated by The MathWorks, Inc. development organization.

7-3

7.3 Protection Mechanisms

The Polyspace Code Prover may be considered a multi-function tool, as defined in DO-330
Section 11.1. The user does have the ability to choose which coding rules to be used for a
project; MISRA-C, MISRA-C++ or JSF++. Only one of these rules checks will be run during a
given verification. But all of these rules checks are qualified to TQL-4 and the selection of the
rules to be used is verified during qualification testing, therefore no protection mechanisms are
needed.

7-4

8 Tool Life Cycle Data

The following table shows the life cycle data provided for Polyspace Code Prover. The table
maps the documents and artifacts to DO-330 life cycle data items.
Polyspace Code Prover Life Cycle Data
Data

Available/
Submit

Tool-Specific Information Submit

in Plan for Software
Aspects of Certication
(PSAC)

DO-330
Documents/Artifacts
Reference
Section
10.1.1

<Insert PSAC or PSAA** reference here.>

The following information might be used to
create the PSAC:

Tool Overview and Identification of

Polyspace Code Prover Tool
Qualification Plan (this document)

Tool Qualication Plan

Submit

Tool Development Plan

Available

Tool Verification Plan

Available

Section
10.1.4

Tool Configuration
Management Plan

Available

Section
10.1.5

Tool Quality Assurance

Plan

Available

Section
10.1.6

Tool Requirements
Standards
Tool Design Standards

N/A for TQL-4 Section

10.1.7
N/A for TQL-4 Section
10.1.8
N/A for TQL-4 Section
10.1.9
Available
Section
10.1.10

Tool Code Standards

Tool Life Cycle
Configuration Index

Section
10.1.2
Section
10.1.3

Certification Credit section of

Polyspace Code Prover Tool
Qualification Plan (this document)

Polyspace Code Prover Tool Qualification

Plan (this document)
DO Qualification Kit: Tool Life Cycle
Process document. For more information,
contact MathWorks.
DO Qualification Kit: Tool Life Cycle
Process document. For more information,
contact MathWorks.
DO Qualification Kit: Tool Life Cycle
Process document. For more information,
contact MathWorks.
DO Qualification Kit: Tool Life Cycle
Process document. For more information,
contact MathWorks.
N/A for TQL-4
N/A for TQL-4
N/A for TQL-4
Polyspace Code Prover Tool Configuration
Index. For more information, contact
MathWorks.

Tool Environment
Configuration Index

Submit

Section
10.1.11

Polyspace Code Prover Tool Configuration

Index. For more information, contact
MathWorks.

Tool Problem Reports

Available

Section
10.1.12

MathWorks bug report system at

www.mathworks.com/support/bugreports.

8-2

Data

Available/
Submit

DO-330
Documents/Artifacts
Reference

Tool Configuration
Management Records
Tool Quality Assurance
Records
Tool-Specific Information
in SECI
Tool Requirements

Available

Tool Design Description

Available

Section
10.1.13
Section
10.1.14
Section
10.1.17
Section
10.2.1
Section
10.2.2

Tool Source Code

Available

Tool Executable Object

Code
Tool Theoretical
Foundation

Available

Tool Operational
Requirements

Submit

Tool Installation Report

Submit

Available
Available
Available

Submit

Test Cases and Procedures Available

Section
10.2.3
Section
10.2.4
Sections
12.2.3.c(2),
12.2.3.2
Section
10.3.1
Section
10.3.2
Section
10.3.3
10.2.5

Records. For more information, contact

MathWorks.
Reports. For more information, contact
MathWorks.
<Insert Software Life Cycle Environment
Configuration Index** reference here>
Polyspace Code Prover Tool Requirements
Polyspace Code Prover Tool Architecture
document. For more information, contact
MathWorks.
N/A for TQL-4
Provided as part of the R2015b release
Polyspace Code Prover Theoretical
Foundation
Polyspace Code Prover Tool Operational
Requirements
<Insert reference to ** here.>
Polyspace Code Prover Test Cases and
Procedures and artifacts referenced in Trace
Matrices:
Matrix_jsf_rules_checker.txt
Matrix_limitation_Cpp.txt
Matrix_limitation_C.txt
Matrix_misra_Cpp.txt
Matrix_misra_C.txt
Matrix_norme_Cpp.txt
Matrix_norme_C.txt
Matrix_opreq_Cpp.txt
Matrix_opreq_C.txt

Test Case Review Checklist. For more

information, contact MathWorks.

8-3

Data

Available/
Submit

DO-330
Documents/Artifacts
Reference

Test Results

Available**

Section
10.3.4
10.2.6

Artifacts referenced in
qualkitdo_codeprover_qualification
report_tor.txt
qualkitdo_codeprover_qualification
report_misrac.txt
qualkitdo_codeprover_qualification
report_misracpp.txt
qualkitdo_codeprover_qualification
report_jsf.txt
qualkitdo_codeprover_qualification
report_code_metrics.txt

Test Result Review Checklist. For more

information, contact MathWorks.
Trace Data

Available

Section
10.2.7

qualkitdo_codeprover_HLR_OR_LSR_tr
ace.xlsx
Matrix_jsf_rules_checker.txt
Matrix_limitation_Cpp.txt
Matrix_limitation_C.txt
Matrix_misra_Cpp.txt
Matrix_misra_C.txt
Matrix_norme_Cpp.txt
Matrix_norme_C.txt
Matrix_opreq_Cpp.txt
Matrix_opreq_C.txt

Tool Independence Data

Available

Tool-specific information Submit

in Software
Accomplishment Summary
(SAS)
Tool Accomplishment
Submit
Summary

FAQ D.7

Section
10.1.16

Section
10.1.15

Polyspace Code Prover Independence

Analysis document. For more information,
contact MathWorks.
<Insert reference to SAS** here.>

<Insert Tool Qualification Accomplishment

Summary** here.>. For more information,
contact MathWorks.

Notes:
** To be created by tool-user

The tool-user must deliver data marked Submit to the certification authorities. Data marked
Available must be available at the tool-users or tool vendors site for inspection by the
certification authorities.

8-4

9 Schedule
<Insert tool schedule here.>