Safe and Secure Dependable Systems

1. Composing, Analyzing and Validating Software Models to Assess / Develop / Validate Methods and Supporting Tools for the Creation of Dependable Systems Frederick T. Sheldon, Ph.D. Oak Ridge National Laboratory Applied Software Engineering Research Laboratory Director – Software Engineering for Dependable Systems Research Lab Safe and Secure Dependable Systems University of Tennessee Knoxville, TN

2. Def: Software Process • Structured set of activities required to develop a software system • Specification • Design • Validation • Evolution • Activities vary depending on the organization and the type of system being developed Must be explicitly modeled to be effectively managed

3. What is a software process? • Activities – things that are done • Products – inputs and outputs • Sequencing – relationship among the activities and products How does sequencing work?

4. Verification versus Validation • Verificationdetermines if the products of a given phase of the SLCfulfill the requirementsestablished during the previous phase • Proof of transformation conformance • Did we build the product right? • Validationchecks if the program, as implemented, meets the expectations of the customerto ensure compliance with software requirements • Did we build the right product ?

5. Verification & Validation in Context

6. Abundance of Process Models • The waterfall model • Separate and distinct phases of specification and development • Evolutionary development • Specification and development are interleaved (e.g., Extreme Prgming) • Formal transformation • Mathematical system model formally transformed to an implementation • Reuse-based development • The system is assembled from existing components • Hybrid Methodologies • Prototyping for high-risk specifications (e.g., Spiral Model) • A heavyweight methodology has many rules, practices, and documents. • A lightweight methodology few rules / practices  easy to follow.

7. Evolutionary development

8. Transformational development Formal Transformations  Proof of Transformation Correctness

9. Spiral Model – Boehm

10. SEI’s 2167 / 2167A

11. The waterfall model • Separate and distinct phases of specification and development • Evolutionary development • Specification and development are interleaved (e.g., Extreme Prgming) • Formal transformation • Mathematical system model formally transformed to an implementation • Reuse-based development • The system is assembled from existing components • Hybrid Methodologies • Prototyping for high-risk specifications (e.g., Spiral Model) • A heavyweight methodology has many rules, practices, and documents. • A lightweight methodology few rules / practices  easy to follow. Indeed an Abundance of Process Models • Each has a particular place within the mosaic of computer science and engineering • However, when safety and/or significant cost are major driving requirements… • Its important to understand the maturity of your process in relation to those requirements!

12. CMM

13. Right process for the product to ensure … and nosilver bullet! • High quality software with competitive cost and cycle time... Quality [Defects] Cycle Time Cost … we must shrink the triangle!

14. Quality Attribute(s) Versus Cost Relation Moore’s law of Software Engineering

15. SLC Expenditure Profile Need to validate effective SE methods and tools…

16. Software Engineering is… • A scienceof building software • Software V&V, the science of building the RIGHT piece of software finding errors as early as possible • Research issues • Build tools for automatic software V&V • Investigate the theories behind the tools • Formal methods are useful for software V&V • Supported by a precise mathematical foundation • Theorem-proving approaches • Model-checking approaches (very short history) • Many apps a must for mission/safety critical software

17. Projects Agenda 1 • Verifying Safety Properties for auto-coded software at the model-based/ linguistic level • PCX Logical/ Stochastic formalism interoperability • SMSC Extending/ Integrating the MSC formalism into the Möbius framework • Model-based Requirements Specification Case study using Zed/Statecharts for guidance control software • Stochastic Modeling Framework (SMF) Case study using PNs/SANs for Anti-lock Braking System 2 3 4 5

18. Project One Project One • Verifying Safety Properties for auto-coded software at the model-based/ linguistic level • PCX Logical/ Stochastic formalism interoperability • SMSC Extending/ Integrating the MSC formalism into the Möbius framework • Model-based Requirements Specification Case study using Zed/Statecharts for guidance control software • Stochastic Modeling Framework (SMF) Case study using PNs/SANs for Anti-lock Braking System

19. Goal: Verifying Safety Properties for Auto-coded Software at the Model level • Domain: X-by-wire driver assisted systems (steering, breaking, power, etc) generally embedded real-time control (hybrid). • Benefits: Higher confidence that defects will be detected earlier  reducing the cost to ensure road vehicles are free of unsafe control software • Related work: http://www.ece.cmu.edu/~webk/checkmate/ overviews research sponsored by Ford Motor Company. • Problems/Results: Very complex system • Status/Plans: Developing a Software Safety Process Guidebook to recommend how to develop software in a more rigorous / systematic way taking into account new state-of-the-art standards and practices

20. Steer-by-wire: steering column disappears! Problem: Steering system is a safety critical in our vehicles... Steering functionality by electronics Possibility for all new dynamic driving control systems Optimized crash behavior No incomng steering column Optimized comfort A failure in the system must not endanger the steerability of the vehicle! Variable Steering gear ratio More fun of driving Vehicle behavior becomes designable Steer-by-wire: steering column disappears! Advantages:

21. Risk Analysis Safety- Requirements (SR) Safety Requirements for vehicles with Steer by wire 1 Vehicle must be steerable at |vx| > 0 km/h. Actuators must be redundant and must not block each other 2 System must be fail tolerant 3 Dormant Failures not allowed A) Errors in the system must be recognized and displayed to the driver or B) Driver is not allowed to put the vehicle into operation Vehicle must be steerable for delta t after motor stand still 4 5 ... SR for subsystems Safety Requirements Electric System Dual-circuit electric system Separation of the circuits Design proposals Safety Analysis Power supply for actuators from different electric circuits Monitoring of the electric system • System Safety is the • ability of a system to avoid critical situations and • also not to create critical situations The Process

22. Continuous Dynamics Differential Equations/Inclusions Stopwatch Timers etc. Discrete Dynamics Finite State Automata Zed/ Statecharts Petri Nets etc. Hybrid Systems

23. Hybrid Systems are … • Found virtually everywhere • Result of switching logic in many computer-controlled applications • Extremely difficult to analyze • Small perturbation can lead to drastically different behavior • No universally accepted framework for analysis and control

24. Focus: Verification Problem Very important problem for safety-critical applications All behaviors must be taken into account

25. Simulink/Stateflow Front End (graphical editing, simulation) Threshold-event-driven Hybrid Systems (TEDHS) Flow Pipe Approximations Conversion Quotient Transition System Partition Refinement Polyhedral-Invariant Hybrid Automaton (PIHA) ACTL Verification Initial Partition MATLAB Tool Overview Slide based on defense of Alongkrit Chutinan Carnegie Mellon University, Dept of ECE

26. switched continuous dynamics threshold event generator threshold events u(t) x(t) y(t) v(t) F(.,.) g(.) zero detector u(t) = h(u(t-),v(t)) u(0-) = u0 finite state machine (event driven) Threshold-event-driven Hybrid Systems (TEDHS) Slide based on defense of Alongkrit Chutinan Carnegie Mellon University, Dept of ECE

27. x1 Mux Mux2 Switched th1 Continuous System 1 Mux C*x <= d Mux Polyhedral x2 Threshold 1 th2 C*x <= d Switched Continuous System 2 Polyhedral OR Threshold 2 Logical Operator th3 x3 C*x <= d Mux Mux1 Switched Polyhedral Continuous System 3 Threshold 3 c1 q1 q c2 Finite State Machine 1 c1 q2 q c2 Finite State Machine 2 Sample Simulink Block Diagram

28. Hybrid Automaton guard condition location (discrete state) edge u’ u reset condition invariant: hybrid automaton may remain in u as long as xI(u) initial condition 5 continuous dynamics Slide based on defense of Alongkrit Chutinan Carnegie Mellon University, Dept of ECE

29. Project Two Project Two • Verifying Safety Properties for auto-coded software at the model-based/ linguistic level • PCX Logical/ Stochastic formalism interoperability • SMSC Extending/ Integrating the MSC formalism into the Möbius framework • Model-based Requirements Specification Case study using Zed/Statecharts for guidance control software • Stochastic Modeling Framework (SMF) Case study using PNs/SANs for Anti-lock Braking System

30. Goal: Logical/Stochastic Formalism Interoperability (SPNs  Promela) • Problem/ Domain: Requirements specification and analysis focused on real-time embedded control • Challenges:Promela is more complex (expressive power) than Petri net formalism • Benefits:predict system performance and dependability (non-functional properties) so that certain structural and architectural features can be evaluated and considered within the context of Spin-verifiable properties. • Related work: • Holzmann presented an approach for the translation of Petri Nets into a PROMELA model [‘94] using the idea that Petri Nets can easily be represented with a small subset of PROMELA constructs. • Grahlmann developed the PEP tool (Programming Environment based on Petri Net) that incorporates a feature that translates PNs into PROMELA for analysis using Spin [‘98] based on the same idea.

31. Example 2: Model created based on domain specific properties like O/P agreement, variable relationships and dependencies, liveness, mutual exclusion and transition/function consistency • Solving a logical model (written in Promela, CTL, etc.) to evaluate performance and reliability (transient and steady state behavior) Goal: Logical/Stochastic Formalism Interoperability (SPNs  Promela) • Problems/Results: Small examples have been translated. Stochastic information is added during the translation. Only a small subset of the PROMELA language has been translated. • Status/Plans: Plan to incorporate more language constructs and run more test cases. GUI PN Editor will be integrated. • Example 1: Model created based on structural/operational characteristics including event/activity characteristics • Model checking a stochastic model by decorating with logical / relational properties and developing/refining safety assertions that must hold • Example 2: Model created based on domain specific properties like O/P agreement, variable relationships and dependencies, liveness, mutual exclusion and transition/function consistency • Solving a logical model (written in Promela, CTL, etc.) to evaluate performance and and reliability (transient and steady state behavior)

32. Promela/PCX/SPN Translation Process

33. ≈ Holzmann and Grahlmann Sheldon and Wang But remember… the model (encircled) is created based on domain specific properties such as O/P agreement, variable relationships and dependencies, liveness, mutual exclusion etc. Solving a logical model (written in Promela, CTL, etc.) to evaluate performance and and reliability (transient and steady state behavior) Are They Equivalent …

34. SEDS Related Publications • Sheldon, F.T. and Wang, S., "A Translation Tool (PCX) from PROMELA/Spin to C-Based Stochastic Petri Net Language (CSPL)," Wkshp PMCCS 2001, Erlangen, pp. 116-120, Sept. 2001. • Sheldon, F.T. and Wang, S., “PCX: A Translation Tool from PROMELA/Spin to the C-Based Stochastic Petri Net Language,” 2003 Illinois International Multiconference on Measurement, Modelling, and Evaluation of Computer-Communication Systems 9/2-5/2003 (Submitted Feb. 2003 to Tools’03)

35. Project Three Project Three • Verifying Safety Properties for auto-coded software at the model-based/ linguistic level • PCX Logical/ Stochastic formalism interoperability • SMSC Extending/ Integrating the MSC formalism into the Möbius framework • Model-based Requirements Specification Case study using Zed/Statecharts for guidance control software • Stochastic Modeling Framework (SMF) Case study using PNs/SANs for Anti-lock Braking System

36. Goal: Extending Message Sequence Charts for Multi-formalism modeling in Möbius • Problem/Domain: modeling and performance analysis of distributed / message passing systems / inter-operability • Benefits: • Analysis for models expressed in the MSC formalism. • Integrating the extended MSC (SMSC) into the Möbius framework facilitates the use of a feature rich toolkit to analyze SMSC models. • MSC used with other formalisms for multi-formalism modeling. • Related work: • ITU-T, Recommendation Z.120: Message Sequence Chart(MSC). 1999: Geneva • D. Daly, et all, Möbius: An Extensible Framework For Performance and Dependability Modeling, FTCS-29, Madison, June 15-18, 1999. • Z. Zhou and F. Sheldon. Integrating the CSP Formalism into the Mobius Framework for Performability Analysis, PMCCS'5, Erlangen, Springer2001

37. Goal: Extending Message Sequence Charts for Multi-formalism modeling in Möbius • Problems/Results: • MSC are a popular formalism used in industry, but cannot be used for performance analysis without including stochastic timing information. • How to map MSC model constructs to the Möbius entities (i.e., identify state variables, actions and action groups). • Status/Plans: • Finished extending and mapping MSC to Möbius entities • Implemented C++ base classes representing MSC models • Implement the SMSC Möbius user interface (not done) • Determine how to handle different MSC model composition methods within Möbius (fundaments however are complete)

38. Hypothesis: Feasible/Useful/Valid Computer communication systems MSC Validation SMSC Möbius entities Application Feedback Möbius solvers MSC/Möbius Integration

39. Frame symbol MSC name Instance head msc example1 Instance axis i1 i2 i3 Instance end symbol m0 Message symbol m1 m2 Local action a m3 Basic MSC – Graphical / Textual Formalism Graphical representation

40. msc example1; i1: out m0 toenv; i1: out m1 to i2; i1: action a; i1: in m3 from i2; i2: in m1 from i1; i2: out m2 to i3; i2: out m3 to i1; i3: in m2 from i2; endmsc; msc example1 i1 i2 i3 Description of instance i1 m0 m1 Description of instance i2 m2 a Description of instance i3 m3 Basic MSC – Graphical / Textual Formalism Graphical representation Textual representation

41. msc A msc AB i j i j k m m n msc B j k n Basic MSC – Vertical Composition

42. msc A msc AB i j i j k m m n msc B j k n Co-region: where event order does not matter Basic MSC – Horizontal Composition

43. msc A msc B i j i j m n Basic MSC – Alternate Composition

44. Basic MSC – Reference msc A msc C i j i j k o m A msc B B j k p n

45. msc example1; i1: out m0 toenv withrate r1; i1: out m1 to i2 withrate r3; i1: action a withrate r; i1: in m3 from i2 withrate r8; i2: in m1 from i1 withrate r4; i2: out m2 to i3 withrate r5; i2: out m3 to i1 withrate r7; i3: in m2 from i2 withrate r6; endmsc; msc example1 i1 i2 i3 m0(r1, r2) m1(r3, r4) m2(r5,r6) a(r) m3(r7,r8) Stochastic MSC – Annotated Messages and Actions

46. msc example1(p1, p2) Global int number; conditionGO; i2 i1 i3 whenGO; a(r): number++; m1(r3, r4) m2(r5,r6) when number>0; m3(r7,r8) Stochastic MSC – Example Showing Shareable Variables

47. Instances, Messages, Activities, Conditions SMSC Model Möbius entities State variables Actions Action groups Model Möbius Model AFI Möbius solvers State space generator Simulator Analytic/numeric solvers SMSC Integration Makeup

48. Computer System Hardware Network OS Application Resource Contention Traffic Fault Tree LOTOS, Estelle Protocol VHDL Block Diagram Language Petri Nets, SANs Control/Data Flow Queuing Model Components Fault Description ? Challenges of Predicting the Performance/ Dependability of Modern Computer Systems Slide based on presentation of Bill Sanders University of Illinois at Urbana/Champagne

49. Submodel Interaction Framework Component Example Formalisms DSPN, GSPN, Markov chain, Queuing Network, SAN, SAN, SPA, other SPN extensions, Domain-specific formalism Atomic Model Graph interconnection Kronecker Composition (SAN), Replicate/Join, SPA Domain-specific formalism Composed Model Rate/Impulse reward variables Path-based reward variables Domain-specific formalism Solvable Model Fixed-point governor Acyclic model composer Connected Model Study Specifier (generates multiple models) Range and Set Variation Non-linear optimizer Model Specification Model Categories in the Möbius Framework Slide based on presentation of Bill Sanders University of Illinois at Urbana/Champagne

50. Composed Model Atomic Model Reward Variables Solvable Model Connected Model Model Construction Process • Models expressed in different framework components can be combined to form larger models • One or more atomic and/or composed models form a composed model • A atomic, composed, or solvable model, together with reward variables, form a solvable model • One or more solvable or connected models, together with reward variables, form a connected model • The model construction process retains the structure of each constituent model, facilitating efficient solution. Slide based on presentation of Bill Sanders University of Illinois at Urbana/Champagne