DATEX II model - HTML Documentation - Home

This DATEX documentation has been automatically extracted from the DATEX II UML model (version v2.3) in Enterprise Architect format, and offers a simple way to discover the model and navigate through it. It targets rather technical readers, to help them getting familiar with the model and easily retrieving specific information.
This HTML publication has been generated via Pulsar's tool called MyModelMapper, able to read and "understand" UML and entity-association relationship models, and generate code around it (documentation in various format such as HTML, Word, or XAR for import in a wiki, but also any output related to the model structure, such as SQL queries or source code).

Thru some specific adaptations, MyModelMapper allows supporting various transformation tasks starting from a data model, and obtaining various results after transformation, and can be included in various architectures automatizing operations around data models, as well as in bigger projects as a module connecting in input and output to other modules of a chain dealing with data models and structures.

For instance, as an example of specific output from MyModelMapper, the advantages of our HTML publication against the one provided by Enterprise Architect, are the reorganization of sections in a more readable format, the extraction of definitions at a higher level, the additional information (such as cardinalities), the search function and the full compatibility with all browsers. We were thus able to drive MyModelMapper to generate as output a specific HTML5 format, including specific JS code to realize specific views and allow specific operations like the search.

General Presentation

The DATEX model aims at supporting information exchange between actors of road traffic management, covering the following areas:

  • Information exchange protocol,
  • Location referencing,
  • Situation description,
  • Variable messages display
  • Measured and calculated data,
  • Parking information.

The DATEX interoperability policy foresee 3 levels:

  • Level A is the agreed data model.
  • Level B is the set of extensions applied to level A. These extensions are optional. Parking information is treated at this level.
  • Level C is the set of possible new modules with no necessary link to level A.

The present documentation covers level A and approved extensions that are delivered within the same Enterprise Architect project.

Tagged Values

Some modelling information are entered into Enterprise Architect using Tagged Values. The most important ones are the definitions and the order. The definitions displayed on the present documentation site are extracted from there. The order information is used in particular to specify a fixed order for the attributes of a class, which may prove essential in 1-to-1 relations that could be relying on this order.

Packages Presentation

The model is organized into the following packages:

♦ The Exchange package contains protocol-relevant information. In the future, it might be moved to a specific separate model.

♦ The Extension package is for level B extensions. The developer is free to remove unwanted delivered extensions ant to create new ones.

♦ The General package contains

o   data types,

o   georeferences, locations, groups of locations (ordered or not),

o   enumerations (divided into alphabetical groups),

o   reusable classes.

♦ The Management package is very small and allows managing the life cycle of other data.

♦ The PayloadPublication and PayloadEnumerations packages are subdivided depending on the kind of messages we want to publish. This is the entry point to discover the possibilities covered by DATEX.

►  GenericPublication just contains an empty class that can be specialized by extensions.

►  ElaboratedDataPublication includes all data computed by algorithms and not directly recorded. Journey time data is included.

►  MeasuredDataPublication are for measured data by opposition to elaborated data. It holds containers for dynamic information that refers to the static information of MeasurementSiteTablePublication.

►  MeasurementSiteTablePublication may be seen as measurement boxes located along the roads.

►  PredefinedLocationsPublication allows defining locations just once for further reference.

►  SituationPublication is used to describe situations, with detailed information such as location, cause, impact.

In this package, the SituationRecord class is the basis class for the following inheriting classes:

NonRoadEventInformation, representing an event which is not on the road, but which may influence the behavior of drivers and hence the characteristics of the traffic flow;

TrafficElement, representing an event which is not planned by the traffic operator, which is affecting, or has the potential to affect traffic flow; it can be further defined as an Accident, Obstruction or other, including specific driving Conditions related to weather;

OperatorAction, representing an action that a traffic operator can decide to implement to prevent or help correct dangerous or poor driving conditions, including maintenance of the road infrastructure.

►  TrafficViewPublication gives a particular view on a section of the network.

►  VmsPublication and VmsTablePublication are dealing with messages (textual messages or pictograms) displayed on variable messages signs (VMS). This publication is used to periodically send messages elaborated by a Traffic Control Centre.

The PayloadPublication class is the basis class for all other publication classes, which take the same name as their package:


Georeferences can be expressed based on:

  • coordinates,
  • references,
  • geometry based on ISO 1948 definitions,
  • pre-defined ALERT-C location tables,
  • TPEG-LOC structures,
  • OpenLR extension.


Some metadata are also parts of the DATEX model:

-    Validity period of the information (from Reusable Classes);

-    Life cycle operations (like cancellation) from Management package.

Static vs Dynamic messages

Static data do not change often and can simply be shared on files without developing complex implementation. Dynamic information are exchanged regularly and they can make references to Static data. However it is not possible to set an aggregation relationship between elements from separate messages like static and dynamic data. In that case the following method applies:

1.    Elements of the static model can get a stereotype "identifiable" or "versionIdentifiable" so they become objects that we can reference as datatypes in the dynamic model.


2.   To make that link, elements of the dynamic model must use the datatype "VersionedReference".


3.   In XML, the link will be made via a unique identifier.



Further Reference

All detailed information on DATEX, including news, forum, full documentation and the model itself on various format are available on Please, try the free registration to access all menu items.