Loading in 5 sec....

Verification in the Model-Based Design FlowPowerPoint Presentation

Verification in the Model-Based Design Flow

- 107 Views
- Uploaded on

Download Presentation
## PowerPoint Slideshow about 'Verification in the
Model-Based Design Flow' - sheehan

**An Image/Link below is provided (as is) to download presentation**

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

### Verification in the Model-Based Design Flow

Bruce H. Krogh

CMACS Review

March 4, 2010

TexPoint fonts use in EMF.

Read the TexPoint manual before you delete this box.: AAAAAAAAAAAAAAAA

Overview

- VVIACS
- Model reduction
- Heterogeneous verification
- Verification of numerical code
- Current directions

FCS – Design flow (LM – VVIACS Project)

Model-based Environments

Formal Specification Techniques

Advanced V&V-aware Designs

Control Analysis

Software Implementation

Formal V&V

Automated Test

Process-Based Certification

flows & blocks modifiedfrom current process

Other Subsystems Requirements

Control Law Requirements

Software Requirements

Hardware Requirements

Subsystem Unit and Component Testing

Other Subsystem Design

Stability and Control

System Level Certification

Control Law Design & Analysis

Hardware & Software Integration Testing

Software Unit and Component Testing

System Level Testing

VMS:

System Requirements

Software Design & Analysis

Hardware Qual & Acceptance Testing

Hardware Design & Analysis

Test Tool Development

Simulation

FCS – Cost of Testing

Future Military Program Testing Hours Are Forecast to Triple

Significant Cost/Schedule Increase Projected Due to Complexity

VVIACS - Impact Analysis Results- Single-Vehicle ECS Increases Development Costs ~ 50%, V&V Costs ~ 100%, and Critical Path Length ~ 50%
- Multiple-Vehicle ECS Increases Development Costs ~ 100%, V&V Costs ~ 150%, and Critical Path Length ~ 125%
- Software: Single-Vehicle 100% Increase and Multiple-Vehicle 200% Increase in V&V Costs
- Test: Single-Vehicle 150% Increase and Multiple-Vehicle 250% Increase in V&V Costs

Far-Term (7-9 Yrs) Process Complexity

- Formal Req/Spec
- V&V Aware

Subsystem Unit and Component Testing

Other Subsystems Requirements

Other Subsystem Design

Stability and Control

System Level Certification

Algorithm Design, Analysis and Functional Test

Algorithm Requirements

Software Analysis, Design, Integration

Integration & System Level Testing

Vehicle:

System Requirements

Software Requirements

Rapid Proto Type Hardware and Test Environment

Hardware Qual & Acceptance Testing

Hardware Requirements

Hardware Design & Analysis

Test Tool Development

Simulation

Some Goals Complexity

- Guarantee correct behavior of the complete system especially with respect to
- timing constraints in the implementation
- performance specifications associated with mission-level objectives

- Develop a comprehensive approach integrating verification, validation and test procedures throughout the complete development cycle, from requirements capture to deployment.
- Achieve confidence levels that exceed those achievable by current practice and current technologies for systems that incorporate emerging adaptive and intelligent control laws.

Model Reduction for Scalability of Hybrid System Verification

- Use simplifiedmodels and/or set representations to perform the reach set computations

Model

Model Order Reduction

-decomposition

Piecewise Linearization

Set representation

Full-dimensionalpolytopes

Low-dimensional polytopesand their neighborhoods

Heterogeneous Verification Verification

- Motivation:
- verifying properties of complete systems is beyond the reach of any one tool or modeling formalism

- Objective:
- reason about verification information collected from multiple sources to achieve system-level verification

System

Unstructured, semi-structured and structured information from various analyses on components

/models.

Verification report

. . . .

Existing

docs

Hybrid

Analysis

Discrete

Analysis

Simulation

Heterogeneous Verification Verification

Managing knowledge for model-based development

embedded system ontology

(base domain description)

entities,

relationships,

rules

ontology

specialization

domain experts

heterogeneous information

sources

specialized ontology

docs

hybrid analysis

static ontology + epistemic ontology

model

development

&

verification

activities

developers

knowledge

assimilation

discrete analysis

simulation

information

knowledge base (Protégé)

targeted knowledge

acquisition

database + epistemic rule base

requirements

inference engine

queries

knowledge

composition,

deduction

update

verification manager

inferences +

knowledge gaps

Verification of numerical programs Verification

- Problem definition
- Polyhedral domains
- Control flow automata (CFA)
- CFA reachability
- Widening based on coefficient limiting
- CFA reduction
- Kahan summation example
- Conclusions

Design and implementation of numerical programs Verification

design model

model-based development

source code implementation

code generation

target processor

compiler

platform implementation

Verification of numerical programs Verification

design model

Need to verify how

numerical code will

execute on the target

processor

code generation

target processor

compiler

Verification of numerical programs Verification

design model

disassembler

control flow graph

numerical

program

verifier

target processor

error model

CFA generator

code generation

CFA

PHAVer

target processor

compiler

reachability

results

Verification of numerical programs Verification

design model

today’s presentation

disassembler

control flow graph

target processor

error model

CFA generator

code generation

CFA

PHAVer

target processor

compiler

reachable sets

error

bounds

Scope of this work Verification

- instructions of the form
- real constants and variables
- linear arithmetic
- floating point error bounds

Polyhedral domains Verification

- linear predicates
- convex polyhedron: conjunction of linear predicates
- polyhedron: disjunction of convex polyhedra
- Parma Polyhedra Library (PPL): performs exact computations with non-convex polyhedra
- PHAVer: performs reachability for LHA
- exact and robust arithmetic with unlimited precision (PPL)
- bit-constrained over-approximations for termination heuristics
- on-the-fly over-approximation of piecewise affine dynamics
- support for compositional and assume-guarantee reasoning.

6 Verification

x

6

y

6

y

1

109

x

121

y

100

0

1

x

Exact Arithmetic in PHAVer- Finite resources require over approximation
- Semi-bounded exact arithmetic
- exact computations that result in finite precision

- * Managing the complexity by over-approximation

generate time-elapse polyhedron

* compute conservative over-approximation

derivative

initial set

limit the number of bits of coefficients

limit the number of constraints

Control flow automata (CFA) Verification

- same node/transition structure as the control flow graph
- instructions replaced by action predicates on the transitions representing the operation error bounds

CFA example Verification

CFA reachability Verification

- CFA state: (q,x) – q discrete state, x valuation of variables x
- Reachable states: smallest fixed point of

where

- All sets are polyhedra
- In general, the reachability iteration will not terminate

Widening for iterative computations Verification

- Accelerates convergence to a fixed point.

P. Cousot and R. Cousot. Abstract interpretation: A unified lattice model for static analysis of programs by construction or approximation of fixpoints. In Proceedings of the Fourth Annual ACM Symposium on Principles of Programming Languages, pp. 238-252, New York, 1977. ACM Press.

Standard widening Verification

- defined for convex polyhedra
- retains
- constraints of P1 also satisfied by P2
- and
- constraints of P2 with equivalent constraints in P1

Standard widening: example Verification

exact

(nonterimintating)

- std. widening
- terminates at iteration 5
- large overapproximation

Widening based on coefficient limiting (NEW) Verification

- Preliminaries:
- CP : set of linear predicates defining polyhedron P
- assume integer coefficients with common divisor 1
- max_coeff(CP) : maximum coefficient in CP
- coeff_limit(P,k) : polyhedron P such that
- 1) P P
- 2) max_coeff(CP) k
- NOTE: Such a P is computed by PHAVer

Widening based on coefficient limiting (NEW) Verification

- Proposition 1. is a widening operator.
- follows from

Example 2: Non-convex polyhedra (w/o convex hull) Verification

CFA Reduction Verification

- Objective: Given a set of variables W, reduce the number of transitions and variables in the CFA without affecting the reachable set for the variables in W.

Merging transitions Verification

- Transition condition for merging

- applied only to the first transition in a pair of transitions

Eliminating irrelevant variables Verification

- transition merging increases the number of globally irrelevant variables
- retains variables that influence error bounds on variables of interest

Precision vs. Efficiency using Verification

- Value of k introduces a tradeoff between - accuracy of polyhedral approximations and - complexity of the computations
- Smaller k increases the over approximation but doesn’t necessarily make termination faster

Example: Kahan summation algorithm Verification

- adding N numbers: error = Ne
- Kahan algorithm introduces intermediate variables to mitigate the effects of repeated summations: error = 2e +O(Ne2)
- From Wikipedia:
- function kahanSum(input, n)
- var sum = input[1]
- var c = 0.0 // A running compensation for lost low-order bits.
- for i = 2 to n
- y = input[i] - c // So far, so good: c is zero.
- t = sum + y // Alas, sum is big, y small, so low-order digits of y are lost.
- c = (t - sum) - y //(t - sum) recovers the high-order part of y;
- // subtracting y recovers -(low part of y)
- sum = t // Algebraically, c should always be zero.
- // Beware eagerly optimising compilers!
- next i // Next time around, the lost low part will
- // be added to y in a fresh attempt.
- return sum

Our implementation Verification

- e = 1.192092896e-7 (i386)
- x0 = 1
- xi = 0.1249999403953552
- N = 8

reduced: 3 locations, 3 transitions, vars y,t eliminated

Current Directions Verification

- Integration through architecture
- Assume-guarantee approach to controller-plant decomposition
- Innovative uses of reachability

Download Presentation

Connecting to Server..