Communication Modeling for System-Level Performance-Simulation

Heike S. Rolfs, Andreas W. Liehr, Klaus J. BuchenriederInstitut fur Technische Informatik

Universitat der Bundeswehr MunchenD-85577 Neubiberg, Germany

{heike.rolfs|andreas.liehr|klaus.buchenrieder}@unibw.de

Abstract—Early in the design-cycle of hardware-systems,details about data-formats, interfaces and the behavior ofsystem components are not available. Nonetheless, choicesbetween design alternatives, depending on given constraints,must be made. To support this process, simulation-models areused to determine the system-performance.In this work, an approach for modeling communication-structures for an EQN-based method, as introduced in previouswork, is given. The approach employs component patterns toreduce the complexity of interfaces, while easing the compo-sition of highly performant systems. As we show with the ex-ample of a FlexRay

TM-bus-model, the proposed method fosters

the assembly of simulation-models from coarse grained systemcomponent patterns, while it still allows to obtain detailedperformance simulation results. Despite a high abstractionlevel, the full functionality can be specified with the proposedapproach.This paper provides the modeling of components with ExtendedQueuing Networks(EQN) and a discussion of a fully param-eterizable FlexRay

TM-bus-model, taken from the automotive

domain.

Keywords-Simulation-Model, Extended Queuing Networks,FlexRay

TM, Communication Modeling

I. INTRODUCTION

The development of electronic systems is getting moreand more complicated, hence time-to-market is prolonged.To avoid this, tools helping the developer to decide whetherthe system fulfills the constraints or not, are needed. Onlower levels, various tools for analyzing or simulatinghardware-systems already exist. Ideally, designers wish tohave tools at every stage of the design-cycle, so that thegiven constraints are always controlled, and problems canbe resolved as early as possible.Another issue, in the context of time-reduction during thedesign-process, is using already existing components fromdifferent vendors. These components have a defined be-havior and a pre-specified interface, and simulation-modelsfor these components often exist. When creating a systemwith pre-specified components, local and global interfacesmust be developed or synthesized. Redesign of interfacesand components are required, whenever system constraint-violations emerge.In addition, it is often possible to create a system in

different manners. According to this, questions, where toattach a component, which bus-structures to use, how toconnect these and how the design fits constraints, haveto be answered. Bus-structure selection was addressed byLahiri et al. [1]. In this work Lahiri and colleagues compar-atively evaluated the behavior of different bus-structures. Asystem-trace was generated, through HW/SW co-simulation,and assigned to corresponding bus-models. Side-effects,including delays in other components, provoked by differentcommunication-delays, were not considered.Other approaches opened the way to analyze the perfor-mance of special bus-structures like CAN [2], TTP [3] andFlexRay

TM[4], [5] through a formal timing analysis.

The main approach for simulating systems w.r.t.performance-information was introduced by Sauer et al. [7].The group around Sauer introduced Extended Queuing Net-works, enabling the use of routing-rules and passive nodes.This modeling-approach was extended by Musovic et al. [8],to evaluate the performance and the power-consumption ofan entire system. For a better usability of these models Liehrand Buchenrieder [9] created an UML-based framework fora pattern-based, automated generation of a system, describedwith EQNs. With this framework, it is possible to delineatea system, including architecture, functionality and activitythreads. An example for the architecture is depicted in Fig. 1.The model within the framework allows to describe not onlyone system-emergence but a number of design-alternatives.These alternatives are automatically processed to EQNs to

ICU

SIF

MPEG

(Camera)

RAM

FlexRay

Controller

CPU

BUS

Core System

Flex

Ray

Flex

Ray

TL

M−

Interfa

ce

Recognition

Classification

Visualization

TL

M−

Interfa

ceF

lexR

ay

Figure 1. Architecture of a traffic-sign recognition-system [6]

2010 17th IEEE International Conference and Workshops on Engineering of Computer-Based Systems

978-0-7695-4005-4/10 $26.00 © 2010 IEEE

DOI 10.1109/ECBS.2010.27

193

gather performance-information through simulation.To be able to generate a system with the framework, Liehrutilizes component-patterns. These patterns are connectedduring a model-to-model transformation from the UML-model to the EQN-system. Whenever new componentsshould be included the transformation has to be extended.In this work, we introduce a method for the specification ofcomponents with a minimal interface, i.e., communication-structures. Additionally, we show, how communication-structures can be modeled, so that components can bechanged without generating a new system-alternative, just byreplacing a closed EQN-structure and the reconfiguration ofvariables. The main benefit of the modeled communication-structures is the resulting detailed timing-behavior, config-ured through specification-data. Although the system is onan abstract stage, the communication can be simulated andoptimized in detail and the findings can be used for the latergenerated detailed system.The remainder of this work is organized as follows: SectionII introduces the main approach how components, especiallycommunication-structures are modeled. Section III illus-trates the method with the example of a FlexRay

TM-bus. In

Section IV, the generation of an entire system based on thepresented component-models is explained with an example.The paper concludes with a summary and an outlook.

II. MODELING HARDWARE COMPONENTS

In this section, basic principles for creating component-models with EQNs on the system-level communication-components are discussed.

A. Basic Principles

When creating a system-model, in our approach, templatesfor components are used. If these models are complex, i.e.,have multiple connections to communicate with each other,a model-to-model transformation is used to connect thecomponents. To avoid this step, template-interfaces must besimple and compatible for interconnection. The minimuminterface of a component is one input and one output.The problem in this case are components creating sub-processes, e.g., memory access. How these subprocesses canbe handled, when a component has a minimal interface, isdescribed in the following section.

1) Routing: Compared to QNs, EQNs can not only useprobabilities to determine the routing for a job, but rout-ing depends on conditions of different types of variablesand state-functions of the entire net. A job-variable, calledDESTINATION , is used for a deterministic routing ofjobs. This variable can include the following representationsof routing-behavior:

• x, a single component, representing the next destinationof the job.

Bus

r/w w

r r/w

r

w

Figure 2. Bus-structure with writing, reading and both components

• {x1, x2}, a set of components, representing a set ofdestinations. Therefore, a job is split and one child isrouted to each of the components.

• (x1, x2), a list of components, representing the orderthe job is routed through the network.

According to this syntax multiple interlacings are possible,e.g., DESTINATION = {(x1, x2), x2}, leads to a splitand the first of the two jobs are routed to a list of compo-nents.This principle can be used to afford the possibility to haveonly one input and one output, also when a componentstarts a sub-process through a fission- or split-node. Thenset-nodes are used to change the destination-variable to anew value or it inserts some elements. If the sub-processis created through a fission-node the sub-process has to getback to the corresponding fusion-node. In this case, the set-node would insert two elements, the new component for thesub-process and the current component, to enable the job tofind the way back to its sibling.

B. Communication Components

When a bus is viewed as a component it must havemore than one input and one output. In this case, the bus-component needs one connection per connected componentto avoid collisions. This enables the selection of one com-ponent to send data at a time. After the input-data is sortedin an order it is processed, it needs a calculated amount oftime to proceed. After that the data only has to get routed toits destination. In general this means that a communication-structure needs one entry for each component writing toit and one output for each component reading from it, asdepicted in Fig. 2.

When analyzing different system-alternatives it is alsouseful not only to create different configurations for thesame bus-structure, but to be able to change this structure toany other kind of communication structure. This is realizedin our approach by separating the part being connectedto the system-model, called bus-interface, from the partcontaining the main-behavior of the bus-model, the bus-protocol. The bus-interface can be used for trivial and non-

194

jobWaiting_x: W

FIFO data_x: DATASIZE

jobPass_x: P

jobPass_x: P

FIFOjobReady_x: R

semaphore: 1

semaphore: 1

FIFO

Figure 3. Bus-interface for component x

trivial communication-structures. Just a replacement of theconfiguration is required and no new system-model has to becreated. According to this and the fact that the bus-protocolis only connected over the interface, it can be replaced byanother one. How these parts work and how they can beconfigured is described in the following two sections.

1) Bus-Interface: In our approach, system models arehigh-level abstractions, which contain only few detailedcomponents. Due to this fact, Jobs in our EQNs arekept on a high-level-view. This means for communication-components, that arriving jobs are not equal to a requiredpackage-size, but the whole data-package. Nevertheless, theprotocols need packages to facilitate, for example, time-slotbased schedulings. The required interface, depicted in Fig.3, is realized with a number of passive nodes, managingwhether a component is allowed to send data or not.In this interface-model, a job generates jobWaiting-tokensfor the network part representing the bus-protocol, producingonly datax-tokens whenever a job is waiting for transmis-sion. After that, the job is delayed in the queue until enoughdatax-tokens can be allocated. Thereafter, the job passesthe allocate-node and creates a token to signal the protocolthe job has finished. After the protocol has generated thejobPass-token, the job can proceed to its destination. Tosecure that the next job does not start before the previousjob has finished, a semaphore mechanism encapsulates themain interface.Depending on the behavior of the corresponding bus-protocol, the interface has to be configured. A configurationof the interface-behavior is defined by:

busint = (x,w, r, p) (1)

with x, a placeholder for the name of the interface, e.g.,the name of the component to connect, w a configurablenumber of tokens to transmit for example the size of the jobpresented to the protocol, r the number of tokens generatedwhen the job has enough datax-tokens to proceed andp the number of tokens the job needs to proceed. Thedefault-value for w,r and p is 1.

2) Bus-Protocol: Since bus-transfers can only engage onesource and one or more sinks, access to the bus mustbe regulated by a bus-protocol. Each component, seekingaccess to the bus requires a permission from the central bus-

jobWaiting_x: W

jobReady_x: R

jobPass_x: PjobReady_x: R

duration(D)data_x: D

jobWaiting_x: W

Figure 4. Basic protocol for component x

protocol to transfer data over the bus. Thereby, the order ofcomponents requiring access to the bus and the duration ofaccess is synchronized.A simple method how the protocol can manage this behavioris presented in Fig. 4. When a job is waiting, an amountof tokens, representing the data-size, is created. After that,the protocol waits a defined amount of time, fitting the sizeof the data, before it continues. In this case, if there is nojobReady-token, the system is configured wrong, becausethe amount of tokens in datax was not equal to the data-sizeof the job. If the job can pass, it generates the token for thejob in the interface to proceed.A configuration of this bus-protocol is:

busprot = (x,w, d, r, p) (2)

with d the duration of the transfer and x,w, r, p equivalentto the configuration of the interface in (1).

This principle can be adapted to almost every kind ofcommunication-behavior. If a priority-based system is used,the structure depicted in Fig. 5 can be used when the basicprotocol from Fig. 4 for each priority is included. This isexpressed as:

busprot = (x,DATASIZE,W, 1, 1) (3)

A round-robin-schedule is created by a circle of protocol-parts. Other scheduling behaviors can be constructed by ar-ranging protocol-parts in corresponding topologies. A time-slot-based schedule is illustrated in the next Section.

prio

alt

prio

alt

Priority 1

Priority 2

Priority 3prio

1

alt

Figure 5. Priority-based protocol with 3 priorities

195

static segment dynamic segment symbolwindow

network idletime

1 2 m-2 m-1 m n…

gMacroPerCycle

gdStaticSlot gdMinislot gdSymbolWindow gdNIT

…

gNumberOfStaticSlots gNumberOfMinislots

t

Figure 6. FlexRayTM

-protocol

III. AN EQN-BASED FLEXRAYTM

-MODEL

The FlexRayTM

-bus is a bus-structure from the automo-tive domain, used in novel cars for the communicationbetween electronic components. The FlexRay

TMwill replace

the automative CAN-bus, because it is a fault-tolerant bussystem exhibiting a higher transfer-rate and offers real-time properties. It is suitable for x-by-wire applications andcan be configured for different behaviors. In the following,we describe the main time-behavior of the FlexRay

TM, as

described in the specification [10].The FlexRay

TMhas a cycle-based protocol, where each cycle

has the same structure, as depicted in Fig. 6. The lengthof a cycle is predetermined by the specification variablegMacroPerCycle. Each cycle has 4 segments, the staticsegment, the dynamic segment, the symbol-window andthe network-idle-time. The last two durations are config-ured with the variables gdSymbolWindow and gdNIT .The static and the dynamic segment are configured witha number of time-slots, gNumberOfStaticSlots respec-tively gNumberofMinislots, and the length of a time-slot, gdStsticSlot and gdMinislot. Each slot has a fixedassociation with a component, allowed to send data. Thedifference between the static and the dynamic segment is,that a static-slot has a constant length, while a dynamicor mini-slot can be expanded to the end of the dynamicsegment, as required by the amount of data to be sent. Inconclusion, the static segment is a time-slot based round-robin schedule and the dynamic segment is similar to apriority schedule. The designer can configure whether to useone of this segments or both.In addition, the FlexRay

TM-bus can be built with one or two

channels. If two channels are used, both channel-cycles aresynchronized. Consequently, it is possible for a componentto send either the same data or different data in the same slot.Furthermore, it is possible to let another component occupythe other channel during this time-frame or leave it unused.A component can also be assigned to more than one staticor mini-slot in case the amount of data or timing-constraintsrequire this.According to the general approach, a FlexRay

TMcan be

modeled with an interface and a separate protocol. Themain part to build for the FlexRay

TM-model is the protocol,

alt

data_x: ALL

data_x: ALL

jobWaiting_x:2

data_x:eStaticSlotData

prio

gdActionPointOffset

gdStaticSlot

prio

alt

jobReady_x: 2

jobReady_x: ALL

eStaticSlotDur

jobWaiting_x: ALL

eStaticSlotDur

jobWaiting_x: ALL

jobPass_x:jobWaiting_x

Figure 7. Static-slot for component x

because only the interface has to be configured with:

busint = (COMPONENT, 1, 1, 1) (4)

A. Bus-Protocol

The bus-protocol is required to generate datax-tokens de-pending on the passing time and to signal the interface whenthe current job can pass through. As mentioned above, thebus-protocol of the FlexRay

TM-bus consists of four segments

per cycle. The symbol-window-segment and the network-idle-time-segment are represented by simple server nodes.The static segment is composed of a configurable numberof static-slots and respectively the dynamic segment of anumber of mini-slots. Each of these slots is assigned to onecomponent. In the following, the models for the two slot-types are presented. These templates have to be combinedto build the complete protocol. Depending on the number ofslots, a very large EQN is created. In this network only onejob is needed to keep it running, so the complexity of thesimulation is low.

1) Static-Slot: The static-slot has a fixed duration andis not dependent on whether a job sends data or not.For the representation of the corresponding model-template,consider Fig. 7. Here the job passes a server node with theduration of gdStaticSlot, when no job is waiting at theinterface. If there is a job waiting, tokens for the datax-token-pool are generated according to (5).

eSSData = gPayloadLengthStatic ∗ 2 (5)−gNetworkManagementV ectorLength

After the time, specified in the variablegdActionPointOffset, it is tested if a job is readyto proceed. If it is not ready, the remaining time passes andaccording to

eSSDur = gdStaticSlot (6)−gdActionPointOffset

the jobWaiting-tokens are released back into the token-pool for subsequent use in the next slot assigned to the samecomponent.

196

gdMinislotchannel_i: 1 channel_i: 1

prio

data_x: [0,eMSData

(channel_i)]

alt End of dynamic segment

jobWaiting_x: ALL

channel_i: ALL

data_x: ALL

jobReady_x:A

LL

eMSDur(channel_i)

eMSDur(channel_i)

jobWaiting_x: ALL

channel_i: eUnusedMS

(data_x)

jobPass_x:jobWaiting_x

jobWaiting_x: ALL

jobReady_x: 2

prio

alt

gdMinislotActionPointOffset

alt

prio

jobWaiting_x: 2

prio

channel_i: [eMinMS(x), eMaxMS(x)]alt

data_x: eMSData

(channel_i)

Figure 8. Mini-slot for component x

Once the job is ready, the corresponding jobReady-tokenand the remaining datax-tokens are destroyed. After theremaining time passes, a jobPass-token is created at theend of the static-slot.

2) Mini Slot: The basic behavior of mini-slots is sim-ilar to the functionality of the static-slot presented in theprevious section. The model-template, presented in Fig. 8,checks, whether a job is waiting. It generates datax-tokensas soon as it resumes execution. Therefore, known nodes,e.g., the allocate- create- or release-nodes connected to thetoken-pools jobWaitingx-, jobReadyx- or jobPassx, areincluded. But the behavior of generating tokens for thedatax-token-pool differs from the static-slot, because themini-slots can get expanded by the component. Nevertheless,a mini-slot has a minimum size gdMinslot, but if theassigned component has data to send the duration canbe expanded until the end of the dynamic segment. Tobuild this behavior, it was necessary to create a token-pool for each channel i with a number of tokens equalto gNumberOfMinislots. This token-pool is used to test,whether the component can send data or not. This is doneby trying to allocate the maximum number of tokens in theinterval [eMinMS(x), eMaxMS(x)]. The function

eMinMS(x) = gNumberOfMinislots− pLatestTx(x) (7)(8)

calculates the minimum number of mini-slot required by thecomponent to send data. The function

eMaxMS(x) =pPayLoadLengthDynMax(x)∗16+64+16

gdMacrotickgdBit

∗gdMinislot

+gdDynamicSlotIdlePhase (9)

expresses the maximum number of usable mini-slots for themaximum length of the payload-segment of x.After allocating the number of mini-slots, the model gener-ates a number of datax-tokens calculated by the function:

eMSData(channeli) =

(channeli−gdDynamicSlotIdlePhase)

∗ gdMacrotickgdBit

∗gdMinislot−64−16

8(10)

Businterface for Component_1

Businterface for Component_2

DESTINATION

Component_2

Component_1

Component_3

2

3

70:A:B

40:A:B

B

A

B

A

Figure 9. System-example with 3 components

As soon as the waiting job has finished, the unused tokensmust be removed from the datax-token-pool, and accordingto the number of tokens, the residual number of mini-slotsis calculated with eUnusedMS(Datax):

eUnusedMS(datax) =datax∗8

gdMacrotickgdBit

∗gdMinislot−64−16

−gdDynamicSlotIdlePhase (11)

This unused mini-slots are released to the channeli-token-pool, to be available for the next component. Hence, the jobnow only owns the number of used channeli-tokens. Onthis base, with

eMSDur(channeli) = channeli ∗ gdMinislot (12)−gdMinslotActionPointOffset

the duration of the current mini-slot can be calculated.After this, the used channeli-tokens are destroyed and thejobPass-tokens are generated.

IV. INTEGRATING A MODEL IN A SYSTEM

When a number of component-models is created, systemintegration follows. In this Section, we provide a represen-tative example for manual component integration and how asimulatable system-description can be derived by using anXSL-transformation and other software.The system example with 3 integral components connectedvia a common bus, is shown in Fig. 9.Jobs are created in the source, processed in the first compo-

nent and routed either to the sink-node or through the bus-interface to the next component. This behavior is determinedby a probabilistic rule, attached at the routing-node. Whenthe job continues it is determined at the next routing-node,depending on the job-variable DESTINATION , to whichcomponent the job proceed. After component 2 the job-routing is determined by another probabilistic rule and aftercomponent 3 the job is finished.This example and all models or model-parts presented inthis paper are generated with Microsoft Visio R©, hence thesecan be saved in an XML-format. The placeholders forcomponents and interfaces are filled with content throughpages with the same name. By using an XSL-transformation(XSLT), the whole system with all subparts is combined and

197

transformed to an XML-serialization, as depicted in Listing1.

Listing 1. Extract of a SimEQN-based system<SIM EQN xmlns=” h t t p : / / qw e r t z . i n f o r m a t i k . unibw−

muenchen . de / s imeqn / s imeqn ” . . .><NETWORK>

. . .<!−−B u s i n t e r f a c e f o r Component 1−−><CREATE Id =” 1 4 . 1 ” NId=” 1 4 . 3 ” TPId=”

j o b W a i t i n g 1 ” Rule=” 2 ” /><ALLOCATE Id =” 1 4 . 3 ” NId=” 14 .14 ” TPId=” d a t a 1 ”

Rule=” D a t a s i z e ” S c h e d u l e r =”FIFO” Length =”−1” />

<ALLOCATE Id =” 1 4 . 4 ” NId=” 1 4 . 5 ” TPId=” j o b P a s s 1” Rule=” 2 ” S c h e d u l e r =”FIFO” Length =”−1” />

<DESTROY Id =” 1 4 . 5 ” TPId=” j o b P a s s 1 ” Rule=” 2 ” /><CREATE Id =” 14 .14 ” NId=” 1 4 . 4 ” TPId=” jobReady 1

” Rule=” 2 ” /><!−−Component 2−−>. . .

< /NETWORK><TOKEN POOLS>

<TOKEN POOL Id =” j o b W a i t i n g 1 ” Tokens=” 0 ”S c h e d u l e r =”FIFO” S i z e =” 0 ” />

<TOKEN POOL Id =” d a t a 1 ” Tokens=” 0 ” S c h e d u l e r =”FIFO” S i z e =” 0 ” />

. . .< /TOKEN POOLS>. . .

< / SIM EQN>

This XML-code is based on a revised version of theSimEQN-schema [11]. This XML-schema enables the val-idation of the model for the simulation-process with acorresponding simulation-tool, as presented by Liehr.For generating and inserting the bus-protocol to the systema script is used with given parameters for all global andcomponent-specific specification-values used in the model.This script creates multiple instances of the modules andreplaces the placeholders for component-names, token-poolsand variables.

V. CONCLUSION AND OUTLOOK

In this work, we present an approach to model the be-havior of components and especially communication struc-tures like buses at the system-level. This is achieved byusing a constant rule set, without the need to insert newrules in a model-to-model transformation-tool, when addinga new component-type to an EQN-based framework. Weintroduce a method to create component-models with aminimal interface, realized through routing-rules, which canbe parametrized and changed by set-nodes. Additionally, weshow how communication-component-models can be buildin two parts, a constant interface and a flexible protocol, be-ing replaceable by any other bus-system without rebuildingthe whole system. As an example, we show a protocol for apart of a FlexRay

TM-bus, in which we keep the model highly

configurable through specification-variables.In future work, we will focus on the automatic generationof systems with the presented component-concepts, by in-

tegrating the script and the XSLT-file to the work-flow ofLiehr’s framework.

ACKNOWLEDGMENT

This work has been partially financed by the Institut furTechnik Intelligenter Systeme (ITIS e.V.).FlexRay

TMis a trademark of the FlexRay Consortium.

REFERENCES

[1] K. Lahiri, A. Raghunathan, and S. Dey, “System-level per-formance analysis for designing on-chip communication ar-chitectures,” IEEE Trans. on CAD of Integrated Circuits andSystems, vol. 20, no. 6, pp. 768–783, 2001.

[2] K. Tindell, A. Burns, and A. J. Wellings, “Calculating con-troller area network (CAN) message response times,” ControlEngineering Practice, vol. 3, no. 8, pp. 1163 – 1169, 1995.

[3] P. Pop, P. Eles, and Z. Peng, “Schedulability-driven com-munication synthesis for time triggered embedded systems,”Real-Time Syst., vol. 26, no. 3, pp. 297–325, 2004.

[4] A. Hagiescu, U. D. Bordoloi, S. Chakraborty, P. Sampath,P. V. V. Ganesan, and S. Ramesh, “Performance analysis ofFlexRay-based ECU networks,” in DAC ’07: Proceedings ofthe 44th annual Design Automation Conference. New York,NY, USA: ACM, 2007, pp. 284–289.

[5] T. Pop, P. Pop, P. Eles, Z. Peng, and A. Andrei, “Timinganalysis of the FlexRay communication protocol,” in Real-Time Systems, 2006. 18th Euromicro Conference on, 2006,pp. 11 pp.–216.

[6] A. W. Liehr, S. Mazanek, K. J. Buchenrieder, andU. Nageldinger, “A model-driven engineering approach toderive simulation models from UML-based hardware descrip-tions,” in The 20th International Conference of Modelling andSimulation, IASTED. Banff, AB, Canada: ACTA Press, July2009, pp. 345–351.

[7] C. H. Sauer, E. A. MacNair, and S. Salza, “A language forextended queuing network models,” IBM Journal of Researchand Development, vol. 24, no. 6, pp. 747–755, 1980.

[8] A. Musovic, R. Fischer, U. Nageldinger, K. J. Buchenrieder,and A. Lehmann, “An EQN* based approach for high-levelperformance and power estimation,” in Conceptual Modelingand Simulation Conference 2005 (CMS). 2nd InternationalMediterranean Modeling Multiconference (I3M), Marseilles,France, October 2005, pp. 193–198.

[9] A. W. Liehr and K. J. Buchenrieder, “Generation of relatedperformance simulation models at an early stage in thedesign cycle,” in 14th IEEE International Conference on theEngeneering of Computer-Based Systems (ECBS). Tucson,AZ, USA: IEEE Computer Society, March 2007, pp. 7–14.

[10] FlexRay Communications System Protocol Specification,2nd ed., FlexRay Consortium, 2004-2005.

[11] A. W. Liehr and K. J. Buchenrieder, “An XML-based simula-tion method for extended queuing networks,” in 22nd Euro-pean Conference on Modelling and Simulation, L. S. Louca,Ed. Nicosia, Cyprus: European Council for Modelling andSimulation, June 2008, pp. 322–328.

198