Ivica Crnkovic ivica.crnkovic@mdh.se http://www.idt.mdh.se/~icc - - PowerPoint PPT Presentation

ivica crnkovic
SMART_READER_LITE
LIVE PREVIEW

Ivica Crnkovic ivica.crnkovic@mdh.se http://www.idt.mdh.se/~icc - - PowerPoint PPT Presentation

CBSE and dependable systems CBSE and dependable systems Ivica Crnkovic ivica.crnkovic@mdh.se http://www.idt.mdh.se/~icc Mlardalen University Page 1, April 15, 2003 Vsters Stockholm Page 2, April 15, 2003 Ivica Crnkovic Prof. in


slide-1
SLIDE 1

Page 1, April 15, 2003

CBSE and dependable systems CBSE and dependable systems

Ivica Crnkovic

ivica.crnkovic@mdh.se http://www.idt.mdh.se/~icc Mälardalen University

slide-2
SLIDE 2

Page 2, April 15, 2003

Västerås Stockholm

slide-3
SLIDE 3

Page 3, April 15, 2003

Ivica Crnkovic

  • Prof. in Software Engineering

http://www.idt.mdh.se/~icc

ivica.crnkovic@mdh.se

  • Chair of Software Engineering Lab at

Chair of Software Engineering Lab at Mälardelen Mälardelen University University CBSE activities: CBSE activities:

  • Participating ARTIST (EU project, WP: CBD for embedded systems)

Participating ARTIST (EU project, WP: CBD for embedded systems)

  • Co

Co-

  • organizer CBSE workshop at ICSE (May 2003)
  • rganizer CBSE workshop at ICSE (May 2003)
  • Program Chair

Program Chair Euromicro Euromicro Conference CBSE track ( Conference CBSE track (Antalya Antalya, Turkey) , Turkey)

  • Co

Co-

  • editor of “Building reliable component

editor of “Building reliable component-

  • based software systems”)

based software systems”)

slide-4
SLIDE 4

Page 4, April 15, 2003

Outline Outline

Motivation example Dependability The questions: Dependability and CBSE Challenges of CBSE - Component and system properties (CBSE for embedded systems)

slide-5
SLIDE 5

Page 5, April 15, 2003

A Distributed Real A Distributed Real-

  • time System for vehicular systems

time System for vehicular systems

Volvo S80

Networks instead of cables Nothing must go wrong ⇒ Robust Design with Predictable Real-time behavior Strong constraints related to the production costs

Volvo S80 ~ 80 Electronic Control Units

slide-6
SLIDE 6

Page 6, April 15, 2003

The car architecture The car architecture -

  • today

today

Vehicle mechanics ECU Sensor Actuator Sensor ECU Sensor Actuator Sensor ECU Sensor Actuator Sensor gateway (CAN) BUS

slide-7
SLIDE 7

Page 7, April 15, 2003

The architectural design challenge The architectural design challenge

Vehicle stability Suspension Drive by wire ……

Complex functions

Local Control Functions Sensor Actuator Sensor

Basic functions

Local Control Functions Sensor Actuator Sensor

How to implement complex functions based on local control functions?

slide-8
SLIDE 8

Page 8, April 15, 2003

Problem: resource sharing Problem: resource sharing

Sensor 1 Sensor 2 Sensor 3 Sensor .. Network resources

++++++++++ ++++++++++ ++++++++++

Sensor .. Execution resources Node 1 Node 2 Node 3 Node … Node … Actuator 1 Actuator 2 Actuator 3 Actuator … Actuator …

Can functions of different criticality be allowed to share resources?

slide-9
SLIDE 9

Page 9, April 15, 2003

sensors

Challenge Challenge – – open and dependable platform

  • pen and dependable platform

Vehicle actuators Engine Control Local brake Control Transmission ………

local

Vehicle stability Cruise control Antispin

Global

Hardware Input/output drivers Middleware Application compnents

ECU ECU ECU

slide-10
SLIDE 10

Page 10, April 15, 2003

Constraints and Questions Constraints and Questions

Constraints

Safety – critical systems Real-time constraints Low consumptions of resources Low production costs

Which architecture to use? Which component technology and model to use? Analysis and verification techniques? Development process? Component properties and system emerging properties

Which extra-functional properties are of interest for safety-

critical real-time embedded systems?

slide-11
SLIDE 11

Page 11, April 15, 2003

The Challenge The Challenge

Conflicting requirements

Safety vs. Cost and time-to-market Safety and Real-Time constraints vs. complexity

Possible solution: Combination of architectural and component-based design with predictability, analysis and verification

slide-12
SLIDE 12

Page 12, April 15, 2003

Dependability Dependability

  • 1. Ability of a system to deliver service that can justifiably be

trusted

Ability of a system to avoid failures that are more frequent or

more severe than is acceptable to user(s) Related to Trustworthiness (assurance that a system will perform as expected)

slide-13
SLIDE 13

Page 13, April 15, 2003

Dependability Attributes Availability Reliability Safety Confidentiality Integrity Maintainability

Readiness for usage Continuity

  • f services

Absence of catastrophic consequences Absence of unauthorized disclosure of information Absence

  • f improper

system alternations Ability to Undergo repairs and evolutions Jean-Claude Laprie

slide-14
SLIDE 14

Page 14, April 15, 2003

Dependability (Extension definition) Dependability (Extension definition)

Dependability Safety-critical systems Mission-critical systems Business-critical systems

Airplanes Cars Nuclear power stations …… Traffic control systems Energy supply and distribution systems?? Telecommunication systems??? NASA Ariane Industrial systems Information systems Traffic control systems Very often dependable systems are:

  • Real-time systems
  • Embedded systems
slide-15
SLIDE 15

Page 15, April 15, 2003

Dependability Attributes Availability Reliability Safety Confidentiality Integrity Maintainability Means Fault Prevention Fault Tolerance Fault Removal Fault Forecasting Faults Errors Failures Threats

Dependability attributes

slide-16
SLIDE 16

Page 16, April 15, 2003

Faults, Errors, Failures Faults, Errors, Failures

Fault Error Failure

Activation propagation

Failures domain Perception by users Consequences Value failures Timing failures Consistent failures … Inconsistent failures (Byzantine) Minors failures ….. Catastrophic

slide-17
SLIDE 17

Page 17, April 15, 2003

Faults Faults

Faults Phenomenological Cause Intent Phase of creation Domain System boundaries Persistence Natural Human made Accidental Deliberate, non-malicious Deliberate, malicious Developmental Production Operational Physical Information Internal External Permanent Transient

slide-18
SLIDE 18

Page 18, April 15, 2003

The means to attain the dependability The means to attain the dependability

Fault Prevention How to prevent occurrence or introduction of faults Fault Tolerance How to deliver correct service in the presence of faults Fault Removal How to reduce the number of severity of faults Fault Forecasting How to estimate the present number, the future incidents, the probability of different consequences

slide-19
SLIDE 19

Page 19, April 15, 2003

Fault Tolerance Fault Tolerance

Error detection concurrent error detection preemptive error detection Recovery error handling (rollback, rollforward) Fault handling fault diagnosis Fault isolation System reconfiguration system re-initialization Fault masking (redundancy)

slide-20
SLIDE 20

Page 20, April 15, 2003

Fault forecasting Fault forecasting

Evaluation of system behavior qualitative (identify, classify, rank the failure modes, the event combinations, environmental conditions that would lead to system failures Quantitative (probabilistic)

slide-21
SLIDE 21

Page 21, April 15, 2003

Question: Is CBSE feasible for Dependable Systems? Question: Is CBSE feasible for Dependable Systems?

How to build dependable component-based systems? How to specify the components to be able to use them for the dependable systems? To which extent the system properties can be determined from the component properties? To which extent can uncertainty in predictability of these properties be minimized and how much is that related to the uncertainty of specification of the component properties? In which phase of the development process are these properties addressed mostly.

slide-22
SLIDE 22

Page 22, April 15, 2003

Component Specification Component Specification

Component Specification Levels:

  • 1. Syntactic interface, or signature (i.e. types, fields, methods,

signals, ports etc., that constitute the interface).

  • 2. Constraints on values (of parameters and state variables:

Invariants, pre- and post-conditions on methods and signals).

  • 3. Protocols (i.e. constraints on the temporal ordering of signals

and method calls).

  • 4. Extra-functional properties (real-time attributes, performance,

QoS (i.e. constraints on response times, throughput, etc.), resource management, etc.

slide-23
SLIDE 23

Page 23, April 15, 2003

Extra Extra-

  • functional properties specifications

functional properties specifications

Credentials (Mary Shaw) A Credential is a triple <Attribute, Value, Credibility>

Attribute: is a description of a property of a component Value: is a measure of that property Credibility: is a description of how the measure has been

  • btained

Implementations

Attributes in .NET

A component developer can associate attribute values with a component and define new attributes by sub-classing an existing attribute class.

ADL UniCon

Allows association of <Attribute, Value> to components

slide-24
SLIDE 24

Page 24, April 15, 2003

Extra Extra-

  • functional Properties

functional Properties

Component Interface Operation * in-interfaces * * * Attribute Value Credibility IsPostulate : Boolean Credential * 1 * 1 * 1 Parameter 1 * Type 1 * *

  • ut-interfaces

*

slide-25
SLIDE 25

Page 25, April 15, 2003

Generalization of a component model Generalization of a component model

SEI/CMU Kurt Wallnau

slide-26
SLIDE 26

Page 26, April 15, 2003

Some extra functional properties… Some extra functional properties…

References:

  • Kazman, R., L. Bass, G. Abowd, M. Webb, “SAAM: A method for analyzing properties of software

architectures,” Proceedings of the 16th International Conference on Software Engineering, 1994.

  • Kazman et al, Toward Deriving Software Architectures from Quality Attributes, Technical Report

CMU/SEI-94-TR-10, 1994.

  • McCall J., Richards P., Walters G., Factors in Software Quality, Vols I,II,III', US Rome Air Development

Center Reports, 1977.

  • Bosch, J., P. Molin, “Software Architecture Design: Evaluation and Transformation,” Proceedings of

the IEEE Conference and Workshop on Engineering of Computer-Based Systems, 1999.

Accuracy; Audibility; Availability; Completeness; Conciseness; Consistency; Correctness; Ease of creation; Efficiency; Error (fault) tolerance; Execution; efficiency; Expandability; Flexibility; Generality; Hardware independence; Integrability; Integrity; Interoperability; Maintainability; Modifiability; Modularity; Operability; Performance; Portability; Reliability; Reliability; Reusability; ScalabilitySecurity; Simplicity; Software system independence; Testability; Traceability; Usability;

slide-27
SLIDE 27

Page 27, April 15, 2003

Extra Extra-

  • functional properties

functional properties -

  • questions

questions

Given the system extra-functional properties

which properties of involved components are required?

Given a set of properties of components

  • which system properties are predictable?

How to accurately predictable extra-functional properties of the system from components which extra-functional properties are determined with a certain accuracy? To what extent, and under which constraints are the emerging properties (i.e. the system properties non-existing

  • n the component level) determined by the component

properties?

slide-28
SLIDE 28

Page 28, April 15, 2003

System (assembly) properties prediction System (assembly) properties prediction

A property of an assembly is: a function of, and only of the same property of the involved

  • component. (example: static memory)

a function of the same property of the components and of the software architecture. (example: architectural styles…) A function depending on several different properties of the

  • components. (example: latency and worst case execution time)

determined by its usage profile. (Example: reliability) is determined by other properties and by the state of the system

  • environment. (Example: safety)

Different levels of predictability of system properties

slide-29
SLIDE 29

Page 29, April 15, 2003

Questions Questions – – Dependability & Components? Dependability & Components?

Safety example: Safety is an extension of reliability

(time to catastrophic failure)

Is safety a subset of reliability?

A system can be safe even if it is not reliable “A car in a desert that can explod is safe”

What do we measure/predict for Safety?

Probability of a failure (related to reliability) Risk that is happens Risk: a combination of the probability of an event and the

nature and severity of the event.

From Nuclear industry: Probability * consequences

slide-30
SLIDE 30

Page 30, April 15, 2003

Safety analysis Safety analysis – – fault fault-

  • tree analysis (FTA)

tree analysis (FTA)

Cooling system Overflow Failure OR Either event can occur Fill mode remains on AND Timeout control fails Sensor fails Valve stuck in

  • pen

position Basic events Both events must occur

slide-31
SLIDE 31

Page 31, April 15, 2003

FTA FTA

When in FT coming to a component what do we look at

Reliability Availability Robustness …. Means (fault tolerance, prevention…)

slide-32
SLIDE 32

Page 32, April 15, 2003

Availability Availability

Availability – the probability of a system (component) being available when needed

Mean time to failure / mean time between failure (mean time between failure = mean time to failure

+ mean time to repair failure) However

Component could be unavailable because of lack of system

resources

Question of contractual specified interface??

slide-33
SLIDE 33

Page 33, April 15, 2003

Reliability Reliability

Mean time between failure How to calculate? The process valid for systems and components

Define usage model Define the usage profile Define the test cases Execution of test cases

slide-34
SLIDE 34

Page 34, April 15, 2003

Usage modeling and usage profile Usage modeling and usage profile

Intended to model external view of the use of the component Component reuse – also reuse of usage model Use of Markov chains (FSM + probability of transition between states)

Problem – for complex systems Markov chains become very

large

slide-35
SLIDE 35

Page 35, April 15, 2003

Conclusion Conclusion

Dependable systems more complex

Importance of extra-functional properties Required: component specification and composability

reasoning

Survey of system extra-functional properties

§Applicable or not on components Relations between system and component properties Instructions per property how to analyze it

slide-36
SLIDE 36

Page 36, April 15, 2003

Component technology in embedded world Component technology in embedded world

We should consider: Contractually specified interfaces Managing extra-functional properties Component as a unit of composition and independent deployment Explicit context dependencies Component granularity Reuse Location transparency Component wiring Portability, platform independence