---

From ODEM to ODEMx

In this chapter we describe differences between ODEMx and its predecessor ODEM and features they have in common.

1. Overview
2. New features
3. Lost features
4. Changes

Overview

The following table lists all classes from ODEM and ODEMx and their status in ODEMx. This Table is not supposed to be a documentation for ODEMx.

Class	Status	Description	Comment
Accum	changed	Statistics	Statistics
Bin	changed	Ressource-like synchronisation	Synchronisation
BinObserver	new	Observer	Observation
Buff_head	lost	Buffered communication	not transferred to ODEMx
Buff_tab	lost	Buffered communication	not transferred to ODEMx
Buff_tail	lost	Buffered communication	not transferred to ODEMx
Condq	changed	Condition queue	Synchronisation
CondqObserver	new	Observer	Observation
Continuous	changed	Time-continuous process	Continuous
ContinuousObserver	new	Observer	Observation
ContuTrace	new	Trace for Continuous	Continuous
Coroutine	new	Portable coroutine implementation	Coroutines
CoroutineContext	new	Portable coroutine implementation	Coroutines
CoroutineContextObserver	new	Observer	Observation
CoroutineObserver	new	Observer	Observation
Count	changed	Statistic	Statistics
DebugTrace	lost	Text-logfile	replaced by HtmlTrace
DefaultContext	new	Portable coroutine implementation	Coroutines
DefaultOrder	new	Process sorting scheme	Process queue
DefaultSimulation	new	Default implementation of Simulation	Encapsulation
DefaultTimeIO	lost	Time to string to time	not transferred
DefLabeledObject	new	Object labels	Object labels
Discrete	lost	Time-discrete process	replaced by Process
Dist	changed	Random number generator	Random
DistContext	new	Random number generator	Random
Draw	changed	Random number generator	Random
dynTableDefinition	new	Report	Report
Elem	lost	ODEM-internal	not transferred
Empirical	lost	Random number generator	not transferred
Entity	lost	ODEM-internal	not transferred
Entry	lost	ODEM-internal	not transferred
Erlang	changed	Random number generator	Random
Event	lost	ODEM-internal	not transferred
ExecutionList	new	Process scheduling	Process
ExecutionListObserver	new	Observer	Observation
File_list	lost	ODEM-internal	not transferred
FormatedTimeInput	lost	String to time	not transferred
FormatedTimeOutput	lost	Time to string	not transferred
Graph	lost	ODEM trace for Continuous	not transferred
Head	lost	ODEM-internal	not transferred
Histo	changed	Statistic	Statistics
HtmlReport	new	Report	Report
HtmlTrace	new	Trace	Trace
Iconst	changed	Random number generator	Random
Idist	changed	Random number generator	Random
LabeledObject	new	Object labels	Object labels
LabelScope	new	Unique object labels	label1
Link	lost	ODEM-internal	not transferred
MarkType	new	Trace	Trace
Memo	lost	ODEM object linking	replaced by Observation
Msg	lost	Buffered communication	not transferred
Negexp	changed	Random number generator	Random
Normal	changed	Random number generator	Random
NoQueue	lost	ODEM-internal	not transferred
NoTally	lost	ODEM-internal	not transferred
Observable	new	Observation of individual objects	Observation
Object_names	lost	Object labels	replaced by LabeledObject
Odem	lost	ODEM-internal	not transferred
Poisson	changed	Random number generator	Random
Port	lost	Port synchronisation	not transferred
Port_head	lost	Port synchronisation	not transferred
Port_tail	lost	Port synchronisation	not transferred
PriorityOrder	new	Process sorting scheme	Process queue
Process	changed	Process	Process
Process_clock	lost	Time event	not transferred
ProcessObserver	new	Observer	Observation
ProcessOrder	new	Process sorting scheme	Process queue
ProcessQueue	new	Process list	Process queue
Queue	changed	Process synchronisation queue	Synchronisation
Randint	changed	Random number generator	Random
Rconst	changed	Random number generator	Random
Rdist	changed	Random number generator	Random
Regress	changed	Statistics	Statistics
Report	new	Report	Report
ReportProducer	new	Report	Report
Reportq	changed	Report	replaced by Report
Res	changed	Ressource-like synchronisation	Synchronisation
ResObserver	new	Observer	Observation
Resource	lost	Ressource-like synchronisation	not transferred
Sched	lost	Scheduling	replaced by ExecutionList
ShortGermanTF1	lost	Time to string	not transferred
Simulation	new	Simulation	Encapsulation
SimulationObserver	new	Observer	Observation
Stackdir	lost	ODEM-internal	not transferred
Starter	lost	ODEM-internal	not transferred
StatisticManager	new	Statistic	Statistics
StatisticObject	new	Statistic	Statistics
Sum	changed	Statistic	Statistics
Tab	changed	Statistic	Statistics
Table	new	Report data table	Report
TableDefinition	new	Report table structure	Report
Tag	new	Trace	Trace
Tally	changed	Statistic	Statistics
Timer	lost	Time events	not transferred
Trace	changed	Trace	Trace
TraceClient	lost	Trace	replaced by TraceConsumer
TraceConsumer	new	Trace	Trace
TraceFilter	new	Trace	Trace
TraceProducer	new	Trace	Trace
TraceServer	lost	Trace	replaced by Trace
TypedObject	new	C++ RTTI	Interface to standard C++ RTTI
Unifrom	changed	Random number generator	Random
utTableDef	new	Report	Report
Version	new	ODEMx version information	no comment
Wait	new	Synchronization with child-processes	Synchronisation
Waitq	changed	Master-Slave synchronisation	Synchronisation
WaitqObserver	new	Observer	Observation

New features

Observation

ODEMx introduces a system for observing individual objects. Observable objects provide an interface with call-back-functions for the events of that object. Observers implement this interface to handle selected events. An observable object inherits an observer management from the template class Observable. Observable objects also have an optional constructor parameter, which allows to register an initial observer.

Documentation:

• odemx::Observable
• odemx::ProcessObserver

Encapsulation

In contrast to ODEM, ODEMx does encapsulate simulations. While in ODEM the main program is always made a part of the simulation, ODEMx separates the simulation from its environment. Simulation specific data and services are put into the class Simulation instead of being placed in the global scope. For many objects of ODEMx this requires a link to the Simulation class, which is in general handed over during construction.
The separation is often realised by the introduction of context-objects. Simulation for instance is the context-object for processes. Due to multiple inheritance Simulation also serves as a context-object for other types of objects, like random number generators, labelled objects and trace producers.
The advantage of the encapsulation is that a simulation can be programmed as an independent component without side-effects on its environment. It is for instance possible to run a simulation in a simulation.

Documentation:

• odemx::Simulation
• odemx::Process

Coroutines

ODEMx separates the implementation of coroutines from the implementation of processes for process-simulation. ODEM on the other hand implements the coroutine functionality inside its process implementation. The coroutine implementation of ODEMx is apart from a few concepts in the Utilities module independent from the rest of ODEMx. It is designed to be portable and already ported to Windows higher than Windows 95 (x86 architecture) as well as Unix and Linux (Sparc, and x86 architecture). Though in some compiler-os-platform configurations there could be problems.
The techniques used to realise coroutines are based on ODEM which in turn has used previous works from HANSEN and others. ODEMx however introduces the encapsulation of coroutines in separate contexts.

Process queue

While in ODEM processes are itself designed to be part of a linked list, ODEMx uses STL containers to manage object collections. ProcessQueue is introduced in ODEMx to manage such collections. ProcessQueue allows different sorting schemes like considering the priority or the execution time of a process. Derived from ProcessQueue is the class Queue designed for synchronisation objects like Res, Bin, and Waitq.

Lost features

Memo

In ODEM many classes include the functionality to be part of a linked list. The Memo concept of ODEM uses this property to provide a synchronisation technique. A Process object can wait in a Memo object until the Memo object is alerted or becomes 'available'. From Memo derived classes can override a function to redefine the 'available' condition. Process from ODEM for instance is also a Memo object which redefines 'available'. A Process in ODEM is 'available' if it is terminated.
ODEMx does not include the Memo feature. But it is possible to realise Memo-like synchronisation with the Observation feature. The ODEMx class Wait in the module Synchronisation is an example for this.

Port

In the HU-Release of ODEMx there is no concept for a buffered process-communication. A user will have to develop its own classes for this purpose. ODEM had such a concept in its Port mechanism.

Time translation

In the later versions of ODEM a simtime to string to simtime translation was introduced to allow human readable time strings other than simple floating point numbers. This feature was introduced for a special application of ODEM. ODEMx has not yet such a feature, but is likely to get it in a future version.

OpenGL visualisation

ODEM had an experimental 3D visualisation of simulation events. Experiences from this 3D-project had lead to changes in the trace-mechanism which finally concluded the current Trace concept of ODEMx. A visualisation might be available in ODEMx in a future version. But the old 3D-Trace of ODEM is not transferable without a redesign.

Continuous Graph

ODEM provides the class Graph which logs Continuous state changes in a text format used by external visualisation tools. A similar tool is already present in ODEMx (odemx::ContuTrace). But at the moment there is no component in ODEMx that generates output in the exact text-format like Graph.

Buffer

Like the missing Port mechanism the simplified Buffer system is not transferred to ODEMx.

Empirical

Empirical from ODEM is not available in ODEMx.

Changes

Synchronisation

ODEMx provides the following synchronisation components: odemx::Res, odemx::Bin, odemx::Waitq, odemx::Condq and odemx::Wait. The first four components are transferred from ODEM but are changed. Res and Bin for instance are not derived from a common base class Resource. The constructors of both classes have additional parameters compared to Res and Bin from ODEM which reflect the Encapsulation and the Observation feature. Both classes have more get* methods to receive information about the statistic. Both classes have a report function according to the Report changes. The basic synchronisation functions however are not changed.
Similar things can be said about Waitq and Condq. The general meaning has not changed while the classes have been adjusted to reflect the ODEMx features. In Waitq and Condq however, small changes have been applied to the classic synchronisation functions as well.

Documentation:

• odemx::Res
• odemx::Bin
• odemx::Waitq
• odemx::Condq

Statistics

Many of the statistic components from ODEM have been transferred to ODEMx. The components in ODEMx share the update() function with their predecessors as well as the used algorithms. They were also changed to match the Encapsulation and the Report feature. Furthermore, several get* methods for the statistical data were added.

Documentation:

• odemx::Accum
• odemx::Count
• odemx::Histo
• odemx::Regress
• odemx::Sum
• odemx::Tally

Random

The random number generators in ODEMx were taken from ODEM and changed to match the features of ODEMx. They have additional get* methods for statistical information, and require a pointer to a DistContext object during construction. They also provide a report function for the report feature of ODEMx.
The DistContext class was introduced to support the Encapsulation feature. All random number generators linked to one DistContext are independent from each other, while the RNGs in different DistContext produce the same sequence of numbers (unless the seed is changed).

Documentation:

• odemx::Accum
• odemx::Count
• odemx::Histo
• odemx::Regress
• odemx::Sum
• odemx::Tally

Process

The Process class of ODEMx replaces the Process class and the Discrete class of ODEM. Its interface is more like the interface of Discrete than of Process. The following table matches the different scheduling functions of Discrete to the functions of ODEMx Process:

Discrete	odemx::Process
start(NOW)	hold()
start(AT, t)	holdUntil(t)
start(AT, t, PRIOR)	activateAt(t)
start(DELAY, t)	holdFor(t)
start(DELAY, t, PRIOR)	activateIn(t)
activate(NOW)	hold() or activate() (FIFO or LIFO)
activate(AT, t)	holdUntil(t)
activate(AT, t, PRIOR)	activateAt(t)
activate(DELAY, t)	holdFor(t)
activate(DELAY, t, PRIOR)	activateIn(t)
activate(BEFORE, q)	activateBefore(q)
activate(AFTER, q)	activateAfter(q)
hold(t)	holdFor(t)
passivate()	sleep()
e_interrupt()	interrupt() (!see documentation!)
cancel()	cancel()

ODEMx Process has only one priority attribute which is used in scheduling as well as in synchronisation queues. The interrupt function in ODEMx has a different effect than the e_interrupt of Discrete. In ODEMx an interrupt causes an immediate activation (activate). The interrupted process is responsible to handle the interrupt.

Documentation:

• odemx::Process

Continuous

The Continuous class of ODEMx is derived from Process. The algorithm used to compute the state changes is taken from ODEM. Some of the Continuous functions in ODEM are also transferred to ODEMx. Other than the ODEM version of Continuous, the ODEMx version does not log the state changes on its own. If a user wants this service he/she has to use the ODEMx class ContuTrace.

Documentation:

• odemx::Continuous
• odemx::ContuTrace

Object labels

The support of object labels has changed in ODEMx. It is now provided by the classes odemx::LabeledObject, odemx::LabelScope and odemx::DefLabeledObject. In contrast to ODEM labels are no longer unique to the program but to a certain LabelScope. Each simulation has of course its own scope.

Documentation:

• odemx::LabeledObject
• odemx::LabelScope
• odemx::DefLabeledObject

Trace

ODEMx introduces the class HtmlTrace. Objects of this class generate Html output from simulation events. HtmlTrace also provides a simple filter for events to reduce the generated output. The trace control is implemented in the ODEMx Trace class which is a base class of Simulation.

Documentation:

• odemx::HtmlTrace

Report

ODEMx supports several reports in one simulation. A report is generated by an object of the HtmlReport class. In contrast to ODEM a user has to register model components to the report. The final report is triggered manually by the function call 'generateReport()'.

Documentation:

• odemx::HtmlReport

---