1 / 31

Introducing Α UML model For Faster-than-Real-Time Simulation

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

stacy
Download Presentation

Introducing Α UML model For Faster-than-Real-Time Simulation

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. Introducing Α UML model For Faster-than-Real-Time Simulation Dimosthenis Anagnostopoulos1, Vassilis Dalakas2, George-Dimitrios Kapos1, Mara Nikolaidou12 1Harokopion University of Athens 2Dept. of Informatics, University of Athens WSC 2005, Orlando Florida

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

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

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

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

  6. FRTS Experimentation • 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

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

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

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

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

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

  12. 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 • Different diagrams may be used to describe different aspects of Experimentation Process (Sequence and Activity proven very useful) • Sequence: Interaction between Experimentation Process activities and sub-activities • Activity: Detail description of activities/subactivies

  13. FRTS First level descriptionSequence Diagram

  14. FRTS System Overview Use Case Diagram

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

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

  17. RT- UML Overview

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

  19. Main FRTS classes Operate independently and occasionally concurrently

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

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

  22. State Monitoring Variables Depicted in Experiment specifications class diagram

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

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

  25. Sequence Diagram – State Audit

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

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

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

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

  30. FRTS UML Model Evaluation • FRT Simulator model and implementation are compared using specific parameters

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

More Related