12.03.2014 Views

Formal Methods in the Aerospace Industry: Follow the Money ICFEM

Formal Methods in the Aerospace Industry: Follow the Money ICFEM

Formal Methods in the Aerospace Industry: Follow the Money ICFEM

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Formal</strong> <strong>Methods</strong> <strong>in</strong> <strong>the</strong><br />

<strong>Aerospace</strong> <strong>Industry</strong>:<br />

<strong>Follow</strong> <strong>the</strong> <strong>Money</strong><br />

<strong>ICFEM</strong><br />

15 November 2012<br />

Dr. Darren Cofer<br />

cofer@ieee.org<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Rockwell Coll<strong>in</strong>s<br />

Headquartered <strong>in</strong> Cedar Rapids, Iowa<br />

20,000 Employees Worldwide<br />

2012 Sales of ~$4.8 Billion<br />

Commercial & Military Avionics Systems<br />

Flight Control Systems & Displays<br />

Heads Up Displays<br />

Navigation & Land<strong>in</strong>g Systems<br />

Defense Communications<br />

Weapons Data L<strong>in</strong>ks<br />

Cryptographic Equipment<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

Domestic<br />

California<br />

Carlsbad<br />

Cypress<br />

Irv<strong>in</strong>e<br />

Los Angeles<br />

Pomona<br />

Poway<br />

San Francisco<br />

San Jose<br />

Tust<strong>in</strong><br />

Florida<br />

Melbourne<br />

Miami<br />

Orlando<br />

Georgia<br />

Atlanta<br />

Warner Rob<strong>in</strong>s<br />

Hawaii<br />

Honolulu<br />

Ill<strong>in</strong>ois<br />

Chicago<br />

Iowa<br />

Bellevue<br />

Coralville<br />

Decorah<br />

Manchester<br />

Kansas<br />

Wichita<br />

Maryland<br />

White Marsh<br />

Massachusetts<br />

Boston<br />

Michigan<br />

Ann Arbor<br />

Detroit<br />

M<strong>in</strong>nesota<br />

M<strong>in</strong>neapolis<br />

Missouri<br />

Kansas City<br />

St. Louis<br />

New York<br />

New York<br />

North Carol<strong>in</strong>a<br />

Charlotte<br />

Raleigh<br />

Oklahoma<br />

Midwest City<br />

Tulsa<br />

Oregon<br />

Portland<br />

Pennsylvania<br />

Philadelphia<br />

Pittsburgh<br />

Texas<br />

Dallas<br />

Fort Worth<br />

Richardson<br />

Utah<br />

Salt Lake City<br />

Virg<strong>in</strong>ia<br />

Sterl<strong>in</strong>g<br />

Warrenton<br />

Wash<strong>in</strong>gton<br />

Kirkland<br />

Renton<br />

Seattle<br />

Wash<strong>in</strong>gton, DC<br />

Advanced Technology Center<br />

Trusted Systems group<br />

(<strong>Formal</strong> <strong>Methods</strong> researchers)<br />

International<br />

Africa<br />

Johannesburg, South Africa<br />

Asia<br />

Bangkok, Thailand<br />

Beij<strong>in</strong>g, Ch<strong>in</strong>a<br />

Hong Kong<br />

Hyderabad, India<br />

Kuala Lumpur, Malaysia<br />

Manila, Philipp<strong>in</strong>es<br />

Moscow, Russia<br />

Osaka, Japan<br />

Shanghai, Ch<strong>in</strong>a<br />

S<strong>in</strong>gapore<br />

Tokyo, Japan<br />

Australia<br />

Auckland, New Zealand<br />

Brisbane, Australia<br />

Melbourne, Australia<br />

Sydney, Australia<br />

Canada<br />

Montreal<br />

Ottawa<br />

Europe<br />

Amsterdam, Ne<strong>the</strong>rlands<br />

Frankfurt, Germany<br />

Heidelberg, Germany<br />

London, England<br />

Lyon, France<br />

Manchester, England<br />

Paris, France<br />

Read<strong>in</strong>g, England<br />

Rome, Italy<br />

Toulouse, France<br />

Mexico<br />

Mexicali<br />

South America<br />

Santiago, Chile<br />

Sao Jose dos Campos, Brazil<br />

Sao Paulo, Brazil


Outl<strong>in</strong>e<br />

• Problem<br />

– Verification of high-assurance complex systems<br />

• Why use formal methods<br />

– Cost, safety, certification<br />

• <strong>Formal</strong> methods for verification<br />

– Model check<strong>in</strong>g<br />

• <strong>Formal</strong> methods for certification<br />

– DO-178C / DO-333<br />

• What’s next<br />

– Compositional reason<strong>in</strong>g<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

3


Doma<strong>in</strong> – avionics<br />

• Embedded systems with safety and security<br />

requirements that are critical to operation of vehicle and<br />

performance of <strong>the</strong> mission<br />

• Commercial and military<br />

• Manned and unmanned<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

4


Software <strong>in</strong> commercial aircraft<br />

B787: 6.5M<br />

Boe<strong>in</strong>g’s new 787 Dreaml<strong>in</strong>er…requires about<br />

6.5 million l<strong>in</strong>es of software code to operate its<br />

avionics and onboard support systems.<br />

This Car Runs on Code, IEEE Spectrum, 2/09<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Software <strong>in</strong> military aircraft<br />

“Software provid<strong>in</strong>g essential JSF capability has<br />

grown <strong>in</strong> size and complexity, and is tak<strong>in</strong>g longer<br />

to complete than expected,” <strong>the</strong> GAO warned.<br />

Pentagon: Trillion-Dollar Jet on Br<strong>in</strong>k of<br />

Budgetary Disaster, Wired 3/21/12<br />

F-35<br />

Source: D. Gary Van Oss (USAF), “Avionics Acquisition, Production, and Susta<strong>in</strong>ment: Lessons<br />

Learned – The Hard Way,” NDIA Systems Eng<strong>in</strong>eer<strong>in</strong>g Conference, Oct 2002.<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


The use of formal methods is motivated by <strong>the</strong><br />

expectation that, as <strong>in</strong> o<strong>the</strong>r eng<strong>in</strong>eer<strong>in</strong>g<br />

discipl<strong>in</strong>es, perform<strong>in</strong>g appropriate ma<strong>the</strong>matical<br />

analyses can contribute to establish<strong>in</strong>g <strong>the</strong><br />

correctness and robustness of a design.<br />

FM : software ::<br />

FEA : structure<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

7


Why use formal methods with avionics SW?<br />

(A lesson <strong>in</strong> technology transition)<br />

• Increase confidence?<br />

– Complete exam<strong>in</strong>ation of complex software and requirements<br />

– “Our systems are already safe.”<br />

• Satisfy certification objectives?<br />

– DO-178C allows certification credit for formal methods<br />

– Requirements/model verification is done by review (too cheap), and<br />

formal source/object code verification is difficult (too expensive)<br />

• Reduce cost?<br />

– YES!<br />

– Early detection/elim<strong>in</strong>ation of defects<br />

– Automation of verification activities<br />

<strong>Follow</strong> <strong>the</strong> money.<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


<strong>Formal</strong> <strong>Methods</strong><br />

for Verification<br />

<strong>Formal</strong> <strong>Methods</strong><br />

for Certification<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

10


1<br />

sync<br />

syn c<br />

2<br />

<strong>in</strong>put_a<br />

3<br />

<strong>in</strong>put_b<br />

4<br />

<strong>in</strong>put_c<br />

5<br />

status_a<br />

6<br />

status_b<br />

7<br />

statu s_c<br />

8<br />

dst_<strong>in</strong>dex<br />

DOC<br />

Text<br />

[trigger]<br />

[A]<br />

[B]<br />

[C]<br />

[status_a]<br />

[status_b]<br />

[status_c]<br />

[DSTi]<br />

[trigger]<br />

[A]<br />

[B]<br />

[C]<br />

trip_level<br />

trip_level1<br />

persist_lim<br />

persistence limit<br />

[MS]<br />

[DSTi]<br />

DST<br />

Data Store<br />

Read<br />

trip_lev el<br />

persist_lim<br />

Index<br />

Vector<br />

<strong>in</strong>put_a<br />

<strong>in</strong>put_b<br />

<strong>in</strong>put_c<br />

trip_lev el<br />

Extract Bits<br />

[0 3]<br />

Extract Bits<br />

f ailreport<br />

f ailreport<br />

double<br />

pc<br />

persistence_cnt<br />

2<br />

persistence_cnt<br />

persist_lim<br />

[trigger]<br />

tc<br />

3<br />

totalizer_cnt<br />

[A]<br />

totalizer_cnt<br />

MS<br />

[B]<br />

[C]<br />

triplex_<strong>in</strong>put_monitor<br />

[DSTi]<br />

[MS]<br />

[status_a]<br />

[status_b]<br />

[status_c]<br />

[prev_sel]<br />

[A]<br />

[B]<br />

[C]<br />

mon_f ailure_report<br />

status_a<br />

status_b<br />

status_c<br />

f ailure_report<br />

prev _sel<br />

<strong>in</strong>put_a<br />

<strong>in</strong>put_b<br />

<strong>in</strong>put_c<br />

Failure_Isolation<br />

pc<br />

trigger<br />

<strong>in</strong>put_a<br />

<strong>in</strong>put_sel<br />

<strong>in</strong>put_b<br />

<strong>in</strong>put_c<br />

DST_<strong>in</strong>dex<br />

triplex_<strong>in</strong>put_selector<br />

4<br />

<strong>in</strong>put_sel<br />

1<br />

failure_report<br />

[prev_sel]<br />

[DSTi]<br />

f ailure_report<br />

dst_<strong>in</strong>dex<br />

Failure_Process<strong>in</strong>g<br />

Model-based development<br />

Doma<strong>in</strong>-specific (often) graphical design<br />

environments for software development<br />

– Early simulation and debugg<strong>in</strong>g<br />

– Automated code generation<br />

– DSL promotes higher level of abstraction<br />

<strong>in</strong> design<br />

MBD enhances <strong>the</strong> FM value proposition<br />

STATE Transition( char *str ) {<br />

<strong>in</strong>t NEXT_SYMBOL;<br />

for( ; *str && state != INVALID; str++ ) {<br />

NEXT_SYMBOL = *str;<br />

switch(state) {<br />

case START:<br />

if(isdigit(NEXT_SYMBOL)) {<br />

state = INT;<br />

ABSTRACT<br />

CONCRETE<br />

• Take advantage of<br />

– <strong>Industry</strong> adoption of Model-Based Development tools<br />

– Increas<strong>in</strong>g power of formal methods analysis eng<strong>in</strong>es<br />

– Moore’s Law<br />

• Use formal methods to fight cost and complexity with<br />

automation and rigor<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Barriers to use of FM<br />

• “If formal methods are so great, why aren’t <strong>the</strong>y more widely<br />

used?”<br />

• The ma<strong>in</strong> barriers <strong>in</strong> <strong>the</strong> past have been:<br />

1. Cost: build<strong>in</strong>g/ma<strong>in</strong>ta<strong>in</strong><strong>in</strong>g separate analysis models<br />

2. Fidelity: models don’t match real system<br />

3. Usability: unfamiliar notations/tools<br />

4. Scale: <strong>in</strong>adequacy of tools for <strong>in</strong>dustrial-sized problems<br />

• MBD is elim<strong>in</strong>at<strong>in</strong>g <strong>the</strong> first three barriers<br />

– Leverages exist<strong>in</strong>g model<strong>in</strong>g effort<br />

– Automated translations and analysis<br />

– Familiar notations for eng<strong>in</strong>eers (Simul<strong>in</strong>k + Stateflow)<br />

• Fourth barrier is also fall<strong>in</strong>g…<br />

– Moore’s Law = more power available on desktop<br />

– Exploit rapid advances <strong>in</strong> model check<strong>in</strong>g (e.g., SMT)<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Problem: bridg<strong>in</strong>g <strong>the</strong> gap<br />

• MBD captures design at sufficient detail and sufficient formality<br />

• Powerful formal methods tools can analyze large models<br />

• However…<br />

– <strong>the</strong>re are still a variety of models used <strong>in</strong> MBD environments<br />

– and many good analysis tools with different strengths and<br />

weaknesses<br />

{ KIND }<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Automatic translation<br />

Gryphon<br />

translation<br />

framework<br />

• Supports a wide<br />

variety of back end<br />

tools and languages<br />

• Straightforward to<br />

add new tools (e.g.<br />

Prover support<br />

added <strong>in</strong> 4 days)<br />

• Apply “<strong>the</strong> right tool<br />

for <strong>the</strong> job”<br />

Automatic<br />

translation<br />

Design feedback<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Translator Framework<br />

Lustre: <strong>in</strong>termediate<br />

representation of AST<br />

Translator<br />

Target Code<br />

…<br />

• Mechanism: Small source-to-source transformations <strong>in</strong> Lustre<br />

– Deal with one language aspect at a time<br />

– Def<strong>in</strong>e pre/post-conditions that describe when transformation can be<br />

performed and its effect<br />

– Ref<strong>in</strong>e Lustre specification until it resembles target language<br />

– Create language-specific emitter to output target code<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Transformations<br />

RC<br />

Lustre<br />

Pretty<br />

Pr<strong>in</strong>t<br />

C Code<br />

RFBY<br />

Lustre<br />

RDV<br />

Lustre<br />

IAS<br />

Pretty<br />

Lustre<br />

RC<br />

Pr<strong>in</strong>t<br />

Lustre Ada Code<br />

RNC<br />

REP<br />

Lustre Lustre Lustre<br />

REN<br />

Lustre<br />

RNC<br />

Lustre<br />

IPS<br />

Lustre<br />

Pretty<br />

Pr<strong>in</strong>t<br />

PVS<br />

FNH<br />

RACT<br />

Lustre<br />

SCA<br />

Lustre<br />

Pretty<br />

Pr<strong>in</strong>t<br />

NuSMV<br />

Lustre<br />

RDV<br />

Lustre<br />

RNST<br />

Pretty<br />

Lustre<br />

PTL<br />

Pr<strong>in</strong>t<br />

Lustre Prover<br />

• Different target languages use different comb<strong>in</strong>ations of<br />

transformations<br />

– May be 50+ transformations for a given target<br />

• Transformations optimize f<strong>in</strong>al output for target language<br />

– Strengths of selected analysis eng<strong>in</strong>e<br />

– Speed/size/readability of source code<br />

– Reduce analysis times from hours to seconds<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Application: Elim<strong>in</strong>ate errors<br />

ADGS-2100<br />

W<strong>in</strong>dow Manager SW<br />

(cockpit display)<br />

WM<br />

WM<br />

PFD EICAS MAP<br />

…<br />

PFD EICAS MAP<br />

…<br />

Display Application<br />

W<strong>in</strong>dow Manager<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


ADGS-2100 model check<strong>in</strong>g results<br />

Requirement<br />

R1: If a DU is available, <strong>the</strong>n it<br />

shall display some application<br />

R2: If a DU is unavailable, <strong>the</strong>n it<br />

shall not attempt to display any<br />

application<br />

R3: The cursor will not be<br />

displayed on a DU that is<br />

unavailable<br />

R4: The cursor shall not be<br />

displayed on a DU whose<br />

application is not MAP<br />

CTL Properties<br />

AG( LEFT_DU_AVAILABLE -> LEFT_DU_APPLICATION != BLANK )<br />

AG( RIGHT_DU_AVAILABLE -> RIGHT_DU_APPLICATION != BLANK )<br />

AG( !LEFT_DU_AVAILABLE -> LEFT_DU_APPLICATION = BLANK )<br />

AG( !RIGHT_DU_AVAILABLE -> RIGHT_DU_APPLICATION = BLANK )<br />

AG( !LEFT_DU_AVAILABLE -> CURSOR_LOCATION != LEFT_DU )<br />

AG( !RIGHT_DU_AVAILABLE -> CURSOR_LOCATION != RIGHT_DU )<br />

AG( LEFT_DU_APPLICATION != MAP -> CURSOR_LOCATION != LEFT_DU))<br />

AG( RIGHT_DU_APPLICATION != MAP -> CURSOR_LOCATION != RIGHT_DU)<br />

Subsystem<br />

Simul<strong>in</strong>k Simul<strong>in</strong>k<br />

Diagrams Blocks<br />

State Space Properties Errors found<br />

GG 2,831 10,669 9.8 x 10 9 43 56<br />

PS 144 398 4.6 x 10 23 152 10<br />

CM 139 1,009 1.2 x 10 17 169 10<br />

DUF 879 2941 1.5 x 10 37 115 8<br />

MFD 302 1,100 6.8 x 10 31 84 14<br />

Totals 4295 16,117 n/a 563 98<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

19


Application: Elim<strong>in</strong>ate errors and save money<br />

• AFRL CerTA FCS program<br />

– Team: Lockheed Mart<strong>in</strong> + Rockwell Coll<strong>in</strong>s<br />

• Problem<br />

– The cost of software V&V for UAVs has been identified as <strong>the</strong><br />

primary obstacle to <strong>the</strong>ir future development<br />

– These costs are expected to grow rapidly as sophisticated adaptive<br />

control systems are <strong>in</strong>troduced<br />

• Measure cost and quality improvements us<strong>in</strong>g model check<strong>in</strong>g<br />

for verification of UAV software<br />

– Use RC model-check<strong>in</strong>g tools to verify LM Aero advanced flight<br />

control models<br />

– Quantify <strong>the</strong> cost and quality achieved by formal verification vs.<br />

test-based verification<br />

It’s a contest!<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Redundancy Manager software for UAV<br />

• Sensor fusion, failure detection,<br />

and reset management for sets of<br />

triply redundant sensors<br />

• Mostly discrete logic: ideal<br />

problem for model check<strong>in</strong>g<br />

Subsystem<br />

Triplex voter<br />

no FHT<br />

failure<br />

process<strong>in</strong>g<br />

reset<br />

manager<br />

Subsystems<br />

/ Blocks<br />

Charts /<br />

Transitions /<br />

TT Cells<br />

Reachable<br />

State<br />

Space<br />

Properties<br />

Confirmed<br />

Errors<br />

10 / 96 3 / 35 / 198 6.0 * 10 13 48 5<br />

7 / 42 0 / 0 / 0 2.1 * 10 4 6 3<br />

6 / 31 2 / 26 / 0 1.32 * 10 11 8 4<br />

Totals 23 / 169 5 / 61 / 198 N/A 62 12<br />

1<br />

sync<br />

sync<br />

2<br />

<strong>in</strong>put_a<br />

3<br />

<strong>in</strong>put_b<br />

4<br />

<strong>in</strong>put_c<br />

5<br />

status_a<br />

6<br />

status_b<br />

7<br />

status_c<br />

8<br />

dst_<strong>in</strong>dex<br />

[trigger]<br />

[A]<br />

[B]<br />

[C]<br />

[status_a]<br />

[status_b]<br />

[status_c]<br />

[DSTi]<br />

[trigger]<br />

[A]<br />

[B]<br />

[DSTi]<br />

DST<br />

Data Store<br />

Read<br />

Index<br />

Vector<br />

<strong>in</strong>put_a<br />

<strong>in</strong>put_b<br />

Extract Bits<br />

[0 3]<br />

Extract Bits<br />

f ailreport<br />

f ailreport<br />

double<br />

[MS]<br />

[status_a]<br />

[status_b]<br />

[status_c]<br />

[prev_sel]<br />

[A]<br />

[B]<br />

[C]<br />

mon_f ailure_report<br />

status_a<br />

status_b<br />

status_c<br />

f ailure_report<br />

prev _sel<br />

<strong>in</strong>put_a<br />

<strong>in</strong>put_b<br />

<strong>in</strong>put_c<br />

failure<br />

isolation<br />

1<br />

failure_report<br />

[DSTi]<br />

f ailure_report<br />

dst_<strong>in</strong>dex<br />

Failure_Process<strong>in</strong>g<br />

DOC<br />

Text<br />

triplex<br />

monitor<br />

[C]<br />

trip_level<br />

trip_lev el<br />

trip_level1<br />

persist_lim<br />

persist_lim<br />

persistence limit<br />

[MS]<br />

<strong>in</strong>put_c<br />

pc<br />

trip_lev el<br />

persist_lim<br />

tc<br />

MS<br />

triplex_<strong>in</strong>put_monitor<br />

persistence_cnt<br />

3<br />

totalizer_cnt<br />

totalizer_cnt<br />

2<br />

persistence_cnt<br />

[trigger]<br />

[A]<br />

[B]<br />

[C]<br />

[DSTi]<br />

Failure_Isolation<br />

pc<br />

trigger<br />

<strong>in</strong>put_a<br />

<strong>in</strong>put_sel<br />

<strong>in</strong>put_b<br />

<strong>in</strong>put_c<br />

DST_<strong>in</strong>dex<br />

4<br />

<strong>in</strong>put_sel<br />

sensor<br />

fusion<br />

[prev_sel]<br />

failure<br />

process<strong>in</strong>g<br />

(logg<strong>in</strong>g)<br />

triplex_<strong>in</strong>put_selector<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Redundancy Manager counterexample<br />

Requirement:<br />

A sensor that does not miscompare<br />

shall not be declared failed <strong>in</strong> <strong>the</strong> next frame.<br />

Property: SPEC AG((!b_miscompare & !dst_b_failed) -><br />

AX (failure_report != b_failed));<br />

Counterexample:<br />

INPU TS<br />

<strong>in</strong>put_a 0 3 3 3 3 3<br />

<strong>in</strong>put_b 0 1 1 1 1 5<br />

<strong>in</strong>put_c 0 3 3 3 3 5<br />

status_a 0 0 0 0 0 0<br />

status_b 0 0 0 0 0 0<br />

status_c 0 0 0 0 0 0<br />

OUTPUTS<br />

failure_report 0 0 0 0 0 4<br />

persistence_cnt 0 1 2 3 4 0<br />

totalizer_cnt 0 1 2 3 4 4<br />

Sensor b miscompares for 4 steps.<br />

Sensor a miscompares<br />

on next step.<br />

Sensor a is declared<br />

failed <strong>in</strong>stead of<br />

sensor b!<br />

(failure report “4”)<br />

Problem:<br />

Only one miscompare persistence counter<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Test<strong>in</strong>g vs. Model Check<strong>in</strong>g<br />

• LM and RC teams start with<br />

same set of requirements and<br />

software models<br />

• Both teams spent comparable<br />

effort to add enhancements to<br />

<strong>the</strong>ir verification framework<br />

(support for new blocks,<br />

graphical test case viewer, XML<br />

test case generation)<br />

• Measure effort to perform<br />

verification and diagnose<br />

results<br />

• [FMICS 2007]<br />

LM: Test<br />

RC: MC<br />

Redundancy Manager<br />

(verification effort)<br />

Effort<br />

X<br />

0.7X<br />

Errors found<br />

0<br />

12<br />

RC effort<br />

<strong>in</strong>cludes fix<strong>in</strong>g<br />

<strong>the</strong> errors found!<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Certification and civil aviation<br />

• Software is not actually certified<br />

• But certification of an aircraft does <strong>in</strong>clude “software<br />

considerations”<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


DO-178B:<br />

“Software Considerations <strong>in</strong> Airborne Systems<br />

and Equipment Certification”<br />

• Published <strong>in</strong> 1992<br />

• Developed jo<strong>in</strong>tly by <strong>in</strong>dustry and<br />

governments from North America and<br />

Europe<br />

– Published by RTCA <strong>in</strong> U.S.<br />

– Published by EUROCAE <strong>in</strong> Europe as ED-12B<br />

• Certification authorities agree that an<br />

applicant can use guidance conta<strong>in</strong>ed <strong>in</strong><br />

DO-178B as a means of compliance (but<br />

not <strong>the</strong> only means) with federal<br />

regulations govern<strong>in</strong>g aircraft certification<br />

• What about military aircraft?<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Overview of DO-178B<br />

• Primarily a quality document, not safety<br />

– Demonstrate that software implements requirements<br />

– and noth<strong>in</strong>g else (no surprises)<br />

• Requires auditable evidence of specific processes<br />

– Software Plann<strong>in</strong>g<br />

– Software Development<br />

– Software Verification<br />

– Software Configuration Management<br />

– Software Quality Assurance<br />

– Certification Liaison<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Overview of DO-178B<br />

• Five Software Levels (DAL <strong>in</strong> o<strong>the</strong>r contexts)<br />

A: Catastrophic (everyone dies)<br />

B: Hazardous/Severe (serious <strong>in</strong>juries)<br />

C: Major (significant reduction <strong>in</strong> safety marg<strong>in</strong>s)<br />

D: M<strong>in</strong>or (annoyance to crew)<br />

E: No Effect (OK to use W<strong>in</strong>dows)<br />

• Objective based<br />

– Specifies what is to be achieved, not how<br />

• Different objectives and requirements for each SW level<br />

– Higher level more objectives to be satisfied<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Verification <strong>in</strong> DO-178B<br />

• Verification = review + analysis + test<br />

• Requirements-based test<strong>in</strong>g<br />

• Traceability among<br />

– Requirements<br />

– Test cases<br />

– Code<br />

• How do we know if we have done enough test<strong>in</strong>g?<br />

– Coverage metrics to determ<strong>in</strong>e adequacy of test<strong>in</strong>g/requirements<br />

• Two complementary objectives<br />

– Demonstrate that <strong>the</strong> software satisfies its requirements.<br />

– Demonstrate with a high degree of confidence that errors which<br />

could lead to unacceptable failure conditions, as determ<strong>in</strong>ed by <strong>the</strong><br />

system safety assessment process, have been removed.<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Coverage metrics<br />

• Def<strong>in</strong>es structural coverage metrics<br />

– Statement coverage (A, B, C)<br />

• Every statement <strong>in</strong> <strong>the</strong> program has been <strong>in</strong>voked at least once<br />

– Decision coverage (A, B)<br />

• and every po<strong>in</strong>t of entry and exit <strong>in</strong> <strong>the</strong> program has been <strong>in</strong>voked at<br />

least once, and every decision (branch) <strong>in</strong> <strong>the</strong> program has taken on all<br />

possible outcomes at least once<br />

– Modified condition / decision coverage (A)<br />

• and every condition <strong>in</strong> a decision <strong>in</strong> <strong>the</strong> program has taken all possible<br />

outcomes at least once, and each condition <strong>in</strong> a decision has been shown<br />

to <strong>in</strong>dependently affect that decision's outcome.<br />

• Coverage shortcom<strong>in</strong>gs could <strong>in</strong>dicate<br />

– Miss<strong>in</strong>g requirements<br />

– Inadequacy of test cases<br />

– Dead or deactivated code<br />

Problem: discrete nature of software<br />

Goal: provide complete evaluation of<br />

software behavior<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


DO-178B Verification Objectives (Level A)<br />

A-3.2 Accuracy & Consistency<br />

A-3.3 HW Compatibility<br />

A-3.4 Verifiability<br />

A-3.5 Conformance<br />

A-3.7 Algorithm Accuracy<br />

A-4. 8 Architecture Compatibility<br />

System<br />

Requirements<br />

A-2: 1, 2<br />

High-Level<br />

Requirements<br />

A-2: 3. 4. 5<br />

A-3.1 Compliance<br />

A-3.6 Traceability<br />

A-6.1 Compliance<br />

A-6.2 Robustness<br />

A-4.1 Compliance<br />

A-4.6 Traceability<br />

A-7.3 Cover<br />

A-7.1 Procedures<br />

Correct<br />

A-4.9 Consistency<br />

A-4.10 HW Compatibility<br />

A-4.11 Verifiability<br />

A-4.12 Conformance<br />

A-4.13 Partition Integrity<br />

A-5.2 Compliance<br />

Software<br />

Architecture<br />

A-5.3 Verifiability<br />

A-5.4 Conformance<br />

A-5.6 Accuracy & Consistency<br />

Design Description<br />

A-2: 6<br />

Source<br />

Code<br />

A-2: 7<br />

Low-Level<br />

Requirements<br />

A-5.1 Compliance<br />

A-5.5 Traceability<br />

A-6.3 Compliance<br />

A-6.4 Robustness<br />

A-4.2 Accuracy & Consistency<br />

A-4.3 HW Compatibility<br />

A-4.4 Verifiability<br />

A-4.5 Conformance<br />

A-4.7 Algorithm Accuracy<br />

A-7.4 Cover<br />

A-7.5-7 Structural<br />

Coverage<br />

Reqts-based<br />

Tests<br />

A-5. 7 Complete<br />

& Correct<br />

Object<br />

Code<br />

A-6.5 Compatible<br />

With Target<br />

A-7.2 Results Correct<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


That was 1992…<br />

• Any changes <strong>in</strong> software technology s<strong>in</strong>ce <strong>the</strong>n?<br />

• New SW development technologies<br />

– Object-oriented programm<strong>in</strong>g languages<br />

– Model-based development (MBD)<br />

• New verification technologies<br />

– <strong>Formal</strong> methods (FM)<br />

• More software!!<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


DO-178C<br />

• In late 2004, RTCA & EUROCAE agree to create jo<strong>in</strong>t<br />

committee to update DO-178B and develop DO-178C<br />

– Start: 2005<br />

– F<strong>in</strong>ish: 2008 2010 2011<br />

• Terms of Reference govern<strong>in</strong>g update<br />

– M<strong>in</strong>imize changes to core document, yet…<br />

– Update to accommodate 15+ years of SW experience<br />

• Strategy: Address new technologies <strong>in</strong> “supplements”<br />

– OO, MBD, FM<br />

– Also tool qualification<br />

• O<strong>the</strong>r issues<br />

– Air/ground synergy (DO-278)<br />

– Rationale, consolidation, issues, errata (DO-248)<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


DO-333: <strong>Formal</strong> <strong>Methods</strong> Supplement<br />

• Objectives<br />

– No longer an “alternate method” (as <strong>in</strong> DO-178B)<br />

– Provide basis for communication between applicants & certification<br />

authorities<br />

– Focus on verification (DO-178 section 6)<br />

– Partial use is OK<br />

– What should formal methods evidence look like?<br />

– Def<strong>in</strong>e new objectives/activities/documentation (abstractions,<br />

assumptions)<br />

– Avoid common errors (check false hypo<strong>the</strong>ses)<br />

• Key issues<br />

– Captur<strong>in</strong>g assumptions used <strong>in</strong> analysis (constra<strong>in</strong>ts, assertions,<br />

environment…)<br />

– If analysis replaces unit test<strong>in</strong>g, what constitutes “completeness” of<br />

analysis? (analog of MC/DC coverage metric)<br />

– How should formal analysis tools be qualified?<br />

• Keep <strong>the</strong> bar high enough<br />

– Applicants with sufficient expertise<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


NASA DO-333 Case Study project<br />

Theorem Prov<strong>in</strong>g<br />

Abstract Interpretation<br />

Model Check<strong>in</strong>g<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

39


What’s next?<br />

Compositional<br />

Reason<strong>in</strong>g<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

40


Vision: “Integrate, <strong>the</strong>n Build”<br />

• Build on success of formal verification of software components<br />

• Extend to system level via software architecture models<br />

• Goals: Early detection/elim<strong>in</strong>ation of bugs<br />

– Cheaper to fix <strong>in</strong> design vs. <strong>in</strong>tegration<br />

– High-assurance<br />

• Hardware analogy…<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Scale and Composition<br />

• Architectural model should not capture implementation details<br />

– Component descriptions, <strong>in</strong>terfaces, <strong>in</strong>terconnections<br />

– L<strong>in</strong>k to implementations<br />

• Assume-guarantee contracts provide <strong>the</strong> <strong>in</strong>formation<br />

needed from o<strong>the</strong>r model<strong>in</strong>g doma<strong>in</strong>s to reason about systemlevel<br />

properties<br />

– Guarantees correspond to <strong>the</strong> component requirements<br />

– Assumptions correspond to <strong>the</strong> environmental constra<strong>in</strong>ts that were<br />

used <strong>in</strong> prov<strong>in</strong>g <strong>the</strong> component requirements<br />

– Contract specifies precisely <strong>the</strong> <strong>in</strong>formation that is needed to reason<br />

about <strong>the</strong> component’s <strong>in</strong>teraction with o<strong>the</strong>r parts of <strong>the</strong> system<br />

– Supports hierarchical decomposition of verification process<br />

• Add contracts to AADL model<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


AADL<br />

system implementation Flight_Guidance_System.Flight_Guidance_System_Impl<br />

subcomponents<br />

FGP: process Flight_Guidance_Process.Flight_Guidance_Process_Impl;<br />

connections<br />

VNAVtoFGP: port VNAV -> FGP.VNAV;<br />

ADtoFGP: port AD -> FGP.AD;<br />

AHtoFGP: port AH -> FGP.AH;<br />

NAVtoFGP: port NAV -> FGP.NAV;<br />

FCItoFGP: port FCI -> FGP.FCI;<br />

LSItoFGP: port LSI -> FGP.LSI;<br />

FGPtoLSO: port FGP.LSO -> LSO;<br />

FGPtoGC: port FGP.GC -> GC;<br />

end Flight_Guidance_System.Flight_Guidance_System_Impl;<br />

thread implementation Control_Laws.Control_Laws_Impl<br />

end Control_Laws.Control_Laws_Impl;<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

44


1<br />

onO ff<br />

boolean<br />

on_off<br />

2<br />

decelS et<br />

boolean<br />

on_off<br />

3<br />

accelResum e<br />

boolean<br />

on_off<br />

4<br />

cancel<br />

boolean<br />

true _false<br />

5<br />

brakeP edal<br />

boolean<br />

on_off<br />

6<br />

carGear<br />

u<strong>in</strong>t32<br />

enum erated<br />

7<br />

carSpeed<br />

double<br />

m iles_per_hour<br />

8<br />

validInputs<br />

boolean<br />

true _false<br />

1<br />

onO ff<br />

boolean<br />

on_off<br />

2<br />

decelS et<br />

boolean<br />

on_off<br />

3<br />

accelResum e<br />

boolean<br />

on_off<br />

4<br />

cancel<br />

boolean<br />

true _false<br />

5<br />

brakeP edal<br />

boolean<br />

on_off<br />

6<br />

carG ear<br />

u<strong>in</strong>t32<br />

enum erated<br />

7<br />

carS peed<br />

double<br />

m iles_per_hour<br />

8<br />

validInputs<br />

boolean<br />

true_false<br />

[carS peed ]<br />

Goto<br />

cancel<br />

brakePedal<br />

carGear<br />

carSpeed<br />

va lid <strong>in</strong> p u ts<br />

safetyCondition<br />

safetyCondition<br />

onOff<br />

decelSet<br />

accelResum e<br />

cancel<br />

brakePedal<br />

carGear<br />

carSpeed<br />

validInputs<br />

Delay = 1 Sec<br />

setEvent<br />

Delay = 1 Sec<br />

M odeLogic<br />

re s u m e E ve nt<br />

1<br />

onOff<br />

boolean<br />

true_false<br />

2<br />

decelSet<br />

boolean<br />

true_false<br />

3<br />

accelResume<br />

boolean<br />

true_false<br />

4<br />

cancel<br />

boolean<br />

true_false<br />

[brakePosition ]<br />

5<br />

carGear<br />

u<strong>in</strong>t32<br />

enumerated<br />

6<br />

carSpeed<br />

double<br />

miles_per_hour<br />

7<br />

validInputs<br />

boolean<br />

true_false<br />

onOff<br />

decel<br />

set<br />

accel<br />

re s u m e<br />

safetyCondition<br />

m ode<br />

m ode<br />

setDesiredSpeed<br />

1<br />

m o d e<br />

u<strong>in</strong>t32<br />

setDesiredSpeed<br />

2<br />

setDesiredS peed<br />

boolean<br />

_logic<br />

isBrakePressed?<br />

m ode<br />

1<br />

[carS peed ]<br />

onOff<br />

decelSet<br />

accelResume<br />

cancel<br />

brakePedal<br />

carGear<br />

carSpeed<br />

validInputs<br />

CruiseController<br />

m ode<br />

u<strong>in</strong>t32<br />

enum erated<br />

m ode<br />

mode<br />

cruiseThrottle<br />

desiredSpeed<br />

carSpeed<br />

1<br />

mode<br />

u<strong>in</strong>t32<br />

enumerated<br />

3<br />

cruiseThrottle<br />

double<br />

percentage<br />

2<br />

desiredSpeed<br />

double<br />

miles_per_hour<br />

setDesiredSpeed<br />

desiredSpeed<br />

SetDesiredS peed<br />

desiredSpeed<br />

double<br />

m iles_per_hour<br />

double<br />

miles_per_hour<br />

double<br />

miles_per_hour<br />

[carS peed ]<br />

3<br />

%_per_second<br />

<br />

<br />

m ode<br />

desiredSpeed<br />

carSpeed<br />

%_per_step<br />

S etThrottle<br />

c ru is e T h ro ttle<br />

<br />

<br />

u<strong>in</strong>t32<br />

enumerated<br />

double<br />

2<br />

cruiseThrottle<br />

double<br />

percentage<br />

<br />

double<br />

miles_per_hour<br />

Compositional reason<strong>in</strong>g follows architecture<br />

Typical Model-Based Design<br />

– Models are organized <strong>in</strong> a<br />

hierarchy several (many) levels<br />

deep<br />

– Much of <strong>the</strong> complexity is <strong>in</strong> <strong>the</strong><br />

leaf models<br />

– Leaf models can often be verified<br />

through model check<strong>in</strong>g<br />

Composition of Subsystems<br />

– Comb<strong>in</strong>es heterogeneous<br />

evidence<br />

2<br />

desiredSpeed<br />

3<br />

carSpeed<br />

1.00<br />

thottleDelta<br />

– Assume/guarantee reason<strong>in</strong>g<br />

StepsPerSec<br />

double<br />

throttleDelta<br />

1<br />

mode<br />

isCruiseActive?<br />

0.0<br />

1<br />

cruiseThrottle<br />

– Well suited for <strong>the</strong>orem<br />

prov<strong>in</strong>g<br />

NOTHROTTLE<br />

1<br />

z<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Compositional reason<strong>in</strong>g<br />

• Given<br />

– Assumptions for system<br />

– Assumptions/Guarantees for components (A, P)<br />

• Prove<br />

– System guarantees (requirements)<br />

• Assume-Guarantee Reason<strong>in</strong>g Environment (AGREE)<br />

– Automatic translation of model structure, contracts, and verification<br />

conditions<br />

– Verify via k-<strong>in</strong>duction model checker (KIND/U. Iowa, Yices/SRI)<br />

Contract compliance:<br />

G(H(A) P)<br />

A<br />

C<br />

Example (to prove)<br />

A S A A<br />

A S P A A B<br />

A S P A P B A C<br />

A S P A P B P C P S<br />

Assumption: Input < 20<br />

Guarantee: Output < 2*Input<br />

B<br />

Assumption: Input < 20<br />

Guarantee: Output < Input + 15<br />

Assumption: none<br />

Guarantee: Output = Input1<br />

+ Input2<br />

Assumption: Input < 10<br />

Guarantee: Output < 50<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

46


HACMS motivation…<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

48


High Assurance Cyber-Military Systems<br />

Network-enabled<br />

UAVs are vulnerable<br />

to cyber-attack<br />

SECURE MATHEMATICALLY-ASSURED<br />

COMPOSITION OF CONTROL MODELS<br />

SMACCM: $18M/4.5 year project funded by DARPA<br />

Information Innovation Office<br />

Objective: Produce a clean-slate, formal methods–<br />

based approach to <strong>the</strong> development of networkenabled<br />

military vehicles to build systems that<br />

provide <strong>the</strong> highest levels of dependability and are<br />

resistant to emerg<strong>in</strong>g cyber threats<br />

• Develop a complete, formally proven architecture for<br />

UAVs (and o<strong>the</strong>r embedded systems) that provides<br />

robustness aga<strong>in</strong>st cyber attack<br />

• Develop compositional verification tools for<br />

comb<strong>in</strong><strong>in</strong>g formal evidence from multiple sources,<br />

components, and subsystems<br />

• Prototype <strong>the</strong>se technologies on an open research<br />

platform and transfer <strong>the</strong>m to a military platform to<br />

demonstrate <strong>the</strong>ir practicality and effectiveness<br />

• Team <strong>in</strong>cludes Boe<strong>in</strong>g, NICTA, Galois, Univ. of MN<br />

ROCKWELL COLLINS HAS ASSEMBLED A TEAM OF THE WORLD’S LEADING AUTHORITIES ON SOFTWARE VERIFICATION AND HIGH<br />

ASSURANCE DEVELOPMENT TO CREATE A REVOLUTIONARY NEW WAY OF BUILDING ROBUST AND SECURE MILITARY VEHICLES<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.


Target: Unmanned Air Vehicles<br />

Security vulnerabilities that can lead<br />

to safety hazards<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

50


NASA AFCS<br />

(Assurance of Flight Critical Systems)<br />

SysML-AADL<br />

translation<br />

Enterprise<br />

Architect<br />

SysML<br />

OSATE:<br />

AADL model<strong>in</strong>g<br />

AADL<br />

Lute:<br />

Structural<br />

verification<br />

AGREE:<br />

Compositional<br />

behavior verification<br />

Eclipse<br />

Lustre<br />

KIND<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

53


Composition of<br />

heterogeneous evidence<br />

• Avionics system requirement<br />

Under s<strong>in</strong>gle-fault assumption, GC<br />

output transient response is bounded<br />

<strong>in</strong> time and magnitude<br />

Behavior<br />

Avionics<br />

System<br />

LS<br />

leader transition<br />

bounded<br />

• Relies upon<br />

– Guarantees provided by<br />

components & design patterns<br />

– Structural properties of model<br />

– Resource allocation feasibility<br />

– Probabilistic system-level<br />

failure characteristics<br />

synchronous<br />

communication<br />

Structure<br />

tim<strong>in</strong>g<br />

constra<strong>in</strong>ts<br />

PALS<br />

Rep<br />

one node<br />

operational<br />

not<br />

co-located<br />

ASSUMPTIONS<br />

GUARANTEES<br />

Pr<strong>in</strong>cipled mechanism for<br />

“pass<strong>in</strong>g <strong>the</strong> buck”<br />

Resource<br />

Platform<br />

Probabilistic<br />

RT sched<br />

& latency<br />

Error<br />

model<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

54


Compositional reason<strong>in</strong>g for FCS (example)<br />

• Want to prove a transient response<br />

property<br />

– The autopilot will not cause a sharp<br />

change <strong>in</strong> pitch of aircraft.<br />

– Even when one FGS fails and <strong>the</strong> o<strong>the</strong>r<br />

assumes control<br />

• Given assumptions about <strong>the</strong><br />

environment<br />

– The sensed aircraft pitch from <strong>the</strong> air<br />

data system is with<strong>in</strong> some absolute<br />

bound and doesn’t change too quickly<br />

– The discrepancy <strong>in</strong> sensed pitch<br />

between left and right side sensors is<br />

bounded.<br />

• And guarantees provided by<br />

components<br />

– When a FGS is active, it will generate<br />

an acceptable pitch rate<br />

• As well as facts provided by<br />

architecture<br />

– Leader selection: at least one FGS will<br />

always be active (modulo one<br />

“failover” step)<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.<br />

ibd [SysML Internal Block] Flight_Control_System_Impl [Flight_Control_System]<br />

FD_L<br />

AD_L<br />

AH_L<br />

FM_L<br />

NAV_L<br />

ADLtoFGSL<br />

AHLtoFGSL<br />

FMLtoFGSL<br />

NAVLtoFGSL<br />

THROT_L<br />

THROTL2FCI<br />

YOKE_L<br />

FGSLtoFDL<br />

AD<br />

AH<br />

VNAV<br />

NAV<br />

YOKEL2FCI<br />

GC<br />

FGS_L : Flight_Guidance_System<br />

FCI<br />

THROT_L<br />

YOKE_L<br />

CSA<br />

Flight_Control_System_Impl<br />

AP2CSA<br />

FGSLtoAP<br />

LSD<br />

LSI<br />

FCItoFGSL<br />

GC_L<br />

CSA<br />

AP : Autopilot_System<br />

FGSLtoFGSR<br />

FGSRtoFGSL<br />

FCI<br />

GC_R<br />

FCI : Flight_Crew_Interface<br />

FGSRtoAP<br />

FCItoFGSR<br />

LSI<br />

LSD<br />

GC<br />

FGS_R : Flight_Guidance_System<br />

THROT_R<br />

YOKE_R<br />

FCI<br />

FGSRtoFDR<br />

AD<br />

AH<br />

VNAV<br />

NAV<br />

YOKER2FCI<br />

THROTR2FCI<br />

YOKE_R<br />

Flight_Control_System<br />

ADRtoFGSR<br />

AHRtoFGSR<br />

FMRtoFGSR<br />

NAVRtoFGSR<br />

transient_response_1 : assert true -><br />

abs(CSA.CSA_Pitch_Delta) < CSA_MAX_PITCH_DELTA ;<br />

transient_response_2 : assert true -><br />

abs(CSA.CSA_Pitch_Delta - prev(CSA.CSA_Pitch_Delta, 0.0))<br />

< CSA_MAX_PITCH_DELTA_STEP ;<br />

THROT_R<br />

55<br />

FD_R<br />

AD_R<br />

AH_R<br />

FM_R<br />

NAV_R


Conclusions<br />

• Model-based development has been key to our adoption of<br />

formal methods<br />

• Current work is expand<strong>in</strong>g <strong>the</strong> size and scope of<br />

systems/models that can be analyzed<br />

• There are many good reasons to use formal methods for<br />

verification and certification…<br />

• But follow <strong>the</strong> money<br />

© Copyright 2012 Rockwell Coll<strong>in</strong>s, Inc.<br />

All rights reserved.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!