Specification: The Biggest Bottleneck in Formal Methods and Autonomy 1

Transcription

1 Specification: The Biggest Bottleneck in Formal Methods and Autonomy 1 Kristin Yvonne Rozier Iowa State University February 13, For expansions on these ideas, see: K.Y.Rozier. Specification: The Biggest Bottleneck in Formal Methods and Autonomy. VSTTE, 2016.

2 Successes Origins? Quality? Usage? Organization? Future Challenges Design-Time Verification! Expected design-time component Recommended in DO-178B/C, D0-254 standards for Successfully applied in many aerospace contexts... Temporal Logic Kristin Yvonne Rozier Specification: The Biggest Bottleneck in FM & Autonomy

3 Successes Origins? Quality? Usage? Organization? Future Challenges Runtime Verification and System Health Management! Required for Autonomy New: Intelligent Interfaces Hot topic: UTM, Mars, NextGen,... Temporal Logic Kristin Yvonne Rozier Specification: The Biggest Bottleneck in FM & Autonomy

4 A Recent Motivation... Crash of ESA s ExoMars Schiaparelli Lander October 19, 2016

5 A Recent Motivation... Crash of ESA s ExoMars Schiaparelli Lander October 19, 2016 parachute deployed at: altitude of 7.5 miles (12 km) speed of 1,1075 mph (1,730 km/h)

6 A Recent Motivation... Crash of ESA s ExoMars Schiaparelli Lander October 19, 2016 parachute deployed at: altitude of 7.5 miles (12 km) speed of 1,1075 mph (1,730 km/h) heat shield ejected at altitude of 4.85 miles (7.8 km)

7 A Recent Motivation... Crash of ESA s ExoMars Schiaparelli Lander October 19, 2016 parachute deployed at: altitude of 7.5 miles (12 km) speed of 1,1075 mph (1,730 km/h) heat shield ejected at altitude of 4.85 miles (7.8 km) IMU miscalculated saturation-maximum period (by 1 sec)

8 A Recent Motivation... Crash of ESA s ExoMars Schiaparelli Lander October 19, 2016 parachute deployed at: altitude of 7.5 miles (12 km) speed of 1,1075 mph (1,730 km/h) heat shield ejected at altitude of 4.85 miles (7.8 km) IMU miscalculated saturation-maximum period (by 1 sec) Navigation system calculated a negative altitude premature release of parachute & backshell firing of braking thrusters activation of on-ground systems at 2 miles (3.7 km) altitude

9 A Recent Motivation... Crash of ESA s ExoMars Schiaparelli Lander October 19, 2016 parachute deployed at: altitude of 7.5 miles (12 km) speed of 1,1075 mph (1,730 km/h) heat shield ejected at altitude of 4.85 miles (7.8 km) IMU miscalculated saturation-maximum period (by 1 sec) Navigation system calculated a negative altitude premature release of parachute & backshell firing of braking thrusters activation of on-ground systems at 2 miles (3.7 km) altitude Crash at 185 mph (300 km/h)

10 A Recent Motivation... Crash of ESA s ExoMars Schiaparelli Lander Sanity Checks Relevant to this Mission: The altitude cannot be negative. The rate of change of descent can t be faster than gravity. The δ altitude must be within nominal parameters; it cannot change from 2 miles to a negative value in one time step. The saturation-maximum has an a priori known temporal bound. These sanity checks could have prevented the crash. Capability of such observations is required for autonomy.

11 Enabling Autonomy What do the humans do? 1 Pilot/control the system (on-board or remotely) 2 Provide self-awareness 3 Respond to off-nominal conditions 4 Make tough judgment calls

12 Enabling Autonomy What do the humans do? And how do we automate that? 1 Pilot/control the system (on-board or remotely) Autopilot 2 Provide self-awareness Runtime System Health Management (SHM) 3 Respond to off-nominal conditions Automated replanning and learning 4 Make tough judgment calls Algorithms like TCAS beat humans Ethical decisions are an open problem... Analysis from design-time and runtime is required for autonomy.

13 Successes Origins? Quality? Usage? Organization? Future Challenges Specifications: Required for Formal Methods and Autonomy! Formal Methodology 2 1 specification language 2 repertoire of proof methods make early precise decisions about major functionalities remove ambiguities from the description of expected behavior 2 Manna & Pnueli. The Temporal Logic of Reactive and Concurrent Systems: Specification. Springer, Temporal Logic Kristin Yvonne Rozier Specification: The Biggest Bottleneck in FM & Autonomy

14 Successes Origins? Quality? Usage? Organization? Future Challenges Specifications: Required for Formal Methods and Autonomy! Formal Methodology 2 1 specification language Linear Temporal Logic 2 repertoire of proof methods make early precise decisions about major functionalities remove ambiguities from the description of expected behavior 2 Manna & Pnueli. The Temporal Logic of Reactive and Concurrent Systems: Specification. Springer, Temporal Logic Kristin Yvonne Rozier Specification: The Biggest Bottleneck in FM & Autonomy

15 A Goal Aerospace System Design Process 3 M = Formal System Model Model Validation via Model Checking REVISE Model Validation Specification SPEC DEBUGGING System Design Model Check Model Verification Specification ERROR SPEC DEBUGGING NO Build Prototype Testing and ERROR... NO Simulation YES USE SPECIFICATIONS FOR RUNTIME MONITORING YES 3 Zhao & Rozier. Formal Specification and Verification of a Coordination Protocol for an Automated Air Traffic Control System. Science of Computer Programming Journal (96:3), pg , Elsevier, 2014.

16 A Goal Aerospace System Design Process 3 M = Formal System Model Model Validation via Model Checking REVISE Model Validation Specification SPEC DEBUGGING System Design Model Check Model Verification Specification ERROR SPEC DEBUGGING NO Build Prototype Testing and ERROR... NO Simulation YES USE SPECIFICATIONS FOR RUNTIME MONITORING... Garbage in, garbage out! YES 3 Zhao & Rozier. Formal Specification and Verification of a Coordination Protocol for an Automated Air Traffic Control System. Science of Computer Programming Journal (96:3), pg , Elsevier, 2014.

17 The Bottom Line Bottom Line: INPUTS to formal analysis are the BIGGEST challenge System Design M = Formal System Model Model Check Model Verification Specification... ERROR......

18 Synthesis! Model checking: check M = φ Problems: 4 Designing M is hard and expensive Re-designing M when M φ is hard and expensive Synthesis: start from φ, design M such that M = φ Simplifies verification No re-design For algorithmic derivations: no design! 4 M.Y.Vardi. From Verification to Synthesis. VSTTE 2008.

19 Synthesis! Model checking: check M = φ Problems: 4 Designing M is hard and expensive Re-designing M when M φ is hard and expensive Synthesis: start from φ, design M such that M = φ Simplifies verification No re-design For algorithmic derivations: no design! What about φ? 4 M.Y.Vardi. From Verification to Synthesis. VSTTE 2008.

20 Synthesis! Model checking: check M = φ Problems: 4 Designing M is hard and expensive Re-designing M when M φ is hard and expensive Synthesis: start from φ, design M such that M = φ Simplifies verification No re-design For algorithmic derivations: no design! What about φ? We need LTL Genesis! 4 M.Y.Vardi. From Verification to Synthesis. VSTTE 2008.

21 Specification Origins Where will we get specifications from? 5 Some critical systems are designed without formal requirements Some design processes don t formally define requirements until the testing phase Early specifications often mix many different objectives levels of detail/abstraction how the system is defined vs how the system should behave legal-speak on why the system satisfies rules desires/opinions of designers 5 Panel: Future Directions of Specifications for Formal Methods. In NFM 2014, J.Badger and K.Y.Rozier, eds.

22 Specification Origins Specification Extraction Strategies Human Authorship: Train system designers to write formal specifications first Pair designers with formal methods team to write specifications Natural Language Processing: extract formal specifications from English Operational Concepts 6 Highly input-dependent: assumptions, implied/arbitrary functions Hard to measure correctness, completeness Specification Mining: extract behaviors from existing systems Static Analysis: map all paths of a program Hard to differentiate normal usage from exceptions Learning/Dynamic Invariants: analyze actual executions; observe use-cases Specification Wizard: Semi-automated exploration of system facets, guided by human input 6 S.Ghosh, N.Shankar, P.Lincoln, D.Elenius, W.Li, and W.Steiener. Automatic Requirements Specification Extraction from Natural Language (ARSENAL). SRI International, Menlo Park CA, 2014.

23 Specification Origins Specifications for Free? 7 Combine specification mining, test-case generation, static analysis, and dynamic invariants to extract specifications automatically! Can use specifications mined from code Specification validation == software defect detection Promising for software runtime verification Still need code... What about early design time? What about cyber-physical system specifications? Can use specifications extracted from last version for new designs Challenges with specialization/levels of abstraction/relevance Other challenges: Scalability Efficiency Expressiveness 7 A. Zeller. Specifications for Free. NFM 2011.

24 Specification Quality How should we measure specification quality? 8 How can we know when we re done? How good are the specifications? How can we measure the completeness, correctness, coverage, or general quality of a set of specifications? 8 Panel: Future Directions of Specifications for Formal Methods. In NFM 2014, J.Badger and K.Y.Rozier, eds.

25 Specification Quality Sanity Checks Satisfiability Vacuity Realizability Coverage

26 Specification Usage How do we best use specifications? 9 Design lifecycles for different cyber-physical systems? How to indoctrinate formal specification into diverse teams of system designers? Barriers to adoption: time to write/validate learning curves culture Need an end-to-end process for specification extraction, usage What should our roadmap look like for a future full of well-specified (formally analyzable) critical systems? 9 Panel: Future Directions of Specifications for Formal Methods. In NFM 2014, J.Badger and K.Y.Rozier, eds.

27 Specification Usage Specification Use Strategies Property-Based Design: from specifications to systems Synthesis: generate M such that M = φ For cyber-physical systems? Specification-Based Testing: use specifications in test-case generation From Design- to Run-Time: carry specifications through the design cycle Specification design lifecycle? Maintenance: using specifications in system up-keep Maintenance of specifications?

28 Specification Patterns! Specifications: Classes 10 Others: Safety Response Reactivity Safety/Liveness/Guarantee/Obligation Fairness/Justice/Compassion Still too coarse and tied to syntax for practical use; need functional and hierarchical specification Manna & Pnueli. The Temporal Logic of Reactive and Concurrent Systems: Specification. Springer, 1992.

29 Specification Patterns! Specifications: Formula Patterns 11 Leverage experience with design and coding patterns Define specification pattern system capture recurring solutions; generalize across specific/domain problems encourage re-use make transparent the means by which requirements are satisfied name, intent, logic (language), scope (time interval), relationship to other patterns Characterized by: Solves a Specific Problem, e.g. not too abstract Proven Concept effective in practice Not Obvious or direct application of basic principles Describes Relationships, not single components Generative, describes how to construct a solution Organized in a hierarchy based on semantics 11 M.B. Dwyer, G.S. Avrunin, and J.C. Corbett. Property specification patterns for finite-state verification. Formal methods in software practice, pp ACM, 1998.

30 Specification Patterns! Specifications: Automata Patterns 12 Challenges Remain with Translational Semantics: Formula patterns are not compositional Need consistency with semantics of informal definitions Automata-based patterns: Compositional: based on compositions of patterns (logic executions) and scopes (time) Homogeneous: don t flatten key patterns/scopes separation Extensible: compositional semantics allow adding patterns & scopes Generic: can combine any pattern and any scope Faithful: formal guarantee that the translated temporal formula is faithful to the intended natural semantics 12 K.C. Castillos, F. Dadeau, J. Julliand, B. Kanso, and S. Taha. A compositional automata-based semantics for property patterns. ifm, pp , 2013.

31 Specification Patterns! Specifications: Automata Patterns 12 Challenges Remain with Translational Semantics: Formula patterns are not compositional Need consistency with semantics of informal definitions Automata-based patterns: Compositional: based on compositions of patterns (logic executions) and scopes (time) Homogeneous: don t flatten key patterns/scopes separation Extensible: compositional semantics allow adding patterns & scopes Generic: can combine any pattern and any scope Faithful: formal guarantee that the translated temporal formula is faithful to the intended natural semantics What about runtime specifications for autonomous systems? 12 K.C. Castillos, F. Dadeau, J. Julliand, B. Kanso, and S. Taha. A compositional automata-based semantics for property patterns. ifm, pp , 2013.

32 Specification Patterns! Specifications: Functional Patterns? Work on specification patterns focuses mostly on design time Formula patterns are not compositional Automata patterns are not decomposable hard for cyber-physical systems during runtime sanity checks are more complex What if that is a functional pattern? Are there different patterns for specification functions, e.g., between design time and runtime?

33 Specification Patterns! Runtime Functional Specification Patterns 13 Rates Ranges Relationships Control Sequences Consistency Checks 13 K.Y.Rozier. Specification: The Biggest Bottleneck in Formal Methods and Autonomy. VSTTE, 2016.

34 Specification Patterns! Runtime Functional Specification Patterns 13 Rates Ranges Relationships Control Sequences Consistency Checks 13 K.Y.Rozier. Specification: The Biggest Bottleneck in Formal Methods and Autonomy. VSTTE, 2016.

35 Specification Patterns! Runtime Functional Specification Patterns 13 Rates Velocity Ranges Relationships Velocity Control Sequences Consistency Checks 13 K.Y.Rozier. Specification: The Biggest Bottleneck in Formal Methods and Autonomy. VSTTE, 2016.

36 Specification Patterns! Runtime Functional Specification Patterns 13 Rates Ranges Relationships Control Sequences Consistency Checks 13 K.Y.Rozier. Specification: The Biggest Bottleneck in Formal Methods and Autonomy. VSTTE, 2016.

37 Specification Patterns! Runtime Functional Specification Patterns 13 Rates Ranges? Relationships Control Sequences Consistency Checks 13 K.Y.Rozier. Specification: The Biggest Bottleneck in Formal Methods and Autonomy. VSTTE, 2016.

38 Specification Patterns! Runtime Functional Specification Patterns 13 Rates Ranges? Relationships Control Sequences Consistency Checks We need to expand specification patterns to runtime! 13 K.Y.Rozier. Specification: The Biggest Bottleneck in Formal Methods and Autonomy. VSTTE, 2016.

39 Specification Patterns! R2U2: Runtime Specification Patterns in the Field 14 1 TL Observers: Efficient temporal reasoning 1 Asynchronous: output t, {0, 1} 2 Synchronous: output t, {0, 1,?} Logics: MTL, pt-mtl, Mission-time LTL Variables: Booleans (from system bus), sensor filter outputs 2 Bayes Nets: Efficient decision making Variables: outputs of TL observers, sensor filters, Booleans Output: most-likely status + probability 14 T. Reinbacher, K. Y. Rozier, and J. Schumann. Temporal-Logic Based Runtime Observer Pairs for System Health Management of Real-Time Systems. TACAS 14, pg

40 Specification Patterns! R2U2: Runtime Specification Patterns in the Field 14 1 TL Observers: Efficient temporal reasoning 1 Asynchronous: output t, {0, 1} 2 Synchronous: output t, {0, 1,?} Logics: MTL, pt-mtl, Mission-time LTL Variables: Booleans (from system bus), sensor filter outputs 2 Bayes Nets: Efficient decision making Variables: outputs of TL observers, sensor filters, Booleans Output: most-likely status + probability How do we organize R2U2 specifications? 14 T. Reinbacher, K. Y. Rozier, and J. Schumann. Temporal-Logic Based Runtime Observer Pairs for System Health Management of Real-Time Systems. TACAS 14, pg

41 Specification Patterns! R2U2: Runtime Specification Patterns in the Field 15 Health Nodes / Failure Modes H FG magnetometer sensor H FC RxUR Receiver underrun H FC RxOVR Receiver overrun H FG TxOVR Transmitter overrun in sensor H FG TxErr Transmitter error in in sensor H_FG H_FC_RxUR H_FC_RxOVR H_FG_TxOVR H_FG_TxErr S4 S5 S6 S3 S1 S2 We combine specifications in a way that is: hierarchical/structured compositional cross-language 15 J. Geist, K.Y. Rozier, and J. Schumann. Runtime Observer Pairs and Bayesian Network Reasoners On-board FPGAs: Flight-Certifiable System Health Management for Embedded Systems. RV 14.

42 How should we organize specifications? How do we store specifications in an accessible way? Allow for automated analysis, including verification? Enable re-use: design-time runtime future systems How do we pair English and Formal specifications? How do we preserve the hierarchical structure, compositionality, and relationships between specifications? Can we do this in a performable way?

43 Specification Organization Strategies Scenario Definition Languages

44 Specification Organization Strategies Scenario Definition Languages M vs φ?

45 Specification Organization Strategies Scenario Definition Languages M vs φ? Matlab/Simulink not scalable not backwards-compatible for long specification lifecycles not designed for this (kludgy)...

46 Specification Organization Strategies Scenario Definition Languages M vs φ? Matlab/Simulink not scalable not backwards-compatible for long specification lifecycles not designed for this (kludgy)... Database: SQL relationships are inherently non-tabular requires flattening the database requires extensive JOINs; non-performable

47 Specification Organization Strategies Scenario Definition Languages M vs φ? Matlab/Simulink not scalable not backwards-compatible for long specification lifecycles not designed for this (kludgy)... Database: SQL relationships are inherently non-tabular requires flattening the database requires extensive JOINs; non-performable None of these solve the organization problem!

48 Big Data of Specifications? If we do it right, specifications are everywhere! How do we organize specifications for each subsystem subcomponent level of abstraction How do we mine specifications for data patterns statistical analysis coverage How do we search specifications? How do we sort specifications? How do we integrate specification languages for different purposes? How do we make specifications available for reuse? We have a Big Data of Specifications problem!

49 Neo4j: Property Graph Database 16 A property graph G = {N, P, R} where N is a set of nodes, P is a set of properties, R is a set of relationships, Node: document contain sets of properties Properties: key/value pair Key: string Value: arbitrary data type Relationships: connect & structure nodes direction label start node end node [properties] 16

50 Specification Challenges: to Infinity and Beyond! You are here Coverage Quality Specifications Where are we now? Continuously re-assess... Where will we get specifications from? Correctness How should we measure specification quality? How do we best use specifications? How should we organize specifications? Completeness

51 Specification Challenges: to Infinity and Beyond! You are here Coverage Quality Specifications Where are we now? Continuously re-assess... Where will we get specifications from? Correctness How should we measure specification quality? How do we best use specifications? How should we organize specifications?... in the context of cyber-physical, autonomous systems? Completeness