An agent based architecture for constructing Interactive Simulation Systems Zhao, Z.

Transcription

1 UvA-DARE (Digital Academic Repository) An agent based architecture for constructing Interactive Simulation Systems Zhao, Z. Link to publication Citation for published version (APA): Zhao, Z. (2004). An agent based architecture for constructing Interactive Simulation Systems General rights It is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s) and/or copyright holder(s), other than for strictly personal, individual use, unless the work is under an open content license (like Creative Commons). Disclaimer/Complaints regulations If you believe that digital publication of certain material infringes any of your rights or (privacy) interests, please let the Library know, stating your reasons. In case of a legitimate complaint, the Library will make the material inaccessible and/or remove it from the website. Please Ask the Library: or a letter to: Library of the University of Amsterdam, Secretariat, Singel 425, 1012 WP Amsterdam, The Netherlands. You will be contacted as soon as possible. UvA-DARE is a service provided by the library of the University of Amsterdam ( Download date: 25 Nov 2017

2 Listt of Figures 1.11 Functional components and the data flow in a simulator. The time stepping routiness define the actual behaviour of the simulator, and the control routines definee the experiment performed on the simulation Computing power increases in the past decade. The figure shows the fastest (N=l)) and the slowest (N=500) computer in the list, and the total performancee of all computers in the list. The original information is from the website A general data flow diagram of visualisation systems. The procedures in a visualisationn pipeline constitute the core of the system. The generation of intuitivee primitives for rendering, and the user interaction that controls the executionn of pipeline can be performed indifferent machines A basic configuration of ISSs. Solid lines depict the simulation loop, and the dashh lines depict the visualisation loop Basic components in SPLICE: application processes, each with an agent and a locall data store Distributed federates and the Runtime infrastructure (RTI) Summary of available architectures Basic architecture of an ISS-Conductor component A simple agent kernel An Actor and its ComA The basic architecture of MA A basic paradigm of assembling ISS-Conductor based components A logical view of the functional components in an MA A partial activity-transition graph of the example. In the description, actions:: Start, DoStep and Stop do not have dependencies on data objects, the actionn InitSimulation requires a Setting object as its input, and the action ExportDataportData has a Result object as its output. In the example, the action DoStep hass a transition with a condition guard: error > Setting.error, which means thee action will only be performed when the error is larger than a given bound A simple model of human interaction involved systems Capability modelling of the components involved with human interactions. A partiall activity-transition graph of Fig The term InState describes the statee of user activities 35

3 1200 List of Figures 3.55 A PT net based model of data production-consumption relation A sample scenario for roles Producer-A, Consumer A and Consumer _B. More exampless will be discussed in the next chapter A belief-transition graph for deriving the states of neighbour roles The action control between an Actor and a conductor, and its reflection in the worldd model The executionn states of the actions A scenario fragment and its marking graph are shown on the left side. The rightt side shows a possible execution sequence of role A and B, when they do nott apply any concurrency controls. The dashed arrows indicate the marking changess that are perceived by the peer role; the markings in Italic font are invalidd Data structure for state synchronisation Routing spaces and their four default profiles defined for ComAs. Roles are {A, B,, C}, the ComAs at Conductor are {A c, B c, C c } and the ComA at Actor are {A a, BB aa,, C a }. The regions for the Conductors use solid lines; and for Actors use dash lines.. XMIN, YMIN, XMAX and YMAX are the boundary of the entire region A detailed lifecycle of a ComA The snapshot of the GUI of a Conductor Generating run-time configuration files Two components constructed for benchmarking ISS-Conductor Action reasoning and update of shared objects in between run-time roles The delays of the local update and reflection and for the remote update of a sharedd object. The error bars indicate the standard deviation at each step Remote update of shared objects and the throughput of pure TCP sockets The basic architecture of DASH and the configurations of the experiment. The RTII is executed in fsl, fs2, and nics Update delay with different RTI locations. The error bars indicate the standardd deviations The comparison of the T R The remote update of all eight consumers Compare the remote update delay of the 8th consumer and 8 times delay of thee first consumer The remote update of the first Consumer in the federation in different configurations)) Passing messages to four receivers. The error bars indicate the standard deviationss A scenario of sending data objects and messages between three component instancess The influence between object distribution and message passing. The error bars showw the standard deviation at each time step Remote update delay of different number of attributes. The error bars show thee standard deviation at each time step 63

4 ListList of Figures Benchmark story. It has three nested scenario nets: T2 (scenario A), T3 (scenarioo B) and T4 (scenario C) Scenario A (involved roles: Producer-A, Consumer A and Consumer _B). Using thee publish and subscribe mechanism, a data object can be simultaneously consumedd by multiple consumers Scenario B (involved roles: Producer^, Producer_B, Consumer_A). SbT7 and SbT8SbT8 are two critical transitions Scenario C (involved roles: Producer_A, Consumer.A, Producer_C and Consumer.C)) Topologies of the routing spaces of the involved roles. The roles that are not involvedd in the scenario set their routing spaces using the away from the others profilee The total number of events and the time cost for processing an event The time cost by Producer A for each scenario in different execution paradigms. Thee error bars show the standard deviations The total number of state-update messages received by the Producer A. in each scenarioo A scenario of simulation based operation planning The basic functionality of Flow Simulator The basic functionality of Desktop -VRE A partial activity-transition graph of the C JFlow_Simulator component. See thee definition of component capability in section Performance comparison between ISS-Conductor component and legacy implementation.. The measurement shows the time cost for one iteration. The error barss indicate the standard deviations A layered vision of the functionality of the Desktop_VRE system A partial activity-transition of the C_Desktop_VRE component. The term In- StateState describes the user activity state An activity diagram for Blood_Flow.Studying scenario. The term UserState describess the activity state of a user A scenario net of the Blood J^low Studying scenario A screen snapshot of the Blood JFlowStudying scenario. The left window showss the interface of the Conductor and the right one is the interface of the CC Desktop-VRE component. The flow boundary is a tube with 32x32x64 lattices.. The image in the window shows the velocity vectors of the calculated flowflow field Remote update of shared objects when the simulation is executed on multiple processes.. The error bars indicate the standard deviations of 100 measurements Asynchronous data transmission between the Surgeon A and Blood Simulator componentt instances A comparison of the time interval between two invocations of Compute actions Basic time costs for updating a Flow Data object The idle time between invoking Refresh JFlow Data actions 89

5 122 2 ListList of Figures The total time for simulation to do 80 iterations computing Multiple users explore the Blood Mow object. The term UserOpinion describes thee opinion choice selected by a user. When both surgeons accept the simulationn results, or one of them does not accept, the simulation scenario ends. The highh level scenario decides whether to make a new scenario or to finish the entiree story User's opinions and the chatting interface The delay for remotely updating Blood Mow object with one, two and four Surgeons.Surgeons. The error bars indicate the standard deviations. The size of data objectt is 2M bytes A scenario template for collaboratively searching optimal bypasses. In the template,, SURGEON MOLE and SIMULATOR HOLE are two general role names,, which have to be replaced with concrete role names at run time Switch shared classes between different instances of a scenario template A graphical representation of the experiment requirement for a bypass-validation experimentt Different types of ontologies Developing Ontologies using Protégé The basic architecture of an agent HI 6.55 A snapshot of the component management subsystem A snapshot of the experiment planning subsystem Searching different number of activities from the component collection