1 / 38

UML Dynamic Specifications: Verification & Validation Proposal for NASA Software IV&V Facility

This proposal outlines the project overview and methodologies for verification, validation, timing analysis, and fault injection of UML dynamic specifications for real-time applications. It includes examples of a pacemaker and auto teller machine. Presented at the OSMA Software Assurance Symposium in 2001.

marcyp
Download Presentation

UML Dynamic Specifications: Verification & Validation Proposal for NASA Software IV&V Facility

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. FY2001 University SOFTWARE INITIATIVE PROPOSALfor theNASA SOFTWARE IV&V FACILITYInitiative Title:Verification & Validation of UML Dynamic Specifications '01 Hany H. Ammar, Vittorio Cortellessa,Rania ElnaggarLaneDepartment of Computer Science and Electrical EngineeringWest Virginia UniversityThe OSMA Software Assurance Symposium September 5-7, 2001 Lakeview, Morgantown, WV

  2. 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

  3. 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

  4. Overview,The Environment

  5. Overview,The Environment Severity Analysis (Failure/Effect analysis) Severity Ranking Analyst Simulation Settings Inspection Viewing Macro UML Simulation Environment Simulation Timing Diag. UML Model Log and Analysis Analysis Sub Run Violation Table HRF Violation Tool Tool Settings Excel sheets Report Observer Component Complexity Factors Connector complexity Factors CDG “hrfiand hrfijunidentified” Formatted Excel charts Violation Tables MS Excel MS Excel Rose Real Time tool Text File Processing Risk Macro Macro CARA Tool

  6. Overview,The Environment: RoseRT notation Capsule A Capsule B A1 Capsule C A2 C1 C2 A3 It is essentially a classical software architecture: Capsules  Components Ports + Links  Connectors

  7. 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

  8. Timing Analysis Methodology

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

  10. Example: PacemakerMain Use Case Diagram

  11. Case Study: Pacemaker Capsule Diagram

  12. Sample Timing Diagram

  13. Performance Analysis Methodology

  14. 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

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

  16. 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

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

  18. 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

  19. ATM resource side configuration examples

  20. Some performance indices : Exp3

  21. A Fault InjectionTechnique • Fault Injection • Develop a Fault Model for UML dynamic specs, to perform severity analysis and test case optimization using the simulation environment

  22. Fault Injection Fault Model for UML Dynamic SPECs • State Selection Process • State faults • Sate transition faults • Timing Faults (Presented , Spring Showcase 2000)

  23. Fault InjectionFault Model for UML Dynamic Model State Selection Process • 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.

  24. Fault Injection Fault Model for UML Dynamic Model State faults • 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.

  25. Fault InjectionFault Model for UML Dynamic Model State Transition 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

  26. Fault InjectionFault Model for UML Dynamic Model Timing faults • Timeouts-based • Concurrency-based • Performance-based • Environmental-interactions

  27. Hub Control Software (HCS) Case StudyInternational Space Station

  28. HCS Internal Architecture HCS Other HCS sub-systems N3-1 Data Access N3-2 Data Access RPCM Scheduler ITCS FRITCS State manger PFMC LT SCITCS LRITCS CMD Queue PFMC MT PPA mon O/P CMD Queue

  29. 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

  30. HCS – Observer – Fault Generator

  31. RRT Structure Diagram for HCS

  32. 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).

  33. 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.

  34. Conclusions • Presented a simple methodology and an Environment forTiming 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

  35. 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.

  36. 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

  37. 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 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.

  38. Future directions • Integrating timing and performance to build a risk assessment approach based on the performancesensitivity 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

More Related