1 outline Project Overview Overview

1

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 2

Project Overview 3

Overview, The Environment 4

Overview, The Environment 5

Overview, The Environment: Rose. RT notation Capsule A Capsule B A 1 Capsule C A 2 A 3 C 1 C 2 6

Overview, The Environment: Rose. RT 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 7

8

Timing Analysis Method Concurrency-based Focus Purpose Architecture Connectors Study effect of delays in (connectors between message delivery between objects) Performance-based components. efficiency. Architecture Components Study effect of various timer (Time) Environment-Interactions Study effect of Implementation (objects) Timeouts-based Architecture Components set values. External Environment Study effect of delays in recognizing hardware events 9

10

Case Study: Pacemaker Capsule Diagram 11

Sample Timing Diagram 12

13

Behind the Approach: • Rose. Rt 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 14

The standard scheme Software side capsule Resource side capsule Application software architecture CPUs Main Disp Int Disp CPUi Disks Networks 15

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 16

Example: Automatic Teller Machines Server Software Server Resources n n Observer ATMs ATM Devices Balance Tr. ATM Resources ATM Software Authenticator Withdrawal Tr. 17

Generating and satisfying resource requests 18

ATM resource side configuration examples CPUs: number of instructions per quantum CPUs: time per Disk: time per quantum (msec) block (msec) Exp 1: 1 CPU, 1 disk 10 0. 0005 1 Exp 2: 1 CPU, 1 disk 10 0. 005 2 Exp 3: 2 CPUs, 1 disk 10, 5 0. 0005, 0. 0005 1, 2 19

Some performance indices : Exp 3 20

A Fault Injection Technique 21

Fault Injection Fault Model for UML Dynamic SPECs 22

23

24

25

26

27

HCS Internal Architecture 28

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 N 3 -1 Data Access -> Has the data of the MT Loop Valve (SFCA MT) N 3 -2 Data Access -> Has the data of the LT Loop Valve (SFCA LT) RPCM -> ( from Spec) open close certain switches 29

HCS – Observer – Fault Generator 30

RRT Structure Diagram for HCS 31

Potential inconsistencies detected in the specs during model development After a successful pump retry, the requirement document does not specify whether 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). 32

Potential inconsistencies detected in the specs during model development In general, preemption of commands may cause issuing new commands to the PFMC during startup and shutdown operations that are not valid according to the specs. 33

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

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 9 th International Conference on Software Quality Management (SQM 2001), 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 2529, 2001 - Beirut (Lebanon). • Cortellessa V. , Ibrahim A. , Ammar H. H. , Simulations of distributed systems for performance analysis in UML, submitted to UML 2001 conference. 35

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, 5 th World Multi-Conference on Systemics, Cybernetics and Informatics 36

Future Work • Complexity and risk assessment Alaa Ibrahim, Sherif M. Yacoub, Hany H. Ammar, Architectural-Level Risk Analysis for UML Dynamic Specifications, Proceedings of the 9 th International Conference on Software Quality Management (SQM 2001), 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. 37

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 38