Page 1, April 15, 2003
Ivica Crnkovic ivica.crnkovic@mdh.se http://www.idt.mdh.se/~icc - - PowerPoint PPT Presentation
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
Page 2, April 15, 2003
Västerås Stockholm
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”)
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)
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
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
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?
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?
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
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?
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
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)
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
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
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
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
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
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
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)
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)
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.
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.
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
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
*
Page 25, April 15, 2003
Generalization of a component model Generalization of a component model
SEI/CMU Kurt Wallnau
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;
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?
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
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
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
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…)
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??
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
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
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
Page 36, April 15, 2003