State of Practice. Automatic Verification of Embedded Control Software with ASTRÉE and beyond

Similar documents
Static Analysis and Verification of Aerospace Software

Static Analysis by A. I. of Embedded Critical Software

The Verification Grand Challenge and Abstract Interpretation

Abstract interpretation

Building a specialized static analyzer

Automatic Qualification of Abstract Interpretation-based Static Analysis Tools. Christian Ferdinand, Daniel Kästner AbsInt GmbH 2013

Widening Operator. Fixpoint Approximation with Widening. A widening operator 2 L ˆ L 7``! L is such that: Correctness: - 8x; y 2 L : (y) v (x y)


Relational Abstract Domains for the Detection of Floating-Point Run-Time Errors

Static Analysis of Embedded Systems

Script started on Thu Oct 11 07:52: demo-astree/programs %./README

ABSTRACT INTERPRETATION

Why does ASTRÉE scale up?

A Static Analyzer for Large Safety-Critical Software

Verification of Embedded Software: Problems and Perspectives

Simulink 모델과 C/C++ 코드에대한매스웍스의정형검증툴소개 The MathWorks, Inc. 1

Model-Based Design for High Integrity Software Development Mike Anthony Senior Application Engineer The MathWorks, Inc.

Lecture 6. Abstract Interpretation

Script started on Mon Oct 15 08:21: demo-astree/programs %./README

Verification and Test with Model-Based Design

Towards an industrial use of FLUCTUAT on safety-critical avionics software

StackAnalyzer Proving the Absence of Stack Overflows

CODE ANALYSES FOR NUMERICAL ACCURACY WITH AFFINE FORMS: FROM DIAGNOSIS TO THE ORIGIN OF THE NUMERICAL ERRORS. Teratec 2017 Forum Védrine Franck

Structuring an Abstract Interpreter through Value and State Abstractions: EVA, an Evolved Value Analysis for Frama C

AstréeA From Research To Industry

Interval Polyhedra: An Abstract Domain to Infer Interval Linear Relationships

Leveraging Formal Methods for Verifying Models and Embedded Code Prashant Mathapati Application Engineering Group

Intro to Proving Absence of Errors in C/C++ Code

CSC313 High Integrity Systems/CSCM13 Critical Systems. CSC313/CSCM13 Chapter 1 1/ 38

Leveraging Formal Methods Based Software Verification to Prove Code Quality & Achieve MISRA compliance

From Design to Production

The Apron Library. Bertrand Jeannet and Antoine Miné. CAV 09 conference 02/07/2009 INRIA, CNRS/ENS

Verasco: a Formally Verified C Static Analyzer

Algebraic Program Analysis

InterprocStack analyzer for recursive programs with finite-type and numerical variables

Sendmail crackaddr - Static Analysis strikes back

Design and Implementation of a Special-Purpose Static Program Analyzer for Safety-Critical Real-Time Embedded Software

Program Verification. Aarti Gupta

Hierarchical Shape Abstraction of Dynamic Structures in Static Blocks

Verifying source code

Semantics and Validation Lecture 1. Informal Introduction

Splitting the Control Flow with Boolean Flags

SMT-Style Program Analysis with Value-based Refinements

Static Program Analysis Part 1 the TIP language

A Multi-Modal Composability Framework for Cyber-Physical Systems

Pierce Ch. 3, 8, 11, 15. Type Systems

Static Analysis and Verification of Aerospace Software by Abstract Interpretation

Bounded Model Checking Of C Programs: CBMC Tool Overview

The Apron Library. Antoine Miné. CEA Seminar December the 10th, CNRS, École normale supérieure

Static Program Analysis CS701

Critical Analysis of Computer Science Methodology: Theory

What s New with the MATLAB and Simulink Product Families. Marta Wilczkowiak & Coorous Mohtadi Application Engineering Group

CSE 403: Software Engineering, Fall courses.cs.washington.edu/courses/cse403/16au/ Static Analysis. Emina Torlak

Tail Calls. CMSC 330: Organization of Programming Languages. Tail Recursion. Tail Recursion (cont d) Names and Binding. Tail Recursion (cont d)

WHITE PAPER. 10 Reasons to Use Static Analysis for Embedded Software Development

Applications of Program analysis in Model-Based Design

Type Checking. Outline. General properties of type systems. Types in programming languages. Notation for type rules.

Outline. General properties of type systems. Types in programming languages. Notation for type rules. Common type rules. Logical rules of inference

Space Software Validation using Abstract Interpretation

Advanced Programming Methods. Introduction in program analysis

Testing. Prof. Clarkson Fall Today s music: Wrecking Ball by Miley Cyrus

Industrial Verification Using the KIND Model Checker Lucas Wagner Jedidiah McClurg

Aerospace Software Engineering

SOFTWARE QUALITY OBJECTIVES FOR SOURCE CODE

Guidelines for deployment of MathWorks R2010a toolset within a DO-178B-compliant process

Formal Semantics of Programming Languages

CIS 890: Safety Critical Systems

Utilisation des Méthodes Formelles Sur le code et sur les modèles

An Eclipse Plug-in for Model Checking

Embedded Software Verification Challenges and Solutions. Static Program Analysis

MURPHY S COMPUTER LAWS

Formal Semantics of Programming Languages

CS 510/13. Predicate Abstraction

A Gentle Introduction to Program Analysis

Unit Testen en embedded software Fout injectie en Software varianten

Static Analysis methods and tools An industrial study. Pär Emanuelsson Ericsson AB and LiU Prof Ulf Nilsson LiU

Semantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics

Lectures 20, 21: Axiomatic Semantics

On the correctness of template metaprograms

Software Engineering using Formal Methods

Model Checking Embedded C Software using k-induction and Invariants

Programming Languages

Testing. Lydie du Bousquet, Ioannis Parissis. TAROT Summer School July (TAROT 2009)

Developing AUTOSAR Compliant Embedded Software Senior Application Engineer Sang-Ho Yoon

UPPAAL. Verification Engine, Options & Patterns. Alexandre David

Recap: ML s Holy Trinity. Story So Far... CSE 130 Programming Languages. Datatypes. A function is a value! Next: functions, but remember.

Certified Memory Usage Analysis

Topics in Software Testing

Synchronous Specification

CSE 130 Programming Languages. Datatypes. Ranjit Jhala UC San Diego

Verifying Parallel Programs

Software Model Checking with Abstraction Refinement

Definition: Data Type A data type is a collection of values and the definition of one or more operations on those values.

Recap from last time. Programming Languages. CSE 130 : Fall Lecture 3: Data Types. Put it together: a filter function

Functions in C C Programming and Software Tools

Verification and Validation of High-Integrity Systems

CUTE: A Concolic Unit Testing Engine for C

Verification and Validation. Assuring that a software system meets a user s needs. Verification vs Validation. The V & V Process

Verification Overview Testing Theory and Principles Testing in Practice. Verification. Miaoqing Huang University of Arkansas 1 / 80

Total No. of Questions : 18] [Total No. of Pages : 02. M.Sc. DEGREE EXAMINATION, DEC First Year COMPUTER SCIENCE.

Transcription:

Automatic Verification of Embedded Control Software with ASTRÉE and beyond Patrick Cousot Jerome C. Hunsaker Visiting Professor Department of Aeronautics and Astronautics, MIT cousot mit edu www.mit.edu/~cousot École normale supérieure, Paris cousot ens fr www.di.ens.fr/~cousot State of Practice Workshop on Critical Research Areas in Aerospace Software Aero. Astro. Dept., MIT, August 9 th, 2005 Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 2 ľ P. Cousot» h=get(gca, children ); An example among many others (Matlab code) apple.awt.eventqueueexceptionhandler Caught Throwable : java.lang.arrayindexoutofboundsexception: 2 >= 2 java.lang.arrayindexoutofboundsexception: 2 >= 2 at java.util.vector.elementat(vector.java:431) at com.mathworks.mde.help.indexitem.getfilename(indexitem.java:100) at com.mathworks.mde.help.index.getfilenameforlocation(index.java:706) at com.mathworks.mde.help.index.access$3100(index.java:29) at com.mathworks.mde.help.index$indexmousemotionadapter.mousemoved(index.java:768) at java.awt.awteventmulticaster.mousemoved(awteventmulticaster.java:272) at java.awt.awteventmulticaster.mousemoved(awteventmulticaster.java:271) at java.awt.component.processmousemotionevent(component.java:5211) at javax.swing.jcomponent.processmousemotionevent(jcomponent.java:2779) at com.mathworks.mwswing.mjtable.processmousemotionevent(mjtable.java:725) at java.awt.component.processevent(component.java:4967) at java.awt.container.processevent(container.java:1613) at java.awt.component.dispatcheventimpl(component.java:3681) at java.awt.container.dispatcheventimpl(container.java:1671) at java.awt.component.dispatchevent(component.java:3543) at java.awt.lightweightdispatcher.retargetmouseevent(container.java:3527) at java.awt.lightweightdispatcher.processmouseevent(container.java:3255) at java.awt.lightweightdispatcher.dispatchevent(container.java:3172) at java.awt.container.dispatcheventimpl(container.java:1657) at java.awt.window.dispatcheventimpl(window.java:1606) at java.awt.component.dispatchevent(component.java:3543) at java.awt.eventqueue.dispatchevent(eventqueue.java:456) at java.awt.eventdispatchthread.pumponeeventforhierarchy(eventdispatchthread.java:234) at java.awt.eventdispatchthread.pumpeventsforhierarchy(eventdispatchthread.java:184) at java.awt.eventdispatchthread.pumpevents(eventdispatchthread.java:178) at java.awt.eventdispatchthread.pumpevents(eventdispatchthread.java:170) at java.awt.eventdispatchthread.run(eventdispatchthread.java:100)» Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 3 ľ P. Cousot The software challenge for next 10 years --- Present-day software engineering is almost exclusively manual, with very few automated tools; --- Trust and confidence in specifications and software can no longer be entirely based on the development process (e.g. DO178B); --- In complement, quality assurance must be ensured by new design, modeling, checking, verification and certification tools based on the product itself. Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 4 ľ P. Cousot

Static analysis tools State of the Art in Automatic Static Program Analysis --- Determine automatically from the program text program properties of a certain class that do hold at runtime (e.g. absence of runtime error); --- Based on the automatic computation of machine representable abstractions 1 of all possible executions of the program in any possible environment; --- Scales up to hundreds of thousands lines; --- Undecidable whence false alarms are possible 2 1 sound but (in general) uncomplete approximations. 2 cases when a question on the program runtime behavior cannot be answered automatically for sure Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 5 ľ P. Cousot Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 6 ľ P. Cousot Degree of specialization --- Specialization for a class of runtime properties (e.g. absence of runtime errors) --- Specialization for a programminglanguage (e.g. PolySpace Suite for Ada, C or C++) --- Specialization for a programming style (e.g. C Global Surveyor) --- Specialization for an application type (e.g. ASTRÉE for embedded real-time synchronous 3 autocodes) ) The more specialized, the less false alarms 4! 3 deterministic 4 but the less specialized, the larger commercial market (and the less client satisfaction)! Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 7 ľ P. Cousot The ASTRÉE static analyzer --- ASTRÉE is a static program analyzer aiming at proving the absence of Run Time Errors (started Nov. 2001) --- C programs, no dynamic memory allocation and recursion --- Encompass many (automatically generated) synchronous, time-triggered, real-time, safety critical, embedded software --- automotive, energy and aerospace applications ) e.g. No false alarm on the electric flight control codes for the A340 (Nov. 2003) and A380 (Nov. 2004) generated from SAO/SCADE. Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 8 ľ P. Cousot

2 d Order Digital Filter: t x(n) + ++ Switch z -1 Unit delay j Switch a B z -1 Unit delay i Switch b - Ellipsoid Abstract Domain for Filters j --- Computes X n = Xn`1 + X n`2 + Y n I n --- The concrete computation is bounded, which must be proved in the abstract. --- There is no stable interval or octagon. --- The simplest stable surface is an ellipsoid. X X U F(X) F(X) F(X) X X U F(X) execution trace unstable interval stable ellipsoid Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 9 ľ P. Cousot typedef enum {FALSE = 0, TRUE = 1} BOOLEAN; BOOLEAN INIT; float P, X; void filter () { static float E[2], S[2]; if (INIT) { S[0] = X; P = X; E[0] = X; } else { P = (((((0.5 * X) - (E[0] * 0.7)) + (E[1] * 0.4)) + (S[0] * 1.5)) - (S[1] * 0.7)); } E[1] = E[0]; E[0] = X; S[1] = S[0]; S[0] = P; /* S[0], S[1] in [-1327.02698354, 1327.02698354] */ } void main () { X = 0.2 *X+5;INIT = TRUE; while (1) { X=0.9*X+35;/* simulated filter input */ filter (); INIT = FALSE; } } Reference see http://www.astree.ens.fr/ Filter Example Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 10 ľ P. Cousot Arithmetic-geometric progressions --- Abstract domain: (R + ) 5 5 --- Concretization (any function bounded by the arithmeticgeometric progression): 2 (R + ) 5 7`! }(N 7! R) (M;a;b;a 0 ;b 0 )= ff j8k 2 N : jf(k)j» Reference see http://www.astree.ens.fr/ 5 here in R x. ax + b ( x. a 0 x + b 0 ) k (M)g Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 11 ľ P. Cousot Arithmetic-Geometric Progressions (Example 1) % cat count.c typedef enum {FALSE = 0, TRUE = 1} BOOLEAN; volatile BOOLEAN I; int R; BOOLEAN T; void main() { R=0; while (TRUE) { ASTREE_log_vars((R)); if(i){r=r+1;} else {R=0;} T = (R >= 100); ASTREE_wait_for_clock(()); }} % cat count.config ASTREE_volatile_input((I [0,1])); ASTREE_max_clock((3600000)); % astree exec-fn main config-sem count.config count.c grep R R <= 0. + clock *1. <= 3600001. potential overflow! Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 12 ľ P. Cousot

% cat retro.c typedef enum {FALSE=0, TRUE=1} BOOL; BOOL FIRST; volatile BOOL SWITCH; volatile float E; float P, X, A, B; Arithmetic-geometric progressions (Example 2) void dev( ) { X=E; if (FIRST) { P = X; } else { P = (P - ((((2.0 * P) - A) - B) * 4.491048e-03)); }; B = A; if (SWITCH) {A = P;} else {A = X;} } void main() { FIRST = TRUE; while (TRUE) { dev( ); FIRST = FALSE; ASTREE_wait_for_clock(()); }} % cat retro.config ASTREE_volatile_input((E [-15.0, 15.0])); ASTREE_volatile_input((SWITCH [0,1])); ASTREE_max_clock((3600000)); P <= (15. + 5.87747175411e-39 / 1.19209290217e-07) * (1 + 1.19209290217e-07)ˆclock - 5.87747175411e-39 / 1.19209290217e-07 <= 23.0393526881 Towards System Verification Tools Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 13 ľ P. Cousot Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 14 ľ P. Cousot Computer controlled systems Software test Approximations: program! precise, system! precise Abstractions: program! none, system! precise Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 15 ľ P. Cousot Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 16 ľ P. Cousot

--- Very expensive --- Not exhaustive --- Extended during flight test period --- Late discovery of errors can delay the program by months (the whole software development process must be rechecked) Software analysis & verification with ASTRÉE Abstractions: program! precise, system! coarse Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 17 ľ P. Cousot Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 18 ľ P. Cousot --- Exhaustive --- Can be made precise by specialization 6 to get no false alarm --- No specification of the controlled system (but for ranges of values of a few sensors) --- Impossible to prove essential properties of the controlled system (e.g. controlability, stability) System analysis & verification by control engineers 6 To specific families of properties and programs Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 19 ľ P. Cousot Abstractions: program! imprecise, system! precise Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 20 ľ P. Cousot

--- The controler model is a rough abstraction of the control program: -- Continuous, not discrete -- Limited to control laws -- Does not take into account fault-tolerance to failures and computer-related system dependability. --- In theory, SDP-based search of system invariants (Lyapunovlike functions) can be used to prove reachability and inevitability properties --- Problems to scale up (e.g. over long periods of time) --- In practice, the system/controler model is explored by discrete simulations (testing) Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 21 ľ P. Cousot Exploring new avenues in static analysis Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 22 ľ P. Cousot System analysis & verification, Avenue 1 --- Exhaustive (contrary to current simulations) --- Traditional abstractions (e.g. polyhedral abstraction with widening) seem to be too imprecise --- Currently exploring new abstractions (issued from control theory like ellipsoidal calculus using SDP) --- Prototype implementation in construction! Abstractions: program! precise, system! precise Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 23 ľ P. Cousot Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 24 ľ P. Cousot

System analysis & verification, Avenue 2 Abstractions: program! precise, system! precise --- Example of invariant translation: ellipsoidal `! polyhedral 7 --- The static analysis is easier on the system/controller model using continuous optimization methods --- The translated invariants can be checked for the system simulator/control program (easier than invariant discovery) --- Should scale up since these complex invariants are relevant to a small part of the control program only 7 For which floating point computations can be taken into account Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 25 ľ P. Cousot Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 26 ľ P. Cousot System analysis & verification, Avenue 3 Abstractions: program! precise, system! precise --- The invariant hypotheses on the controlled system are assumed to be true --- It remains to perform the control program analysis under these hypothesis --- The results can then be checked on the whole system (as in case 2, but now using refined invariants on the control program!) --- Iterating this process leads to static analysis by refinement of specifications Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 27 ľ P. Cousot Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 28 ľ P. Cousot

Conclusion Scientific and technologic objective To develop formal tools to answer questions about software: --- from control model design to software implementation, --- for a wide range of design and software properties, which would be general enough to benefit all softwareintensive industries, and can be adapted to specific application domains. Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 29 ľ P. Cousot Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 30 ľ P. Cousot --- Investing Research on software safety and security 1 10000 or even less of the software costs in research is far from sufficient --- A sustained effort of 1 to 3%would be more realistic and could significantly contribute to progress in the 10 forthcoming years. Critical Research Areas in Aerospace Software, MIT August 9 th, 2005 30 ľ P. Cousot