dinamic distributed DEVS model on OSGI

8/12/2019 dinamic distributed DEVS model on OSGI

http://slidepdf.com/reader/full/dinamic-distributed-devs-model-on-osgi 1/10

Dynamic Distributed Simulation of DEVS Models on

the OSGi Service Platform

Martin Petzold, Oliver Ullrich, Ewald Speckenmeyer

{petzold|ullrich|esp}in!ormatik"uni#koeln"de

$epartment o! %omputer Science, University o! %olo&ne

Pohli&stra'e (, )*++ %olo&ne, -ermany

Abstract.nteropera/ility amon& simulators is one o! the key !actors in distri/uted simulations"

Several interopera/ility in!rastructures such as 012 and $E3S4SO2 have /een utilised,

/ut most o! them do not provide any dynamics"

5his paper introduces the use o! the OS-i service plat!orm as universal middleware

!or dynamic distri/uted simulation o! $E3S models" 6e have desi&ned and implemented

the $E3S4OS-i simulation !ramework, which is an approach similar to $E3S4SO2, /ut

relies on an inte&rated service#oriented and protocol independent architecture" .t ena/les

standardized plu&#and#play capa/ilities and dynamic recon!i&uration within distri/uted

simulations" 5he architecture and implementation has /een validated in an analytical

conte7t a&ainst a tra!!ic simulation model" 6e conclude that the standardised

interopera/ility and run#time dynamics provided /y the OS-i service plat!orm are hi&hly

valua/le !or distri/uted simulations"

1 Introduction$istri/uted simulations 8$S9 are used in the conte7t o! analytical simulations !or the

analysis or !orecast o! the /ehaviour o! a real or ima&inary system :;" .n this case

detailed <uantitative data is collected and simulation runs are typically e7ecuted as !ast as

possi/le" =urther, $S have /een applied in distri/uted virtual environments 8$3E9, such

as Second 1i!e5M" .n this case the simulation em/eds human participants or physical

devices and simulation time advances usually in real time" =or $3E the need o! system

accuracy is usually lower than in analytical simulations"

.n /oth domains interopera/ility in!rastructure ena/les &eo&raphically distri/uted

e7ecution and the inte&ration o! hetero&eneous simulators" >e7t to proprietary protocols

more a/stract interopera/ility in!rastructures such as 012 and $E3S4SO2 have /een

utilised !or $S o! $E3S models :+, ();" 0owever, in recent work :?, (@; a lack o!

standardization !or plu&#and#play capa/ilities and a need !or research on dynamicrecon!i&uration in distri/uted simulations has /een identi!ied" 5his should /e adopted on

an a/stract architectural level and possi/ly also within the simulation nodes"

5he $E3S4OS-i simulation !ramework introduced in this paper addresses /oth

issues" 5he $E3S standard !or modellin& and simulation o! discrete event systems is

/ein& mapped to the OS-i service plat!orm, a widely used industrial standard !or

modular and dynamic applications in Aava" 5he standardized run#time dynamics and

service#oriented 8distri/ution9 concepts o! OS-i ena/le plu&#and#play capa/ilities !or



distri/uted simulation" =urthermore dynamic recon!i&uration within the distri/uted

simulation environments /ecomes possi/le".n chapter two /oth standards 8$E3S and OS-i9 will /e introduced, !ollowed /y a

short overview over recent work in this conte7t" .n chapter three we will present the

architecture and implementation o! the $E3S4OS-i simulation !ramework" 5his is

!ollowed /y some e7periments usin& a tra!!ic simulation model" =inally, some

conclusions are drawn and issues !or !urther research are hi&hli&hted"

2 ac!"round

2#1 $he Discrete Event System S%ecification &DEVS'5he $iscrete Event System Speci!ication 8$E3S9 is a modular and hierarchical

system !ormalism that was introduced /y Bernard P" Cei&ler in (+D :(;" $E3S models

consist o! atomic and coupled components" 2tomic components de!ine a speci!ic

/ehaviour o! an entity that is /ein& modelled" 6hereas coupled components de!ine the

couplin& o! output to input ports o! components" Every atomic component has a de!ined

state at any time" State transition !unctions prescri/e the chan&e o! this state i! events

occur" =or internal events the internal transition !unction and !or e7ternal events the

e7ternal transition !unction de!ine the new state" =urthermore an output !unction returns

the output events and a time advance !unction returns the remainin& time in state"

.n (++ Parallel $E3S was introduced, which allows the parallel e7ecution o! $E3S

models :;" .nput events are handled as a set o! events and a con!luent transition !unction

de!ines the new state in case o! concurrent internal and e7ternal events" =or the simulation

o! such Parallel $E3S models speci!ic simulation protocols are re<uired" 5he Parallel

$E3S simulation protocol is /ased on a direct mappin& approach and thus the processin&o! simultaneous internal events" 5his simulation protocol has /een used !or our work and

is de!ined /y the !ollowin& stepsF (" .nitialization, " determination o! the ne7t event time,

G" output o! events, and @" e7ecution o! state transitions" Even thou&h we !ocussed on this

protocol others could /e implemented"

2#2 $he OSGi Service Platform5he OS-i standard de!ines a dynamic module system !or Aava, the OS-i service

plat!orm" 5he OS-i 2lliance 8!ormerly known as the Open Services -ateway initiative9

is an industrial consortium 8Oracle, .BM, Siemens, ProSyst and others9 !ounded in (+++,

which is !ocused on the maintenance o! this standard :(*;" Several or&anizations have

implemented the standard" 2pplications ran&e !rom industrial automation over mo/ile

applications to enterprise systems" 2pache =eli7, ProSyst mBS, and Eclipse E<uino78core o! the Eclipse .$E9 are well known implementations o! OS-i"

5he OS-i !ramework is the core o! the OS-i service plat!orm" .t provides a standard

environment !or run#time components, called /undles" Bundles are A2H packa&es with

additional mani!est headers" 2pplications are developed !rom these reusa/le and loose

coupled components" 5he !ramework architecture can /e divided into three layers 8=i&ure

(9" 5he module layer de!ines class loadin& /ehaviour" .n Aava it is common to have one

classpath, OS-i e7tends this model with modularization" 5hus every /undle has its own

classpath and holds private classes, that can /e e7ported to other /undles"



5he li!e#cycle layer adds run#time dynamics, that are normally not part o! an

application" .t provides capa/ilities to install, start, stop, update, and uninstall /undles inan OS-i !ramework" 5his allows !ine#&rained maintenance on the level o! /undles"

On the service layer services and the service re&istry are introduced" 5he /asic model

is a Ipu/lish4!ind4/ind4e7ecuteI pattern as in a service#oriented architecture 8SO29" But it

does not rely on we/ services, in !act in OS-i it operates within an application" 0ence,

POAOs 8IPlain Old Aava O/JectsI9 can /e re&istered with the OS-i service re&istry" 5hese

services can /e !ound and e7ecuted /y other /undles"

.n the OS-i service compendium :((; and correspondin& speci!ications, such as the

OS-i enterprise speci!ication :(;, system services !or numerous domains o! application

development are speci!ied" =or our work the event admin service and remote services

have /een used" 5he event admin service de!ines a simple Ipu/lish4su/scri/eI pattern"

5hus /undles can re&ister 8su/scri/e9 event handler services !or a speci!ic topic with the

service re&istry" .! an event is posted 8pu/lished9 via an event admin serviceimplementation, it will /e dele&ated to all correspondin& event handlers"

Hemote services provide the a/ility to re&ister services not only !or internal use in the

!ramework, they can /e made remotely accessi/le, so that /undles o! another !ramework

or even other applications can make use o! them" =urthermore e7ternal services, such as

we/ services, can /e re&istered with the service re&istry" 5he type o! service distri/ution

and discovery depends upon installed distri/ution and discovery providers 8=i&ure 9"

Several implementations !or service discovery e7ist, e"&" via .P /roadcast 8Cerocon! or

S1P9 or distri/uted con!i&uration servers with 2pache CooKeeper" $istri/ution providers

rely on protocols such as HM., 6e/ Services 8SO2P4HES59, or H#OS-i :(G;"

(i"ure 2) OS-i remote services

(i"ure 1) OS-i service plat!orm



2#* +elated ,or!

Even thou&h OS-i has not /een used to simulate $E3S models, some simulationenvironments use the Eclipse .$E and Eclipse plu&#ins !or component#/ased simulation"

.n :G; the implementation o! an o/Ject#oriented &eneric simulation environment /ased on

Eclipse is introduced" 5he main /ene!its identi!ied are the separation o! model and

e7periments and the e7tensi/ility via Eclipse plu&#ins" 0owever, this simulation

environment is not capa/le o! simulatin& $E3S models"

2nother !le7i/le, e7tendi/le, and reusa/le simulation !ramework is Aames .. :D;" .t is

/ased on an OS-i#like architecture that uses plu&#ins !or the inte&ration o! di!!erent

simulators, includin& $E3S" But this approach does not use OS-i as plu&#in

environment"

5he %$LLBuilder introduced in :(; is an Eclipse plu&#in and thus uses the OS-i

/undle concepts, /ut it is only used in terms o! $E3S modellin& and does also not use

OS-i plu&#ins !or the implementation and simulation o! $E3S models"Several protocols and distri/uted middleware concepts have /een applied !or

distri/uted simulation o! $E3S models in Aava" 5he most appropriate one is $E3S4SO2

:+;, which uses a SO2 and thus classic SO2P we/ services !or distri/uted interopera/ility

amon& simulators" .t ena/les run#time composa/ility and has /een approved o! simulatin&

$E3S models in parallel" Even thou&h the architecture o! $E3S4SO2 is service#

oriented, it is still rather di!!erent !rom the service#oriented interopera/ility and

distri/ution concept provided /y the OS-i service layer and OS-i remote services"

5he approach o! a shared a/stract model 8S2M9 introduced in :(); tar&ets the

inte&ration o! hetero&eneous models and uses pro7ies as a/straction o! model inter!aces"

S2Ms can /e implemented usin& sound distri/ution middleware and ena/le !le7i/le and

non#tedious inte&ration o! new component models" 5his is indeed close to our intent o!

the a/straction o! the interopera/ility in!rastructure"

>e7t to distri/uted interopera/ility our &oal is to ena/le dynamic recon!i&uration

within the simulation !ramework" 6ith a varia/le structure approach introduced in :?;

dynamic recon!i&uration can /e achieved durin& run#time" %omponents can /e added,

removed, updated or mi&rated and connections /etween components can /e added or

removed dynamically"

0owever, the run#time dynamics and distri/ution concepts provided /y the OS-i li!e#

cycle and service layer have not /een !ully utilised yet"

* $he DEVS-OSGi Simulation (rame.or! 5he $E3S4OS-i simulation !ramework introduced in this chapter will ena/le all

/ene!its o! o/Ject#oriented application !rameworksF Modularity, reusa/ility, e7tensi/ility,and inversion o! control :);" =urthermore a service#oriented architecture concept is used

!or interopera/ility and e7tended modularity, e"&" loose couplin& and run#time dynamics"

*#1 A%%roachO/viously $E3S and OS-i rely on the same /asic concept, a decomposed system

approach" .n $E3S a system is /ein& modelled !rom decomposed components, while

with OS-i applications are /uild out o! components" =urthermore OS-i is /ased upon

service#oriented interopera/ility concepts, proven to /e appropriate !or distri/uted



simulations o! $E3S models" Both standards have not /een inte&rated in a well#!ounded

way yet" 5hus our approach is to /rin& to&ether /oth standards and ena/le dynamicdistri/uted simulation" .n !act two aspects need to /e considered, !irst the mappin& o! the

$E3S !ormalism onto the OS-i service plat!orm and second the concepts o!

interopera/ility and distri/ution !or the Parallel $E3S simulation protocol"

$E3S components 8implemented as Aava classes9 are wrapped into /undles that

re&ister a service with the OS-i service re&istry" >otice, that in case o! this (F( mappin&

only one $E3S component is wrapped into a sin&le /undle" 2lthou&h this is not the /est

!or every application, it ena/les the !ull power o! OS-i li!e#cycle layer dynamics, e"&"

installation4uninstallation and update o! $E3S components" $raw/acks and potential

improvements o! this mappin& will /e discussed later"

5he interopera/ility can /e descri/ed as an a/stract inte&rated service#oriented

architecture, that is /asically provided /y the OS-i service plat!orm" 5he service#oriented

desi&n is similar to the concepts o! $E3S4SO2 /ut protocol independent 8a/stract9 andmore !ine#&rained 8inte&rated9" 5he interopera/ility is a/stract as it depends upon the

installed discovery and distri/ution providers" 5he term inte&rated re!lects the service

concept that is /ein& used internally in a simulation node and also e7ternally via OS-i

remote services" Both issues will /e descri/ed in the !ollowin& two chapters in detail"

*#2 Architecture5he main /undle o! the $E3S4OS-i simulation !ramework 8=i&ure G9 is the

$E3S4OS-i core /undle" .t consists o! all inter!aces and a/stract classes re<uired !or the

implementation o! $E3S4OS-i components, simulators, and nodes"

$E3S4OS-i components are simple $E3S component classes that implement a$E3S4OS-i atomic or coupled component inter!ace" 5hese inter!aces de!ine the methods

o! the $E3S !ormalism and thus should /e compati/le with every $E3S component

implemented !or other simulation environments" 5he component classes are then wrapped

into /undles and re&ister a component service on startup 8=i&ure @a9"

$E3S4OS-i simulators implement the steps o! the Parallel $E3S simulation

protocol" Each simulator installed in a simulation node is responsi/le !or a speci!ic type

o! component" .t instantiates a simulator o/Ject !or each correspondin& component and

re&isters this as remote simulator service with the OS-i service re&istry 8=i&ure @/9"

(i"ure *) $E3S4OS-i simulation !ramework



$E3S4OS-i nodes are not re<uired !or the e7ecution o! a simulation, however we

have de!ined a node service that represents our simulation nodes in the serviceenvironments" 6ith this it is possi/le to install, uninstall and update $E3S4OS-i

component /undles into remote simulation nodes" =urthermore in!ormation a/out

installed components, states and simulation pro&ress are provided that can /e used /y the

controller 8-U.9"

5he interopera/ility o! a simulation is related to simulation control and event

dele&ation" 5he simulation is controlled /y a root simulator that is typically installed in a

separate controller node" 5his root simulator is aware o! the simulator service /elon&in&

to the root component 8this needs to /e set4selected9" .t e7ecutes the steps o! the

simulation protocol via asynchronous calls and dictates the simulation time advance, e"&"

real time or as !ast as possi/le" 5he same is done /y every coupled simulator, they are

responsi/le !or the e7ecution o! the steps on their child simulators" .nvocation o! all

8root4child9 simulators is realised via OS-i service layer and OS-i remote services" 5husthe simulation control is e7ecuted transparently without knowin& i! the simulator is

installed in the local or in a remote simulation node"

Event dele&ation uses the OS-i event admin and thus a Ipu/lish4su/scri/eI pattern

8=i&ure @c9" 2s mentioned /e!ore, event handlers are re&istered !or each port" .! events are

posted to the OS-i event admin, it is responsi/le !or the dele&ation to all appropriate

event handlers o! other simulators"

2s re&ular OS-i event admin implementations are only used !or !ramework internal

event dele&ation, we had to implement a remote event admin"

*#* Im%lementation5he implementation is similar to others !or $E3S, such as $E3S4SO2" 0owever with

the implementation o! the $E3S4OS-i simulation !ramework some recent concepts o!

the Aava pro&rammin& lan&ua&e, such as &enerics, annotations, and e7ception handlin&

were inte&rated" Especially the use o! &enerics !or the separation o! state and component

implementation /rin&s si&ni!icant improvements !or the development o! $E3S4OS-i

simulators" 5he state is implemented as separate class and &eneric type o! the

(i"ure /) $E3S4OS-i simulation !ramework services and distri/ution



correspondin& component" 5hus simulators mana&e the state o! its components usin& Aava

&enerics and can store state data via o/Ject serialization"5he a/stract simulator classes implement a service tracker concept to reco&nise

component services and 8child9 simulator services installed within the simulation

environment dynamically" 5he event dele&ation via OS-i event admin has also /een

implemented on this a/stract level" =or this we needed to implement a remote event

admin implementation, which uses service pro7ies !or remote event handler services and

thus uses OS-i remote services !or event dele&ation"

6e have implemented two de!ault simulators /ased on the Parallel $E3S simulation

protocol, one is appropriate !or atomic, the other !or coupled $E3S4OS-i components"

5he atomic simulator mana&es the state and !unctions o! components, as mentioned in

chapter "(" 5he coupled simulator mana&es all child simulators and e7ecutes the

simulation steps" 2ll steps are e7ecuted as asynchronous4non#/lockin& calls"

=urthermore we implemented a de!ault node implementation and a controller 8with-U.9 !or the decentralized installation o! $E3S4OS-i components 8=i&ure )9" 6e /uilt

releases o! /oth, node and controller 8includin& the core and simulators9, so that they can

/e used standalone without the Eclipse .$E"

/ E0%eriments.n order to validate the !ramework architecture and implementation we have

conducted some e7periments" 5he main o/Jective was to test !unctionality and

per!ormance" =or all e7periments the $E3S4OS-i simulation !ramework was installed in

(i"ure ) $E3S4OS-i %ontroller -U.



an Eclipse E<uino7 8G""(9 OS-i !ramework" 6e used the Eclipse %ommunication

=ramework 8E%=9 in version G"@ as OS-i remote service implementation" 5he /est per!ormance could /e achieved with the E%= &eneric distri/ution provider /ased on

sockets and Coo$iscovery /ased on 2pache CooKeeper as discovery provider"

/#1 $raffic Simulation Model6e have implemented a sin&le road crossin& as an atomic $E3S component" %ars

pass the crossin&s and are directed to other crossin&s via output and input events" 5he

tra!!ic li&hts consist o! !our states 8&reen, yellow, redLyellow, and red9, thus we possi/ly

&ain multiple simultaneous events per simulation step" 5his component was then

replicated 8wrapped9 with di!!erent tra!!ic li&ht con!i&urations and cars <ueuin& in !ront

o! them" 5he crossin&s were connected usin& coupled $E3S components that !orm a

torus model 8=i&ure 9"

/#2 +esults6e have installed models with @( to @@ crossin&s on di!!erent distri/uted simulation

con!i&urations 8(, @, ?, and ( nodes9 and run several simulation runs" Every simulation

run was set to @ hours simulation time" 5he results in =i&ure D show, that we can achieve

a speed#up 85(45n, 5n simulation time on n nodes9 &reater than ("* !or torus models

with @ and ) crossin&s" 5he torus model with ) crossin&s can /e e7ecuted on !our,

ei&ht, and si7teen simulation nodes !aster than on one" 2n avera&e speed#up o! ("?@ was

o/tained"

(i"ure ) 5ra!!ic simulation model

(i"ure 3) Speed#up on @, ?, and ( simulation nodes

4 16 64 256

0

1

23

4

8

16

Torus model size (number of crossings)

S p e e d - U p

( T 1

T n )



/#* Discussion

5he per!ormance tests with the tra!!ic simulation models approved the simulation!ramework e7ecutin& steps in parallel" But due to memory utilisation we could install

only ) crossin& /undles per simulation node and the installation time was si&ni!icantly

hi&h" =or per!ormance tests replication o! crossin&s as /undles is appropriate, /ut in !act

it is not that reasona/le installin& /undles consistin& o! the same class into one simulation

node" 5hus support !or multiple occurrence as descri/ed in :@; should /e considered" .n

other applications it could /e appropriate wrappin& more than one $E3S component into

a /undle" 5he challen&e is to address these issues without losin& the power o! the run#

time dynamics provided /y the OS-i service plat!orm"

4onclusions5he OS-i run#time dynamics are hi&hly valua/le !or plu&#and#play capa/ilities and

dynamic recon!i&uration in $S, especially !or the inte&ration o! simulators, components,

and distri/ution4discovery providers, dynamic assem/ly o! distri/uted models and

dynamic distri/ution o! components"

=urthermore OS-i provides a standardised and protocol independent interopera/ility

in!rastructure" 5he $E3S4OS-i simulation !ramework is !ully compati/le to Eclipse

plu&#ins and has /een tested usin& the Eclipse E<uino7 OS-i !ramework" >evertheless

some research needs to /e done on the implementation o! multiple occurrence and the

inte&ration o! hetero&eneous simulators" =urther inte&ration into the Eclipse .$E in

means o! e7tensions and views would /e use!ul" 2dditionally OS-i has a lot more

capa/ilities that could /e inte&rated, such as versionin& and con!i&uration mana&ement"

6e !ocussed our e7periments on an analytical simulation conte7t" .n $3E the system

accuracy is lower and possi/ly its components more hetero&eneous, thus the $E3S4OS-isimulation !ramework may /e even more appropriate"

+eferences

:(; Chiril Chidisiuc, Gabriel A. Wainer: %$LLBuilderF 2n Eclipse#/ased .$E !or $E3S

Modelin&" Proceedin&s o! the **D Sprin& Simulation Multicon!erence 8**D9"

:; Alex ChungHen Chow, Bernard P. Zeigler: Parallel $E3SF 2 Parallel, 0ierarchical,

Modular Modelin& =ormalism and its $istri/uted Simulator" 5ransactions o! the

Society !or %omputer Simulation .nternational 3olume (G, .ssue 8(++9, ))#?"

:G; Rainer Czogalla, Nicolas naa!, Bernd Page: Simulatin& the Eclipse 6ayF 2

-eneric E7perimentation Environment Based on the Eclipse Plat!orm" Proceedin&so! the *th European %on!erence on Modellin& and Simulation 8**9"

:@; "li#ier $alle, Bernard P. Zeigler, Gabriel A. Wainer: E7tendin& $E3S to Support

Multiple Occurrence in %omponent#/ased Simulation" Proceedin&s o! the **?

6inter Simulation %on!erence 8**?9"

:); %oha&ed 'a(ad, $ouglas C. )ch&id*: O/Ject#oriented 2pplication =rameworks"

%ommunications o! the 2%M 3olume @*, .ssue (* 8(++D9, G#G?"



:; Richard 'u+i&o*o: Parallel and $istri/uted Simulation Systems" >ew NorkF Aohn

6iley Sons, ***":D; an Hi&&els-ach, Adelinde %. hr&acher: Plu&In Simulate" Proceedin&s o! the

@*th 2nnual Simulation Symposium 8**D9, #?"

:?; /iaolin Hu, Bernard P. Zeigler, )aurabh %i**al: 3aria/le Structure in $E3S

%omponent#Based Modelin& and Simulation" S.MU125.O> 3olume ?(, .ssue

8**)9, +(#(*"

:+; )aurabh %i**al, os0 1. Risco2%ar*3n, Bernard P. Zeigler: $E3S4SO2F 2 %ross#

Plat!orm =ramework !or >et#centric Modelin& and Simulation in $E3S Uni!ied

Process" S.MU125.O> 3olume ?), .ssue D 8**+9, @(+#@)*"

:(*; ")Gi Alliance: OS-i Service Plat!orm Helease @"" aQute Pu/lishin&, **+"

:((; ")Gi Alliance: OS-i Service Plat!orm, Service %ompendium Helease @"" aQute

Pu/lishin&, **+"

:(; ")Gi Alliance: OS-i Service Plat!orm, Enterprise Speci!ication Helease @""

aQute Pu/lishin&, **+"

:(G; an ). Reller&e(er, Gus*a#o Alonso, 4i&o*h( Roscoe: H#OS-iF $istri/uted

2pplications throu&h So!tware Modularization" Proceedin&s o! the

2%M4.=.P4USE>.R ?th .nternational Middleware %on!erence 8**D9, (#*"

:(@; )*e55en )*rassburger, 4ho&as )chulze, Richard 'u+i&o*o: =uture 5rends in

$istri/uted Simulation and $istri/uted 3irtual EnvironmentsF Hesults o! a Peer

Study" Proceedin&s o! the @*th %on!erence on 6inter Simulation 8**?9, DDD#D?)"

:(); 4ho&as Wu*zler, Hessa& ). )ar+oughian: .nteropera/ility amon& Parallel $E3S

Simulators and Models .mplemented in Multiple Pro&rammin& 1an&ua&es"

S.MU125.O> 3olume ?G, .ssue 8**D9, @DG#@+*"

:(; Bernard P. Zeigler, Herber* Praeho5er, 4ag Gon i&: 5heory o! Modelin& and

Simulation" San $ie&oF 2cademic Press, ***"

dinamic distributed DEVS model on OSGI

Documents

Transcript of dinamic distributed DEVS model on OSGI