Safe and secure dependable systems
This presentation is the property of its rightful owner.
Sponsored Links
1 / 82

Safe and Secure Dependable Systems PowerPoint PPT Presentation


  • 126 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Safe and Secure Dependable Systems

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Safe and secure dependable systems

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


Def software process

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


What is a software process

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?


Verification versus validation

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 ?


Safe and secure dependable systems

Verification & Validation in Context


Abundance of process models

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.


Evolutionary development

Evolutionary development


Transformational development

Transformational development

Formal Transformations 

Proof of Transformation Correctness


Spiral model boehm

Spiral Model – Boehm


Safe and secure dependable systems

SEI’s 2167 / 2167A


Indeed an 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.

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!


Safe and secure dependable systems

CMM


Right process for the product to ensure and no silver bullet

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!


Quality attribute s versus cost relation

Quality Attribute(s) Versus Cost Relation

Moore’s law of Software Engineering


Slc expenditure profile

SLC Expenditure Profile

Need to validate

effective SE methods

and tools…


Software engineering is

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


Projects agenda

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


Project one

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


Goal verifying safety properties for auto coded software at the model level

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


Safe and secure dependable systems

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:


Safe and secure dependable systems

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


Hybrid systems

Continuous

Dynamics

Differential Equations/Inclusions

Stopwatch Timers

etc.

Discrete

Dynamics

Finite State Automata

Zed/ Statecharts

Petri Nets

etc.

Hybrid Systems


Hybrid systems are

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


Focus verification problem

Focus: Verification Problem

Very important problem for safety-critical applications

All behaviors must be taken into account


Matlab tool overview

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


Threshold event driven hybrid systems tedhs

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


Sample simulink block diagram

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


Hybrid automaton

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


Project two

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


Goal logical stochastic formalism interoperability spns promela

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.


Goal logical stochastic formalism interoperability spns promela1

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


Promela pcx spn translation process

Promela/PCX/SPN Translation Process


Are they equivalent

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 …


Seds related publications

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)


Project three

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


Goal extending message sequence charts for multi formalism modeling in m bius

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


Goal extending message sequence charts for multi formalism modeling in m bius1

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)


Msc m bius integration

Hypothesis: Feasible/Useful/Valid

Computer communication systems

MSC

Validation

SMSC

Möbius entities

Application

Feedback

Möbius solvers

MSC/Möbius Integration


Safe and secure dependable systems

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


Safe and secure dependable systems

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


Basic msc vertical composition

msc A

msc AB

i

j

i

j

k

m

m

n

msc B

j

k

n

Basic MSC – Vertical Composition


Safe and secure dependable systems

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


Safe and secure dependable systems

msc A

msc B

i

j

i

j

m

n

Basic MSC – Alternate Composition


Safe and secure dependable systems

Basic MSC – Reference

msc A

msc C

i

j

i

j

k

o

m

A

msc B

B

j

k

p

n


Safe and secure dependable systems

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


Safe and secure dependable systems

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


Safe and secure dependable systems

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


Challenges of predicting the performance dependability of modern computer systems

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


Safe and secure dependable systems

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


Model construction process

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


Model support of the abstract functional interface state variables actions groups

Model Support of the Abstract Functional Interface: State Variables, Actions, & Groups

  • Formally, amodel 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 groupsdefine sets of actions and/or action groups thatcooperate or compete to change state

  • Other models and solvers may request state information or change a model’s state variables, actions, and groups via the abstract functional interface

Slide based on presentation of Bill Sanders

University of Illinois at Urbana/Champagne


M bius tool architecture

Reward Editor

Project Manager

Atomic Editor

Composer

Model Connector

`

`

Study Editor

Model Conn. Object Code

Composed Model Object Code

Atomic Model Object Code

Reward Object Code

Study Editor Object Code

Formalism Libraries

Linker

Solver Libraries

Executable Model

Möbius Tool Architecture

Slide based on presentation of Bill Sanders

University of Illinois at Urbana/Champagne


Seds related publications1

SEDS Related Publications

  • Sheldon, F.T. and Zhou, Z, "Integrating the CSP formalism into Möbius Framework for Performability Analysis," Fifth Int’l 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, 2:4 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).


Project four

Project Four

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


Goal zed statecharts analysis for validating software requirements

Goal: Zed/ Statecharts analysis for validating software requirements

  • Problem/Domain: Specification / analysis for the purpose of V&V (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.


From nl based srs statecharts and beyond

NASA Spacecraft Guidance and Control Software

Application

Feedback

From NL-based SRS  Statecharts, and beyond …

NL-based SRS

Z Specification

Statecharts

Testing and

Fault Injection


Related work results plans

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)


Landing vehicle during descent

Landing Vehicle During Descent


Illustration of vehicle

Illustration of Vehicle


Planned terminal descent trajectory

Planned Terminal Descent Trajectory


Safe and secure dependable systems

Altitude

Engines On Altitude

Velocity-Altitude Contour


Gcs system architecture

GCS System Architecture


Natural language based srs

Natural Language based SRS

Zed Specification and Proof

Statechart Visualization and Simulation


Gcs schema hierarchy

GCS Schema Hierarchy


Gcs module chart

GCS Module Chart


Actual gcs module chart

Actual GCS Module Chart


Methodology summary

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


Two formalisms combining strengths

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


Summary of case study findings

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_COUNTER*75000

      Or,… AR_COUNTER = –1  (0≤AR_COUNTER≤AR_FREQUENCY/75000)


Seds related publications2

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," IEEEProc. 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


Project five

Project Five

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


Goal stochastic modeling framework case study anti lock braking system

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.


Goal stochastic modeling framework case study anti lock braking system1

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).


Safe and secure dependable systems

ESA

Electronic Steer Assistance

ABS (Anti-lock Braking System)

Problem Identification & Requirements Analysis

Analysis using UltraSAN v. 3.5

Modeling using Stochastic Petri Nets

Experiments (Monitoring of real system)

Comparison of results (Semi-validation)

Modeling using Stochastic Activity Networks

Analysis using Stochastic Petri Net Package v. 6

TC

Traction

Control

feedback

feedback

PT

Power Transmission

Simulation

Sensitivity Analysis

Complete validation by comparison against real data

Further Details

DDR (Dynamic Driving Regulation System)


Seds related publications3

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 Int’l 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 Int’l. 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


Key se issues in software safety i

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


Key se issues in software safety ii

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.


Research summary and plans

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 …


Contact information

Frederick T. Sheldon, Ph.D. and Tom Potok, Ph.D.

Software Engineering for Dependable for Systems

Applied Software Engineering Laboratory

Rick: 865-576-1339

Tom: 865-574-0834

Fax: 865-574-6275

URL: http://www.csm.ornl.gov/~sheldon

http://computing.ornl.gov/cse_home/acer.shtml

Contact Information


The end

The end…


Other seds research

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. Int’l. 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 ([email protected])


Making verification tools useful for industry

Making Verification Tools Useful for Industry


  • Login