# Presentation: 508147

## FY2001 University SOFTWARE INITIATIVE PROPOSALfor theNASA SOFTWARE IV&V FACILITY   Initiative Title: Verification & Validation of UML Dynamic Specifications '01    Hany H. Ammar, Vittorio Cortellessa,Rania Elnaggar Lane Department of Computer Science and Electrical EngineeringWest Virginia UniversityThe OSMA Software Assurance Symposium September 5-7, 2001 Lakeview, Morgantown, WV

## outline

**outline**

**Project Overview**
**Overview, The Environment**
- Timing Analysis Methodology
- The Pacemaker Example
- Performance Analysis Methodology
- The Auto teller machines Example
- Fault Injection Model
-  HCS NASA case study
- Conclusions

## Project Overview

**Develop an Environment for ****verification of performance and timing behavior of real-time applications based on dynamic specifications in UML (first year)**
**Develop a methodology for timing analysis (first year)**
**Develop a methodology for performance analysis (first year)**
**Develop a methodology for fault-injection and failure propagation analysis (second year)**
**Complexity, and Risk Assessment at the architecture level (second year)**
**Apply the above methodologies to a NASA case study**

## Overview,The Environment

## Overview,The Environment

**Overview,****The Environment**

**CARA Tool**

## Overview,The Environment: RoseRT notation 

- It is essentially a classical software architecture:
- 	Capsules 		 	Components
- 	Ports + Links	 	 	Connectors

- A1

- A3

- A2

- C1

- C2

- Capsule A

- Capsule B

- Capsule C

## Overview,The Environment: RoseRT notation 

- _Component nesting_
- The internal behavior of each lowest level (primitive) capsule can be modeled by a State Charts

- The union of all the State Diagrams composes the model that has to be simulated

##  Timing Analysis Methodology 

## Timing Analysis Methodology

## Example: Pacemaker Main Use Case Diagram 

## Case Study: Pacemaker Capsule Diagram

## Sample Timing Diagram

## Performance Analysis Methodology 

## Behind the Approach:

-  RoseRt notation is well suited to also represent the hardware platform

- Migrating the **hardware model** into the same
- notation as the one required from the tool
- for the **software representation** and thereafter using the tool to **simulate** the resulting integrated model

## The standard scheme

- Software side
- capsule

- Resource side
- capsule

- Application software architecture

## Resource requests

-  Wherever needed in the software side a **resource request** is originated as a **demand vector**
-  The **size** of a demand vector depends on the number of resource types building up the platform
-  **Each cell** of a demand vector represents the amount of that resource type that the software block requires to be executed (e.g., number of instructions, number of accesses to disk, etc.)
-  Each demand vector is mostly handled, in the resource side, by the **Main Dispatcher**

## Example: Automatic Teller Machines 

**Example: Automatic Teller Machines **

- Observer

- Server Software

- Server Resources

- ATM Devices

- ATM Software

- Balance Tr.

- Authenticator

- Withdrawal Tr.

- ATMs

- ATM Resources

- n

- n

## Generating and satisfying resource requests

- No. of times the Job is queued depends on the amount of recourses required

- Similarly all other Resource types are consumed

## ATM resource side configuration examples

|  | CPUs: number of instructions per quantum | CPUs: time per quantum (msec) | Disk: time per block (msec) |
| --- | --- | --- | --- |
| Exp1: 1 CPU, 1 disk | 10 | 0.0005 | 1 |
| Exp2: 1 CPU, 1 disk | 10 | 0.005 | 2 |
| Exp3: 2 CPUs, 1 disk | 10,5 | 0.0005,0.0005 | 1,2 |

## Some performance indices : Exp3

## A Fault InjectionTechnique

**Fault Injection**
- Develop a Fault Model for UML dynamic specs, to perform severity analysis and test case optimization using the simulation environment

## State Selection Process 
State faults 
Sate transition faults
Timing Faults (Presented , Spring Showcase 2000)

**State faults **
**Sate transition faults**
**Timing Faults ****(Presented , Spring Showcase 2000)**

**Fault Injection ****Fault Model for UML Dynamic SPECs**

## Order Components based on dynamic complexity
Select the set of components to be injected with faults based on highest complexities.
Order states and macro states in each selected component based on contribution to the component complexity.  

**Select the set of components to be injected with faults based on highest complexities.**
**Order states and macro states in each selected component based on contribution to the component complexity.  **

- Fault InjectionFault Model for UML Dynamic Model** State Selection Process**

## Swap the selected state with the state next in the complexity order. “state actions code fault”
Swap transitions out of the selected state.
If an initial state exists, force the selected state to be the initial state.
If a final state exists, force the selected state to be the final state.

**Swap transitions out of the selected state.**
**If an initial state exists, force the selected state to be the initial state.**
**If a final state exists, force the selected state to be the final state.**

- Fault Injection Fault Model for UML Dynamic Model** State faults**

## For the Transitions that are firing out of or into the selected state
Change trigger message to null (Disable the transition) 
Interchange trigger message with another randomly selected message

**Change trigger message to null (Disable the transition) **
**Interchange trigger message with another randomly selected message**

- Fault InjectionFault Model for UML Dynamic Model** State Transition faults**

## Timeouts-based
Concurrency-based
Performance-based
Environmental-interactions

**Concurrency-based**
**Performance-based**
**Environmental-interactions**

- Fault InjectionFault Model for UML Dynamic Model** Timing faults**

## Hub Control Software (HCS) Case StudyInternational Space Station

## HCS Internal Architecture 

**HCS**

** ****ITCS**

- SCITCS

- FRITCS

- LRITCS

- PPA mon

- PFMC LT

- PFMC MT

- Scheduler

- State manger

- CMD Queue

- O/P CMD Queue

- N3-1 Data Access

- RPCM

- N3-2 Data Access

- Other HCS sub-systems

## HCS Internal Architecture

- _ITCS:_  (Spec)
- SCITCS-> System controller
- FRITCS-> Fault recovery
- LRITCS-> Leak recovery
- PFMC (MT,LT) -> Pump and Fan  Motor Controller
- PPA Monitor -> (Top Level Design) for PPA control in Spec
- _HCS:_  (Top Level Design)
- Scheduler -> give 1 Hz interrupt
- State Manager -> decides if the system is in standby or operating
- Command Queue -> has the orders for the ITCS ( Trans to single MT,..)
- O/P Command Queue -> receives the orders the ITCS issues to get to
- 			 other HCS components
- N3-1 Data Access -> Has the data of the MT Loop Valve (SFCA MT)
- N3-2 Data Access -> Has the data of the LT Loop Valve (SFCA LT)
- RPCM -> ( from Spec) open close certain switches

## HCS – Observer – Fault Generator

**HCS – Observer – Fault Generator**

## RRT Structure Diagram for HCS

## Potential inconsistencies detected in 

- 	the system should return to the last operation mode (*this may cause the system either to deadlock or operate without noticing there is still a problem with running that mode*)
- 	the FRITCS should reconfigure the  system in accordance with the current state (*this is a more logical choice, in fact the simulation showed better system performance when doing so*).

**Potential inconsistencies detected in **
**the specs during model development **

## Potential inconsistencies detected in 

**Potential inconsistencies detected in **
**the specs during model development **

## Conclusions

- Presented a simple methodology and an Environment  for** **Timing and Performance Analysis of dynamic Specifications
- The methodology is extended to risk assessment and fault-injection analysis** **
- Illustrated the methodology using simple generic examples (the pacemaker, and ATMs)
- Developed a simulation model of a NASA case study (The Hub Control Software HCS, of the International Space station)
- Appling the methodology to the specification of HCS

## Papers

-  Ammar H.H., Cortellessa V., *Report on the development of an automated simulation environment for UML dynamic specification*, March 2001 deliverable.
-  Alaa Ibrahim, Sherif M. Yacoub, Hany H. Ammar, *Architectural-Level Risk Analysis for UML Dynamic Specifications*,
- Proceedings of the 9th International Conference on Software Quality Management (SQM2001), Loughborough University, England, April 18-20, 2001, pp. 179-190.
-  Ammar H.H., Cortellessa V., Ibrahim A., *Modeling Resources in a UML-based simulative environment*, Proc. of ACS/IEEE International Conference on Computer Systems and Applications 2001, June 25-29, 2001 - Beirut (Lebanon).
-  Cortellessa V., Ibrahim A., Ammar H.H., *Simulations of distributed systems for performance analysis in UML*, submitted to UML 2001 conference.

## Project current work

** ****HCS timing and performance parameter collection**
- Ammar H.H., Cortellessa V., Ibrahim A., *Modeling Resources in a UML-based simulative environment*, Proc. of ACS/IEEE International Conference on Computer Systems and Applications 2001, June 25-29, 2001 - Beirut (Lebanon).
- 	Cortellessa V., Ibrahim A., Ammar H.H., *Simulations of **	**distributed systems for performance analysis in UML*, submitted 	to ISPASS 2001 conference.
-  **GSM radio system timing and performance analysis**
-  Rania M. Elnaggar, Vittorio Cortellessa, Hany Ammar, *A UML-based Architectural Model for Timing and Performance Analyses of GSM Radio Subsystem*, 5th World Multi-Conference on Systemics, Cybernetics and Informatics

## Future Work

- Alaa Ibrahim, Sherif M. Yacoub, Hany H. Ammar, *Architectural-Level Risk Analysis for UML Dynamic Specifications*, Proceedings of the 9th International Conference on Software Quality Management (SQM2001), Loughborough University, England, April 18-20, 2001, pp. 179-190.
-  ***Fault***** injection and Fault propagation**
- Alaa Ibrahim., H. H. Ammar, S. Yacoub  *A Fault Model for Fault Injection analysis of UML Dynamic Specifications*, accepted to ISSRE 2001 conference.

**Future Work**

## Future directions

-   **Integrating timing and performance to build a risk assessment approach based on the performance**           sensitivity of the risk factors to changes in the architecture or to fault recovery routines
** ****Semi-formal approach to identify high risk scenarios**
- B. Cukic, H. Ammar and K. Lateef, *Identifying High-Risk Scenarios of Complex Systems using Input Domain Partitioning*, Proc. of ISSRE 98
-  **Hybrid simulation/analytical validation approach**
- Paper submitted to NASA Goddard SW Engineering Workshop, November 27-29, 2001
** ****Development of an Analytical V&V approach**

**Future directions**