Model Checking and Planning for Critical Software Paolo

Model Checking and Planning for Critical Software Paolo Traverso ITC/IRST, Via Sommarive 18, 38050 Trento traverso@itc. it htttp: //sra. itc. it/

Motivations · · · Industrial Embedded Software o Functionality Issues: Safety Critical Systems, Growing Complexity o Market Issues: Time to delivery, Costs o Maintenance Issues: Requirements change over time, Feature interaction problem Difficulties with Traditional Methodologies o Ambiguous Specification (requirements, Analysis, Design) o Errors in Specifications/Design Refinements o Limited Coverage by Tests Consequences o Expensive errors in the early design phase o Infeasibility of achieving (ultra-high) reliability requirements o Low Software Quality (hard to maintain)

Formal Methods: The Potentials · · Key Ingredients o Formal Specification: unambiguous description of the system and of the required properties o Formal Validation and Verification Tools: exhaustive comparison of the formal description of the system against the formal properties Potential Benefits o Find design bugs in early design stages o Achieve higher quality standards o Shorten Time to Market reducing manual validation phase

Formal Methods: The Practice · · Technical Problems o Formal Specification: hard to write, high costs. . . o Formal Validation and Verification Tools: models of real industrial systems are often hard to analyze, tools often do not scale up or are not automatic, . . . Practical & Methodological Problems: o Introduction of a new technology that requires … o High expertise, long training, … o Modification of standard development process. . . o Increase of development costs. . .

Formal Methods @ IRST Adapt the Application of Formal Methods to the Customers’ real needs • In-house Tool Support and Development • Integration with Standard Technologies • Lightweight Approach • Gentle Integration in the Development Process

A technology: Model Checking Requirement Always (if Signal=On then Engine=Off) Model Checker Yes!, the model satisfies the requirements System Model No! Here’s a counterexample. . . Signal Engine · Basic Ingredients o Systems Modeled as a Finite State Automata (FSA) o Requirement Expressed in Temporal Logic o Formal V&V by exhaustive search over the state space

Model Checking · · · Powerful debugging capabilities o Helps detect problems in early stages of the development cycle, where they are more costly o exhaustive, thus effective (often bugs are also in scaleddown problems) o provides counterexamples Easier to integrate within industrial development cycle o compilers for practical design languages (e. g. VHDL, Statecharts) o although limited, expressiveness is often sufficient in practice Does not require deep training (push-button technology)

Model Checking: Problems Requirement System Model · Model Checker Yes!, the model satisfies the requirements No! Here’s a counterexample. . . Problems: o Technical: Automata of 10, 000, 000, . . . states o Practical: Costs of the introduction the Technology o Methodological: How this affects Development Process (e. g. testing) . . . Is model checking still a dream?

Model Checking@IRST Requirement System Model · Model Checker Nu. SMV Yes!, the model satisfies the requirements No! Here’s a counterexample. . . Main features: o State-of-the art techniques to scale up to huge state spaces o Open architecture (one techniques for one problem) o Open interface (“let me work with my own language!”)

The Nu. SMV Model Checker Nu. SMV is an Industrial Strength, Open Architecture, Model Checker · · · Originally, joint project with CMU Academic version released in June 99 Over 200 installations worldwide High quality implementation Current interest by various industrial partners Used in industrial technology transfer projects . . . and it is open-source: http: //sra. itc. it/tools/nusmv

Automated Synthesis of Controller Requirement System Model Automated Synthesis Controller that makes the system satisfy the requirements No! There is no controller such that. . . There exists some approaches …. Automated Synthesis @ IRST by ….

… by Planning as model checking Requirement Always (if Signal=On then Engine=Off) System Model Automated Synthesis the system satisfy the requirements MBP M P B Controller that makes Signal Engine No! There is no controller such that. . . · Basic Ingredients o Planning as Model Checking: § plan becomes a FSM, i. e. , a controller § goal becomes a requirement in temporal logic § planning: generate plan s. t. system satisfies the goal (similar to a model checking problem)

The Nu. SMV Model Checker MBP: a Model Based Planner · · · Developed on top of Nu. Smv Academic version released in June 2001 Several installations worldwide High quality implementation Current interest by various industrial partners Used in industrial technology transfer projects . . . and it is available at http: //sra. itc. it/tools/mbp

Some projects at IRST · · · Railways (Ansaldo, Union Switch & Signal, …) Avionics (Alenia, Airbus, Rockwell, …) Embedded Controllers (Invensys, …) Micro. Processors (Intell, …) Space (Nasa, Asi, …)

Application I: Interlocking System

Application I: Interlocking System Validation of Interlocking System for Control of Railway Stations · Difficulties o Safety Critical System o High-Complexity of functions and controlled devices o Time-to-market: large amount of manual verification

Application I: Interlocking System · Goals o Increased confidence in the correctness of design o Automation of the verification task o Improvement of time-to-market reducing manual validation effort · Results o Automated generation of formal specifications o Integrated, application specific verification engine o Subtle bugs detected in simple configurations

Application II: Tool Certification of COTS based, Safety Critical Compiler · Requirements o Automation, Efficiency, Certification

Application II: Tool Certification · Approach (Run-Time Result Checking) o Certification Tool: validates each single run of the compiler o Efficiency: specialized, problem dependent verification engine o Certification of the Certification Tool: Logging + Checking · Results o Certification Tool satisfies the requirements o Bug Found in Compiler Design

Application III: Comm. Protocol A high complexity communication protocol for redundancy · Starting Point o Incomplete, informal specifications o Existing Implementation (legacy code) o A history of expensive debugging on the field

Application III: Comm. Protocol · Approach § Specification of Functional Requirements with MSC § Architectural and Formal Model in SDL § Formal Validation using Model Checking § Subtle bugs detected after exchange of over 200 messages § Detailed Informal/Formal specification to code developers · Results o First Implementation passed all tests

Application IV: RBC Radio Block Center Interlocking Radio Block Centre

Application IV: RBC · Approach o Solution based on the integration of different languages and notations o Simulation/Validation of the design o Simulation on a significant portion of the Italian trial site · Results o Increased confidence in the correctness of the design o “Incremental” Architecture o Subtle communication issues detected (mainly liveness issues)

Application V: Air Conditioning

Application V: Air Conditioning Design and Implementation of a Tool to Support Controllers’ Construction Configuration Tool Firmware Compiler Plant Specification M P B Functions Specification Model Checker Model. Library (on motherboard) Simulator

Application VI: ESACS Enhanced Safety Analysis for Complex Systems AERONAUTICA

Application Domain

The Problem System Design Safety Analysis System Level Requirements Fault Hazard Analysis System Architecture Fault Tree Analysis PSSA FMEA Fault Intermediate Effect Final Effect Severity Undetected Fire in Bay Area System Safety Analysis Proba bility 10 e-8 Subsystem A fails Loss of mechanical drive 5 … System Implementatio n … … Critical Points Certification • Link between System Design and Safety Analysis. • Growing complexity of systems. Complex System

Goals Goal I. Development of a Platform (FSAP/Nu. SMV-SA) to Enhance Safety Analysis Process System Design FSAP Nu. SMV-SA Safety Analysis System Level Requirements Fault Hazard Analysis System Architecture PSSA System Implementation System Safety Analysis • Provides a formal link between System Design and Safety Analysis. • Produces results useful both for System Design and for Safety Analysis (e. g. counterexamples and fault trees). • Based on the Nu. SMV Tool. • Implements novel techniques for dealing, e. g. with injection of failures and automatic construction of fault trees. Goal II. Application to Case Studies Certification • Application to various industrial case studies. Complex System

NASA Ames · · Application areas: complex on-board subsystems o Example: Shuttle Fuel management system On-board model-based diagnosis executor o Keep Track of observations to detect faults The diagnosability problem: o can on-board diagnosis detect ALL faults? Goal: formal techniques for diagnosability: o Reduce diagnosability to model checking o Nu. SMV used on real applications

Rockwell Collins · · · Application areas: complex on-board subsystems o Example: Pilot cockpit control system Enhance quality of requirements and designs o Possibly contradictory requirements o Complex interaction between functions Goal: formal techniques for verification o Map formal design language to Nu. SMV for requirement verification o Nu. SMV for design verification

Intel · · · Application areas: circuit analysis o ASICs, Micro. Processors subunits o Equivalence Checking, Property Checking The problem o Boolean Verification techniques o Do not exploit system structure (data vs control) Goal: Hybrid verification techniques o Response to Academic Research Program o Boolean and non-boolean verification

The DOVES Project: Motivations Domain o Deep Space missions o Small Scientific Missions program o International Space Station Autonomous On-Board Software o Operate flexibily in unmanned and unstructured environment o Can carry out wide spectrum of complex functions Problem: achieve higher degree of validation o Example: deadlock in Deep Space 1 space probe software o Detect software problems and faults at design time

The DOVES project: Goals Deliver effective methods and tools for enabling production of VERIFIED AUTONOMOUS ON-BOARD SOFTWARE Integrated platform to support: o Specification, Verification and Validation of Aos Requirements o Verification and Validation of Aos Designs o Simulation of Aos o Compilation of Aos o Test planning · Advanced synthesis techniques: o From Specification of Aos Requirements. . . o … to Aos Designs… o. . . guaranteed to satisfy requirements ·

Conclusions & Future Scenarios · · Conclusions o There is a market need for model checking and planning o There are technologies of potential significant impacts o They have to be integrated and applied selectively Future o Automated synthesys for more complex controllers o “Hybrid” techniques to deal wider range of problems o From off-line synthesis to on-board autonomy

A technology: Model Checking Requirement System Model · Model Checker Yes!, the model satisfies the requirements No! Here’s a counterexample. . . Basic Ingredients o Systems Modeled as a Finite State Automata (FSA) o Requirement Expressed in Temporal Logic o Formal V&V by exhaustive search over the state space