Bridging the Gap Between Model-Based Development and Model Checking

Transcription

1 Bridging the Gap Between Model-Based Development and Model Checking AFRL Safe & Secure Systems & Software Symposium Dr. Steven P. Miller

2 Acknowledgements NASA Langley Research Center (Ricky Butler) Air Force Research Labs University of Minnesota (Dr. Mats P. E. Heimdahl) Lockheed Martin Dr. Mike Whalen Dr. Darren Cofer 2

3 Who Are We? Presentation Overview What Problem are We Solving? Overview of Our Approach Case Studies Challenges and Future Directions 3

4 Rockwell Collins Headquartered in Cedar Rapids, Iowa 20,000 Employees Worldwide 2008 Sales of $4.77 Billion Domestic California Carlsbad Cypress Irvine Los Angeles Pomona Poway San Francisco San Jose Tustin Florida Melbourne Miami Orlando Georgia Atlanta Warner Robins Hawaii Honolulu Illinois Chicago Iowa Bellevue Coralville Decorah Manchester Kansas Wichita Maryland White Marsh Massachusetts Boston Michigan Ann Arbor Detroit Minnesota Minneapolis Missouri Kansas City St. Louis New York New York North Carolina Charlotte Raleigh Oklahoma Midwest City Tulsa Oregon Portland Pennsylvania Philadelphia Pittsburgh Texas Dallas Fort Worth Richardson Utah Salt Lake City Virginia Sterling Warrenton Washington Kirkland Renton Seattle Washington, DC International Africa Johannesburg, South Africa Asia Bangkok, Thailand Beijing, China Hong Kong Hyderabad, India Kuala Lumpur, Malaysia Manila, Philippines Moscow, Russia Osaka, Japan Shanghai, China Singapore Tokyo, Japan Australia Auckland, New Zealand Brisbane, Australia Melbourne, Australia Sydney, Australia Canada Montreal Ottawa Europe Amsterdam, Netherlands Frankfurt, Germany Heidelberg, Germany London, England Lyon, France Manchester, England Paris, France Reading, England Rome, Italy Toulouse, France Mexico Mexicali South America Santiago, Chile Sao Jose dos Campos, Brazil Sao Paulo, Brazil 4

5 Rockwell Collins core business is based on the delivery of High Assurance Systems Commercial/Military Avionics Systems Communications Navigation & Landing Systems Flight Control Displays Weapon Data Links Working together creating the most trusted source of communication and aviation electronic solutions 5

6 Advanced Technology Center Identify, acquire, develop and transition value-driven technologies to support the continued growth of Rockwell Collins. Automated Analysis Section Technologists: 10 Administrators: 1 Bachelors 37% PhD 17% PhD 64% Masters 46% BA 9% BA MS 27% Technologists: 173 Administrators: 10 Technicians: 31 Applies mathematical tools and reasoning to the production of high assurance systems. 6

7 Formal Methods at Rockwell Collins AAMP5 Microcode Verification (PVS) AAMP-FV Microcode Verification (PVS) AAMP5 Partitioning (PVS) FGS Mode Confusion Study (PVS) FGS Safety Analysis (RSML -e, NuSMV) NASA Aviation Safety FGS Mode Confusion (RSML -e, PVS) ADGS 2100 (Simulink, NuSMV) AFRL CerTA FCS (NuSMV, Prover) Mixed Criticality Architectures JEM Java μproc (PVS) FCP 2002 Microcode (ACL2) AAMP7 Separation Kernel (ACL2)l vfaat (ACL2, PVS) SHADE (ACL2) Greenhills Integrity RTOS (ACL2) Turnstile (SPARK) NSA Greenhills Integrity Gen4 (ACL2) Guardol (ACL2, Prover) 7

8 Who Are We? Presentation Overview What Problem are We Solving? Overview of Our Approach Case Studies Challenges and Future Directions 8

9 Airborne Software Doubles Every Two Years K Words A300B A300FF A K 2M A320 4M A330/A340 10M 10 INS 23K 1 4K J.P. Potocki De Montalk, Computer Software in Civil Aircraft, Sixth Annual Conference on Computer Assurance (COMPASS 91), Gaithersberg, MD, June 24-27,

10 Similar Growth Has Been Seen by Boeing 230K Complexity Size 777 No. of Signals Object Code (Mbytes) /767 Year /767 Year

11 WPAFB RBO /20/

12 WPAFB RBO /20/

13 Who Are We? Presentation Overview What Problem are We Solving? Overview of Our Approach Case Studies Challenges and Future Directions 13

14 Exploit the Convergence of Two Trends Model-Based Development Domain specific graphical notations MATLAB Simulink, Esterel Technologies SCADE Suite Enable early simulation and debugging Automated generation of code and tests Model-Checking Prove properties about a model Explore all possible inputs and states Highly automated Reduce Costs and Improve Quality by Using Analysis to Find Errors During Early Design 14

15 Company Product Tools Specified & Autocoded Benefits Claimed Airbus A340 SCADE With Code Generator Eurocopter GE & Lockheed Martin Schneider Electric US Spaceware PSA CSEE Transport Honeywell Commercial Aviation Systems EC-155/135 Autopilot FADEDC Engine Controls Nuclear Power Plant Safety Control SCADE With Code Generator 70% Fly-by-wire Controls 70% Automatic Flight Controls 50% Display Computer 40% Warning & Maint Computer 90 % of Autopilot 20X Reduction in Errors Reduced Time to Market 50% Reduction in Cycle Time ADI Beacon Not Stated Reduction in Errors 50% Reduction in Cycle Time Decreased Cost SCADE With Code Generator 200,000 SLOC Auto Generated from 1,200 Design Views 8X Reduction in Errors while Complexity Increased 4x DCX Rocket MATRIXx Not Stated 50-75% Reduction in Cost Reduced Schedule & Risk Electrical SCADE 50% SLOC Auto Generated 60% Reduction in Cycle Time Management With Code 5X Reduction in Errors System Generator Subway Signaling System Primus Epic Flight Control System Model-Based Development SCADE With Code Generator MATLAB Simulink 80,000 C SLOC Auto Generated 60% Automatic Flight Controls Improved Productivity from 20 to 300 SLOC/day 5X Increase in Productivity No Coding Errors Received FAA Certification 15

16 What Are Model Checkers? Breakthrough Technology of the 1990 s Widely Used in Hardware Verification (Intel, Motorola, IBM, ) Several Different Types of Model Checkers Explicit, Symbolic, Bounded, Infinite Bounded (SMT), Exhaustive Search of the Global State Space Consider All Combinations of Inputs and States Equivalent to Exhaustive Testing of the Model Produces a Counter Example if a Property is Not True Easy to Use Push Button Formal Methods Very Little Human Effort Unless You re at the Tool s Limits Limitations State Space Explosion ( States) 16

17 Advantage of Model Checking Testing Checks Only the Values We Select Model Checker Tries Every Possible Value! Even Small Systems Have Trillions (of Trillions) of Possible Tests! Finds every exception to the property being checked! 17

18 Rockwell Collins Translation Framework NuSMV Simulink Simulink Gateway SCADE Prover Reactis Lustre ACL2 StateFlow Simulink Gateway Safe State Machines PVS C, Ada Rockwell Collins/U of Minnesota Esterel Technologies SRI International Reactive Systems MathWorks SAL SAL Symbolic Model Checker SAL Bounded Model Checker SAL Infinite Model Checker 18

19 A Product Family of Translators Many small Lustre-to-Lustre translation passes Each pass refines closer to the target language Each pass deals with one change Pre/Post conditions define when a pass is valid RFBY Lustre RDV Lustre RC IAS Lustre Pretty Print RC C Code Pretty Print Lustre Lustre Ada Code RNC REP Lustre Lustre Lustre REN Lustre RNC Lustre IPS Lustre Pretty Print PVS Last step pretty prints to the target language Extensive reuse of passes Lustre RDV Lustre New translators can be developed quickly (usually in less than a week) FNH RACT RNST Lustre SCA PTL Lustre Pretty Print Pretty Print NuSMV Lustre Lustre Prover 19

20 Translators Optimize for Specific Analysis Tools CPU Time Model (For NuSMV to Compute Reachable States) Before After Improvement Mode1 > 2 hours 11 sec > 650x Mode2 > 6 hours 169 sec > 125x Mode3 > 2 hours 14 sec > 500x Mode4 8 minutes < 1 sec 480x Arch 34 sec < 1 sec 34x WBS 29+ hours 1 sec 105,240x 20

21 Who Are We? Presentation Overview What Problem are We Solving? Overview of Our Approach Case Studies Challenges and Future Directions 21

22 ADGS-2100 Adaptive Display & Guidance System Modeled in Simulink Translated to NuSMV 4,295 Subsystems 16,117 Simulink Blocks Over Reachable States Example Requirement: The Cursor Shall Never be Positioned on an Inactive Display Counterexample Found in 5 Seconds Checked 563 Properties - Found and Corrected 98 Errors in Early Design Models 22

23 ADGS-2100 Technology Transfer Iteration 1 Iteration 2 Iteration 3 Dev. Group (Blue) Simulink R14 Model Simulink R14 Model Simulink R14 Model Simulink R13 Model ATC Group (Beige) SCADE Model Reactis Model Reactis Model NuSMV Model NuSMV Model NuSMV Model Translation Time: 1-4 Hours Turnaround: 1 Day to 1 Week Translation Time: 10 Minutes Turnaround: 3 Hours to 2 Days Translation Time: 10 Minutes Turnaround: 10 Minutes 23

24 CerTA FCS Phase I Sponsored by the Air Force Research Labs Air Vehicles (RB) Directorate - Wright Patterson Investigate Roles of Testing and Formal Verification Can formal verification complement or replace some testing? Example Model Lockheed Martin Adaptive UAV Flight Control System Redundancy Management Logic in the Operational Flight Program (OFP) Well suited for verification using the NuSMV model-checker Lockheed Martin Aero Based on Testing Enhanced During CerTA FCS Graphical Viewer of Test Cases Support for XML/XSLT Test Cases Added C++ Oracle Framework Developed Tests from Requirements Executed Tests Cases on Test Rig Rockwell Collins Based on Model-Checking Enhanced During CerTA FCS Support for Simulink blocks Support for Stateflow Support for Prover model-checker Developed Properties from Requirements Proved Properties using Model-Checking WPAFB RBO /20/

25 CerTA FCS Phase I - OFP Redundancy Management Logic For Each of Ten Control Surfaces Triplex Voter Input monitor, sensor fusion, and failure isolation Failure Processing Logs failures into a data store Reset Manager Reset logic for sensors and control surfaces (not shown) Subsystems / Blocks Charts / Transitions 1 sync<> sync 2 input_a 3 input_b 4 input_c 5 status_a 6 status_b 7 status_c 8 dst_index DOC Text [trigger] [A] [B] [C] [status_a] [status_b] [status_c] [DSTi] [trigger] [A] [B] [C] trip_level trip_level1 persist_lim persist_lim persistence limit [MS] Input Monitor [DSTi] DST Data Store Read trip_lev el Truth Table Cells Index Vector input_a input_b input_c trip_lev el persist_lim MS Extract Bits [0 3] Extract Bits f ailreport triplex_input_monitor pc tc f ailreport double persistence_cnt<pc> totalizer_cnt<tc> 3 totalizer_cnt 2 persistence_cnt [trigger] Reachable State Space [A] [A] [MS] [status_a] [status_b] [status_c] [prev_sel] [B] [C] [B] [C] [DSTi] mon_f ailure_report status_a status_b status_c prev _sel input_a input_b input_c pc trigger input_a input_b input_c DST_index input_sel triplex_input_selector f ailure_report Failure_Isolation Failure Isolation 4 input_sel 1 failure_report [prev_sel] Properties [DSTi] f ailure_report dst_index Failure Processing Sensor Fusion Failure_Processing Triplex voter 10 / 96 3 / * Failure processing Reset manager 7 / 42 0 / * / 31 2 / * Total 23 / / N/A 62 WPAFB RBO /20/

26 CerTA FCS Phase I Errors Found Model Checking Testing Errors Found in Redundancy Manager Triplex Voter 5 0 Failure Processing Reset Manager Total 12 0 Model-Checking Found 12 Errors that Testing Missed Spent More Time on Testing than Model-Checking 60% of total on testing vs. 40% on model-checking Model-checking was more cost effective than testing at finding design errors. WPAFB RBO /20/

27 CerTA FCS Phase II Sponsored by the Air Force Research Labs Air Vehicles (RB) Directorate - Wright Patterson Can Model-Checking be Used on Infinite State Systems? Large, numerically intensive, non-linear systems Example Model Lockheed Martin Adaptive UAV Flight Control System Effector Blender (EB) Generates actuator commands for aircraft control surfaces Matrix arithmetic of floating point numbers Challenges Identifying the right properties to verify Verification of floating point numbers Verification of Stateflow flowcharts with cyclic transition paths Compositional verification to scale to entire Effector Blender WPAFB RBO /20/

28 CerTA FCS Phase II Effector Blender Generates Actuator Commands Six control surfaces Adapts its behavior as aircraft state changes Iterative algorithm that repeatedly manipulates a 3 x 6 matrix of floating point numbers Large Complex Model Inputs 32 floating point inputs 3 x 6 matrix of floating point values Outputs 1 x 6 vector of floating point values 166 Simulink subsystems basic Simulink blocks Huge reachable state space Completely Functional No internal state Effector Blender Surf1 surf2 surf3 surf4 surf5 surf6 Control Effector Arrangement Spoilers (L&R) left vertical tail right vertical tail left flap right flap left outboard spoiler right outboard spoiler V-Tail Rudders (L&R) 1 Flaps (L&R) WPAFB RBO /20/

29 CerTA FCS Phase II What to Verify? No Explicit Requirements for the Effector Blender Model Requirements defined for Effector Blender + aircraft model Addition of aircraft model pushes verification beyond current tools Avoid Properties Verifiable by Other Means Control theory stability, tracking performance, feedback design Simulation design validation Implementation code generation/compilation, scheduling, Focus on the Consistency of the Effector Blender Model Relationships the model should always maintain Partial requirements specification Preservation of Control Surface Limits EB computes upper and lower limits for each control surface command Function of aircraft design, aircraft state, and max extension per cycle Commanded extension should always be between these limits WPAFB RBO /20/

30 CerTA FCS Phase II Verification of Floating Point Numbers Floating Point Numbers Fixed number of bits with a movable decimal (radix) point No decision procedures for floating point numbers available Real Numbers Real numbers have unbounded size and precision Would hide errors caused by limitations of floating point arithmetic Control theory problems are inherently non-linear Decision procedures for non-linear real numbers have exponential cost Solution - Translate Floating Point Numbers into Fixed Point Extended translation framework to automate this translation Convert floating point to fixed point (scaling provided by user) Convert fixed point into integers (use bit shifting to preserve magnitude) Shift from NuSMV (BDD-based) to Prover (SMT-solver) model checker Advantages & Issues Use bit-level integer decision procedures for model checking Results unsound due to loss of precision Highly likely to find errors very valuable tool for debugging WPAFB RBO /20/

31 CerTA FCS Phase II Compositional Verification Typical Specification Models are typically organized in a hierarchy of subsystems Subsystems are often nested several levels deep Most of the complexity is in the leaf subsystems Leaf subsystems can often be verified through model checking P1 1 In1 P2 & P3 2 In2 P2 & P3 -> Q1 In_A1 Out_A In_A2 Subsystem A Q1 P1 & Q1 -> Q2 In_B1 Out_B In_B2 Subsystem B Q2 Q 1 Out1 Composition of Subsystems Tends to be simple Lends itself well to theorem proving P2 & P3 => Q1 P1 & Q1 => Q2 => P1 & P2 & P3 => Q Issues Need to avoid circular reasoning to ensure soundness Can be ensured by eliminating cyclic dependencies between atomic subsystems Identifying the right leaf level invariants to support composition Complexity of the proof obligations for the intermediate levels Lack of a unified automated verification system WPAFB RBO /20/

32 CerTA FCS Phase II - Results Can Model-Checking be Used on Infinite State Systems? Large, numerically intensive, non-linear systems Effector Blender Inputs 32 floating point inputs 3 x 6 matrix of floating point values Outputs 1 x 6 vector of floating point values 166 Simulink subsystems basic Simulink blocks Errors Found Five previously unknown errors that would drive actuators past their limits Several implementation errors were being masked by defensive programming WPAFB RBO /20/

33 Presentation Overview What Problem are We Solving? Who Are We? What are Formal Methods? Examples of Using Formal Methods Challenges and Future Directions 33

34 Extending the Verification Domain Theorem Provers Deal with arbitrary models Concerns are ease of use and labor cost Large Finite Systems (< States) Implicit state (BDD) model checkers Easy to use and very effective Very Large or Infinite State Systems SMT-Solvers Large integers and reals Limited to linear arithmetic Ease of use is a concern Floating Point Arithmetic Most modeling languages use floating point (not real) numbers Non-Linear Arithmetic Multiplication/division of real variables Transcendental functions (trigonometric, ) Essential to navigation systems Theorem Provers Non Linear Arithmetic Floating Point SMT-Solvers Implicit State Model Checkers < Reachable States Infinite State Models using k - Induction Decision Procedures Transcendental Functions Arbitrary Models Labor Intensive 34

35 1 onoff boolean on_off 2 decelset boolean on_off 3 accelresume boolean on_off 4 cancel boolean true_false 5 brakepedal boolean on_off 6 cargear uint32 enumerated 7 carspeed double miles_per_hour 8 validinputs boolean true_false 1 onoff boolean on_off 2 decelset boolean on_off 3 accelresume boolean on_off 4 cancel boolean true_false 5 brakepedal boolean on_off 6 cargear uint32 enumerated 7 carspeed double miles_per_hour 8 validinputs boolean true_false [carspeed ] Goto cancel brakepedal cargear carspeed validinputs safetycondition safetycondition onoff decelset accelresume cancel brakepedal cargear carspeed validinputs Delay = 1 Sec setevent Delay = 1 Sec ModeLogic resumeevent 1 onoff boolean true_false 2 decelset boolean true_false 3 accelresume boolean true_false 4 cancel boolean true_false [brakeposition ] 5 cargear uint32 enumerated 6 carspeed double miles_per_hour 7 validinputs boolean true_false onoff decel set accel resume safetycondition mode setdesiredspeed mode _logic isbrakepressed? mode setdesiredspeed 1 [carspeed ] 1 mode uint32 2 setdesiredspeed boolean onoff decelset accelresume cancel brakepedal cargear carspeed validinputs CruiseController mode uint32 enumerated mode mode cruisethrottle desiredspeed carspeed 1 mode uint32 enumerated 3 cruisethrottle double percentage 2 desiredspeed double miles_per_hour setdesiredspeed desiredspeed SetDesiredSpeed desiredspeed double miles_per_hour double miles_per_hour double miles_per_hour 3 [carspeed ] %_per_second <U=10.0> <L=-10.0> mode desiredspeed carspeed %_per_step SetThrottle cruisethrottle <U=100.0> <L=0.0> uint32 enumerated double 2 cruisethrottle double percentage <Init = 0.0> double miles_per_hour Combining Theorem Proving and Model Checking For Compositional Verification What Should the User Interface Be? Not emacs! Integrated with the model Simple theorem proving Powerful model checking Composition of Subsystems Tends to be simple Well suited for theorem proving Typical Model-Based Specification 2 desiredspeed 3 carspeed 1.00 thottledelta StepsPerSec double throttledelta 1 mode iscruiseactive? 0.0 NO THROTTLE 1 z 1 cruisethrottle Models are organized in a hierarchy several levels deep Most of the complexity is in the leaf models Leaf models can often be verified through model checking 35

36 Finding the Right Properties How Many Properties Do I Need? When am I done? Are there coverage metrics like there are for testing? How do I convince the certification authorities I m done? Are Some Properties Better than Others? Properties related to safety Cross cutting properties find the most important errors Simple, local properties find a surprising number of errors Is There a Process or Heuristics for Defining Properties? Prove a property about each discontinuity in each output What is the Relationship Between Proof and Testing Can proving replace some testing? Can testing replace some proving? 36

37 Verifying Asynchronous Systems Occur Frequently in System Designs Implement fault tolerance or meet performance requirements No Global Clock - Each Node Has Its Own Clock Quasi-Synchronous System Clocks have similar (but not identical) periods, drift, jitter Interleaving Leads to State Space Explosion Makes model checking difficult Need to Exploit the Constraints Imposed by Quasi-Synchrony 37

38 System Architectural Modeling & Analysis System Architecture Model Logical Abstracts Security Analysis Performance Analysis ADL Level B Classified Implements Auto Generate Safety Analysis Simulink Model C Code IMA Cabinet VAPS Model C Code Common Computing Resource 3 Common Computing Resource 2 Common Computing Resource 1 App A App B App C Sys Specific Middleware (Schedule, Communication Routes) Reusable Trusted Middleware (RTOS, I/O, RT-CORBA) Separation Kernel Target Hardware Level C Unclassified Ada Code Level A Top Secret Software Component Development Physical IMA BUS System Architecture Development 38

39 Conclusions Formal Methods Are Practical and Are Being Widely Used Model Based Development is the industrial face of formal methods The engineers get to pick the modeling tools! Semantics of some of the commercial tools could be improved Formal Verification Tools Are Being Used in Industry Key is to verify the models the engineers are already building Large portions of existing systems can be verified with model checkers Need to make model checking accessible to the average engineer Directions for the Future Work Making verification tools more powerful and easier to use Integration of theorem proving and model checking Finding the right properties Verification of asynchronous systems Modeling and analysis of system architectural models 39

40 For More Information Whalen, M., Cofer, D., Miller, S., Krogh, B., Storm, W.: Integration of Formal Analysis into a Model-Based Software Development Process. In 12th International Workshop on Formal Methods for Industrial Critical Systems (FMICS2007), Berlin, Germany (2007). Whalen, M., Innis, J., Miller, S., Wagner, L.: ADGS-2100 Adaptive Display & Guidance System Window Manager Analysis, CR , NASA (2006). Mats P.E. Heimdahl, Michael W. Whalen, Ajitha Rajan, and Steven P. Miller, Testing Strategies for Model-Based Development, NASA Contractor Report NASA-2006-CR214307, April Available at Miller, S., Tribble, A., Whalen, M., Heimdahl, M., Proving the Shalls, International Journal on Software Tools for Technology Transfer (STTT), Feb Michael W. Whalen, John D. Innis, Steven P. Miller, and Lucas G. Wagner, ADGS-2100 Adaptive Display & Guidance System, NASA Contractor Report NASA-2006-CR213952, Feb Available at Steven P. Miller, Mike W. Whalen, Dan O Brien, Mats P.E. Heimdahl, and Anjali Joshi, A Methodology for the Design and Verification of Globally Asynchronous/Locally Synchronous Architectures, NASA Contractor Report NASA/CR , Sept Available at Miller, S., Anderson, E., Wagner, L., Whalen, M., Heimdahl, M.: Formal Verification of Flight Critical Software. In AIAA Guidance, Navigation and Control Conference and Exhibit, AIAA , American Institute of Aeronautics and Astronautics (2005). 40