Introducing Α UML model For Faster-than-Real-Time Simulation Dimosthenis Anagnostopoulos 1, Vassilis Dalakas 2, George- Dimitrios Kapos 1, Mara Nikolaidou 12 1 Harokopion University of Athens 2 Dept. of Informatics, University of Athens WSC 2005, Orlando Florida

Outline FRTS Scope and Benefits Experimentation Phase - Timing issues Building FRT Simulators UML and RT-UML An RT-UML model for FRTS experimentation Benefits Overall Model FRT Coordinator Model Simple Case Study Remarks –Future work

Faster than Real Time Simulation - FRTS Scope: Study the behavior of real-world systems in the near future Characteristics Simulation runs concurrently with the real world system Simulation time advances faster than real time Simulation model interacts with the real world system during experimentation Test model validity Adjustment to system changes  Focus on Experimentation Phase

FRTS Experimentation Concurrent system and model Execution Monitoring System and model coordination Compare system and model states (Auditing) State Set of attributes describing the model and the system at specific time instances Attributes are defined as Monitoring Variables Describe the system structure, operation parameters and input data

FRTS Experimentation Auditing Auditing Determine System reformations System/model deviation Whether the model may considered as valid RemodellingPlan Scheduling Initiate Remodelling or Plan Scheduling Performed at specific time points Performed at specific time points

 Model Execution  Monitoring  Auditing  Remodeling Auditing at tn-1,tn, tn+1, … Auditing interval is constant: [tn-1, tn], [tn, tn+1] Prediction: Sim(tx)=tn, tn>tx Sim(tn)=ty, ty>tn FRTS Experimentation

Is itself a complex “real-time system” Strong time restrictions are imposed on Model Execution (faster than the real system) Auditing (auditing and remodeling must be executed really fast)

Activities accomplished in RT -Monitoring: TExec (model execution) -Auditing: TAudit -Remodeling: TRemodel -Model initialization: TInit -Auditing interval: AudInt Timing issues

FRTS Experimentation Is itself a complex “real-time system” Strong time restrictions are imposed on Model Execution (faster than the real system) Auditing (auditing and remodeling must be executed really fast) Must be effectively implemented Supported by custom FRT Simulators

FRT Simulators Mainly support experimentation phase Usually have object-based architecture Interact with the real-world system Must perform monitoring and auditing May or may not include simulation model execution environment

Modeling an FRT Simulator Modeling/Remodeling and Model Execution are system specific Monitoring and Auditing are common to all FRTS implementations Monitoring and Auditing impose strong real time and concurrency constraints IMPORTANT to model and study them in detail prior FRT Simulator implementation  Creation of an FRT Simulator model  Emphasize monitoring and auditing not domain-oriented Establish common guidelines for FRT Simulator development

Modeling FRTS Experimentation Adopt UML for modeling purposes Is widely used in software engineering Facilitates researchers built their own implementation of the model in different platforms using a variety of existing tools Sequence Activity Different diagrams may be used to describe different aspects of Experimentation Process (Sequence and Activity proven very useful) Sequence Sequence: Interaction between Experimentation Process activities and sub-activities Activity Activity: Detail description of activities/subactivies

FRTS First level description Sequence Diagram

FRTS System Overview Use Case Diagram

Modeling FRTS Experimentation Adopt UML for modeling purposes Is widely used in software engineering Facilitates researchers built their own implementation of the model in different platforms using a variety of existing tools sequence activity Different diagrams may be used to describe different aspects of Experimentation Process (sequence and activity proven very useful) RT-UML Depict synchronization requirements and time constraints Lead to standardized implementations that meet strict time requirements auditing

RT- UML Overview UML Profile for Schedulability, Performance and Time Issues – RT-UML Facilitates annotation of UML models with properties related to modeling of time and time-related aspects Includes specific subprofiles emphasizing on time and concurrency issues Extends UML notation using stereotypes

RT- UML Overview

Useful RT- UML stereotypes in FRTS RTaction Applied to Activity, Method Additional tags: RTStart, RTDuration Used in Activity and Sequence diagrams RTtimer Models timer mechanisms Applied to Class Additional tags:RTDuration, RTPeriodic Used in Class diagrams CRcuncurrent Denotes concurrent execution of objects Applied to Class Additional method:CRmain Used in Class diagrams

Main FRTS classes Operate independently and occasionally concurrently

Auditing Audit must be completed within a small fraction of the auditing interval. RT-UML modeling facilitates Detail estimation of Audit duration Identification of factors/ processes affecting it and their relationships Comparing it to other crucial time-related attributes, e.g. auditing interval. Audit State Audit: determine reformations Full Audit: determine both reformations and deviations

State Auditing Inspects the current state of the real time system to detect reformations Compares current and previous value of each monitoring variable Defining the state of the real time system

State Monitoring Variables Depicted in Experiment specifications class diagram

State Auditing Inspects the current state of the real time system to detect reformations Compares current and previous value of each monitoring variable Defining the state of the real time system Invokes Remodelling  Performed by “audit” method of the State Auditor

State Audit – Activity Diagram MAX MAX duration of the state audit is 5*b+e*(4*b+d)+net1 ms

Sequence Diagram – State Audit

FRTS UML Model Evaluation A Simulator is implemented in Java using FRTS Experimentation model To contact FRTS experiments successfully, execution time of specific activities must be similar to the time estimations reported in the model To evaluate model richness and flexibility Simple FRTS are used as examples

FRT Simulator Implementation Simulation Environment and simulation models also constructed in Java. Usability Interaction with simulation execution environments is seamlessly performed Implementation (using Rational Rose platform) Coding effort was minimized

FRTS Example Two node web site second node is used only in cases of heavy load (that is when FRTS predicts that first node load is over a certain threshold) Modeled as a Multi-Queue, Multi-Server System

FRTS Example Detailed description of Monitoring Variables and Remodeling Conditions was needed during the initialization MV(3).mvname = servers.type = integer.ctechnique = integer.compParam = 1.indication = STRUCTURE.stateMonitoringIndication = TRUE.rcondition.rcname = “server change” MV(4).mvname = lamda1.type = real.ctechnique = real.compParam = 0.1.indication = OPERATION_PARAMETER.stateMonitoringIndication = FALSE.rcondition.rcname = “ia1 parameter”.rcondition.weight = 0.1

FRTS UML Model Evaluation FRT Simulator model and implementation are compared using specific parameters Duration (avg,min,max) in msec Theoretical EstimationMeasured Time Time for basic operation Computer depended (b) ,0.0011, State audit interval1000, 1000, , 891, 1106 State audit duration0.565, 0.017, , 0.087, 10.70

Conclusions Objective: Introduce a specification, establishing common guidelines for developing FRTS systems not domain-oriented Remarks RT-UML enabled the description of time constraints imposed in FRTS The modeling process was straightforward, while no extensions were needed to describe FRTS The FRT Simulator model is quite accurate and complete Based on current implementation results