Parallelisation & Intelligence
Ontologies for model reuse.


In simulation we build models of the world. In the keynote speech of the European Simulation Multiconference 2001 [Meersman 2001, Vangheluwe 2001] the need  for reuse of models is expressed. Ontologies promise an adequate technology for this: This project will investigate the benefits of introducing ontologies in the field of discrete event simulation (DES), as developed at the PADX lab (, in cooperation with StarLab (

Discrete Event Simulation (DES)

Discrete Event Simulation keywords: processes, behaviour, events, topology, simulation algorithm [see website for an introduction to DES:]
The DES environment of the PADX lab is written in C++.
Models developed: street [Aerts], telecommunication network, telecommunication component [Geudens: Router], internet [Wang], logical circuits [Maman], fpga's [Bousis].

An ontology can be developed for the 5 main parts of DES:

  1. Simulation Terminology
  2. Events
  3. Processes
  4. Process behaviour
  5. Topology
  6. The modeling process
Reuse of simulation algorithms is another challenge, but I think it goes beyond the scope of ontologies...


The ontology approach

More ontology things (but their use is not clear to me)

Benefits of using ontologies...

More possible benefits, but less clear: cooperation with other research labs?? this to test the reuse & exchange of models
experiments on ontologies in a realistic environment

Applying the ontology approach

1. Simulation terminology

  => ORM, see Appendix 1
  => terminology will be used in implementation!!

check different formalisms, in other research labs

2.  Events

3. Process Classification

4. Process behaviour

See Appendix 4 for the behaviour description of the demux processes.
the ultimate goal of reuse is the possibility to write the behaviour of processes in a 'language' that can be 'understood' by any simulation environment:

5. Topology description

The topology of a model consists of processes that are connected by channels. Each process is an instance of a certain process type (eg mux, demux, ...).

6. The modeling process

When modeling a new system, the modeler creates new event types and new processes. The approriate ontology-way of doing this, is by integrating it in the existing ontology-database: => define the standard approach for the modeling process.

Starlabs interpretation layer could here be seen as the model of the system .. [dixit Mustafa Jarrar].


Appendix 1: ORM of DES concepts

Appendix 2: Event classification

When creating the event classification tree, we see that we have basic subtypes describing the basic properties of events. Events will (multiple) inherit from these.

Appendix 3: Demultiplexer ("demux") taxonomy

A demultiplexer is a process with one input and N outputs of the same type, it is the opposite process of a multiplexer where N inputs go to 1 output.

The behaviour of a demux should tell what happens with an incoming event. There a an infinite number of possibilities, here are some of the most commonly used:

 We can build a classification tree (taxonomy) for this:

Appendix 4: Demux Process Behaviour

subtype of demultiplexer configuration state behaviour
broadcast - nbr-of-outputchannels
- delay
none when an event enters
  add delay to event.timestamp
  event.outputchannel = 0
  for i = 1 to (nbr-of-outputchannels - 1)
    new_event = copy(event)
    new_event.outputchannel = i
  only accepts route-events
- nbr-of-outputchannels
- delay
- routing table: mapping of all destinations to the corresponding outputchannel
none when an route-event enters
  add delay to route-event.timestamp
  lookup the corresponding outputchannel for route-event.destination 
  -> set route-event.outputchannel
random output - nbr-of-outputchannels
- delay
none when an event enters
  add delay to event.timestamp
  event.outputchannel = random between 0 and (nbr-of-outputchannels - 1)
alternating output - nbr-of-outputchannels
- delay
- last- outputchannel when an event enters
  add delay to event.timestamp
  add 1 to last-outputchannel
  if last-outputchannel=nbr-of-outputchannels then
    last-outputchannel = 0
  event.outputchannel = last-outputchannel


Appendix 5a: Topology description

When creating a topology, we instantiate processes and connect them by channels. Each process can have several channel inputs and/or outputs, so we number them. The Entity-Relationship Diagram of the topology looks like this:

Appendix 5b: Parametrized topology

Topologies of a model can be parametrized, as in the following example, where the outputs of the demux and the number of sinks is a parameter (n):
The topology description will look like this:

    get topology parameter n
    create source
    connect source outputchannel to source inputchannel
    create demux
    connect source to demux
    for i = 0 to n
        create sink
        connect demux outputchannel i to sink
    end for

Is such a parametrized description possible in XML?

Appendix 5c: Superprocesses

The client superprocess consists of a source, which sends events, and a sink, which receives the answers:
Once created, a superprocess can be used like any other process.