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.
The DATEX model aims at supporting information exchange between actors of road traffic management, covering the following areas:
The DATEX interoperability policy foresee 3 levels:
The present documentation covers level A and approved extensions that are delivered within the same Enterprise Architect project.
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.
The model is organized into the following packages:
♦ Thepackage contains protocol-relevant information. In the future, it might be moved to a specific separate model.
♦ Thepackage is for level B extensions. The developer is free to remove unwanted delivered extensions ant to create new ones.
♦ Thepackage 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 This is the entry point to discover the possibilities covered by DATEX.and packages are subdivided depending on the kind of messages we want to publish.
► just contains an empty class that can be specialized by extensions.
► includes all data computed by algorithms and not directly recorded. Journey time data is included.
► are for measured data by opposition to elaborated data. It holds containers for dynamic information that refers to the static information of MeasurementSiteTablePublication.
► may be seen as measurement boxes located along the roads.
► allows defining locations just once for further reference.
► is used to describe situations, with detailed information such as location, cause, impact.
In this package, the class is the basis class for the following inheriting classes:
♦, 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;
♦ or other, including specific driving related to weather;, 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 ,
♦, 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.
► gives a particular view on a section of the network.
► and 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.
Theclass is the basis class for all other publication classes, which take the same name as their package:
Georeferences can be expressed based on:
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 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.
All detailed information on DATEX, including news, forum, full documentation and the model itself on various format are available on www.datex2.eu. Please, try the free registration to access all menu items.