DD CEN/TS 16157 — Intelligent Transport Systems DATEX II Data Exchange Specifications (Parts 1-3: Context, Location Referencing, Situation Publication)

🚦 DD CEN/TS 16157 (corresponding to the CEN/TS 16157 series) is the UK implementation of the DATEX II data exchange specifications in the European Intelligent Transport Systems (ITS) field, supporting data exchange for traffic management and traffic information services. DATEX II is founded on a single UML model made available in a usable form to all, supporting standardised data interoperability between different countries and systems. The series is the responsibility of BSI Technical Committee EPL/278 (Road transport informatics) and supersedes the experimental standards ENV 13106 and ENV 13777 published around 2000 (withdrawn in 2007).

💡 DATEX II has become a de facto standard for European traffic-management information exchange: through a unified UML model and a layered publication structure, traffic centres, roadside devices, and service providers can exchange and interpret consistent traffic data, reducing the “data silos” created by proprietary formats.

1. Series Structure 📌

Part	Corresponding CEN/TS	Title	Subject
DD CEN/TS 16157-1:2011	CEN/TS 16157-1:2011	Part 1: Context and framework	Overall architecture, model, and framework conventions
DD CEN/TS 16157-2:2011	CEN/TS 16157-2:2011	Part 2: Location referencing	Location referencing methods for events and data
DD CEN/TS 16157-3:2011	CEN/TS 16157-3:2011	Part 3: Situation Publication	Publication structure for traffic event/situation information

All three parts were published in 2011, superseding the withdrawn ENV 13106:2000 and ENV 13777:2000. Later parts extend to variable message signs (VMS), measured data publication, and parking information (see the PD CEN/TS 16157 series); this article focuses on the first three parts.

2. Context and Framework (Part 1) 🏗️

Part 1 defines the overall context and framework of the DATEX II data exchange specifications, including:

Exchange scenarios and stakeholders (traffic management centres, information providers, road operators, etc.);
Organisation of the unified UML model and its use in data exchange;
General conventions for messaging, sessions, and exchange, providing the basis for the models in subsequent parts.

⚠️ Correct use of DATEX II depends on a complete understanding of the framework model. Implementers should not implement fragments of a single part (e.g. “situation publication”) in isolation but should align with the context conventions of Part 1, otherwise interoperability deviations may arise.

3. Location Referencing (Part 2) 📍

Part 2 specifies the method of location referencing in traffic information — a precondition for usable traffic data: without a stable location expression, events and data cannot be located or routed. Key points include:

Location entities and their attributes in the road network;
Encoding and exchange of location references, ensuring sender and receiver interpret the same location consistently;
Interface with geographic positions (e.g. WGS-84 coordinates) and other reference systems.

4. Situation Publication (Part 3) 🚧

Part 3 specifies the publication structure for situation information, used to describe events, measures, and conditions affecting traffic. Typical content:

Classification and description fields of traffic events (accidents, works, weather impacts, etc.);
Modelling of severity, duration, and impact extent;
Lifecycle management of publication and update, so consumers always receive current, consistent situation information.

✅ With a unified framework and location referencing, the situation publication model allows event information from different sources (police, road operators, maintenance agencies) to be merged into a consistent traffic-management view, supporting route guidance and information services.

5. Engineering Practice Essentials 🛠️

🔍 Interoperability design: when implementing a DATEX II interface, generate the data model from the unified UML model rather than defining proprietary messages by hand.
🔧 Location consistency: use standard location referencing when publishing location and verify with map providers/navigation services that the location encoding is interpreted consistently.
📊 Publication lifecycle: manage the create/update/end (cancel) lifecycle of situations, clearing stale events promptly to avoid outdated, misleading information.
📋 Version tracking: CEN/TS is provisional and regularly reviewed; track progress towards conversion to an EN and the release of new parts (VMS, parking, etc.).

6. Frequently Asked Questions ❓

❓ Q: What is the difference between DATEX II and an ordinary XML interface?
A: DATEX II not only defines message syntax but also provides a unified UML model, location referencing, and publication lifecycle conventions, ensuring cross-system semantic consistency; ordinary XML interfaces often only agree at the message-field level, allowing interpretation errors.

❓ Q: Why does location referencing matter so much?
A: Traffic information must be locatable accurately by consumers (navigation, guidance, management). Unified location referencing ensures “what you point at” and “what I read” are the same location — a precondition for usable data.

❓ Q: How is Part 3 “situation publication” different from an event list?
A: It defines a structured situation model with event classification, impact, duration, and lifecycle management, allowing events from multiple sources to be published, merged, and updated with a consistent structure.

🔍 Q: Must the whole series be implemented at once?
A: It is recommended to build on the Part 1 framework and progressively implement location referencing (Part 2) and specific publication models (Part 3 and later parts) as needed, but not to implement fragments in isolation from the framework conventions.

🔒

正在加载下载地址，请稍候 10 秒