Safe and Secure Dependable Systems

1
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

• Verification determines if the products of a
  given phase of the SLC fulfill the requirements
  established during the previous phase
• Proof of transformation conformance
• Did we build the product right ?
• Validation checks if the program, as implemented,
  meets the expectations of the customer to 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
SEIs 2167 / 2167A
11
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 no
silver 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
Moores law of Software Engineering
15
SLC Expenditure Profile
Need to validate effective SE methods and tools
16
Software Engineering is

• A science of building software
• Software VV, the science of building the RIGHT
  piece of software ? finding errors as early as
  possible
• Research issues
• Build tools for automatic software VV
• Investigate the theories behind the tools
• Formal methods are useful for software VV
• 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

• 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

1
2
3
4
5
18
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/checkma
  te/ 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!
Advantages
21
System Safety is the ability of a system to avoid
critical situations and also not to create
critical situations
The Process
22
Hybrid Systems

• Continuous
• Dynamics
• Differential Equations/Inclusions
• Stopwatch Timers
• etc.

• Discrete
• Dynamics
• Finite State Automata
• Zed/ Statecharts
• Petri Nets
• etc.

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
MATLAB Tool Overview
Slide based on defense of Alongkrit
Chutinan Carnegie Mellon University, Dept of ECE
26
Threshold-event-driven Hybrid Systems (TEDHS)
Slide based on defense of Alongkrit
Chutinan Carnegie Mellon University, Dept of ECE
27
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

• 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
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
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 Tools03)

35
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,
  Springer 2001

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
MSC/Möbius Integration
39
Basic MSC Graphical / Textual Formalism
Graphical representation
40
Basic MSC Graphical / Textual Formalism
Graphical representation
Textual representation
41
Basic MSC Vertical Composition
42
Basic MSC Horizontal Composition
43
Basic MSC Alternate Composition
44
Basic MSC Reference
45
Stochastic MSC Annotated Messages and Actions

• msc example1
• i1 out m0 to env 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

46
Stochastic MSC Example Showing Shareable
Variables

47
SMSC Integration Makeup
48
Challenges of Predicting the Performance/
Dependability of Modern Computer Systems
Slide based on presentation of Bill
Sanders University of Illinois at
Urbana/Champagne
49
Model Categories in the Möbius Framework
Slide based on presentation of Bill
Sanders University of Illinois at
Urbana/Champagne
50
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
51
Model Support of the Abstract Functional
Interface State Variables, Actions, Groups

• Formally, a model in the Möbius framework is a
  set of state variables, a set of actions, and
  set of action groups
• State variables contain information about the
  state of the system being modeled
• They have a type, which defines their structure
• They have a value, which defines the state of
  the variable
• Actions prescribe how the value of state
  variables may change as a function of time
• Action groups define sets of actions and/or
  action groups that cooperate or compete to change
  state
• Other models and solvers may request state
  information or change a models state variables,
  actions, and groups via the abstract functional
  interface

Slide based on presentation of Bill
Sanders University of Illinois at
Urbana/Champagne
52
Möbius Tool Architecture
Slide based on presentation of Bill
Sanders University of Illinois at
Urbana/Champagne
53
SEDS Related Publications

• Sheldon, F.T. and Zhou, Z, "Integrating the CSP
  formalism into Möbius Framework for
  Performability Analysis," Fifth Intl Wkshp on
  Performability Modeling of Computer and
  Communication Systems PMCCS 2001, Erlangen, pp.
  86-89, Sept. 2001.
• Sheldon, F.T., Xie, Gaoyan, Pilskalns, Orest and
  Zhou, Zhihe, "Survey of Rigorous Software
  Specification and Design Tools," Software Focus
  Jr., John Wiley and Sons, London, 24 Winter
  2001.
• Sheldon, F.T. and Zhou, Z., "Extending Message
  Sequence Charts for Multi-level and
  Multi-formalism Modeling in Möbius," Submit Feb.
  15 2003, PNPM 2003).

54
Project Four

• 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

55
Goal Zed/ Statecharts analysis for validating
software requirements

• Problem/Domain Specification / analysis for the
  purpose of VV (testing requirements)
• Challenges
• Validity of abstract / translation Zed ? NL,
  S/Cs ? Zed
• Choosing test cases to ensure complete coverage.
• Benefits One is able to
• Ensure the completeness, consistency, and
  fault-tolerance of a software requirements
  specification (SRS),
• Avoid the problems that force corrective rework,
• to minimize risk of costly errors propagated
  into downstream activities.

56
From NL-based SRS ? Statecharts, and beyond
NL-based SRS
Z Specification
Statecharts
Testing and Fault Injection
57
Related Work/ Results/ Plans

• Related work
• (1) Hierons RM, Sadeghipour S, Singh H. Testing a
  system specified using Statecharts and Z. Info
  and SW Tech 43 137-149 2001
• (2) Bussow R, Geisler R, Klar M. Specifying
  Safety-Critical Embedded Systems with Statecharts
  and Z A Case Study. LNCS 1382 1998
• Problems/Results Guidance Control NL-based SRS
  Case Study
• Showed/ detected multiple ambiguities,
• Verified completeness, consistency, and
  fault-tolerance,
• Approach is extensible to embedded control
  systems,
• See below for more specific results.
• Status/Plans
• Develop concrete (mechanizable) translation rules
  between methods.
• Plan to evolve/ revise the approach to x-by-wire
  composed system (e.g., Steer/Brake/Power/Traction-
  by-wire for collision avoidance and automatic
  functions like parking)

58
Landing Vehicle During Descent
59
Illustration of Vehicle
60
Planned Terminal Descent Trajectory
61
Velocity-Altitude Contour
62
GCS System Architecture
63
Natural Language based SRS
Zed Specification and Proof
Statechart Visualization and Simulation
64
GCS Schema Hierarchy
65
GCS Module Chart
66
Actual GCS Module Chart
67
Methodology Summary

• Interpretation from NL to Zed
• Clarified ambiguities
• Interpretation from Zed to Statecharts
• Iterative process that clarified misinterpreted
  Zed specification
• Simulation and testing with fault injection
• Reveals fault-prone system states
• Fault-tolerance validation

Several versions of Statecharts were developed.
During the testing phase a better understanding
of the specification/model caused revision of the
Zed specification
68
Two Formalisms Combining Strengths

• Zed
• Clarify ambiguities and identify assumptions
• Correctness checking tool-based hand-guided
  proofs
• In-depth understanding of the requirements
• Statecharts
• Visual formalism with diagrammatic grammar made
  up of activity and Statecharts
• Symbolic simulation enables testing and
  evaluation
• Providing e.g., predevelopment evaluation via
  fault injection

69
Summary of Case Study Findings

• From NL to Zed discovered ambiguities
• Rotation variable definition are ambiguous
• AR_COUNTER variable type scope are ambiguous
• Undefined 3rd order polynomial.
• Zed to Statecharts revealed a deficiency must
  include
• 1 AR_FREQUENCY AR_COUNTER75000
• Or, AR_COUNTER 1 ?
  (0AR_COUNTERAR_FREQUENCY/75000)

70
SEDS Related Publications

• Sheldon, F.T., Kim, H.Y., and Zhou, Z, "A Case
  Study Validation of Guidance Control Software
  Requirements for Completeness, Consistency and
  Fault Tolerance," IEEE Proc. Pacific Rim
  Dependability Conference PRDC 2001, Seoul, Dec.
  2001.
• Sheldon, F.T., Kim, H.Y., and "Validation of
  Guidance Control Software Requirements for
  Reliability and Fault-Tolerance," IEEE Proc.
  Reliability and Maintainability Symp. RAMS 2001,
  Seattle, Jan. 2002.
• Kim, H.Y. and Sheldon, F.T., "Testing Software
  Requirements with Z and Statecharts Applied to an
  Embedded Control System," Springer-Verlag,
  Software Quality Jr. Kluwer Submitted Dec. 2002

71
Project Five

• 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 Case study using
  PNs/SANs for Anti-lock Braking System

72
Goal Stochastic Modeling Framework Case Study
Anti-lock Braking System

• Problem/Domain Model road vehicle ABS
  emphasizing failure severity, coincident failures
  and usage profiles using SPNs and SANs
  formalisms.
• Challenges
• Need to handle large state space complex systems
  often include many layers of complexity and
  numerous constituent components
• For realistic results we must model components to
  a sufficient level of detail
• Models should be scalable and extensible to
  accommodate the larger context
• Benefits Greater insight about the contribution
  of different components and non-functional
  factors to the overall system reliability.
• Establishes a framework for studying important
  factors that determine system reliability
• Related work
• F.T. Sheldon, S. Greiner and M. Benzinger,
  Specification, safety and reliability analysis
  using Stochastic Petri Net models, in Proc. of
  10th Int. Wkshp on Software Specification and
  Design, San Diego, 2000, pp. 123-132.

73
Goal Stochastic Modeling Framework Case Study
Anti-lock Braking System

• Problems/Results Transient analysis of SPNs
  (using Stochastic Petri Net Package v. 6) and
  Stochastic Activity Network (UltraSAN v. 3.5)
  models was carried out and the results compared
  for validation purposes.
• Results emphasized the importance of modeling
  failure severity, coincident failures and
  usage-profiles for measuring system reliability.
  
• Status/Plans
• Carry out the sensitivity analysis for the models
  developed to gain an insight into which
  components affect reliability more than others.
• Model the entire system. ABS is a small part of
  the Dynamic Driving Regulation system and shares
  components with the ESA (Electronic Steer
  Assistance) and TC (Traction Control).
• Use simulation to analyze the model of the entire
  system. The model of the system would be too
  complex to allow numerical means of analysis.
• Validate the results of the analysis against real
  data (if such data becomes available to us).

74
Further Details
DDR (Dynamic Driving Regulation System)
75
SEDS Related Publications

• Sheldon, F.T. Greiner, S.A., and Benzinger, M.,
  "Specification, Safety and Reliability Analysis
  Using Stochastic Petri Net Models," ACM Proc.
  10th Int'l Wkshp on SW Spec. and Design, San
  Diego, pp. 123-132 Nov. 5-7 2000.
• Sheldon, F.T. and Jerath, K., "Reliability
  Analysis of an Anti-lock Braking System Using
  Stochastic Petri Nets," 5th Intl Wkshp on
  Performability Modeling of Comp. / Comm. Sys
  PMCCS 2001, Erlangen, pp. 56-60, Sept. 2001.
• Sheldon, F.T., Jerath, K., and Greiner, S.A.,
  Examining Coincident Failures and Usage-Profiles
  in Reliability Analysis of an Embedded Vehicle
  Sub-System, Proc. 9th Intl. Conference on
  Analytical and Stochastic Modeling Techniques
  ASMT 2002, Darmstadt, June 3-5, 2002.
• Sheldon, F.T. and Jerath, Kshamta, Specification
  Modeling and Stochastic Analysis of Embedded
  Systems with Emphasis on Coincident Failures and
  Usage-Profiles, Submit June 2002, IEEE Trans.
  On Reliability

76
Key SE Issues in Software Safety I

• Provide readier access to formal methods for
  developers of safety-critical systems by further
  integration of informal and formal methods .
• Develop better methods for safety analysis of
  product families and safe reuse of
  Commercial-Off-The-Shelf software .
• Improve the testing and evaluation of
  safety-critical systems through the use of
  requirements-based testing, evaluation from
  multiple sources, model consistency, and virtual
  environments .

R. Lutz, NASA JPL
77
Key SE Issues in Software Safety II

• Ensure SW technology transfer from the lab to
  practice with case studies to enable earlier
  adoption of potentially cost savings / safety
  ensuring advances.
• Advance the use of runtime monitoring to detect
  faults and recover to a safe state, as well as to
  profile system usage to enhance safety analyses.
• Promote collaboration with related fields in
  order to exploit advances in areas such as
  security and survivability, software
  architecture, theoretical computer science, human
  factors engineering, and software engineering
  education.

78
Research Summary and Plans

• Experience with numerous formalisms and tools
• We will continue to
• Assess, develop and validate methods and
  supporting tools for the creation of safe and
  dependable systems
• Develop an integrated framework for composing,
  analyzing and validating system and software
  models
• Verification mission / safety critical hybrid
  systems
• Extend to security related verification and
  validation
• Publish

79
Contact Information
80
The end
81
Other SEDS Research

• Recent publications
• Sheldon, F.T., Jerath, Kshamta and Chung, Hong,
  "Metrics for Maintainability of Class Inheritance
  Hierarchies," Jr. of Software Maintenance and
  Evolution, John Wiley and Sons, London, Summer
  2002.
• Sheldon, F.T., Kwon, Y-J., Baik, Young-Wook and
  Jerath, K., Case Study Implementing a Web Based
  Auction System using UML and Components, Proc.
  Intl. Annual Computer Software and Applications
  Conference COMPSAC 2002, Oxford, Aug. 26-29, 2002
• Developing CGE (PN Graphical Editor) with Java
  using various graph layout algorithms for model
  visualization
• Home page http//www.csm.ornl.gov/sheldon
• Publications http// www.csm.ornl.gov/sheldon
  /publications.html
• Username batman, Password just ask me
  (sheldon_at_acm.org)

82
Making Verification Tools Useful for Industry