Qualkitdo Codeprover Tf

8/20/2019 Qualkitdo Codeprover Tf

1/22

DO Qualification Kit

Polyspace® Code Prover ™ Theoretical Foundation

R2015b, September 2015


2/22

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 Prover ™ Theoretical Foundation

© COPYRIGHT 2013 – 2015 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 writtenconsent 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 agreesthat 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 conditi ons.

If this License fails to meet the government’s needs or is inconsistent in any respect with federal procurement law, thegovernment 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 f or alist of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respectiveholders.

Patents

MathWorks products are protected by one or more U.S. patents. Please see www.mathworks.com/patents f or moreinformation.

http://www.mathworks.com/http://www.mathworks.com/http://www.mathworks.com/company/aboutus/contact_us/http://www.mathworks.com/company/aboutus/contact_us/http://www.mathworks.com/matlabcentral/http://www.mathworks.com/matlabcentral/http://www.mathworks.com/support/contact_us/http://www.mathworks.com/support/contact_us/http://www.mathworks.com/trademarkshttp://www.mathworks.com/trademarkshttp://www.mathworks.com/trademarkshttp://www.mathworks.com/patentshttp://www.mathworks.com/patentshttp://www.mathworks.com/patentshttp://www.mathworks.com/patentshttp://www.mathworks.com/trademarkshttp://www.mathworks.com/support/contact_us/http://www.mathworks.com/matlabcentral/http://www.mathworks.com/company/aboutus/contact_us/http://www.mathworks.com/


3/22

Revision History

September 2013 New for Version 2.2 (Applies to Release 2013b)March 2014 Revised for Version 2.3 (Applies to Release 2014a)

October 2014 Revised for Version 2.4 (Applies to Release 2014b)March 2015 Revised for Version 2.5 (Applies to Release 2015a)

September 2015 Revised for DO Qualification Kit Version 3.0 (Applies to Release 2015b)


4/22


5/22

v

Contents

1

Introduction ...................................................................................................................................... 1-1

2 Initial Specification .......................................................................................................................... 2-1

3 High-Level Semantics of Programming Languages ......................................................................... 3-1

Definition 1. (Operational Semantics) ......................................................................................... 3-2

Definition 2. (Kripke Structures with Single Failure) .................................................................. 3-3 Definition 3. (Run-Time Errors) .................................................................................................. 3-4

Definition 4. (Strongest Invariant at k) ........................................................................................ 3-5

Definition 5. (Run-Time Error Modalities/Colors) ...................................................................... 3-6

Proposition 6. (Run-Time Error Modalities Are Noncomputable) ............................................... 3-7

Definition 7. (Admissible Check Modalities) .............................................................................. 3-9 Proposition 8. (Semantics of C # (k))............................................................................................ 3-10

4 References ........................................................................................................................................ 4-1

4.1 Reference Documents.............................................................................................................. 4-2


6/22

vi


7/22

1 Introduction

This document describes the Theoretical Foundation for the Polyspace® Code Prover TM

verification tool. It is intended for use in the DO-178C tool qualification process for verification

tools.

This document is a high-level specification of Polyspace Code Prover code verification

technology for ANSI C and ISO C++. It starts from the user need to detect more bugs earlier on

in the development process and in a more automated way. Conventional technologies, such as

testing, should be disruptively improved. MathWorks® particularly focuses on run-time errors,

which typically represent 30-40% of the total program errors that occur after delivery. These

errors are both difficult to detect through conventional means, and can have significant negativeimpact, which can range from erroneous outputs to system crash or security breaches.

This document describes the formal, theoretical background of Polyspace Code Prover

technology. Detecting automatically and exhaustively run-time errors in general programs isvery complex. The seminal idea, introduced by Ben Wegbreit in 1974 and 1975, is to perform

approximate computations in which the direction of approximation is controlled. These

approximations are formalized by closure operators on algebraic structures called completelattices, starting with a mathematical model of program execution via operational semantics and

Kripke structures.

Polyspace® Bug Finder TM identifies run-time errors in C and C++ embedded software. PolyspaceBug Finder does not prove the absence of run-time errors. Polyspace Bug Finder uses the same

theoretical foundation as Polyspace Code Prover, but it is not irrefutable with respect toidentification of run-time errors.


8/22

1-2


9/22

2 Initial Specification

Designing a bridge, choosing the trajectory for the launch of a communication satellite,

optimizing the shape of a plane wing, estimating the multiple echo effects of urban buildings incellular phone communications: what is common among these industrial activities is high-speed

processors and applied mathematics. The central paradigm is to model a physical world system

as a set of mathematical equations, solving these equations using high-speed processors, and

finally using the solutions to these equations to predict the behavior of the physical system.

The software industry has not yet really leveraged this paradigm to optimize its own verification

and validation processes. Polyspace Code Prover brings to the software industry the power of

applied mathematics and high-speed modern processors. The Polyspace Code Prover software

aims at helping users simultaneously:

Automate specific software development and verification processes

Increase the reliability of software

The main criteria for software are:

Functional correctness: computes expected outputs

Temporal correctness: computes outputs within specified time bounds

Robustness: does not halt, crash, or behave erratically because of run-time errors

Run-time errors are an important cause of software defects. The study of Sullivan and

Chillarege1 conducted at Berkeley and IBM® Watson found that many software defectsaddressed during a four-year maintenance phase on large IBM codes are due to run-time errors.Memory allocation errors, array out of bounds, uninitialized pointers, and pointer management

errors accounted for 26% of all observed software faults and more than 57% of the highest

severity faults, causing system outage or major disruption.

1 M. SULLIVAN AND R. CHILLAREGE, Software defects and their impact on system availability, proc. 21th InternationalSymposium on Fault-Tolerant Computing (FTCS-21), Montreal, 1991, 2-9, IEEE Press.


10/22

2-2

The Polyspace Code Prover software targets the mathematical modeling paradigm regarding

run-time errors. Polyspace Code Prover addresses two essential needs:

Static verification: statically predicting specific classes of run-time errors and sources ofnondeterminism

Semantic browsing: statically computing data and control flow to ease programunderstanding, verification, or qualification

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 futuredynamic, 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 (for semantic browsing).

This document serves as a reference for the design of Polyspace Code Prover and as a criterionfor functional validation testing. MathWorks uses an established tool life cycle process to

address tool development and verification activities. Hardware errors, coding errors, testing

errors, documentation errors, or other unforeseen circumstances may cause significantdeviations between expected behavior and actual behavior of the software tool. Therefore, this

document and the associated documents do not imply that MathWorks explicitly or implicitlyguarantees that Polyspace Code Prover is fully compliant to the specification, that it always

delivers correct results, or that it conforms to the user needs.


11/22

3 High-Level Semantics of

Programming Languages

Program behavior and run-time errors are formalized to provide a firm basis for the specificationof Polyspace Code Prover outputs.


12/22

3-2

Definition 1. (Operational Semantics)

The operational semantics of a program, P, written in programming language L, consists in the

set of finite and infinite execution traces O[P] 2Trace. An execution trace is a time-evolving sequence of states defined as Trace = State . Each trace Trace is a function from positiveintegers to states. These integers represent the discrete computation time measured as the

number of elementary language constructs executed since program start.

The formal behavior of program P consists in the set of all possible runs of P , where each run is

represented by a possibly infinite sequence of states. States can be chosen according to the programming language. Consider a simple flowchart programming language consisting of

integer variables, integers, arithmetic operations, assignments, conditionals, and loops. Statescan be defined as pairs consisting of an integer representing the current flowchart instruction to

be executed, and a vector of integers in an n-dimensional state, where n is the number of

variables in the flowchart program, P, under consideration.

Infinite traces correspond to either diverging (looping) programs or nonterminating programs (aserver loop, for instance).


13/22

3-3

Definition 2. (Kripke Structures with Single Failure)

Given a Kripke structure2 with single failure (State, succ, ) associated to program P, where:

succ State 2State is a transition function that relates each state to its successors;

State 2 A, is a valuation that associates each state with the set of atomic formulas truein this state. A contains the distinguished elements error, final , initial and the set {at1,at2,…};

s State, error (s) succ(s)= ;

s State, succ(s)= (s) { error , final } .

O[P] = { Trace | initial ( (0)), (1) succ( (0)), …, (n+1) succ( (n)), …}

If a state s State is such that succ(s)= , the state is final.

If at k (s), state s is at program point k.

The transition function associates zero, one, or several successors with a given state: a state with

no successors is either an error state or a final state (corresponding to the nominal termination of

program P); a state with one successor is the ordinary case; and a state with several successorscorresponds to nondeterminism. Nondeterminism can be the result of interleaving tasking or canoccur as a modelization of input/output from the world, external to the computer under

consideration.

No further hypotheses on how the transition function and the set of states are defined. This iscalled semantics of programming languages. For further information, see the Handbook ofTheoretical Computer Science by Van Leeuwen3.

2 S.K RIPKE.A completeness proof in modal logic. J. Symbolic Log ic, 24 :1-14, 1959.

3 J.VAN LEEUWEN. Handbook of theoretical computer science. The MIT Press,1990.


14/22

3-4

Definition 3. (Run-Time Errors)

A run-time error occurs in state s State if and only if error (s).

An execution trace can be any one of the following:

Infinite and without run-time errors

Finite ending with a final state

Finite ending with an error state

What is the connection with actual programming languages? The ANSI C and C++ standardshave an immediate and precisely defined notion of run-time error, as the standard gives aninformal but precise definition of the cases where a run-time occurs. Examples of run-time

errors include indexing an array out of its bounds, dividing by zero, referencing an illegal field

of a structure, or dereferencing a dangling pointer.


15/22

3-5

Definition 4. (Strongest Invariant at k)

The strongest invariant at k in program P as the set of states is:

SGI(k)={ (t) | O[P], t, at k ( (t))}

SGI(k) is the set of all possible states that are at point k and reachable in program P. It can be

equivalently formulated by translating the source program, P, to a system of equations that has

one equation per program point456. For each program point k , the solution yields the invariant

SGI(k).

4 R. FLOYD, Assigning meaning to programs. In Mathematical Aspects of Computer Science, Proc. of Symposia on AppliedMathematics, American Mathematical Society, 19-32, Providence, 1967.

5 D. PARK , Fixpoint induction and proofs of program properties, in Machine Intelligence, Edinburgh Univ. Press, 5 : 59-78, 1969.

6 E. CLARKE, Program invariants as fixedpoints, Computing 21- : 273-294, 1979.


16/22

3-6

Definition 5. (Run-Time Error Modalities/Colors)

In some instances, deviation from the reference workflow explained in this document might

occur.

In a program, P, define the modality (color) C(k) { gray ,red ,green ,orange } associated to program point k as follows:

C(k) = gray SGI(k)=

C(k) = red SGI(k) and s SGI(k), error (s)

C(k) = green SGI(k) and s SGI(k), error (s)

C(k) = orange s1 , s2 SGI(k), error (s1 ) and error (s2 )

This formal definition of the (semantic, exact) color (modality) associated with program point k

is the cornerstone of the Polyspace Code Prover specification. Polyspace Code Prover does not

rely on a binary partition of cases (correct versus incorrect) but on a more expressive set of fourmodalities. Having more than two modalities is a common phenomenon in modal or temporallogics.

A program point associated with gray or green will not raise run-time errors during execution. A program point associated with red triggers a run-time error if executed. Gray identifies a

program point that cannot be executed (dead code) and orange is associated with a program

point that can intermittently execute correctly or incorrectly.

The color C(k) is a prediction of the future behavior of program P . If you compute for each program point k of a program P the modality C(k ), then there is a powerful means of verifying

the absence of run-time errors. First fix the red errors in P and then fix the orange program

points by either inserting protection code or correcting the cause of the underlying red case. At

the end, there is a program containing only gray and green program points that is completelyfree of run-time errors in any future execution.

It is not possible to automatically compute these modalities C(k ) on general programs incommon programming languages.


17/22

3-7

Proposition 6. (Run-Time Error Modalities AreNoncomputable)

Given an arbitrary program, P, written in programming language L, the run-time error

modalities for P are noncomputable in finite time by any initially established means.

Observe that the halting problem (deciding if a program stops) is reducible to the run-time error

problem. As the halting problem has been shown to be undecidable by Church and Turing7 in

the general case, and for computer programs by Hoare and Allison 8 , it follows that the

computation of C (k ) is undecidable as well, which in turn implies noncomputability in finitetime.

What is the practical significance of this theoretical fact? Does it mean that run-time errors are a

problem for which theoretical computer science cannot help? When confronted with a problem

for which computational complexity is too difficult, you can resort to approximate methods, if

they can provide close enough solutions for an acceptable time and memory space usage.

What is a meaningful approximation in this case?

Probabilistic or statistical methods give results of the form “C(k) is green with a 95%confidence interval ”. These results raise difficult questions to answer, such as: What is the

underlying notion of distribution? Such probabilistic information cannot validate highly

critical systems such as power plant control systems or fly-by-wire software.

Algebra, lattice theory9, and logics introduce another approximation that is based onimplication and partial orderings. This approximation obtains results of the form: “C(k) is not

orange or red ”. This is an approximate property; it could mean that C (k ) is actually either

gray or green. Despite the approximation, it can be directly used because it implies that the

operation at k is never wrong.

This document pursues this second approach, following the pioneering work of Wegbreit 10,

further extended by Karr, Cousot, & Cousot, Halbwachs, Jones, Sharir, & Pnueli, and others tomore complex language constructs and more expressive properties.

7 A. TURING. Computability and -definability. J. Symbolic Logic, 2 :153-163, 1937.

8 C. HOARE AND D. ALLISON. Incomputability, ACM Computing Surveys, 4(3) :169-178, 1972.

9 G. BIRKHOFF, Lattice Theory, American Mathematical Society, 1940.

10 B. WEGBREIT, Property extraction in well-founded property sets, IEEE Transactions on Software Engineering , 1(3):270-285,1975.


18/22

3-8

The key idea of Wegbreit’s work is that while the exact program property may not be

computable, a weaker property implied by the exact one may be computable. He also devises a

means to compute these approximate properties by replacing the exact invariant propagation of a

Floyd-style equation system by its image in a weaker space through an approximation operator. If properly designed, the approximated system is solvable and its solution, called SGI # (k) at a

particular program point k, is related to that of strongest global invariant by: (SGI(k)) SGI # (k).

This approximate invariant can in turn be used in the computation of run-time error modalities(colors) according to Definition 5. Replacing the exact invariant SGI(k) at point k in this

definition by its supersets yields an approximate check color C # (k) that is related to the exact

color C(k) by the following relation.


19/22

3-9

Definition 7. (Admissible Check Modalities)

An approximate check color C # (k) is admissible with respect to the exact check color C (k ) if,

and only if:

C(k) C # (k)

The following lattice diagram defines the ordering between check colors.

The partial order relation is defined as follows:

Gray Red Green Orange

Gray 1 1 1 1

Red 1 1

Green 1 1

Orange 1

In turn, this induces the following meanings for the color defined by C # (k).


20/22

3-10

Proposition 8. (Semantics of C # (k ) )

If C # (k) is computed with an approximate invariant that is a superset of SGI(k), then it is related

to the exact color C(k), as follows:

If C # (k) = gray, then C(k) = gray

If C # (k) = green, then C(k) { green,gray }

If C # (k) = red, then C(k) { red,gray }

If C # (k) = orange, then C(k) { red,green,gray,orange }

Knowing the value of the computable term C # (k) gives partial but useful information about theactual value of the term of interest C(k) that is not computable:

If C # (k) = green, then C(k ) is neither red nor orange; the operation at k is correct.

Conversely, if C(k) = orange or C(k )= red, then C# (k ) is either red or orange.


21/22

4 References


22/22

4-2

4.1 Reference DocumentsFloating point arithmetic standard IEEE 748

Programming languages – C. International standard ISO/EIC 9899: 1990 (E)

Programming languages – C. International standard ISO/EIC 9899: 1999 (E)

Programming languages – C++. International standard ISO/EIC 14882: 1998 (E)