1. Research Heaven, West Virginia
Severity Analysis at Architectural Level Based on UML Dynamic Specification

2. Research Heaven, West Virginia
Overview
Research Heaven, West Virginia
Introduction
Hazard analysis techniques
UML and Hazard analysis
Proposed Severity Analysis Method
Conclusion and Future work
References

3. Research Heaven, West Virginia
Introduction
Research Heaven, West Virginia
We have developed a risk assessment methodology applied on systems
architecture composed of components and connectors
We define risk as a combination of two factors
The probability of malfunctioning (failure)
The consequence of malfunctioning (severity)
Severity analysis is conducted for the purpose of quantifying
severity of failures of system components and connectors, and
severity of failures of scenarios
We propose severity analysis technique based on Unified Modeling Language (UML), this technique is based on classical hazard analysis techniques
Why risk assessment at early phase of software life cycle?
This kind of analysis in the early phase of software lifecycle allows us to build more robust systems, since we have knowledge about possible failure models from the beginning
The analysis will shorten the design time reduce the chances for late changes
We donot have to wait to the test phase result to find possible failures, and can avoid most of them early in our design
Possible actions taken as a result of the severity analysis
Software design may be changed to eliminate the identified hazards or to reduce them to acceptable levels
Software quality may be improved sufficiently to reduce the probability of a hazard to an acceptable level
Software may be rejected if it is considered too hazardous

4. Hazard analysis techniques
Research Heaven, West Virginia
Hazard analysis techniques
Classical Hazard analysis techniques
Functional Failure Analysis (FFA),
Failure Mode and Effects Analysis (FMEA),
Fault Tree Analysis (FTA),
(HAZOP), It is a technique used for identifying and analysing the hazards and operation concerns of a system using guide words.
(FMEA), It is a technique used to evaluate the ways components of the system can fail and the effects these failures on the system.
(FTA), It is a top-down method used to identify failure causes .
(FHA),It is used for identifying safety hazards at a system functional level.
(ETA),It is an inductive logic method for identifying the various possible outcomes of a given initiating event.
(FFA), FFA method has been developed by extending FHA with guide words similar to the guide words used in HAZOP

5. UML and Hazard analysis
Research Heaven, West Virginia
Why UML is a good candidate for severity analysis technique
The UML could capture dynamic behavior of the system (Scenario diagram, State diagram)
UML provides a clear relationship between the system and the environment (Use case diagram)
UML gives a good picture of possible functional aspects of the system ( Use cases)
To develop a hazard analysis technique the relationship between the system and the environment is defined sufficiently clearly that it is possible to identify how system failures may cause harm (i.e., the system boundary is clear) Use cases fit well for defining system boundary.
The use case forms a top-level view of the functionality that the system should provide to a user.

6. Proposed Severity Analysis Process
Research Heaven, West Virginia
INPUT: UML DYNAMIC SPECIFICATIONS
usecases, and annotated scenario diagrams,
OUTPUT: COST OF FAILURE OF COMPONENTS AND CONNECTORS, SEVERITY

7. OUTPUT Schematic of the proposed severity analysis process 1 FFA 4
UseCase
Diagrams,
System
Sequence
Diagrams
(List of scenario level Hazards)
Scenario Level
Cost
Of Failure Table,
Severity
Cost of Failure
Graph
UML
Specs
FTA
Components/
Connectors
Cost of
Failure
Table, Severity
Scenario
Diagrams
Component/
Connector
interactions
(List of Component/Connector
Failure Modes)
FMEA
(Complete List of Failure modes
of Components/Connectors) 3
Scenario Level Cost of Failure, Severity 2
Component/Connector Cost of Failure, Severity

8. The steps for the proposed process
Research Heaven, West Virginia
Identify system hazards: states of the system that can contribute to accidents and mishaps
Perform FFA using UML Use Case diagrams as an input
Identify component/connector failure modes
Perform FMEA using UML Scenario Diagrams as an input
Construct a detailed cause-and-effect model, to record how failures propagate from component/connector level through the system level
FTA is used to combine the outputs from FFA and FMEA
Develop the Cost of Failure Graph to estimate severity of each component/connector in a given scenario, or severity level of the scenario
The final result is a table of component/connector severity.

9. Step 1: Function Failure Analysis (FFA)
Research Heaven, West Virginia
Step 1: Function Failure Analysis (FFA)
The use case diagram for system S
The sequence diagram of use case UC1 for system S

10. Research Heaven, West Virginia
Step 1: FFA Table
Research Heaven, West Virginia
Event Name
Class Of
failure
Failure
Effects on
System
Severity
Comments
One or more of The guide
Words
Omission
Commission
Early
Late
Value
description
How is this
effecting
the System
class
Omission The service is never delivered: there is no communication.
Commission The service is delivered when not required:there is an unexpected communication.
Early The event occurs earlier than intended: this may be absolute or relative.
Late The event occurs later than intended: this may be absolute or relative.
Value The information delivered by the event has the wrong value.

11. Step 1: Example (Pacemaker AVI Scenario)
Research Heaven, West Virginia
Event Name
Actor sends or receives this event
Command
from programmer to the system
VSence
from the heart to the system
Pace
from the system to the heart
Sequence Diagram of Pacemaker System in AVI mode (use case)

12. Research Heaven, West Virginia
Step 1: FFA Table
Event Name
Class of failure
Failure
Effects on System
Severity
Comments
Command
Value
A Fault in processing command routine
Heart is continuously triggered but device is still monitored by physician, need immediate fix or disable.
Marginal
The component received the command misinterpret it
VSence
Omission
Timer not set correctly
No pace is generated for the heart, patient could die
Catastrophic
Some component’s timers does not work well
Pace
Commission
Pacing hardware device malfunctioning
Heart is always paced while patient condition requires only pacing the heart when no pulse is detected. Heart operation is irregular because it receives no pacing
Some component’s sensor failed to sense the heart.

13. The steps for the proposed process
Research Heaven, West Virginia
Identify system hazards: states of the system that can contribute to accidents and mishaps
Perform FFA using UML Use Case diagrams as an input
Identify component/connector failure modes
Perform FMEA using UML Scenario Diagrams as an input
Construct a detailed cause-and-effect model, to record how failures propagate from component/connector level through the system level
FTA is used to combine the outputs from FFA and FMEA
Develop the Cost of Failure Graph to estimate severity of each component/connector in a given scenario.
The final result is a table of component/connector severity.

14. Step 2:Identify the component/connector failure modes (FMEA)
Research Heaven, West Virginia
Functionality as a sequence of interactions for System S

15. Step 2: Example (Pacemaker AVI Scenario)
Research Heaven, West Virginia
Detailed Sequence diagram of the AVI scenario

16. Step 2: Example (AR Component )
Research Heaven, West Virginia
State Chart diagram of AR Component

17. Research Heaven, West Virginia
Step 2: FMEA Table
Component
Failure Modes
Effect on the system
Cause of failure AR
ToOn Value Error
The component will not work and there is no pace of the heart
The component does not receive signal from CG -
VR stuck in Refractory State
The component will stay in Refractory state and there is no pace
Connector VT-AR sends a wrong message, or component AR failes to understand the message.
The component receive GotVSence but there is no pace
(Stuck in Waiting state)
The component will stay in waiting state and there is no pace
The component sensor does not work
Sense TimeOut Error
The component in waiting state, heart operation is irregular because it receives no pacing
The component sensor does not work or value of Sence Time is wrong
PaceTimeOut Error
(component stuck in Pace state)
Heart is always paced while patient condition requires only pacing the heart when no pulse is detected
There is a problem in the sensor, or the timer does not work

18. The steps for the proposed process
Research Heaven, West Virginia
Identify system hazards: states of the system that can contribute to accidents and mishaps
Perform FFA using UML Use Case diagrams as an input
Identify component/connector failure modes
Perform FMEA using UML Scenario Diagrams as an input
Construct a detailed cause-and-effect model, to record how failures propagate from component/connector level through the system level
FTA is used to combine the outputs from FFA and FMEA
Develop the Cost of Failure Graph to estimate severity of each component/connector in a given scenario.
The final result is a table of component/connector severity.

19. Step 3: Fault Tree Analysis (FTA)
Research Heaven, West Virginia
Step 3: Fault Tree Analysis (FTA)
Step 3:Combining the results of steps 1 and 2 to build a cause-effect model by applying FTA
Step 1:Top event hazard identified by applying FFA
Step 2: Component/Connector failure modes identified through FMEA
Omission “Pace” Fault Tree

20. The steps for the proposed process
Research Heaven, West Virginia
Identify system hazards: states of the system that can contribute to accidents and mishaps
Perform FFA using UML Use Case diagrams as an input
Identify component/connector failure modes
Perform FMEA using UML Scenario Diagrams as an input
Construct a detailed cause-and-effect model, to record how failures propagate from component/connector level through the system level
FTA is used to combine the outputs from FFA and FMEA
Develop the Cost of Failure Graph for each component/connector
Estimate the cost of failure of each component/connector
Estimate the severity of each component/connector
The final result is a table of component/connector severity.

21. Step 4: Cost of Failure Graph for the AR Component
Research Heaven, West Virginia
List of hazards (Fault Tree Top Event)
Failure Modes
Consequence (Cost)
“ToOn” Value Error
AR failed to handle ToOn
P(Fm) =.99
$ 1000
(regular care)
P(“ToOn”
Value Error) =
0.02
$ 1000
(regular care)
AR “ stuck in Refractory” State P(Fm) = 0.05
Failure
Commission “Pace”
P(Commission Pace) = 0.50
Sence TimeOut Error
P(Fm) = 0.3 $
(intensive care)
AR “ stuck in Waiting” State
P(Fm) = 0.05 $
(intensive care)
Sence TimeOut Error
P(Fm) = 0.3
P(Omission
VSence) = 0.48 $
(intensive care)
AR stuck in “Pace” State
P(Fm) = 0.3 $
(intensive care)
PaceTimeOut Error
P(Fm) = 0.3

22. Step 4: Severity of components/connectors
Research Heaven, West Virginia
Cost-Severity
Graph
Cost of failure table
For components/Connectors
Severity of
Components/Connectors

23. Step 4: Output Component/connector name Severity Connector CG-AR
Research Heaven, West Virginia
Component/connector name
Severity
Connector CG-AR
Marginal
Connector CG-VT
Connector AR-VT
Catastrophic
Connector VT-AR
Component CG
Component AR
Component VT
Severity of components/connectors in the AVI scenario

24. Research Heaven, West Virginia
Conclusion
Proposed a methodology for scenario-based severity analysis of components/connectors of complex systems.
Based on the UML dynamic specifications of system scenarios (use case diagrams, sequence diagrams and state charts)
FFA is used as a top down approach based on abstract functional view of the system (use case) and its main functional failures
FMEA is used as a bottom up appraoch based on the detailed view of the system to identify the possible causes component/connector
failures
FTA is used to correlate the results of FMEA and FFA
Considered the concept of cost of failures, and cost-severity graph

25. Research Heaven, West Virginia
References
A. Hassan, W. Abdelmoez , A. Guedem, K. Apputkutty, K. Goseva-Popstojanova, H. Ammar, “Severity Analysis at Architectural Level Based on UML Diagrams’, 21st Intl. conference System Safety conference, Ottawa, Canada, August 4th – 8th , 2003.
A. Hassan, K. Goseva-Popstojanova, H. Ammar , “Methodology for Architecture Level Hazard Analysis, A Survey”, ACS/IEEE Intl. Conference on Computer Systems and Applications (AICCSA'03), Tunis, Tunisia, July 14-18, 2003.
Sherif M. Yacoub, Hany H. Ammar, “A Methodology for Architectural-Level Reliability Risk Analysis”, IEEE Transactions on Software Engineering, June 2002 V28, N 6, pp
K. Goseva-Popstojanova, A. Hassan, A. Guedem, W. Abdelmoez, D. Nassar, H. Ammar, A. Mili, “Architectural-Level Risk Analysis using UML”, IEEE Transaction of Software Engineering, Oct., 2003.
Naylor, W. William Everett, Michael LeBeau, Peggy Rogers, and Ronald Stroup, “The Challenges Facing System Safety in the New Millennium “, 20th International System safety Conference, Aug. 5-9, 2002, Denver, Colorado.
Susan A. Sherer, “Methodology For The Assessment Of Software Risk”, Ph.D. Dissertation, Wharton School, University of Pennsylvania, 1988.
Yiannis Papadopoulos, John A. McDermid, “Hierarchically Performed Hazard Origin and Propagation Studies”, Proceedings of SAFECOMP ’99, 18th International Conference on Computer Safety, Reliability and Security, Toulouse France, Lecture Notes in Computer Science, 1698: , Springer Verlag, 1999.
Steven Kmenta, Kosuke Iskii, “Scenario-Based FMEA: A Life Cycle Cost Perspective”, Proceeding of DETC 2000, 2000 ASME Design Engineering Technical Conferences, Sept , 2000,Baltimore, Maryland.
M.S. Feather, S.L. Cornford, J. Dunphy & K. Hicks, “A Quantitative Risk Model for Early Lifecycle Decision Making”, in Proceedings of the Conference on Integrated Design and Process Technology, Pasadena, California, June Society for Design and Process Science

26. Research Heaven, West Virginia
Future work
Integrate and validate the risk assessment methodology with the Defect Detection and Prevention (DDP) process (developed at JPL by Martin Feather)
The development of Maintainability-based Risk assessment technique