EUROPEAN PRESTANDARD
ENV 13777
PRÉNORME EUROPÉENNE EUROPÄISCHE VORNORM
May 2000
ICS 35.240.60
English version
Road transport and traffic telematics - DATEX specifications for data exchange between trafic and travel information centres (version 1.2a) Télématique de la circulation et du transport routier Spécifications DATEX pour l'échange des données entre les centres d'information routière (version 1.2a)
Telematik für den Strassenverkehr und -Transport - DATEX Spezifikation für den Datenaustausch zwischen Verkerhs und Reiseinformationszentralen (Version 1.2a)
This European Prestandard (ENV) was approved by CEN on 5 May 2000 as a prospective standard for provisional application. The period of validity of this ENV is limited initially to three years. After two years the members of CEN will be requested to submit their comments, particularly on the question whether the ENV can be converted into a European Standard. CEN members are required to announce the existence of this ENV in the same way as for an EN and to make the ENV available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the ENV) until the final decision about the possible conversion of the ENV into an EN is reached. CEN members are the national standards bodies of Austria, Belgium, Czech Republic, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Italy, Luxembourg, Netherlands, Norway, Portugal, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
Central Secretariat: rue de Stassart, 36
© 2000 CEN
All rights of exploitation in any form and by any means reserved worldwide for CEN national Members.
B-1050 Brussels
Ref. No. ENV 13777:2000 E
Page 2 ENV 13777:2000
Contents 1.
FOREWORD [INFORMATIVE]
8
2.
INTRODUCTION [INFORMATIVE]
8
3.
SCOPE [NORMATIVE]
8
4.
NORMATIVE REFERENCES
8
5.
GENERAL ARCHITECTURE
9
5.1
Overview [informative]
5.2
Levels of Operation [normative]
6.
SITUATION DATA
9 10
10
6.1
Definitions [normative]
10
6.2
Situation data [normative]
11
6.3 Location referencing methods [normative] 6.3.1 Pre-defined primary location + extent 6.3.2 Pre-defined primary and secondary locations 6.3.3 Primary and secondary locations using pre-defined locations + extent + distances 6.3.4 Primary and secondary locations using pre-defined locations + distances 6.3.5 Application of location referencing methods to the Element Location
13 13 13 13 13 14
6.4 Situation Element message [informative] 6.4.1 Message Content and Structure
14 14
6.5
21
7.
Physical Format [informative]
TRAFFIC DATA
22
7.1
Definitions [normative]
22
7.2
Exchange description [informative]
23
7.3
Measurement point table [normative]
24
7.4
Traffic Data message [informative]
24
7.5
Physical format [informative]
25
7.6
Traffic data model [informative]
25
8. 8.1
COMMON FUNCTIONS Introduction [informative]
8.2 Supplier and Client: Interchange agreement [informative] 8.2.1 Main choices available
26 26 26 30
Page 3 ENV 13777:2000 8.3 Supplier and Client: Establish code lists 8.3.1 Data objects, phrases, attributes, supplementary information 8.3.2 Location code
30 31 31
8.4 Supplier and Client: Handle location table 8.4.1 General description 8.4.2 Physical format [informative] 8.4.3 Exchange description 8.4.3.1 Client: Request for location table 8.4.3.2 Supplier: Send location table 8.4.3.3 Client: Receive location table
31 31 32 32 32 33 33
8.5 Supplier and Client: Handle measurement point table 8.5.1 General description 8.5.2 Physical format 8.5.3 Exchange description 8.5.3.1 Client: Request for measurement point table 8.5.3.2 Supplier: Send measurement point table 8.5.3.3 Client: Receive measurement point table
33 33 34 34 34 35 36
8.6 Situation and element information management 8.6.1 Introduction [normative] 8.6.2 End Situation [normative] 8.6.3 Updating Methods [normative] All Situation element Updating 8.6.4 Example [informative]
36 36 39 39 39 39
8.7 Filtering general specification 8.7.1 Introduction [normative] 8.7.2 “Out of Range”, “Filter End” and “Delivery Break” Indicators [normative] 8.7.3 Historical, Active and Future information [informative] 8.7.4 Filter Definition [informative] 8.7.4.1 Introduction 8.7.4.2 Filter conceptual data model 8.7.4.3 Data Delivery Modes description 8.7.4.4 Filter Expression Description 8.7.5 Filter Message [informative] 8.7.6 Filter Status Message [informative] 8.7.7 Filter fax form example [informative]
44 44 46 48 49 49 50 51 51 53 53 54
8.8
Supplier: Send data
55
8.9
Client: Receive data
55
8.10 Supplier and Client: Diversion 8.10.1 Introduction 8.10.2 Agreement Process 8.10.3 Messages exchange 8.10.4 Functional description of Traffic/Travel Responsibilities Agreement Process 8.10.4.1 Introduction 8.10.4.2 Client 8.10.4.3 Supplier 8.10.5 Proposal for alternative route 8.10.6 Physical format
55 55 56 57 58 58 58 59 61 62
8.11
62
Client and Supplier: Handle status messages
9.
COMMUNICATIONS
63
9.1
Protocols [informative]
63
Page 4 ENV 13777:2000 9.2
Networks [normative]
10. LEVEL 1 DESCRIPTION
63
63
10.1
Introduction [informative]
63
10.2
Functions list [normative]
64
10.3 Client Sub-system 10.3.1 Internal functions 10.3.1.1 Produce Data Filter [informative] 10.3.2 Off-line functions 10.3.2.1 Send Data Filter Request [informative] 10.3.2.2 Receive Data Filter Request Status [informative] 10.3.3 Interoperability with Suppliers at Level 2 and 3 [informative]
65 65 65 65 65 66 66
10.4 Supplier Sub-system 10.4.1 Off-line functions 10.4.1.1 Receive Data Filter Request [informative] 10.4.1.2 Send Data Filter Request Status [informative] 10.4.2 Internal functions 10.4.2.1 Process Data Filter Request [informative] 10.4.2.2 Activate Filter [informative] 10.4.2.3 Deactivate Filter [informative] 10.4.2.4 Perform One Shot filtering [informative] 10.4.2.5 Perform On Occurrence filtering [informative] 10.4.2.6 Perform periodic filtering [informative] 10.4.3 Interoperability with Clients at Level 2 and 3 [informative]
66 66 66 67 67 67 68 68 69 69 69 70
11. LEVEL 2 DESCRIPTION
70
11.1
Introduction [informative]
70
11.2
Functions list [normative]
71
11.3 Client Sub-system 11.3.1 On-line functions 11.3.1.1 Send Data Filter Request 11.3.1.2 Receive Data Filter Request Status 11.3.2 Interoperability with Suppliers at Level 1 and 3 [informative]
72 72 72 73 73
11.4 Supplier Sub-system 11.4.1 On-line functions 11.4.1.1 Receive Data Filter Request 11.4.1.2 Send Data Filter Request Status 11.4.2 Interoperability with Clients at Level 1 and 3 [informative]
73 73 73 73 74
12. LEVEL 3 DESCRIPTION
75
12.1
Introduction [informative]
75
12.2
Functions list [normative]
76
12.3 Client sub-system 12.3.1 On-line functions 12.3.1.1 Request for catalogue 12.3.1.2 Receive catalogue 12.3.1.3 Send data order 12.3.1.4 Receive data order status 12.3.2 Interoperability with Suppliers at Level 1 and 2 [informative]
77 77 77 77 78 80 81
Page 5 ENV 13777:2000 12.3.3
Client data model
12.4 Supplier sub-system 12.4.1 On-line functions 12.4.1.1 Send catalogue 12.4.1.2 Process data order 12.4.1.3 Perform data order 12.4.2 Interoperability with Clients at Level 1 and 2 [informative] Solution 1: the Client creates manually the data order 12.4.3 Supplier data model
13. MESSAGE FORMATS
81 84 84 84 85 86 88 88 88
90
13.1 13.1.1 13.1.2 13.1.3
Background Information References [informative] Terms and Definitions [informative] Data Segment Clarification [informative]
90 90 90 92
13.2 13.2.1 13.2.2 13.2.3
EDIFACT Interchanges Data Segment Clarification [normative] Segment table [normative] Data Segment Index (Alphabetic Sequence) [informative]
93 93 94 94
13.3
Methods of Location Referencing [normative]
95
13.4 Traffic/Travel Situation Information Message (TRAVIN) 13.4.1 Scope 13.4.1.1 Functional Definition [normative] 13.4.1.2 Principles [informative] 13.4.2 Message Definition 13.4.2.1 Data Segment Clarification [normative] 13.4.2.2 Message Structure [normative]
98 98 98 98 100 100 117
13.5 Status Information, Traffic/Travel Route Guidance And Planning Message (TRAILS) 13.5.1 Scope 13.5.1.1 Functional Definition [normative] 13.5.1.2 Principles [informative] 13.5.2 Message Definition 13.5.2.1 Data Segment Clarification [normative] 13.5.2.2 Message Structure [normative] 13.5.2.3 Data Segment Index (Alphabetic Sequence) [informative]
119 119 119 119 120 120 139 141
13.6 Traffic/Travel Location Definition Message (TRALOC) 13.6.1 SCOPE 13.6.1.1 Functional Definition 13.6.1.2 Principles 13.6.2 Message Definition 13.6.2.1 Data Segment Clarification [normative] 13.6.2.2 Message Structure [normative] Segment table 13.6.2.3 Data Segment Index (Alphabetic Sequence) [informative]
141 141 141 141 143 143 150 151 151
13.7 Traffic/Travel Information Acknowledgement Message (TRAVAK) 13.7.1 Introduction [informative] 13.7.2 Scope 13.7.2.1 Functional Definition [normative] 13.7.2.2 Principles [informative] 13.7.3 Message Definition 13.7.3.1 Data Segment Clarification [normative] 13.7.3.2 Message Structure [normative] 13.7.3.3 Data Segment Index (Alphabetic Sequence) [informative]
152 152 152 152 152 153 153 160 161
Page 6 ENV 13777:2000 13.8 Traffic/Travel Information Request Message (TRAREQ) 13.8.1 Scope 13.8.1.1 Functional Definition [normative] 13.8.1.2 Principles [informative] 13.8.2 Message Definition 13.8.2.1 Data Segment Clarification [normative] 13.8.2.2 Message Structure [normative] 13.8.2.3 Data Segment Index (Alphabetic Sequence) [informative]
162 162 162 162 165 165 176 178
13.9 Traffic/Travel Information Catalogue Message (TRACAT) 13.9.1 Scope 13.9.1.1 Functional Definition [normative] 13.9.1.2 Principles [informative] 13.9.2 Message Definition 13.9.2.1 Data Segment Clarification [normative] 13.9.2.2 Message Structure [normative] 13.9.2.3 Data Segment Index (Alphabetic Sequence) [informative]
179 179 179 179 179 179 191 194
14. CONCEPTUAL DATA MODELS 14.1
Introduction
195 195
14.2 Situation Conceptual Data Model (Levels 1, 2 and 3) [informative] 195 14.2.1 Attributes 195 14.2.2 Data object 196 14.2.3 Element 196 14.2.4 Element attributes 197 14.2.5 Element decision point 197 14.2.6 Element primary location 198 14.2.7 Element secondary location Error! Bookmark not defined. 14.2.8 Phrase 199 14.2.9 ALERTC location 200 14.2.10 Situation 200 14.3 14.3.1 14.3.2 14.3.3 14.3.4 14.3.5
Conceptual Traffic Data Model (Levels 1, 2 and 3) [informative] Data object Traffic data value Measurement point location ALERT C location Traffic measurement point
201 201 201 202 202 203
14.4 Complete Conceptual Data Model of Client At Level 3 [informative] 14.4.1 Attributes 14.4.2 Catalogue situation 14.4.3 Catalogue traffic 14.4.4 Client order 14.4.5 Client order line 14.4.6 Data object 14.4.7 Element 14.4.8 Element attributes 14.4.9 Element decision point 14.4.10 Element primary location 14.4.11 Element secondary location 14.4.12 Measurement point location 14.4.13 Phrase 14.4.14 ALERT C location 14.4.15 Situation 14.4.16 Supplier 14.4.17 Traffic measurement point
204 204 204 205 206 207 208 209 210 211 212 213 214 215 215 216 217 218
14.5
219
Complete Conceptual Data Model of Supplier At Level 3 [informative]
Page 7 ENV 13777:2000 14.5.1 14.5.2 14.5.3 14.5.4 14.5.5 14.5.6 14.5.7 14.5.8 14.5.9 14.5.10 14.5.11 14.5.12 14.5.13 14.5.14 14.5.15 14.5.16 14.5.17 14.6
Attributes Catalogue situation Catalogue traffic Client Client order Client order line Data object Element Element attributes Element decision point Element primary location Element secondary location Measurement point location Phrase ALERT C location Situation Traffic measurement point Domains [informative]
219 219 220 220 221 222 222 223 223 224 224 225 225 226 227 227 228 229
15. DEFAULT PHRASES PER DATA OBJECT [INFORMATIVE]
230
16. BIBLIOGRAPHY
231
Page 8 ENV 13777:2000
1. Foreword [informative] This European Prestandard has been prepared by Technical Committee CEN/TC 278 "Road transport and traffic telematics", the secretariat of which is held by NNI. This draft, produced from the DATEX-Net specifications is intended to serve the general needs and in particular the data exchange applications as specified by DATEX. According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following countries are bound to announce this European Prestandard: Austria, Belgium, Czech Republic, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Italy, Luxembourg, Netherlands, Norway, Portugal, Spain, Sweden, Switzerland and the United Kingdom.
2. Introduction [informative] Information system applications are increasingly interconnected. A predominant trend towards standardisation has been a major theme throughout DRIVE and its successors, which is found in national projects as well. In December 1996, DATEX has prepared both versions 3.0 of the dictionary and the first version, numbered 1.1, of the Specifications for Interoperability. This package has been put forward to the CEN TC 278 WG8 which in turn sent it in 1997 to stage 32 for informal vote. The resulting comments have been processed by the last DATEX effort, funded by the EC, which has produced this Data Exchange Specifications for Interoperability version 1.2a proposed as a draft prENV to WG8 as well as version 3.1a of the Traffic and Travel Data Dictionary. These Data Exchange Specifications for Interoperability aim to be used as a companion book of the DATEX-Net Data Dictionary also proposed for standardisation in data/information exchange. For this reason this ENV contains common normative elements and specific informative parts.
3. Scope [normative] This standard defines the methodology, functions and message structures for the exchange of data between traffic and travel information centres managed by different road operators. The normative and informative clauses of the draft have been identified but due to the complexity of the document and cross-referencing the normative and information clauses have not been separated.
4. Normative References This European Prestandard incorporates by dated and undated reference, provisions from other publications. These normative references are cited at the appropriate places in the text and publications are listed below. For dated references, subsequent amendments to or revisions of any of these publications apply to this European Prestandard only when incorporated in it by amendment or revision. For undated references the latest edition of the publication referred to applies. PrENV ISO 14819-3
Traffic and traveller Information (TTI) - TTI Messages via traffic message coding - Part 3: Location
Page 9 ENV 13777:2000 Referencing for ALERT C (under preparation, current document CEN/TC 278/N783, October 1997) ENV 13106
DATEX Data Dictionary, version 3.1a
EN ISO 3166-1
Codes for the representation of names of countries and their subdivisions - Part 1: Country codes
ISO 4217
Codes for the representation of currencies and funds
The reference documents are still evolving and have various status. The following versions of this document will be updated to include the modifications of the above reference documents. PrENV ISO 14819-3 indicates how the ALERT C RDS-TMC location referencing system should be used. This is of major importance to DATEX-Net. The draft European Prestandard will shortly be submitted to a Formal Vote. Keeping updated with these developments is important. ENV 13106 is including the CEN/TC 278/WG 8 requirements as in the draft prENV/278/8/1/8 issued in October 1998. CORD Deliverable D0004/Part 6 (see 16) provides methodology guidelines which were used when preparing the conceptual data models of the specifications. It may be used for an easier understanding of the specifications.
5. General architecture 5.1 Overview [informative] DATEX-Net will allow different systems to exchange traffic data between different regions and countries. The peculiarity of DATEX-Net is that each system adopting this solution will be free to implement its own functionalities that may be different from region to region according to the local user requirements. The DATEX-Net system comprises a certain number of Client and Supplier sub-systems. Each sub-system is composed of the following interfaces: 1.
Application Interface;
2.
Operator Interface;
3.
Communication Interface;
4.
Database Interface.
4
Operator
Operator
2
2
Client sub-system
3
3
Supplier sub-system
Database (client)
4 Database (supplier)
1 Application (client)
1 Application (supplier)
Figure 2 - Schematic of general system architecture
Page 10 ENV 13777:2000 This document deals only with communication interface number 3. DATEX-Net specifies the data exchange across this interface, where the actual data are specified in the Data Dictionary version 3.1a. DATEX-Net enables the communication between two or more traffic centres implementing a data exchange system, as depicted in figure 3. In order to achieve interoperability between centres, it is required to agree upon several options and choices which must be fixed in an Interchange Agreement. Clause 8.2 contains a checklist of items to be considered in such an agreement. In the framework of the communication architecture proposed by DATEX, a traffic centre implementing the data exchange system “A”, which includes DATEX-Net, will be able to be interoperable with any different DATEX-Net compatible system (like “B” and “N”); and at the same time it can exchange information with other traffic centres adopting the same protocol as “A”. B1
A1 Z=DATEX
• • • •
An
Z System A
• • • •
Z Z
Z
Z
System B
Bn
+ data base + MMI + application
System N
Figure 3 - General communication architecture
5.2 Levels of Operation [normative] Each system including these specifications has to make its own choices and then has to follow the document according to what has been chosen. The DATEX Task Force has defined three system operating Levels. Implementors can decide at which Level they want to operate, being sure that following the rules explained in this document their choice of Level will be compatible with the others. The identified Levels are: Level 1: delivery; Level 2: request / delivery; Level 3: order on catalogue / delivery. There are interoperability solution given between Levels. They are specified in each of the Level descriptions (10, 11 and 12).
6. Situation data 6.1 Definitions [normative] Traffic/Travel situation: a set of traffic/travel circumstances with a common cause (or causes) which apply to a common set of locations. Traffic/travel situations comprise event and status reports. A situation shall be composed of situation elements.
Page 11 ENV 13777:2000 Situation Element: a traffic/travel circumstance related to one data object, one phrase, and one location. In each DATEX-Net message, only one situation element is sent. Each situation element is uniquely identified by the combination of message sender identification, situation reference and element reference. The situation reference is a unique reference to each sender. The element reference is a unique reference within each situation. For specific definitions refer to ENV 13106 (see 4).
6.2 Situation data [normative] One data model has been built with the following rules: SITUATION: One situation shall have one or several situation elements. SITUATION ELEMENT: One situation element shall have: - one DATA_OBJECT, - one PHRASE, - one location: - If the situation is not related to a diversion, the situation element shall have one ELT_PRIM_LOC (element primary location) and may have one ELT_SEC_LOC (element secondary location), - If the situation is related to a diversion, the situation element shall have one ELT_DEC_PT (element decision point). One situation element shall have one or several ELT_ATTRIBUTES (element attributes). ELT_ATTRIBUTES (element attribute): The element attribute refers to a list of predefined attributes. For entities, attributes and domains details, see ENV 13106 (see 4). Note 1:
This data model has been built to solve interoperability problems (between EUROTRIANGLE, INTERCHANGE, STRADA).
Note 2:
This data model has led to the definition of the “DATEX-Net Situation Message”, which is detailed in 6.4: “Situation Element message”.
Note 3:
In this data model situation elements are updated as the situation evolves in time.
Note 4:
The updating results in a new version of the situation element which may either contain active information or be not active any more.
Note 5:
At a given time a situation is described by collecting information from the last version of all active situation elements related to the situation.
The following diagram represents the DATEX Situation Conceptual Data Model. It has been used the Entity-Relationship method. The Entity-Relationship approach is described in Annex A of document CORD Deliverable D004/Part 6 (see 4).
Page 12 ENV 13777:2000 ATTRIBUTES @att_code att_text
ELT_ATTRIBUTE
@ela_ref ela_value
ELT_DEC_PT dec_rds_direction
DATEX SITUATION CONCEPTUAL DATA MODEL
SITUATION @sit_ref
ELEMENT @ele_ref ele_input_time ele_start_time ele_stop_time
ELT_PRIM_LOC
pri_alertc_code pri_rds_direction pri_distance
ALERTC_LOCATION @alertc_table_ref @alertc_table_version @alertc_location_code alertc_location_type alertc_road_number alertc_road_name alertc_first_name alertc_second_name alertc_A_reference alertc_L_reference alertc_negative_offset alertc_positive_offset alertc_urban_code alertc_intersection_code
Figure 4 - Situation conceptual data model
PHRASE @phr_code phr_text
DATA_OBJECT @dob_code dob_text
ELT_SEC_LOC sec_alertc_code sec_extent sec_distance
Page 13 ENV 13777:2000
6.3 Location referencing methods [normative] Different ALERT C location referencing methods shall be used. These methods are described in prENV ISO 14819-3 (see 4). 6.3.1 Pre-defined primary location + extent This method refers to method 1.2.1 of prENV ISO 14819-3 (see 4). This method uses a predefined primary location which shall be one ALERT C location code (LCO). Optionally an extent (LEX) may be used to indicate the extent of the event and show the secondary location. This is coded as DATEX-Net method 1. In this method, ALERT C direction shall be used to indicate the direction(s) affected. ALERT C direction shall be positive if the extent is negative and, conversly, negative if the extent is positive unless both directions are affected or the direction is unknown. Further details of usage of the UN EDIFACT Location Segment (LOC) are given in 13.3. 6.3.2 Pre-defined primary and secondary locations This method refers to method 1.2.2 of prENV ISO 14819-3 (see 4). This method uses a predefined primary location and a predefined secondary location which shall each be one ALERT C location code (LCO). This is coded as DATEX-Net method 2. In this method, ALERT C direction shall be used to indicate the direction(s) affected. Further details of usage of the UN EDIFACT Location Segment (LOC) are given in 13.3. 6.3.3 Primary and secondary locations using pre-defined locations + extent + distances This method refers to method 1.2.5 of prENV ISO 14819-3 (see 4). This method uses a predefined primary location which shall be one ALERT C location code (LCO). Optionally an extent (LEX) may be used to indicate the extent of the event and show the secondary location. Additionally and optionally offset distances from the primary and the inferred secondary predefined locations may be used to indicate to a higher degree of accuracy the position of the primary and secondary position of the event. The offsets distance from the primary and the inferred secondary predefined locations shall only indicate distances toward the inferred secondary and primary predefined locations respectively. If no extent is given, such as in the case of a point location, the ALERT C direction shall indicate the direction in which to apply an offset distance from the predefined primary location. If no extent is given no offset from the secondary location shall be given. This is coded as DATEX-Net method 3. In this method, ALERT C direction shall be used to indicate the direction(s) affected. ALERT C direction shall be positive if the extent is negative and, conversly, negative if the extent is positive unless both directions are affected or the direction is unknown. Further details of usage of the UN EDIFACT Location Segment (LOC) are given in 13.3. 6.3.4 Primary and secondary locations using pre-defined locations + distances This method refers to method 1.2.6 of prENV ISO 14819-3 (see 4). The method uses a predefined primary location and a predefined secondary location which shall each be one ALERT C location code (LCO). Optionally offset distances from the primary and secondary predefined locations may be used to indicate to a higher degree of accuracy the position of the
Page 14 ENV 13777:2000 primary and secondary position of the event. The offsets distance from the primary and secondary predefined locations shall only indicate distances toward the secondary and primary predefined locations respectively. This is coded as DATEX-Net method 4. In this method, ALERT C direction shall be used to indicate the direction(s) affected. Further details of usage of the UN EDIFACT Location Segment (LOC) are given in 13.3. 6.3.5 Application of location referencing methods to the Element Location ELEMENT PRIMARY LOCATION (ELT_PRIM_LOC): shall be defined with an ALERT C location code. One distance may be added to indicate a distance offset from the ALERT C location, depending on the referencing method which is used (DATEX-Net method 3 and DATEX-Net method 4). ELEMENT SECONDARY LOCATION (ELT_SEC_LOC): may be defined with an extent related to the primary location (DATEX-Net method 1 and DATEX-Net method 3) or one ALERT C location code (DATEX-Net method 2 and DATEX-Net method 4). One distance may be added, depending on the referencing method which is used. ELEMENT DECISION POINT (ELT_DEC_PT): shall be defined with an ALERT C location code.
6.4 Situation Element message [informative] 6.4.1 Message Content and Structure Within the structure of the situation information message individual data shall have two different status. The status of data are: Mandatory (M)
These data shall be used in the message.
Conditional (C)
These data should be used in the message dependent on certain conditions. The relevant conditions for required occurrence of the data may be given as part of the definition. If no conditions are specified then the data may be used subject to agreement between the Supplier and Client, or at the option of the Supplier.
The list below indicates the key data to be carried by the situation information message. Data types are indicated as mandatory or conditional. Additionally these data have been catagorised as system/message management (M), meta-data (MD) or traffic/travel data (D) (see ENV 13106).
Page 15 ENV 13777:2000 MANAGEMENT INFORMATION Mandatory:
Code list version number (CLV)
M
Situation reference (SNM)
M
Element reference (ERF)
M
Message sending time (MST)
M
Message sender (MSE)
M
Conditional:
Urgency (URG)
M
Message priority (MPR)
M
TMC message reference (TMN)
M
Subscription (SUT)
M
Request time (REQ)
M
Expiry time (EXP)
M
Out of range (OOR)
M
Filter end (FIL)
M
Order number (ORN)
M
Specification version (SVE)
M
Data dictionary version (DDV)
M
Message chain (MCH)
M
Delivery mode (DMD)
M
Message reference (MRF)
M
Element version number (VNM)
M
Message Content - Part 1: General Information METADATA: Conditional:
Element version time (VET)
MD
Area of interest (ARI)
MD
Broadcast (BRO)
MD
Cancel (CAN)
MD
Page 16 ENV 13777:2000
Confidentiality (CFI)
MD
Nature (NAT)
MD
Quality index (QIN)
MD
Reference time (RTI)
MD
Source type qualifier (value of SOT)
MD
Source identification (SID)
MD
Source name (SNA)
MD
Link with other traffic/travel situation (LNK)
MD
Rerouting agreement request reference (RAR)
MD
Accuracy (ACU)
MD
Probability (PRB)
MD
Measurement length (MLE)
MD
TRAFFIC/TRAVEL DATA: Mandatory:
Data object (value of DOB)
D
Phrase (value of PHR)
D
Start time (STA)
D
Input time (INP)
D
Location usage (values of LOT - Element location (LOC) - the element location for situation information - OR - element rerouting decision point (RDP) - the element rerouting decision point in the diversionary route agreement process) D
ALERT C location table reference (LTR)
D
Location referencing method (LRM)
D
ALERT C direction (RDI)
D
ALERT C location table version number (LTV)
D
Conditional:
Confirmation time (CNT)
D
Stop time (STO)
D
Time until (UTM)
D
Entering delay (DEN)
D
Leaving delay (DLE)
D
Delay time value (DLT)
D
Duration value (DUV)
D
Page 17 ENV 13777:2000
Travel time numerical value (TTV)
D
Coded delay time (DLC)
D
Coded duration (DUR)
D
Time of day (TOD)
D
Time until (UTM)
D
Day of week (DOW)
D
Day until (DUN)
D
Diversion advice (DAD)
D
Mobility (MBY)
D
Motoring conditions (MOT)
D
Probability, coded
D
Severity (SEV)
D
Action plan identifier (API)
D
Forecast (FOR)
D
End (END)
D
Element supplementary advice (SAD)
D
Cause (PHC)
D
Location usage (values of LOT - element rerouting destination location (RDL), element rerouting locations (RDD), element distribution location (DIL), element presentation location (PAL), location of source of problem (LSP)) D
ALERT C location code (primary) (LCO)
D
ALERT C location name
D
ALERT C location code (secondary) (LCO)
D
ALERT C direction, named (LDN)
D
Extended location type code (ELT)
D
Lane (LNP)
D
Distance from primary location (DPL)
D
Distance from secondary location (DSL)
D
Wind direction bearing (WDB)
D
Wind direction compass (WDD)
D
Vehicle classification (CLA)
D
Vehicle class (VCL)
D
Page 18 ENV 13777:2000
Direction bearing (DIR)
D
Compass point direction (DRC)
D
Link time (LTT)
D
Nationality (NAL)
D
Next departure time (NTI)
D
Service number (SEN)
D
Individual vehicle ID (VID)
D
Above stated altitude (ALG)
D
Advisory speed limit (SPA)
D
Air temperature (ATE)
D
AM frequency (AMH)
D
Atmospheric pressure at sea level (APR)
D
Average speed numerical value (AVV)
D
Average wind speed (WDS)
D
Below stated altitude (BSA)
D
Capacity remaining (CYR)
D
Car park occupancy (POC)
D
Carbon monoxide concentration (CMC)
D
Channel number (NCH)
D
Concentration numerical value (CTV)
D
Depth (DPH)
D
Direction bearing (DIR)
D
FM frequency (FMH)
D
Gross vehicle weight (GVW)
D
Journey number (JRN)
D
Length affected (LEN)
D
Mandatory speed limit (SPM)
D
Maximum permitted axle weight (MAW)
D
Maximum temperature (MTE)
D
Maximum wind speed (MWS)
D
Methane concentration (CH4)
D
Minimum car occupancy (OCP)
D
Minimum temperature (MIT)
D
Non methane hydrocarbon concentration (NMC)
D
Page 19 ENV 13777:2000
Number of accidents (NAC)
D
Number of bridges (NBR)
D
Number of broken down vehicles (NBV)
D
Number of burst pipes (NBP)
D
Number of buses (NBU)
D
Number of caravans (CAV)
D
Number of convoys (NCY)
D
Number of deaths (DEA)
D
Number of drivers (NRD)
D
Number of fallen trees (NFT)
D
Number of heavy lorries (NHL)
D
Number of heavy vehicles (NHV)
D
Number of incidents (NIC)
D
Number of injured (INJ)
D
Number of lanes (NLN)
D
Number of loads (NLD)
D
Number of objects (NOJ)
D
Number of obstructions (NOB)
D
Number of queues (NLQ)
D
Number of ramp controls (NRC)
D
Number of service lanes (NSL)
D
Number of sewers (NSW)
D
Number of shed loads (NSH)
D
Number of trailers (TAI)
D
Number of vacant parking spaces (NPS)
D
Number of vehicles (NVE)
D
Number of vehicles on fire (NVF)
D
Number of waiting vehicles (NWV)
D
Occupancy numerical value (OCV)
D
Original number of lanes (ONL)
D
Ozone concentration (O3C)
D
PCU flow numerical value (FLV)
D
Precipitation intensity (PIN)
D
Precipitation or deposition depth (PDD)
D
Primary particulate concentration (PPP)
D
Page 20 ENV 13777:2000
Queue length (QUE)
D
Relative humidity (HUM)
D
Ratio of a vehicle class in a traffic flow (VCF)
D
Road surface temperature (RTE)
D
Sections of resurfacing work (SRR)
D
Sequential ramp number (SEQ)
D
Sets of blasting work (SBL)
D
Sets of construction work (SCR)
D
Sets of maintenance work (SMW)
D
Sets of road marking work (SRM)
D
Sets of roadworks (SRW)
D
Sets of slow moving maintenance vehicles (SMM) D
Sets of temporary traffic lights (NTL)
D
Sets of traffic lights (STL)
D
Speed reduction (SPV)
D
Speed reduction ratio (SPR)
D
Test message number (TES)
D
Total hydrocarbons concentration (THC)
D
Travel time increase (TTI)
D
Vehicle flow numercial value (VFV)
D
Vehicle height (HEI)
D
Vehicle length (VLN)
D
Vehicle speed (IVS)
D
Vehicle weight (WEI)
D
Vehicle width (WID)
D
Visibility (VIS)
D
Volume of dangerous goods (VDG)
D
Weight of dangerous goods (WDG)
D
Nitrogen dioxide concentration (N2C)
D
Nitrogen monoxide concentration (NOC)
D
Sulphur dioxide concentration (S2C)
D
Sun radiation net (SRN)
D
Sun total radiation (STR)
D
Wind direction bearing (WDB)
D
Wind measurement height (WMH)
D
Page 21 ENV 13777:2000
Message display (DIS)
D
Comment (text) (SUR)
D
Chemical name (AAD)
D
Message Content - Part 2: Conditional: Tariff associated with a duration of parking Mandatory:
Cost for the duration indicated (COS) - either
D
Rate per hour (RPH) - or
D
Rate per day (RPD) - or
D
Parking duration (PAD)
D
Message Content - Part 3: Conditional: Situations involving hazardous materials: Mandatory:
Type of load (value of LOA)
D
Conditional:
Dangerous goods regulations (DRE)
D
Hazard code identification (HCI)
D
Hazard substance/item/page no. (HSI)
D
Hazard code version number (HZV)
D
UNDG number (UNN)
D
Dangerous goods flashpoint (DGF)
D
TREM card number (TRN)
D
6.5 Physical Format [informative] The EDIFACT message TRAVIN is used (see 13.4).
Page 22 ENV 13777:2000
7. Traffic Data 7.1 Definitions [normative] Traffic data are produced by physical traffic equipment. Each physical traffic equipment can deliver measurement values concerning:
different data objects: average speed, flows, occupancies, ... ,
different vehicle classes (All vehicles, Light Vehicles, Heavy Vehicles, ...),
different measurement units (Example: vehicle/hour or vehicle/day),
different measurement periods (Example: 1 minute or 6 minutes),
different roads (at cross-roads),
different directions on one road,
different lanes (or all lanes) in one direction.
This means that each measurement value is associated with:
one data object,
one vehicle class,
one measurement unit,
one measurement period,
one road, one direction, one lane (or all lanes).
We define the notion of “measurement point” which shall have one unique reference (measurement point reference) and corresponds to:
one data object,
one vehicle class,
one measurement unit,
one measurement period,
one road, one direction, one lane (or all lanes).
This notion of “measurement point” is the basis of the DATEX traffic data transfers. Note 1: The measurement point may have one ALERT C location (ALERT C location table number, ALERT C location table version number, ALERT C location type, ALERT C location code, ALERT C direction, ALERT C offset point distance). Note 2: The measurement point may have a name (measurement name) given by the Supplier. Note 3: The side of the road concerned by the measurement point may be described in a text field (measurement side).
Page 23 ENV 13777:2000
7.2 Exchange description [informative] The message for traffic data shall be as short as possible, as it may be sent, by the Supplier, every 5 or 6 minutes for several hundred values. The following solution has been chosen: a.
The measurement points are defined, by the Supplier, in a Measurement point table.
b.
The Supplier sends the Measurement point table to the Client (on-line or off-line) when the Client asks for it.
c.
In each Traffic Data message, for each traffic data the Supplier only sends the measurement point reference and the data object corresponding value.
d.
The Client can find the physical characteristics of each measurement point (data object, vehicle class, measurement unit, measurement period, road, direction, lane(s)) in the Measurement point table that he has previously received from the Supplier. Client Sub-System
Supplier Sub-System
Measurement point table (one time)
Traffic data message Several (reference + value) (every n minutes)
Figure 5 - Schematic of message exchanges related to Measurement point table
Page 24 ENV 13777:2000
7.3 Measurement point table [normative] Table 1 contains the measurement point definitions. Field name
Format
Measurement point reference
M
Data Object
M
ALERT C location table number
C
ALERT C location table version number
C
ALERT C location code
C
ALERT C direction
C
ALERT C point distance
C
Measurement point name
C
Measurement side
C
Measurement lane
M
Measurement vehicle class
M
Measurement period
M
Measurement unit
M
Measurement equipment reference
C
Table 1 - Measurement point definitions
The management of this table is described in 8.5 “Supplier and Client: Handle measurement point table”. 7.4 Traffic Data message [informative] In each message we find: one measurement time (start time), for each measurement point: one reference, one value. Field name
Format
Start time
M
Measurement point
C 99999
Reference
M
Value
M Table 2 - Indicative content of Traffic Data Message
Page 25 ENV 13777:2000
7.5 Physical format [informative] The EDIFACT message TRAILS is used (see 13.5). 7.6 Traffic data model [informative] RDS_LOCATION
DATA_OBJECT
@alertc_table_ref @alertc_table_version @alertc_location_code alertc_location_type alertc_road_number alertc_road_name alertc_first_name rds_second_name alertc_A_reference alertc_L_reference alertc_negative_offset alertc_positive_offset alertc_urban_code alertc_intersection_code
@dob_code dob_text
MEAS_PT_LOCATION
TRAFFIC_MEAS_PT
mpl_rds_direction mpl_distance
@mea_pt_ref mea_pt_name mea_side_name mea_lane-pos mea_vehicle_class mea_period mea_unit mea_traffic_eqpt_ref
TRAFFIC DATA VALUE @tdv_mea_time tdv_value
Figure 6 - Traffic data model
EXPLANATION TRAFFIC MEASUREMENT POINT:
The TRAFFIC_MEASUREMENT_POINT refers to one DATA_OBJECT.
The TRAFFIC_MEASUREMENT_POINT may be localised with one MEASUREMENT_POINT_LOCATION.
The value of the TRAFFIC_MEASUREMENT_POINT may be stored in a MASSIVE_STORAGE table.
MEASUREMENT POINT LOCATION: One MEASUREMENT_POINT_LOCATION refers to one RDS_LOCATION code, a point location given by which shall be an ALERT C location point and may have an offset distance. MASSIVE_STORAGE: This table contains the measurement point values for the different start times. For entities, attributes and domains details, see Conceptual data models (see 14).
Page 26 ENV 13777:2000
8. Common functions 8.1 Introduction [informative] The functions detailed in this clause are common to the different operating Levels (1, 2 and 3) described later on in the document. Before exchanging data, traffic centres shall agree on some specific issues that are described in the Interchange Agreement and shall adopt the same code lists for data objects, phrases, attributes and location referencing. The common functions to be handled at each Level are:
Handle location table;
Handle measurement point table for traffic data;
Creating and updating situation information;
Filtering process;
Send data;
Receive data;
Diversion process;
Handle status message.
8.2 Supplier and Client: Interchange agreement [informative] The interchange agreement is a document that describes bilateral agreements between Supplier and Client needed for the exchange of DATEX-Net information. The interchange agreement should deal with all the information that is needed for the data exchange to take place. In the current clause you will find a checklist of items that could be considered in the agreement. The list also shows DATEX-Net suggested values for specific items. The description assumes that the information exchange follows the basic principles of DATEX. Specifically it is assumed that two parties are involved: a Supplier providing messages and a Client receiving messages. General: 1.
Time period throughout which the overall agreement is valid The agreement shall state the time period in which the agreement is valid. It should define the date of commencement and the date of ending.
2.
Rules for terminating the agreement before the expiry time of the agreement The agreement should specify the conditions under which the contract can be terminated before its expiry date.
3.
Company/authority names, contact addresses, telephone, fax and E-mail details The two parties shall clearly defined the company and/or the authority’s names address and the practical contacting persons with all related communication data such as telephone and fax numbers and email addresses.
Access: DATEX-Net assumes access through user name/password. The user names are required to be unique across the network and shall consist of 5 alphanumeric characters. A user name is
Page 27 ENV 13777:2000 composed of a 2 letter country code according to EN ISO 3166-1, followed by three characters that identify the user. 4.
IP address of the Client The agreement should mention the Internet Protocol address of the client that is going to be used for setting up the communication between the parties.
5.
IP address of the Supplier The agreement can mention the Internet Protocol address of the supplier that is going to be used for setting up the communication between the parties.
6.
Supplier user name The agreement should mention the user name that will be adopted by the supplier. This will be the SupplierId used throughout this paper.
7.
Client user name The agreement can mention the user name that will be adopted by the supplier. This will be the ClientId used throughout this paper.
8.
Password for Supplier to connect to Client If the parties decide to use a password, this should be specified here. If other means of access control are used these should be specified here.
9.
Password for Client to connect to Supplier If the parties decide to use a password, this should be specified here. If other means of access control are used they should be specified here.
File transfer: 10. Choice of public network for File Transfer Protocol and configuration All technical information needed for the file transfer between the parties should be described here (Example: X25, ISDN, special line … and router parameters, ASCII transfer mode...) 11. Name of directory at the Client site where the transmitted messages from the Supplier Server are placed The directory name is PATH_CLI and is given by the Client during the interchange agreement, because it depends on the Client’s hardware and software. 12. Name of files containing supplier messages Files are named USERNAMEXXX.MSG, where USERNAME is the SupplierId, and XXX represents a sequence guaranteeing unique names in the time period needed by the Client to process the message. XXX could be numbers starting from 000 incrementing to 999 and then repeating from 000 again. 13. Name of directory at the Supplier site where the Client can place requests or orders The directory name is PATH_SUP and is given by the Supplier during the interchange agreement, because it depends on the Supplier’s hardware and software. For one system which contains both one Client sub-system and one Supplier sub-system, PATH_SUP shall be different from PATH_CLI. If the requests or orders are done using FAX or HTML forms, the fax number or URL address should be given.
Page 28 ENV 13777:2000 14. Name of files containing client messages Files are named USERNAMEXXX.REQ, where USERNAME is the ClientId of the Client, and XXX represents a sequence guaranteeing unique names in the time period needed by the Supplier to process the request. XXX could be numbers starting from 000 increasing to 999 and then repeating from 000 again. This is not applicable if the requests or orders are done using FAX or HTML forms. EDIFACT: 15. Character repertoire The interchange agreement shall mention the character repertoire to be used. The character sets ISO 8859-1: Latin 1 characters (UNOC) is recommended. For information, the code table for Latin alphabet N°1 is given in Table 3.
X0 X1 X2 X3 X4 X5 X6 X7 X8 X9 XA XB XC XD XE XF
0X 1X 2X 3X 4X 5X 6X 7X 8X 9X AX BX SP NBSP 8 0 @ P ` p ! 1 A Q a q ° ± “ 2 B R b r ¢ = # 3 C S c s £ = $ 4 D T d t § ¥ % 5 E U e u • µ & 6 F V f v ¶ ' 7 G W g w ß ? ( 8 H X h x ® ? ) 9 I Y i y © * : J Z j z ™ ? a + ; K [ k { ´ o SHY , < L \ l | = M ] m } ? ? . > N ^ n ~ Æ æ / ? O _ o Ø ø 0X 1X 2X 3X 4X 5X 6X 7X 8X 9X AX BX
CX DX EX FX ¿ – ‡ ? X0 ¡ — · Ò X1 ¬ “ ‚ Ú X2 v “ „ Û X3 ƒ ‘ ‰ Ù X4 ˜ ’  ý X5 ? ÷ Ê ˆ X6 “ ? Á ˜ X7 “ ÿ Ë ¯ X8 … Ÿ È X9 / Í XA À ¤ Î ° XB à ‹ Ï ¸ XC Õ › Ì XD Œ ? Ó XE œ ? Ô XF CX DX EX FX
Table 3 - UNOC Character Set
16. Information separators The default service characters are Table 4: The use of the UNA service segment is optional if the default characters are used. Graphic Representation ‘ + : ?
Name Apostrophe Plus sign Colon Question mark
Functionality segment terminator data element separator component data element separator release character
Table 4 - Separator Characters
17. Structure - Functional group
Page 29 ENV 13777:2000 The functional group as specified in EDIFACT is not used in DATEX. 18. Date/Time formats Default formats for date/time are provided in the Data Dictionary ENV 13106. If default formats are not used, the formats to be used shall be specified here. In all cases, it is recommended that the format should be indicated where possible. 19. Default language for free text The default language for free text should be specified here. 20. Decimal mark The representation of the decimal mark should be given here. Management of background information: 21. Specification of the Attribute list, phrase code list and data object list (see 8.3) This clause deals with the code lists that have to be shared in order that the exchanged data can be decoded properly at the receiving site. The DATEX codes lists are included in the DATEX dictionary. Due to its wide-scope, the DATEX Data Dictionary may be too extensive for some users and not enough for others. Therefore, some users may which to:
add entities and attributes not listed in this dictionary;
use attributes not recommended in a given object description;
use only a part of the proposed entities.
22. Specification of location tables used (see 8.4) A site dependent location table also has to be identified. This list is provided by the Supplier. Message management and functions: 23. Level of operation and all related options
Specify the operation level and how to exchange filters/orders Level 1: HTML/SGML or fax form; Level 2: EDIFACT TRAREQ message or HTML/SGML or fax form; Level 3: EDIFACT TRACAT message or HTML/SGML or fax form.
Specify which are the data exchange supported (situation data or/and traffic data);
Specify if diversion process is used;
Specify how to manage situation data (updating method, end …);
Specify how to exchange location table (offline or EDIFACT TRALOC message, see 8.4);
Specify if handle status messages is used (see 8.11).
24. Actions to be taken when errors occur during message transmission/reception. Rights and obligations: 25. Description of the quality of the data provided by Supplier. 26. Description of actions by Supplier in connection with the Supplier Server being down:
Page 30 ENV 13777:2000 -
actions when Supplier Server is down for planned maintenance,
-
actions when Supplier Server is down due to system crash,
-
actions when Supplier server starts up.
27. Description of actions by Client in connection with the Client system being down: -
actions when Client system is down for planned maintenance,
-
actions when Client system is down due to system crash,
-
actions when Client system starts up.
28. Description of payment mechanism for the service, if any. 29. Statement on liability in case of transmission of incorrect information. 30. Rules for the further dissemination by the Client of information received using DATEX. 8.2.1 Main choices available This clause provides an overview of the main choices that are available to the system developer when implementing a DATEX-Net compatible information exchange system. A range of interoperable choices exist due to the evolution of these standards from a number of pilot systems which incorporate different philosophies and focuses on user requirements. It should be stressed that these solutions are interoperable and the selection of particular choices should not inhibit further and future interoperability. The main areas of choice available to the system developer are as follows: 1. The types of data to be exchanged The DATEX-Net specifications enable the exchange of traffic/travel situation and status information and traffic data. The system developer has to choose which data will be supported and exchanged. It is possible to implement a subset of data suited to the user requirements as long as the mandatory data is exchanged. 2. The operating level of the system There are three levels of operation defined in the DATEX-Net specification. These operating levels broadly range from simple one-way information distribution links to complex messaging environments with a system administrator function. 3. The updating strategy adopted within message management As the unified DATEX-Net approach has been developed from a number of earlier pilot project based information exchange systems, two methods for updating information have been accommodated. These can be considered to be the necessary approaches if communications between Supplier and Client are performed either in real-time or on a batch-mode periodic basis.
8.3 Supplier and Client: Establish code lists The situation conceptual data model shows that: - one situation element shall be related to
one data object in a pre-defined data object list, one phrase in pre-defined phrase list, one location in a pre-defined location code list.
- an element attribute shall refer to
one of the attributes of the pre-defined list.
Page 31 ENV 13777:2000 These pre-defined lists shall be common to all DATEX-Net network users, in order that Clients and Suppliers could understand in the same way requests and distributions of data. Users do not necessarily have to implement the complete list. 8.3.1 Data objects, phrases, attributes, supplementary information The different codes to be used in the DATEX-Net context are described in ENV 13106. The process concerning the translations of the definitions of the standards codes is on going under the responsibility of the different Member States. 8.3.2 Location code In this version of the DATEX-Net Specification, the ALERT C location referencing system will be used. The ALERT C location referencing system is described in prENV ISO 14819-3 (see 4). The definition of an off-line format is under progress in CEN TC278 WG7.3; this format should be used by national authorities responsible to produce the national databases. An EDIFACT on-line message TRALOC can be used to exchange these tables between Suppliers and Clients (see the common function 8.4: Handle location table). A Supplier may need several location tables from different regions or countries, they can be merged in the same Supplier table, indeed each location code is unique since it is composed of the ALERT C location table reference, the ALERT C location table version number and the code in the ALERT C location table itself (see the situation data model in 6).
8.4 Supplier and Client: Handle location table 8.4.1 General description For locating situations, a Supplier uses his ALERT C location table. This Supplier ALERT C location table can be composed of different elementary ALERT C location tables (each with its ALERT C location table reference, the ALERT C location table version number and the code in the ALERT C location table itself). For each elementary ALERT C location table, the list of locations should conform fully to the location referencing rules prENV ISO 14819-3 (see 4). When a Client wants to receive information from a Supplier, he needs the Supplier ALERT C location table to “understand” the ALERT C location codes. The exchange of this Supplier ALERT C location table is made in three steps: 1. the Client has to REQUEST FOR LOCATION TABLE; 2. the Supplier has to SEND LOCATION TABLE; 3. the Client has to RECEIVE LOCATION TABLE. These steps can be made off-line or on-line.
Page 32 ENV 13777:2000 Client Sub-System
Supplier Sub-System
REQUEST FOR LOCATION TABLE
LOCATION TABLE
Figure 7 - Schematic of handle location table
8.4.2 Physical format [informative] When the exchange of the location table is made off-line, the physical format, which is under progress in CEN TC278 WG7.3, is recommended. At present, the physical format is the result of an agreement between the Supplier and the Client. When the exchange of the location table is made on-line, the physical format corresponds to the EDIFACT message TRALOC for the LOCATION TABLE. For the REQUEST, using EDIFACT, the message TRAREQ is used (see 13.8). 8.4.3 Exchange description 8.4.3.1 Client: Request for location table The operator of the Client sub-system uses this function to ask for an initial version or update of the Location Table, relating to a Supplier. External Interface [normative] Input Request containing:
SupplierId.
Output Message REQUEST FOR LOCATION TABLE to Supplier (For the physical format, see the previous clause). Process Description [informative] Send the REQUEST FOR LOCATION TABLE message to the selected Supplier.
Page 33 ENV 13777:2000 8.4.3.2 Supplier: Send location table This function processes the REQUEST FOR LOCATION TABLE message from Clients. It returns to each Client a message containing the list of locations stored in the Supplier’s database. External Interface [normative] Input Message REQUEST FOR LOCATION TABLE from Client. Output Message LOCATION TABLE to Client. Process Description [informative] Compose the LOCATION TABLE message from the location data stored in the Supplier’s sub-system (list of all the locations). Send the message to the Client. 8.4.3.3 Client: Receive location table This function is used to create or update the Client’s Location Table for one Supplier. Location data integrity is kept between the Supplier (sender) and the Client (receiver) once the update is done. Warning: when updating, Client information may be linked to the previous table. Implementation choices shall be taken to achieve global information integrity. External Interface [normative] Input Message LOCATION TABLE from Supplier. Output New location table in the Client database for this Supplier. Process Description [informative] Replace the previous Location Table with the one described in the LOCATION TABLE message. Location data related to other Suppliers are maintained.
8.5
Supplier and Client: Handle measurement point table
8.5.1 General description Each traffic data corresponds to one measurement point (see 7: Traffic data). At the Supplier level, the measurement point is described in the measurement point table. When a Client wants to receive information from a Supplier, he needs the Supplier measurement point table to “understand” the measurement point references.
Page 34 ENV 13777:2000 The exchange of this Supplier measurement point table is made in three steps: 1. the Client has to REQUEST FOR MEASUREMENT POINT TABLE, 2. the Supplier has to SEND MEASUREMENT POINT TABLE, 3. the Client has to RECEIVE MEASUREMENT POINT TABLE. These steps can be made off-line or on-line. Client Sub-System
Supplier Sub-System
REQUEST FOR MEASUREMENT POINT TABLE
MEASUREMENT POINT TABLE
Figure 8 - Schematic of handle measurement point table
8.5.2 Physical format When the exchange of the measurement point table is made off-line, the physical format is the result of an agreement between the Supplier and the Client. At Level 3, the measurement point table is included in the catalogue and the exchange is made on-line (see 12). When the exchange of the measurement point table is made on-line, the physical format corresponds to the EDIFACT message TRACAT. For the request using EDIFACT, the message TRAREQ is used (see 13.8). 8.5.3 Exchange description 8.5.3.1 Client: Request for measurement point table The operator of the Client sub-system uses this function to create or update the measurement point table relating to the selected Supplier. External Interface [normative][normative] Input Request from Application or Operator Interface, containing:
SupplierId.
Output Message REQUEST FOR MEASUREMENT POINT TABLE to Supplier.
Page 35 ENV 13777:2000 Process Description [informative] Compose and send the REQUEST FOR MEASUREMENT POINT TABLE message to the selected Supplier. 8.5.3.2 Supplier: Send measurement point table This function process the Request for measurement point table message from Clients. It returns to each Client a message containing the measurement point table stored in the Supplier’s database. External Interface [normative] Input Message REQUEST FOR MEASUREMENT POINT TABLE from Client. Output Message MEASUREMENT POINT TABLE to Client. Table 5 indicates the fields contained in this message. Field name
Format
Measurement Point
M 9999
Measurement point reference
M
Data Object
M
ALERT C location table number
C
ALERT C location table version number
C
ALERT C location code
C
ALERT C direction
C
ALERT C point distance
C
Measurement point name
C
Measurement side
C
Measurement lane
M
Measurement vehicle class
M
Measurement period
M
Measurement unit
M
Measurement equipment reference
C
Table 5 - Indicative content of Measurement point table message
Process Description [informative] Compose the MEASUREMENT POINT TABLE message from data stored in the Supplier’s database. Send the message to the Client.
Page 36 ENV 13777:2000 8.5.3.3 Client: Receive measurement point table This function is used to create or update the Client’s measurement point table related to a Supplier. Data integrity is kept between the Supplier (sender) and the Client (receiver) once the update is done. External Interface [normative] Input Message MEASUREMENT POINT TABLE from Supplier. Output If necessary, information to Operator Interface, containing:
SupplierId,
Request for measurement point table status,
List of the references and the descriptions of the measurement point table.
Process Description [informative] Data, contained in the received message, are dumped into the Client’s database, replacing the previous values. Warning: once the update is effective, some records may refer to non-existent references. Warning messages shall appear on the Client’s Operator Interface to inform the operator, and ask for action: modification or deletion of the inoperative records. The measurement point tables related to other Suppliers are kept in place. If necessary, inform the Operator Interface about the status of the previous request (Request for measurement point table).
8.6 Situation and element information management 8.6.1 Introduction [normative] Situations and their elements are created, updated and terminated by a number of methods described below. Three possibilities exist to change an active situation element into a nonactive one. A situation element should be ended using an “End”.
A Situation element can be cancelled using “Cancel”. In this case, part or all of the information previously sent for this Element was wrong.
A Situation element can be invalidated by use of an expiry time. If this time is reached on the Client’s side, it is assumed that the information is no longer valid, i.e. the situation element is implicitly ended. The delivery of a situation element to a specific client can be stopped and indicated to him by three methods: 1. the use of an “Out of range”, 2. the use of a “Filter end”, 3. the use of a “Delivery break”.
Page 37 ENV 13777:2000 The use of an “Out of Range” indicates to the client that the information is no longer delivered to him because the element has passed out of the filter range (Example: the queue length is now below the threshold specified by the client). “Filter End” indicates to the Client that the information is no longer delivered to him because the end of the time frame specified in the filter is reached. “Delivery break” indicates that the data delivery is stopped by some reason independent from the element existence and filter specification. Using any of these attributes means that the delivery has stopped, while the situation element may still be active on the ground. This clause describes processes that may have to be taken during the management of situations and messages exchanged. Each of the message management processes is described below.
Create Situation and first situation element;
Update Situation;
Create a further Situation element;
Update an existing Situation element;
Cancel Situation element Information;
Out of filter specification.
End Situation element.
End Situation.
The information describing a traffic/travel situation is likely to be altered throughout the duration of the situation. Renewal of the situation information to the Client is provided by means of an update to the situation elements. Create Situation and first situation element The situation creation is done automatically by sending an situation element, for the first time, for this situation. Fields to be filled:
Situation Reference (SNM): generate a new situation reference.
Element Reference (ERF): generate a unique element reference within the situation.
When a situation element begins, it shall have a start time (STA), data object (DOB), phrase (PHR) and location (see 6.2). Update Situation On updating the state of an existing situation alterations may be made by means of creating an additional new situation element or by updating the information within an existing situation element. Three special cases of situation element updating are covered here where the situation element changes from an active to a non-active condition due to cancellation or invalidation. Create a further Situation element Fields to be filled:
Situation Reference (SNM): use the existing situation reference.
Page 38 ENV 13777:2000
Element Reference (ERF): generate a unique element reference within the situation.
When a situation element begins, it shall have a start time (STA), data object (DOB), phrase (PHR) and location (see 6.2). Update an existing Situation element Fields to be filled:
Situation Reference (SNM): use the existing situation reference.
Element Reference (ERF): the reference of the situation element concerned.
The Data Object cannot be changed when updating the situation element information. The inclusion of new Data Object requires the generation of new situation elements. Special case - Cancel Situation element Information All the information previously sent for the situation element are not valid anymore. If the Supplier has new valid information this should be sent in the same message. Fields to be filled:
Cancel (CAN): filled.
If new information is inserted into the message, the element is to be considered as valid and former information is replaced by the new one; if no new information is provided, the client must consider this element existence as an error and close it in his database. Special case - Out of Filter Specification Due to a change within the attributes of a situation element or a change in the filter requirements or for some other reason in relation to information filtering, the information contained within a situation element is considered to be out of the filter specification. This is explained in greater detail in 8.7.2. Three cases exist as explained in 8.7.2. Fields to be filled:
Out of Range (OOR): filled or
Filter End (FIL): filled or
Delivery Break (DBK): filled.
End Situation element Fields to be filled:
Situation Reference (SNM): use the existing situation reference.
Element Reference (ERF): the reference of the situation element concerned.
A situation element is considered to have ended when an “End” has been used. This method is recommended. An Expiry Time may be used to invalidate a situation element - following the application of an expiry time (EXP) to situation element information, if this situation element information has not been superseded (updated) and the expiry time has been passed, the situation element is considered to have expired (the information will be considered to sufficiently aged to contain errors). This is a method of terminating or de-activating a situation element by default.
Page 39 ENV 13777:2000 8.6.2 End Situation [normative] A situation is ended when all of its situation elements are not active. A situation element is not active when it has been ended (see End Situation Element above), expired (see End Situation Element above), or is out of Filter Specification (see Special case - Out of Filter Specification above). 8.6.3 Updating Methods [normative] Two methods to update information can be used by the Supplier, as described below. Both of the updating methods can support the situation version number, if it is used. This is not mandatory. In both cases, when an information update is made the situation version number would be incremented by one. This is for interoperability with existing Interchange applications. Single Situation element Updating In this option, Supplier sends only those situation elements that contain new or updated information. Each new or updated situation element will be transmitted once the information has been altered by the Supplier. It is assumed, by the Client, that all the other information contained in other situation elements relating to the situation are unchanged. The Client will gain a full description of the current status of a situation by searching the Client database for the latest versions of situation elements relating to that situation. Single situation element updating is the recommended method. All Situation element Updating In this option, a full description of the situation is sent with each update. The Supplier sends all situation elements related to a situation when sending an update, including those situation elements of the situation that have ended. This procedure ensures that when receiving an update the Client will identify correctly the current status of all situation elements relating to a situation. This may result in the Client receiving multiple updates indicating that a situation element has ended. The Client will gain a full description of the current status of a situation either by receiving an update of the situation or by searching the Client database for the latest versions of elements relating to that situation. 8.6.4 Example [informative] This example illustrates the two methods of information updating provided above - Single situation element updating and All situation element updating. The information displayed for each situation element is an extract of the full element information. Step 1 An accident (ACI) is reported to the Supplier at 10:00 am. Additionally the Supplier is told that there is stationary traffic (LS1). Both Single Situation element Updating and All Situation element Updating will react in the same manner when a situation is first reported. Both methods will create two elements of the situation (situation reference, say, 110). These situation elements will contain the phrase codes ACI and LS1 respectively, which provide a partial description of the situation. This information will be sent to the Client by means of two messages, each describing one situation element. Both updating methods will send the same simplified messages:
Page 40 ENV 13777:2000 1ab.
Situation 110; element 1; ACI.
2ab.
Situation 110; element 2; LS1.
The table below shows a representation of what may be held in a Client’s database, with each of the updating methods. With each step of the example a new line is added. The version of situation elements shown in this table are only for clarity and are not exchanged as part of the message. The version number shown may be generated by the Client’s database, but are not mandatory.
Page 41 ENV 13777:2000 All Element Updating
Single Element Updating 10 00 ACI
ACI, LS1
LS1 ACI, LS1
Time
Figure 9 - Schematic of example, step 1
Input
Situation overview
Single Element Updating
All Element Updating
Time
Element 1
Element 2
Element 1
Element 2
Element 1
Element 2
10:00
ACI
LS1
ACI
LS1
ACI
LS1
(Version 1) (Version 1) (Version 1) (Version 1) (Version 1) (Version 1) Table 6 - Different updating views of Step 1
Step 2 At 10:30 am the Supplier is informed that the accident has been cleared but that the stationary traffic remains. Using the Single Situation element Updating method only the situation element containing new information will be updated and exchanged between Supplier and Client. Element 1 will be ended by use of “End”. As only one situation element has been updated only one message will be exchanged. Element 2 will remain unchanged. The simplified messages to be exchanged: 3a.
Situation 110; element 1; ACI End.
Using the All Situation elements Updating method the information within element 1 is modified. Then both situation elements are sent to the Client again. In this case, the information relating to element 2 will be identical to that originally sent. The simplified messages to be exchanged: 3b.
Situation 110; element 1; ACI End.
4b.
Situation 110; element 2; LS1.
Page 42 ENV 13777:2000 All Element Updating
Single Element Updating
10 00
ACI, LS1
ACI, LS1 ACI
LS1
10 30 ACI End
ACI End, LS1 Time
Figure 10 - Schematic of example, step 2
Input
Situation overview
Single Element Updating
All Element Updating
Time
Element 1
Element 2
Element 1
Element 2
Element 1
Element 2
10:00
ACI
LS1
ACI
LS1
ACI
LS1
(Version 1) (Version 1) (Version 1) (Version 1) (Version 1) (Version 1) 10:30
ACI End
LS1
ACI End
-
(Version 2) (Version 1) (Version 2)
ACI End
LS1
(Version 2) (Version 1)
Table 7 - Different updating views of Step 2
Step 3 At 10:45 am the traffic has started to move again. Its description has changed from stationary traffic (LS1) to slow traffic (LS3). Using the Single Situation element Updating method, only the situation element containing new information will be updated and exchanged between Supplier and Client. The phrase code contained in Element 2 will changed from LS1 to LS3. As only one situation element has been updated only one message will be exchanged. Element 1 information is unchanged and Element 1 has been ended. The simplified messages to be exchanged: 3a.
Situation 110; element 2; LS3.
Once created a situation element shall have one and one only data object throughout all of its versions. Using the All Situation elements Updating method the information within Element 2 is modified. Then both situation elements are sent to the Client again. In this case, the information relating to element 1 will be identical to that last sent (Element 1 has ended).
Page 43 ENV 13777:2000 The simplified messages to be exchanged: 5b.
Situation 110; element 1; ACI End.
6b.
Situation 110; element 2; LS3.
All Element Updating
Single Element Updating
10 00
ACI, LS1
ACI, LS1 ACI LS1 10 30 ACI End
ACI End, LS1
Time 10 45 LS3 ACI End, LS3
LS3
Figure 11 - Schematic of example, step 3
Input
Situation overview
Single Element Updating
All Element Updating
Time
Element 1
Element 2
Element 1
Element 2
Element 1
Element 2
10:00
ACI
LS1
ACI
LS1
ACI
LS1
(Version 1) (Version 1) (Version 1) (Version 1) (Version 1) (Version 1) 10:30
ACI End
LS1
ACI End
-
(Version 2) (Version 1) (Version 2) 10:45
ACI End
LS3
(Version 2) (Version 2)
-
ACI End
LS1
(Version 2) (Version 1) LS3
ACI End
LS3
(Version 2) (Version 2) (Version 2)
Table 8 - Different updating views of Step 3
From this example, it is clear that the major advantage of the Single Situation element Updating method is that it reduces the communications burden by sending only the altered information. However, the advantage of All Situation element Updating method arises from the knowledge that the current status of the situation is fully described in the latest update.
Page 44 ENV 13777:2000
8.7 Filtering general specification 8.7.1 Introduction [normative] Information has to be transmitted from Supplier to Client. The information can be filtered in order:
that the Client gets adequate information;
to reduce communications costs.
This can be done using Client filter and/or Supplier filter which can be Client and/or Supplier driven.
Figure 12 - Example using three kind of filters
Page 45 ENV 13777:2000 The only case where Client and Supplier interact is when there is a Supplier Filter set up by Client. The way the Filter setup process is done defines the Levels: Level 1: Filter exchange (if any) is done off-line. It means that a Supplier operator has to validate and install the filter. The Client requests information from the Supplier offline and the Supplier provides what he is able to or he chooses to (See Figure 13 Levels 1 and 2).
Figure 13 - Levels 1 and 2
Level 2: The Filter exchange is done on-line using request. It allows the automation of the exchange process and the application of the filter. The Client requests information from the Supplier following precise rules and the Supplier provides what he is able to or what he chooses to (see Figure 13). Level 3: The filter exchange is done on-line via catalogue by using an order. The Client orders some items of a Supplier catalogue and the Supplier provides what the Client ordered (see Figure 14).
Page 46 ENV 13777:2000
Figure 14 - Level 3
The detail of each Level is given in 10, 11 and 12. Interoperability between Levels: To be interoperable at this stage the Level 1 has been chosen. There is a possibility to gather all those options in a common solution, such as HTML pages on Internet, but this will be studied more closely at a later stage. Every centre can choose how far it will implement the filter process but is invited to follow the same rules in order to be interoperable. You will find description of those rules in this clause. 8.7.2 “Out of Range”, “Filter End” and “Delivery Break” Indicators [normative] These filter status indicators requires some explanation. The information and/or the filters can evolve over time and it is very important for the Client to know the validity of the information received.
Page 47 ENV 13777:2000
Figure 15 - Zones I, II, III
Example: An event on the road occurs and the information A about this event is input into the Supplier system. This information exists in the sets on Figure 15. As long as this information is in Zones II or III, it is not sent and the Client knows nothing of the event. After some time (because of information content and/or a change to the set) the information A exists in Zone I. This information is then sent to the Client. After some further time (because of information content and/or a change to the set) the information A exists outside Zone I. There are two possibilities: 1.
The information A exists in Zone II, meaning that the information is out of the filter range (“out of range”).
2.
The information A exists in Zone III, meaning that the information is no longer available for this Client.
When such an event occurs, with information A in Zone II (possibility 1), the Supplier shall send an “Out of Range” related to this information to the Client. Alternatively the filter established for the Client may pass its valid period of operation, no further information would be sent, so the Supplier shall send a “Filter End” in relation to this information. If for a reason the information cannot be supplied by the Supplier or is longer available to the Client (possibility 2), the Supplier shall send a “Delivery Break” related to this information. The Client has to manage “Out of Range”, “Filter End” and “Delivery Break” because it is possible that an “End” or “Cancel” will not be received at a later time for this situation element.
Page 48 ENV 13777:2000 8.7.3 Historical, Active and Future information [informative] Definitions: Future information are not already known by the system at the Present System Time. Past information exist in the system by present system time. This includes both Active and Non-Active information. Active information at Present System Time are defined as last version of information known by the system at that time excluding versions which have been invalidated. Invalidation occurs by the specific use of “End”, “Out of Range”, “Filter End”, “Delivery Break”, or an expired Expiry Time.
Figure 16 - Future, Past and Active information
Historical information at a time are defined as the last version of information known by the system at that time excluding versions which are not Active at that time. Notes: If a TIC operator needs information on-line, he will be interested in Active and Future information only. If he needs Non Active information for special applications, he can store information received for later usage. In this case, the filter deals only with Active and Future information. Generally, non Active information is needed when a filter comes into operation or for a special purpose like recovering from a system crash. If a statistician needs Historical information, he can ask the Supplier directly. However Historical information can be linked to the backup procedure of each centre and therefore difficult to specify. Some Suppliers will not be able to supply Historical information on-line. In conclusion, each Supplier shall supply Active and Future information for on-line operations. The Supplier can supply Historical information on-line or off-line.
Page 49 ENV 13777:2000 8.7.4 Filter Definition [informative] 8.7.4.1 Introduction Each Client has its own set of filters. A filter definition is composed of:
Filter Reference This is a reference that uniquely defines the Filter (ClientId and Filter Id). Each Client shall ensure that the Filter Id is unique for him.
Filter Expression This is a Boolean expression composed of operands (DATEX Data Dictionary information codes or other agreed codes or their related constants) and operators (comparison and logical operators). The Filter Expression is true when information (traffic/travel event or status or traffic data) fulfils the Filter Expression.
Geographical Filter This consists of a set of ALERT C location codes. Information fulfils the Geographical Filter when its location belongs to at least one location within the Geographical Filter.
Data Delivery Mode There are three delivery modes available: One Shot, On Occurrence or Periodic.
Filter Validity Interval The Filter Validity Interval is defined by Validity Start Time and Validity Stop Time and is the time interval when the filter is active. If Validity Start Time is omitted, the Supplier shall provide information as soon as possible.
Filter Period (if Delivery Mode is Periodic) The Filter Period is the value of the data delivery.
Filter Action For situation data, there are two actions available: Element Only or Whole Situation. If Filter Action is Element Only, when an situation element fulfils the Filter Expression and the Geographical Filter then this situation element fulfils the Filter Action. If Filter Action is Whole Situation, when at least one element of a situation fulfils the Filter Expression and the Geographical Filter then all elements belonging to this situation fulfil the Filter Action.
For traffic data, the only Filter Action available is Element Only.
Page 50 ENV 13777:2000 8.7.4.2 Filter conceptual data model
Figure 17 - Filter conceptual data model
Page 51 ENV 13777:2000 8.7.4.3 Data Delivery Modes description 8.7.4.3.1 One shot Active data: The Supplier will send all active data fulfilling the Filter Action as soon as possible. In this case there is no Filter Validity Interval. The Supplier shall send the data request number so that the Client can identify that this data is supplied in One Shot mode. Historical data: The Supplier will send all historical data fulfilling the Filter Action as soon as possible. In this case Filter Start time is the time at which historical data is needed. The Supplier shall send the data request number so that the Client can identify that this data is supplied in One Shot mode. 8.7.4.3.2 On Occurrence For Situation Data, when the Filter Start Time is reached, all active situation elements fulfilling the Filter Action are sent. If Supplier can not provide information at Filter Start Time, he shall provide information as soon as possible. After this the Filter is activated. When the Filter is Active, the new data fulfilling the Filter Action are sent. When the Filter Stop Time is reached, the Filter is deactivated. 8.7.4.3.3 Periodic For Situation Data, when the Filter Start Time is reached, all active situation elements fulfilling the Filter Action are sent. If Supplier can not provide information at Filter Start Time, he shall provide information as soon as possible (during the first period if possible). When the filter is Active, on each delivery period, all data fulfilling the Filter Action are sent. The first period begins at Filter Start Time. When the Filter Stop Time is reached, the Filter is deactivated. Note: For the On Occurrence and Periodic modes, this gives the Supplier the possibility to provide non-Active information. 8.7.4.4 Filter Expression Description The Filter Expression is a Boolean expression composed of Operands and Operators. Operands are DATEX codes (DATEX Data Dictionary information codes or other agreed codes) and values (related to the corresponding DATEX code). Operators can be relational or logical operators. The precedence rules follow from the syntax of expressions, which are built from factors and terms.
Page 52 ENV 13777:2000
OR Filter Expression
Term
(
Filter Expression
)
DATEX code
Operator
Value
Factor NOT
Figures 18 a, b, c - Schematics of precedence rules
Operator = < > =
Meaning Equal to Not equal to Less than Greater than Less than or equal to Greater than or equal to
Table 9 - Operators and their meanings
The relational operator and value shall correspond to a DATEX code type.
Boolean: No (binary) Operator needed;
Unsorted: Only equal or not equal Operators;
Sorted: All Operators.
Page 53 ENV 13777:2000 8.7.5 Filter Message [informative] Message information:
Message Sender (see ENV 13106).
The Message Function is a code indicating the purpose of the message. Possible indicators include: End, Cancel, Update, New.
Filter Reference is a unique alphanumeric reference for the filter (see 8.7.4.1).
The Validity Start Time is the date/time when the filter is put into effect (see 8.7.4.1).
The Validity Stop Time is the date/time when the filter becomes inactive (see 8.7.4.1).
Delivery interval (see 8.7.4.1 and ENV 13106).
The Filter Action is a code indicating whether the selection applies to Element Only (E) or to the Whole Situation (W) (see 8.7.4.1). The Data Delivery Mode is a code indicating the delivery mode (see 8.7.4.1 and ENV 13106).
Geographical Filter (see 8.7.4.1).
Filter Expression (see 8.7.4.1).
Physical format: For the Filter message, using EDIFACT, the TRAREQ message is used. 8.7.6 Filter Status Message [informative] Message Information
Message Sender (see ENV 13106).
Filter Reference (see 8.7.4.1).
The Filter Status is a code indicating the status of the request. Possible indicators include: Approval, Rejection, Rejection with Suggestion.
The Filter Suggestion is a description of suggested filter data.
Physical format: For the Filter message, using EDIFACT, the TRAREQ message is used.
Page 54 ENV 13777:2000 8.7.7 Filter fax form example [informative] DATEX FILTER FAX FORM From: Fax: To: Fax: Filter Id (aaaaaa)
Date (dd/mm/yy)
Time (hh:mm)
O
Request
O
Rejection
O
Approval
O
Rejection with Suggestion
O
End, Cancel
O
Update
O
New
O
One Shot
O
Periodic
O
On Occurrence
O
Element Only
O
Whole Situation
Date (dd/mm/yy)
Time (hh:mm)
Days (dddd)
Time (hh:mm)
Filter Start Time Filter Stop Time
Filter Periodicity Filter Expression:
Geographical Filter or Measurement point list:
Page 55 ENV 13777:2000
8.8 Supplier: Send data External Interface [normative] Input ClientId, Data to be sent. Output Message DATA DISTRIBUTION to Client. Process Description [informative] Convert the Data to be sent into a physical format. Find the network address of Client using ClientId. Transfer the produced file to the Client. If the Client cannot be contacted: - Inform the Operator, - Undertake the actions specified in item 24 of the Interchange Agreement (see 8.2).
8.9 Client: Receive data This function processes data distribution messages from a Supplier. These messages occur in the shape of a file in an input directory at the Client site. It is the obligation of the Client to remove old files in the input directory in order to avoid duplicate names. External Interface [normative] Input Receipt of DATA DISTRIBUTION message from Supplier. Output Translated message or error message in case of incorrect messages. If necessary, data storage of received information. File removed from input directory. Process Description [informative] The Client scans his input directory for incoming files or sets up an interrupt routine that will inform him that a file has arrived. When a file is seen it is read and converted into an in house format - possibly in a database. After being processed, the file shall be removed from the input directory. The Client shall assure that he does not attempt to read the file before the Supplier has finished writing it.
8.10 Supplier and Client: Diversion 8.10.1 Introduction In case of incidents occurring on cross-regional1 roads, a recommendation of cross-regional alternative routes might be useful. In such situations a concerted agreement on traffic 1
in this chapter, “region” is a generic term which could be “country” in some cases.
Page 56 ENV 13777:2000 guidance between the authorities of the affected regions which are responsible for traffic guidance is necessary. Figure 19 shows two different situations.
Figure 19 - Scheme of situation sites
Situation 1 takes place in region 1, affecting traffic travelling from region 1 to region 2 requiring guidance onto an alternative route starting in region 1 running through region 3. The message has to be disseminated to drivers in region 1 in front of the decision point. This is a request by region 1 with agreement by region 2 and 3 necessary. Situation 2 takes place in region 2, affecting traffic travelling from region 1 to region 2 requiring guidance onto an alternative route starting in region 1 running through region 3. The message has to be disseminated to drivers in region 1 in front of the decision point. This is a request by region 1 with agreement by region 2 and 3 necessary. 8.10.2 Agreement Process There shall be a centre who should lead the whole agreement process. This centre can be either be the responsible organisation in the area where the decision point stands or the responsible organisation in the area where the problems occur. Figure 20 shows the agreement process.
Page 57 ENV 13777:2000
Figure 20 - Flow chart of Agreement Process
8.10.3 Messages exchange After the transmission of messages which describe the situation itself (DATA DISTRIBUTION), the necessary information exchange process requires several different stages:
Page 58 ENV 13777:2000 1. Agreement process The transmission of a request for agreement on an alternative route including a proposal for that alternative route (AGREEMENT REQUEST). The transmission of answers to the request (AGREEMENT ANSWER):
Agreement;
Rejection without proposal;
Rejection with new proposal. 2. The transmission of a message describing the agreed alternative route (DATA DISTRIBUTION).
Leading Sub-System
Concerned Sub-System
AGREEMENT REQUEST
AGREEMENT ANSWER AGREEMENT REQUEST
AGREEMENT ANSWER DATA DISTRIBUTION
Figure 21 - Messages between the Leading sub-system and the Concerned sub-system.
8.10.4 Functional description of Traffic/Travel Responsibilities Agreement Process 8.10.4.1 Introduction During the Agreement Process, we can say that the Leading sub-system is the Client subsystem and the Concerned sub-systems are the Suppliers’ sub-systems. There is one Client and one or more Supplier sub-systems. 8.10.4.2 Client 8.10.4.2.1 Send Agreement Request
The Client sub-system Operator2 uses this function to ask for an agreement on a proposal to the Supplier sub-system Operators. External Interface [normative] Input 2
In this chapter, “Operator” could be replaced by “Application”
Page 59 ENV 13777:2000 Information from Operator: Concerned SupplierIds, Proposal for agreement. Output Message AGREEMENT REQUEST to Concerned SupplierIds, containing: ClientId, Agreement Request Reference, Proposal for agreement. Process Description [informative] Compose and send the AGREEMENT REQUEST message to the Concerned Suppliers. 8.10.4.2.2 Receive Agreement Answer
This function gives the Client sub-system an Answer from Suppliers sub-system Operator to the Operator Agreement Proposal. External Interface [normative] Input Message AGREEMENT ANSWER from Supplier. Output Information to Operator, containing: Agreement Request Reference, SupplierId, Agreement -or- Rejection without proposal, -or- Rejection with new proposal for agreement. Process Description [informative] Compose the presentation of Agreement Answer for the Operator. 8.10.4.3 Supplier 8.10.4.3.1 Receive Agreement Request
This function presents the Agreement Proposal to the Operator and executes the Send Agreement Answer Function. External Interface [normative] Input Message AGREEMENT REQUEST from Client.
Page 60 ENV 13777:2000 Output Information to Operator, containing: ClientId, Proposal for agreement. Information to Send Agreement Answer Function, containing: Agreement Request Reference, ClientId. Process Description [informative] Compose the presentation of agreement request for the operator and execute Send Agreement Answer Function. 8.10.4.3.2 Send Agreement Answer
This function gives a response from the Supplier Operator to a Proposal for agreement. External Interface [normative] Input Information from Receive Agreement Request Function: Agreement Request Reference, ClientId. 0
Information from Operator:
Agreement -or- Rejection without proposal,
1
-or- Rejection with new proposal for agreement.
Output Message AGREEMENT ANSWER to ClientId, containing: SupplierId, Agreement Request Reference,
Agreement
0
-or- Rejection without proposal,
1
-or- Rejection with new proposal for agreement.
Page 61 ENV 13777:2000 Process Description [informative] Compose and send the AGREEMENT ANSWER message to the Client. 8.10.5 Proposal for alternative route A proposal shall have one decision point, this is the point where the alternative route begin. One alternative route description with one or more destinations may also be included. An alternative route description consists of one segment or a sequence of segments along the diversion. The segment can be wholly predefined by a code or can be given by a primary (Downstream) and secondary location code (Upstream). In special case, only traffic heading for a particular destination is recommended to divert, the destinations can be indicated by one or several location codes. Example: Alternative route 1:
Alternative route 2:
Decision point=101
Decision point=102
Destination=71
Destination=73 and 77
Route=534 Brussels”
1131
- not used -
3055
- not used -
3232
ALERT C direction, named (value of LDN)
For point or linear locations, data element 3233 (ALERT C direction) shall be used to indicate the direction(s) affected. For 3233 (ALERT C direction) use P or p if the extent is negative and N or n if the extent is positive unless both directions are affected (B or b) or the direction is unknown (U, u or *). Method 2: ALERT C based - Predefined primary and secondary locations This method refers to method 1.2.2 of prENV ISO 14819-3 (see 4) and the predefined primary and secondary locations use ALERT C location codes. The use of the generic data elements in the LOC segment in this method is as follows: 3227
Location usage (value of LOT)
M an..3
3225
ALERT C location code (primary) (value of LCO) M n..25
Example: LOC Example: 12345
Page 96 ENV 13777:2000 1131
Location referencing method (value of LRM)
3055
ALERT C location table reference (value of LTR) M an..3
3224
ALERT C location name (value of LNA)
3223
ALERT C location code (secondary) (value of LCO)
1131
- not used -
3055
- not used -
M an..3
i.e. 2 Example: F17
C an..70
C n..25 Example: 12347
3222
ALERT C location name (value of LNA)
C an..70
3233
ALERT C direction (value of RDI)
C a1
Example: P
C an..70
Example: “Lille -> Brussels”
1131
- not used -
3055
- not used -
3232
ALERT C direction, named (value of LDN)
For point or linear locations, data element 3233 (ALERT C direction) shall be used to indicate the direction(s) affected. Method 3: ALERT C based - Predefined primary location + extent + distances This method refers to method 1.2.5 of prENV ISO 14819-3 (see 4) and the predefined primary location uses one ALERT C location code. The offset distances are given in the QTY segment of the relevant message (codes DPL and DSL). The use of the generic data elements in the LOC segment in this method is as follows: 3227
Location usage (value of LOT)
3225
ALERT C location code (primary) (value of LCO) M n..25
Example: 12345
1131
Location referencing method (value of LRM)
M an..3
i.e. 3
3055
Alert C location table reference (value of LTR)
M an..3
Example: F17
3224
ALERT C location name (value of LNA)
C an..70
3223
ALERT C extent (value of LEX)
C n..2
1131
- not used -
3055
- not used -
M an..3
3222
ALERT C location name (value of LNA)
C an..70
3233
ALERT C direction (value of RDI)
C a1
1131
- not used -
3055
- not used -
Example: LOC
Example: -2
Example: P
Page 97 ENV 13777:2000 3232
ALERT C direction, named (value of LDN)
C an..70
Example: “Lille -> Brussels”
For point or linear locations, data element 3233 (ALERT C direction) shall be used to indicate the direction(s) affected. For 3233 (ALERT C direction) use P or p if the extent is negative and N or n if the extent is positive unless both directions are affected (B or b) or the direction is unknown (U, u or *). Method 4: ALERT C based - Predefined primary and secondary locations + distances This method refers to method 1.2.6 of prENV ISO 14819-3 (see 4) and the predefined primary and secondary locations use ALERT C location codes. The offset distances are given in the QTY segment of the relevant message (codes DPL and DSL). The use of the generic data elements in the LOC segment in this method is as follows: 3227
Location usage (value of LOT)
3225
ALERT C location code (primary) (value of LCO) M n..25
Example: 12345
1131
Location referencing method (value of LRM)
M an..3
i.e. 4
3055
Alert C location table reference (value of LTR)
M an..3
Example: F17
3224
ALERT C location name (value of LNA)
C an..70
3223
ALERT C location code (secondary) (value of LCO)
1131
- not used -
3055
- not used -
M an..3
3222
ALERT C location name (value of LNA)
C an..70
3233
ALERT C direction (value of RDI)
C a1
1131
- not used -
3055
- not used -
3232
ALERT C direction, named (value of LDN)
C an..70
Example: LOC
C n..25 Example: 12347
Example: P
Example: “Lille -> Brussels”
For point or linear locations, data element 3233 (ALERT C direction) shall be used to indicate the direction(s) affected.
Page 98 ENV 13777:2000
13.4 Traffic/Travel Situation Information Message (TRAVIN) 13.4.1 Scope 13.4.1.1 Functional Definition [normative] The Traffic/Travel Situation Information Message (TRAVIN) serves parties that send and/or receive traffic/travel information (Example: traffic/travel information or control centres, telecommunications services, broadcasters, police, road authorities, public transport operators, breakdown/rescue services, freight operators, individual travellers), conveying information relating to one traffic/travel situation such as an accident, roadworks, public transport delay, snowstorm, or security alert. 13.4.1.2 Principles [informative] This message is meant to comply with the operational requirements of organisations concerning the notification/dissemination of traffic/travel situation information. 1.
Each TRAVIN message conveys information about one element which consists of one data object, one phrase, one location and one or several attributes.
2.
Each TRAVIN message conveys information relating to one version of a situation element. A traffic/travel situation is a set of traffic/travel circumstances with a particular cause, or causes (Example: a specific accident). Each situation consists of one or more situation elements. Further clarifications regarding the interpretation of a traffic/travel situation are as follows:
the definition refers to an actual, real-life traffic/travel situation (Example: one specific accident), not to a class of traffic/travel situations (Example: accidents in general).
EXAMPLE 1:
accident at a location in Paris
accident at a location in Brussels
These are two different traffic/travel situations. Although they share the same ‘type’ of traffic/travel circumstances, they refer to two unrelated real-life situations. EXAMPLE 2:
snow affecting road E19
snow affecting road E40
If it is the same snowstorm affecting both locations (likely to be geographically close to one another) then they can be regarded as one traffic/travel situation. If it is two separate snowstorms, in different parts of the country, they should be regarded as two traffic/travel situations. EXAMPLE 3:
roadworks on E19, at km 10.4 (primary location)
slow traffic on E19, from km 9.0 (secondary location) to 10.4 (primary location).
Page 99 ENV 13777:2000 Since the slow traffic is related to the roadworks, these constitute one traffic/travel situation. The phrases ‘roadworks’ and ‘slow traffic’ (i.e. set of two phrase codes) relate to a single cause. EXAMPLE 4:
roadworks on E19, at km 10.4
slow traffic on E19, from km 24.2 to 27.3.
Since the slow traffic and roadworks are unrelated, these constitute two traffic/travel situations. The phrase ‘roadworks’ applies to one location, and the phrase ‘slow traffic’ applies to the other. EXAMPLE 5:
roadworks on E19, at km 10.4
roadworks on E19, from km 24.2 to 27.3.
Since the two sets of roadworks may be regarded as related or unrelated, this can be treated as either one, or two traffic/travel situations. The phrase ‘roadworks’ applies to both locations, but it may, or may not, be considered to relate to a single cause. 3.
A traffic/travel situation may be an event (Example: an accident, or roadworks) and/or a traffic/travel status report (Example: an indication of level-of-service).
4.
Each message relates to one version of an element of the situation. A traffic/travel situation contain several pieces of information is split in different messages, Example: as it is known at different times, or for the different routes affected. Remark: To describe all traffic/travel situations relating to one area might imply accumulation of many traffic/travel situation messages from the same or several information sources.
5.
A traffic/travel information message shall contain one phrase and data object describing the traffic/travel situation. Each phrase and data object addresses one element of the situation (Example: Element 1: roadworks; Element 2: slow traffic). Each phrase and data object, with its corresponding attributes (location, time, etc.) relates to a situation element - a part of the situation.
6.
The TRAVIN message shall be based on agreed operating practices regarding the notification of relevant traffic/travel situations to the receiving party. N.B. This may mean that in a certain application, a data element (or qualifier) that is conditional according to this specification becomes mandatory for that application.
7.
A traffic/travel information message may address one affected location.
8.
Each traffic/travel information message shall only contain information of one particular type (Example: driver information, rerouting information). A Message Type element indicates the operational structure and content of the information.
9.
A traffic/travel situation may affect one or more routes. Also, a single route or location may contain one or more traffic/travel situations at a particular time.
10.
A TRAVIN message may be sent according to existing agreements with the recipient, or in response to an earlier traffic/travel information request (TRAREQ) message. Requester ---- -----
Page 100 ENV 13777:2000 13.4.2 Message Definition 13.4.2.1 Data Segment Clarification [normative] See 13.1.3. UNH, Message header This mandatory segment is used to head, identify and specify a message. Each message shall be assigned a unique message reference number by the sender’s software. 010 0062 MESSAGE REFERENCE NUMBER
M an..14 software generated
020 S009 MESSAGE IDENTIFIER
M
0065 Message type
M an..6
i.e. TRAVIN
0052 Message version number
M an..3
i.e. 14
0054 Message release number
M an..3
i.e. 97B
0051 Controlling agency
M an..2
i.e. DX
0057 Association assigned code
C an..6
030 0068 COMMON ACCESS REFERENCE
C an..35
040 S010 STATUS OF THE TRANSFER
C
0070 Sequence of transfers
M n..2
0073 First and last transfer
C a1
BGM, Beginning of message This segment shall be used once to indicate the identifying situation reference and element reference of the information contained in the message. Situation reference and element reference are unique identifier to the situation element when used in combination with the information supplier identification. BGM is also used to indicate the message type/subtype. 010 C002 DOCUMENT/MESSAGE NAME 1001 Document/message name, coded Message type, coded 1131 Code list qualifier Code list version number (value of CLV)
C C an..3 M an..3 C an..3 M n..3
3055 Code list responsible agency, coded
C an..3
1000 Document/message name
C an..35
Situation reference (value of SNM) 020 C106 DOCUMENT/MESSAGE IDENTIFICATION 1004 Document/message number
i.e. 1
i.e. 1
M an..35 Example: 101 C C an..35
Page 101 ENV 13777:2000 Element reference (value of ERF)
M an..35 Example: 1
1056 Version
C an..9
Specification version (value of SVE)
C an..9
1060 Revision number
i.e. 1.2
C an..6
Data dictionary version (value of DDV)
C an..6
i.e. 3.1
030 1225 MESSAGE FUNCTION, CODED (value of MFU)
C an..3
Example: 1
040 4343 RESPONSE TYPE, CODED
C an..3
Message type for traffic/travel situation messages, given in the first character of 1001, shall be 1 (i.e. Type 1 messages). Message function, coded, can be used to indicate the nature and purpose of the information carried in the message. Message function, coded can also be used to indicate that this message contains a request for approval of a proposed diversion through another jurisdiction or a response to such a request. Similarly, it can be used to indicate that this message contains a request from a freight operator for approval of an individual vehicle’s route (Example: for a hazardous load, or an exceptional/abnormal load - overweight/over dimension). Message function, coded, types are as follows:
information only (default value)
1
diversionary route request
16
approval of diversionary route
29
rejection of request for diversionary route
27
alternative diversionary route proposal
ALT
vehicle route request
SVR
approval of vehicle route
CVR
rejection of request for vehicle route
RVR
alternative vehicle route proposal
AVR
DTM, Date/time/period This segment shall be used on the top level to indicate the message sending time, the element start time, and the input time. DTM can also be used on the top level to indicate other times which apply to the element information as a whole, as specified below.
Page 102 ENV 13777:2000 010 C507 DATE/TIME/PERIOD
M
2005 Date/time/period qualifier
M an..3
2380 Date/time/period
C an..35
Date/time/period
Example: MST
M an..35 Example: 199610141010P03
2379 Date/time/period format qualifier
C an..3
Example: 303
The following qualifiers can be used in DTM occurrences (data element 2005): Qualifier Default format
message sending time
MST
303 CCYYMMDDHHMMZZZ
start time
STA
303 CCYYMMDDHHMMZZZ
input time
INP
303 CCYYMMDDHHMMZZZ
confirmation time
CNT
303 CCYYMMDDHHMMZZZ
stop time
STO
303 CCYYMMDDHHMMZZZ
element version time
VET
303 CCYYMMDDHHMMZZZ
request time
REQ
303 CCYYMMDDHHMMZZZ
expiry time
EXP
303 CCYYMMDDHHMMZZZ
next departure time
NTI
303 CCYYMMDDHHMMZZZ
entering delay
DEN
401 HHMM
leaving delay
DLE
401 HHMM
delay time value
DLT
401 HHMM
duration value
DUV
401 HHMM
travel time numerical value
TTV
402 HHMMSS
link time
LTT
402 HHMMSS
coded delay time
DLC
N
coded duration
DUR
AN
day until
DUN
804 N
day of week
DOW
804 N
time of day
TOD
401 HHMM
time until
UTM
401 HHMM
When format 303 is used, CCYYMMDDHHMM shall be UTC, and ZZZ contains the local offset from UTC. The codes P and M shall be used for + and - respectively. Use of the default formats is recommended, for consistency purposes. It is recommended that the date/time/period format qualifier is given in data element 2379.
Page 103 ENV 13777:2000 GIS, General indicator This optional segment can be used to indicate various items which refer to the situation element. 010 C529 PROCESSING INDICATOR
M
7365 Processing indicator, coded
M an..3
Indicator qualifier
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
7187 Process type identification
C an..17
Indicator value
Example: ARI
C an..17 Example: 1
The following qualifiers can be used in this segment (data element 7187): area of interest
ARI
Example: 1
broadcast
BRO
Example: Y
cancel
CAN
Example: Y
cause
PHC
Example: Y
compass point direction
DRC
Example: ENE
confidentiality
SEEI
Example: 1
delivery mode
DMD
Example: P
diversion advice
DAD
Example: Y
end
END
Example: Y
filter end
FIL
Example: Y
forecast
FOR
Example: Y
message priority
MPR
Example: 1
mobility
MBY
Example: M
motoring conditions
MOT
Example: 1
nature
NAT
Example: F
out of range
OOR
Example: Y
Probability, coded
PHQ
Example: d
quality index
QIN
Example: 1
reference time
RTI
Example: L
subscription
SUT
Example: 1
severity
SEV
Example: 1
urgency
URG
Example: N
wind direction compass
WDD
Example: ENE
Page 104 ENV 13777:2000 LOC, Location This segment shall be used once to indicate the element location for situation information or the element rerouting decision point within the diversionary route agreement process. Further occurrences can also be used to indicate a variety of other location types. 010 3227 PLACE/LOCATION QUALIFIER LOCATION USAGE (value of LOT - see below)
020 C517 LOCATION IDENTIFICATION LOCATION IDENTIFICATION 3225 Place/location identification ALERT C location code (primary) (value of LCO) 1131 Code list qualifier Location referencing method (value of LRM) 3055 Code list responsible agency, coded ALERT C location table reference (value of LTR) 3224 Place/location ALERT C location name (value of LNA)
030 C519 RELATED LOCATION ONE IDENTIFICATION 3223 Related place/location one identification - see 13.3 1131 Code list qualifier Code list version number
M an..3 M an..3
C M C an..25 M an..25 C an..3 M an..3 C an..3 M an..3 C an..70 C an..70
C C an..25 C an..25 C an..3 C an..3
3055 Code list responsible agency, coded
C an..3
Code list responsible agency
C an..3
3222 Related place/location one ALERT C location name (value of LNA)
040 C553 RELATED LOCATION TWO IDENTIFICATION 3233 Related place/location two identification ALERT C direction (value of RDI) 1131 Code list qualifier Code list version number 3055 Code list responsible agency, coded
C an..70 C an..70
C C an..25 M an..3 C an..3 C an..3 C an..3
Code list responsible agencyC an..3 3232 Related place/location two
C an..70
ALERT C direction, named (value of LDN)
C an..70
Example: LOC
Page 105 ENV 13777:2000 050 5479 RELATION, CODED
C an..3
The following qualifiers can be used in LOC occurrences (data element 3227):
element location
LOC
element rerouting destination location
RDL
element rerouting decision point
RDP
element rerouting locations
RDD
element distribution location
DIL
element presentation location
PAL
location of source of problem
LSP
Within the above generic framework, alternative methods of location referencing are supported. The alternative methods are described in 13.3. Data element 3232 (ALERT C direction, named) is given to provide additional information concerning the positive direction. The positive direction described in data element 3232 (ALERT C direction, named) shall be coherent with the positive direction described in the location referencing method used. NAD, Name and address This segment shall be used to indicate the identity of the message sender within the application. It can also optionally be used to indicate the original information source type, and the source name or source identification. In the mandatory first occurrence of this segment, the message sender identity data takes the form , where the country code is given by a two letter ISO 2-alpha code and the user identifier is three characters. The message sender is unique across the network. In the optional, second occurrence of this segment (indicated by a qualifier which is not MSE), the source of information can be indicated. Source name should only be used in cases where no source identification (coded) is available. It can also be used to define a new source identification (coded). 010 3035 PARTY QUALIFIER
M an..3
Message sender (“MSE”) / source type qualifier (values of SOT)
020 C082 PARTY IDENTIFICATION DETAILS 3039 Party id. identification Message sender/source identification (SID)
M an..3
C M an..35 C an..35 Example: GBAAR
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
030 C058 NAME AND ADDRESS
Example: MSE
C
Page 106 ENV 13777:2000 3124 Name and address line
M an..35
3124 Name and address line
C an..35
3124 Name and address line
C an..35
3124 Name and address line
C an..35
3124 Name and address line
C an..35
040 C080 PARTY NAME 3036 Party name Source name (SNA)
C M an..35 C an..35 Example: British Rail
3036 Party name
C an..35
3036 Party name
C an..35
3036 Party name
C an..35
3036 Party name
C an..35
3045 Party name format, coded
C an..3
050 C059 STREET
C
3042 Street and number/p.o. box
M an..35
3042 Street and number/p.o. box
C an..35
3042 Street and number/p.o. box
C an..35
3042 Street and number/p.o. box
C an..35
060 3164 CITY NAME
C an..35
070 3229 COUNTRY SUB-ENTITY IDENTIFICATION
C an..9
080 3251 POSTCODE IDENTIFICATION
C an..9
090 3207 COUNTRY, CODED
C an..3
Segment Group 1: RFF-DTM This mandatory segment group is included for compatibility with existing EDIFACT transport applications. The DTM segment below RFF is not currently used in ATT applications. RFF, Reference This segment shall be used at least once in SG1 to indicate the ALERT C location table version number. Further occurrences may be used to indicate the element version number, and/or the order number. It can also be used to cross-reference a related situation (Example: a secondary accident). Where a diversionary route agreement is being sought the rerouting agreement request reference indicates the unique reference when used in combination with the information supplier.
Page 107 ENV 13777:2000 010 C506 REFERENCE
M
1153 Reference qualifier
M an..3
1154 Reference number
C an..35
Reference value
Example: ORN
M an..35 Example: A102
1156 Line number
C an..6
4000 Reference version number
C an..35
1060 Revision number
C an..6
The following qualifiers can be used:
action plan identifier
API
element version number
VNM
extended location type code
ELT
lane
LNP
link with other traffic/travel situation
LNK
Alert C location table version number
LTV
order number
ORN
rerouting agreement request reference
RAR
TMC message reference
TMN
Message chain
MCH
Vehicle classification
CLA
Vehicle class
VCL
Individual vehicle ID
VID
Message reference
MRF
Nationality
NAL
Service number
SEN
Number of situation elements
NSE
Page 108 ENV 13777:2000 DTM, Date/time/period This segment is not currently used. STS, Status This segment shall be used at least twice to specify the characteristics of the traffic/travel situation being reported in this situation element. One (and only one) occurrence indicates the element data object code related to this element. A further one (and only one) occurrence indicates the element phrase code related to this element. Further optional occurrences indicate element supplementary advice codes with enhance the information relating to the element. 010 C601 STATUS CATEGORY 9015 Status category, coded Qualifier
C M an..3 M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
020 C555 STATUS
C
4405 Status, coded
M an..3
Coded value
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
4404 Status
C an..35
030 C556 STATUS REASON
C
9013 Status reason, coded
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
9012 Status reason
C an..35
040 C556 STATUS REASON
C
9013 Status reason, coded
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
9012 Status reason
C an..35
050 C556 STATUS REASON
Example: PHR
C
9013 Status reason, coded
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
Example: ACC
Page 109 ENV 13777:2000 9012 Status reason
C an..35
060 C556 STATUS REASON
C
9013 Status reason, coded
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
9012 Status reason
C an..35
070 C556 STATUS REASON
C
9013 Status reason, coded
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
9012 Status reason
C an..35
The following qualifiers can be used in STS segments (data element 9015):
data object
DOB
element supplementary advice
SAD
phrase
PHR
QTY, Quantity This optional segment can be used to indicate quantities associated with a situation element. 010 C186 QUANTITY DETAILS
M
6063 Quantity qualifier
M an..3
Example: LEN
6060 Quantity
M n..15
Example: 21.7
6411 Measure unit qualifier
C an..3
Unit qualifier (value of UNI)
C an..3
Example: KMT
The following qualifiers can be used (data element 6063): Qualifier
Default units
above stated altitude
ALG
m
MTR
accuracy
ACU
%
PER
advisory speed limit
SPA
km/h
KMH
air temperature
ATE
°C
CEL
Page 110 ENV 13777:2000
AM frequency
AMH
kHz
KHZ
atmospheric pressure at sea level
APR
hPa (mbar)
HPA
average speed numerical value
AVV
km/h
KMH
average wind speed
WDS
km/h
KMH
below stated altitude
BSA
m
MTR
capacity remaining
CYR
%
PER
car park occupancy
POC
%
PER
carbon monoxide concentration
CMC
PPM
PPM
channel number
NCH
-
concentration numercial value
CTV
veh/km
VPK
depth
DPH
mm
MMT
direction bearing
DIR
degrees
DEG
distance from primary location
DPL
m
MTR
distance from secondary location
DSL
m
MTR
FM frequency
FMH
MHz
MEZ
gross vehicle weight
GVW
Tonnes
TNE
journey number
JRN
-
length affected
LEN
km
KMT
mandatory speed limit
SPM
km/h
KMH
maximum permitted axle weight
MAW
Tonnes
TNE
maximum temperature
MTE
°C
CEL
maximum wind speed
MWS
km/h
KMH
measurement length
MLE
km
KMT
methane concentration
CH4
PPM
PPM
minimum car occupancy
OCP
-
minimum temperature
MIT
O
C
CEL
nitrogen dioxide concentration
N2C
PPM
PMM
nitrogen monoxide concentration
NOC
PPM
PPM
Non methane hydrocarbon concentration
NMC
PPM
PPM
number of accidents
NAC
-
number of bridges
NBR
-
number of broken down vehicles
NBV
-
number of burst pipes
NBP
-
number of buses
NBU
-
number of caravans
CAV
-
-
Page 111 ENV 13777:2000
number of convoys
NCY
-
number of deaths
DEA
-
number of drivers
NRD
-
number of fallen trees
NFT
-
number of heavy lorries
NHL
-
number of heavy vehicles
NHV
-
number of incidents
NIC
-
number of injured
INJ
-
number of lanes
NLN
-
number of loads
NLD
-
number of objects
NOJ
-
number of obstructions
NOB
-
number of queues
NLQ
-
number of ramp controls
NRC
-
number of service lanes
NSL
-
number of sewers
NSW
-
number of shed loads
NSH
-
number of trailers
TAI
-
number of vacant parking spaces
NPS
-
number of vehicles
NVE
-
number of vehicles on fire
NVF
-
number of waiting vehicles
NWV
-
occupancy numerical value
OCV
%
original number of lanes
ONL
-
ozone concentration
O3C
PPM
PPM
PCU flow numercial value
FLV
pcu/hour
PCH
precipitation intensity
PIN
mm/h
MMH
precipitation or deposition depth
PDD
mm
MMT
primary particulate concentration
PPP
PPM
PPM
probability
PRB
%
PER
queue length
QUE
km
KMT
ratio of a vehicle class in a traffic flow
VSEE
%
PER
relative humidity
HUM
%
PER
road surface temperature
RTE
°C
CEL
-
PER
Page 112 ENV 13777:2000
sections of resurfacing work
SRR
-
sequential ramp number
SEQ
-
sets of blasting work
SBL
-
sets of construction work
SCR
-
sets of maintenance work
SMW
-
sets of road marking work
SRM
-
sets of roadworks
SRW
-
sets of slow moving maintenance vehicles
SMM
-
sets of temporary traffic lights
NTL
-
sets of traffic lights
STL
-
speed reduction
SPV
km/h
KMH
speed reduction ratio
SPR
%
PER
sulphur dioxide concentration
S2C
PPM
PPM
sun radiation net
SRN
Watt/m2
WM2
2
-
sun total radiation
STR
Watt/m
WM2
test message number
TES
-
-
total hydrocarbons concentration
THC
PPM
PPM
travel time increase
TTI
%
PER
vehicle flow numerical value
VFV
veh/day
VHD
vehicle height
HEI
m
MTR
vehicle length
VLN
m
MTR
vehicle speed
IVS
km/h
KMH
vehicle weight
WEI
tonnes
TNE
vehicle width
WID
m
MTR
visibility
VIS
m
MTR
volume of dangerous goods
VDG
m3
MCU
weight of dangerous goods
WDG
tonnes
TNE
wind direction bearing
WDB
degrees
DEG
wind measurement height
WMH
m
MTR
Page 113 ENV 13777:2000 FTX, Free text This optional segment can be used to add a free text qualifier or to add a comment to a phrase, but should not be used to replace use of a phrase. A default language can be specified in the interchange agreement. 010 4451 TEXT SUBJECT QUALIFIER
M an..3
020 4453 TEXT FUNCTION, CODED
C an..3
030 C107 TEXT REFERENCE
C
4441 Free text identification
M an..17
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
040 C108 TEXT LITERAL
Example: SUR
C
4440 Free text
M an..70
4440 Free text
C an..70
4440 Free text
C an..70
4440 Free text
C an..70
4440 Free text
C an..70
050 3453 LANGUAGE, CODED
C an..3
060 4447 TEXT FORMATTING, CODED
C an..3
Example: EN
The following qualifiers can be used in FTX (data element 4451):
message display
DIS
comment (text)
SUR
chemical name
AAD
Segment Group 2: MOA-DTM An optional group of segments giving various times associated with a situation element. It can also be used to indicate a parking tariff. MOA, Monetary Amount This segment shall be used in SG2 to give the parking tariff for a time period indicated in DTM below.
Page 114 ENV 13777:2000 010 C516 MONETARY AMOUNT
M
5025 Monetary amount type qualifier
M an..3
5004 Monetary amount
C n..35
Monetary amount
M n..35
6345 Currency, coded
C an..3
6343 Currency qualifier
C an..3
4405 Status, coded
C an..3
Example: RPH
Example: 2.00
The following monetary qualifiers can be used in MOA:
cost for the duration indicated
COS
rate per hour
RPH
rate per day
RPD
Currency codes shall be ISO 4217 alpha codes. DTM, Date/time/period This segment shall be used at least once in SG2 to indicate times to which the monetary amounts in MOA apply. 010 C507 DATE/TIME/PERIOD
M
2005 Date/time/period qualifier
M an..3
2380 Date/time/period
C an..35
Date/time/period
i.e.. PAD
M an..35 Example: 0704
2379 Date/time/period format qualifier
C an..3
Example: 401
The following qualifier shall be used in DTM occurrences (data element 2005): Qualifier Default format
parking duration
PAD
401
HHMM
Use of the default formats is recommended, for consistency purposes. It is recommended that the date/time/period format qualifier is given in data element 2379. Segment Group 3: GDS-DGS An optional group of segments giving details about hazardous material loads. GDS, Nature of cargo This segment shall be used in SG3 to indicate the type of load associated with a phrase, Example: a load shed onto the roadway.
Page 115 ENV 13777:2000 010 C703 NATURE OF CARGO 7085 Nature of cargo, coded Type of load (value of LOA)
C M an..3 M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
DGS, Dangerous Goods This segment can optionally be used to give details of dangerous goods, Example: in connection with a routing request. 010 8273 DANGEROUS GOODS REGULATIONS, CODED DANGEROUS GOODS REGULATIONS (DRE)
020 C205 HAZARD CODE
C an..3 C an..3
C
8351 Hazard code identification (HCI)
M an..7
8078 Hazard substance/item/page number (HSI)
C an..7
8092 Hazard code version number (HZV)
C an..10
030 C234 UNDG INFORMATION
C
7124 UNDG number (UNN)
C n4
7088 Dangerous goods flashpoint (DGF)
C an..8
040 C223 DANGEROUS GOODS SHIPMENT FLASHPOINT
C
7106 Shipment flashpoint
C n3
6411 Measure unit qualifier
C an..3
050 8339 PACKING GROUP, CODED
C an..3
060 8364 EMS NUMBER
C an..6
070 8410 MFAG
C an..4
080 8126 TREM CARD NUMBER (TRN)
C an..10
090 C235 HAZARD IDENTIFICATION
C
8158 Hazard identification number, upper part
C an..4
8186 Substance identification number, lower part
C an4
Example: ADR
Page 116 ENV 13777:2000 100 C236 DANGEROUS GOODS LABEL
C
8246 Dangerous goods label marking
C an..4
8246 Dangerous goods label marking
C an..4
8246 Dangerous goods label marking
C an..4
110 8255 PACKING INSTRUCTION, CODED
C an..3
120 8325 CATEGORY OF MEANS OF TRANSPORT, CODED
C an..3
130 8211 PERMISSION FOR TRANSPORT, CODED
C an..3
UNDG number and TREM card number shall be used, in conjunction with the chemical name in FTX at the top level. The qualifiers to be used in data element 8273 as specified within the UN EDIFACT code lists. The most significant codes are (non-exhaustive list):
ADR European agreement on the international carriage of dangerous goods on road.
ICA IATA ICAO Regulations covering the international transportation of dangerous goods issued by the International Air Transport Association and the International Civil Aviation Organization.
IMD IMO IMDG code. Regulations regarding the transportation of dangerous goods on ocean-going vessels issued by the International Maritime Organization.
RID Railroad dangerous goods book (RID). International regulations concerning the international carriage of dangerous goods by rail.
UNT, Message trailer This mandatory service segment ends a message, giving the total number of segments in the message and the message reference number: 0074
NUMBER OF SEGMENTS IN THE MESSAGE
M n..6
software generated
0062
MESSAGE REFERENCE NUMBER
M an..14 software generated
Page 117 ENV 13777:2000 13.4.2.2 Message Structure [normative] Branching diagram See Figure 28 for the branching diagram of the TRAVIN message.
Figure 28 - Branching diagram for the TRAVIN message
Page 118 ENV 13777:2000 Segment table TAG
NAME
S
REPT
UNH
Message header
M
1
BGM
Beginning of message
M
1
DTM
Date/time/period
M
99
GIS
General indicators
C
99
LOC
Location identification
M
99
NAD
Name and address
M
9
Segment Group 1 RFF
Reference
M
1
DTM
Date/time/period
C
1
STS
Status
M
9
QTY
Quantity
C
99
FTX
Free text
C
9
Segment Group 2 MOA
Monetary amount
M
1
DTM
Date/time/period
M
9
Segment Group 3 GDS
Nature of cargo
M
1
DGS
Dangerous goods
C
1
UNT
Message trailer
M
1
Data Segment Index (Alphabetic Sequence) [informative]
BGM
Beginning of message
DTM
Date/time/period
DGS
Dangerous goods
FTX
Free text
GDS
Nature of cargo
GIS
General indicator
S
REPT
M
99
C
9
C
1
Page 119 ENV 13777:2000
LOC
Place/location identification
MOA
Monetary amount
NAD
Name and address
QTY
Quantity
RFF
Reference
STS
Status
UNH
Message header
UNT
Message trailer
13.5 Status Information, Traffic/Travel Route Guidance And Planning Message (TRAILS) 13.5.1 Scope 13.5.1.1 Functional Definition [normative] The Status Information, Traffic/Travel Route Guidance and Planning Message (TRAILS) serves parties that send and/or receive traffic/travel information (Example: traffic/travel information or control centres, road authorities, public transport operators, breakdown/rescue services, freight operators, individual travellers), conveying data (such as flows, speeds or times) relating to one or more locations in a traffic/travel network, in order to support traffic/travel planning, management and/or intelligent navigation systems. 13.5.1.2 Principles [informative] Traffic/travel planning and system management by road authorities requires exchanges of traffic/travel data such as traffic flows, speeds and classified traffic counts. Also, in-vehicle route guidance systems have been developed by the major automobile and consumer electronics companies of Europe, North America and Japan. On-board computers calculate minimum paths from traffic/travel network data, which shall be updated in real time. TRAILS data provide basic planning and management information for road and traffic authorities, police forces, etc. They can also be used to provide traffic-responsive route selection recommendations in real time, for processing in on-board navigation systems. TRAILS will allow public and private sector service providers to exchange these data in compatible formats. 1.
One TRAILS message conveys data about one or more locations on a transport network, such as links in a route guidance system.
2.
One message can be used to describe basic traffic/travel data for one or more locations, such as flows, occupancies, link speeds, link times and/or turn penalties.
3.
One message may relate to all relevant data about the locations, or to a part of these data. The data may be split in different messages, Example: as known at different times. Remark: To obtain all traffic/travel data for a region might imply accumulation of many TRAILS messages from the same or several data sources.
4.
The TRAILS message shall be based on agreed operating practices regarding the notification of relevant data to the receiving party.
Page 120 ENV 13777:2000 N.B. This may mean that in a certain application, a data element (or qualifier) that is conditional according to this specification becomes mandatory for that application. 5.
A TRAILS message may be sent according to existing agreements with the recipient, or in response to an earlier traffic/travel information request (TRAREQ) message. Requester ---- ----
13.5.2 Message Definition 13.5.2.1 Data Segment Clarification [normative] See 13.1.3. UNH, Message header This mandatory segment is used to head, identify and specify a message. Each message shall be assigned a unique message reference number by the sender’s software. The other data required in segment UNH are fixed. 010 0062 MESSAGE REFERENCE NUMBER
M an..14 software generated
020 S009 MESSAGE IDENTIFIER
M
0065 Message type
M an..6
i.e. TRAILS
0052 Message version number
M an..3
i.e. 15
0054 Message release number
M an..3
i.e. 97B
0051 Controlling agency
M an..2
i.e. DX
0057 Association assigned code
C an..6
030 0068 COMMON ACCESS REFERENCE
C an..35
040 S010 STATUS OF THE TRANSFER
C
0070 Sequence of transfers
M n..2
0073 First and last transfer
C a1
BGM, Beginning of message This segment shall be used once to indicate the message type/subtype. 010 C002 DOCUMENT/MESSAGE NAME 1001 Document/message name, coded Message type, coded
C C an..3 M an..3
i.e. 2
Page 121 ENV 13777:2000 1131 Code list qualifier
C an..3
Code list version number (CLV)
M n..3
3055 Code list responsible agency, coded
C an..3
1000 Document/message name
C an..35
020 C106 DOCUMENT/MESSAGE IDENTIFICATION
C
1004 Document/message number
C an..35
1056 Version
C an..9
Specification version (SVE)
C an..9
1060 Revision number
i.e. 1
i.e. 1.2
C an..6
Data dictionary version (DDV)
C an..6
030 1225 MESSAGE FUNCTION, CODED
C an..3
040 4343 RESPONSE TYPE, CODED
C an..3
i.e. 3.1
Message type for route guidance and planning data, given in the first character of 1001, shall be 2 (i.e. Type 2 messages). DTM, Date/time/period This segment shall be used to time-stamp the message. The mandatory time-stamps are the input time and the message sending time of the information. DTM can also be used on the top level to indicate other times which apply to the message as a whole, as specified below. 010 C507 DATE/TIME/PERIOD
M
2005 Date/time/period qualifier
M an..3
2380 Date/time/period
C an..35
Date/time/period
Example: MST
M an..35 Example: 199604181215P01
2379 Date/time/period format qualifier
C an..3
Example: 303
The following qualifiers can be used in DTM top level occurrences (data element 2005): Qualifier Default format
message sending time
MST
303 CCYYMMDDHHMMZZZ
input time
INP
303 CCYYMMDDHHMMZZZ
expiry time
EXP
303 CCYYMMDDHHMMZZZ
request time
REQ
303 CCYYMMDDHHMMZZZ
Page 122 ENV 13777:2000 When format 303 is used, CCYYMMDDHHMM shall be UTC, and ZZZ contains the local offset from UTC. The codes P and M shall be used for + and - respectively. Use of the default formats is recommended, for consistency purposes. It is recommended that the date/time/period format qualifier is given in data element 2379. When using references to the table of measurement points, the sample time for the traffic data provided is identified by the input time qualifier. GIS, General indicator This optional segment can be used to indicate various items which refer to the message information. 010 C529 PROCESSING INDICATOR
M
7365 Processing indicator, coded
M an..3
Indicator qualifier
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
7187 Process type identification
C an..17
Indicator value
Example: MPR
C an..17 Example: 2
The following qualifiers can be used in this segment (data element 7187):
area of interest
ARI
Example: 1
cancel
CAN
Example: Y
confidentiality
CFI
Example: 1
end
END
Example: Y
filter end
FIL
Example: Y
forecast
FOR
Example: Y
message priority
MPR
Example: 1
out of range
OOR
Example: Y
Probability, coded
PHQ
Example: d
quality index
QIN
Example: 1
reference time
RTI
Example: L
severity
SEV
Example: 1
LOC, Location This segment can be used on the top level to indicate the distribution and/or presentation areas of the message. 010 3227 PLACE/LOCATION QUALIFIER
M an..3
Page 123 ENV 13777:2000 LOCATION USAGE (value of M an..3 Example: DIL
LOT - see below)
020 C517 LOCATION IDENTIFICATION
C
LOCATION IDENTIFICATION
M
3225 Place/location identification
C an..25
ALERT C location code (primary) (value of LCO) 1131 Code list qualifier
M an..25 C an..3
Location referencing method (value of LRM)
M an..3
3055 Code list responsible agency, coded
Example: 2
C an..3
Alert C location table reference (value of LTR) 3224 Place/location
M an..3
Example: F17
C an..70
ALERT C location name
C an..70
030 C519 RELATED LOCATION ONE IDENTIFICATION 3223 Related place/location one identification
C C an..25
- see 13.3 -
C an..25
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
3222 Related place/location one
C an..70
ALERT C location name
C an..70 DATEX
040 C553 RELATED LOCATION TWO IDENTIFICATION 3233 Related place/location two identification
C C an..25
ALERT C direction (value of RDI)
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
3232 Related place/location two
C an..70
ALERT C direction, named (value of LDN)
C an..70
050 5479 RELATION, CODED
C an..3
The following qualifiers can be used in LOC top level occurrences (data element 3227):
distribution area
DIL
presentation area
PAL
Where location referencing methods 3 and 4 (see 13.3) are used the offset distance (distance from primary location and distance from secondary location) are contained within the QTY segment in SG3.
Page 124 ENV 13777:2000 Data element 3232 (ALERT C direction, named) is given to provide additional information concerning the positive direction. The positive direction described in data element 3232 (ALERT C direction, named) shall be coherent with the positive direction described in the location referencing method used. Segment Group 1: RFF-DTM This mandatory segment group is included for compatibility with existing EDIFACT transport applications. The DTM segment below RFF is not currently used in ATT applications. RFF, Reference This segment shall be used once in SG1 to indicate the location table version number. Further occurrences may be used to indicate the element version number, the order number and/or to cross-reference a related situation (Example: a secondary accident). 010 C506 REFERENCE
M
1153 Reference qualifier
M an..3
1154 Reference number
C an..35
Reference value
Example: ORN
M an..35 Example: A102
1156 Line number
C an..6
4000 Reference version number
C an..35
1060 Revision number
C an..6
The following qualifiers can be used:
element version number
VNM
link with other traffic/travel situation
LNK
order number
ORN
Message chain
MCH
DTM, Date/time/period This segment is not currently used. NAD, Name and address This segment shall be used to indicate the identity of the message sender within the application. It can also optionally be used to indicate the original information source type, and the source name or source identification, coded. In the mandatory first occurrence of this segment, the message sender identity data takes the form , where the country code is given by the 2-alpha code as given in EN ISO 3166-1, followed by the user identifier is three characters. The message sender is unique across the network.
Page 125 ENV 13777:2000 In the optional, second occurrence of this segment (indicated by a qualifier which is not MSE), the source of information can be indicated. Source name should only be used in cases where no source identification (coded) is available. It can also be used to define a new source identification (coded). 010 3035 PARTY QUALIFIER
M an..3
Message sender qualifier (“MSE”)/ source type qualifier (values of SOT)
020 C082 PARTY IDENTIFICATION DETAILS 3039 Party id. identification Message sender/source (SID) identification, coded
M an..3
C M an..35 C an..35 Example: GBAAR
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
030 C058 NAME AND ADDRESS
C
3124 Name and address line
M an..35
3124 Name and address line
C an..35
3124 Name and address line
C an..35
3124 Name and address line
C an..35
3124 Name and address line
C an..35
040 C080 PARTY NAME 3036 Party name Source name (SNA)
C M an..35 C an..35 Example: British Rail
3036 Party name
C an..35
3036 Party name
C an..35
3036 Party name
C an..35
3036 Party name
C an..35
3045 Party name format, coded
C an..3
050 C059 STREET
C
3042 Street and number/p.o. box
M an..35
3042 Street and number/p.o. box
C an..35
3042 Street and number/p.o. box
C an..35
3042 Street and number/p.o. box
C an..35
060 3164 CITY NAME
Example: MSE
C an..35
Page 126 ENV 13777:2000 070 3229 COUNTRY SUB-ENTITY IDENTIFICATION
C an..9
080 3251 POSTCODE IDENTIFICATION
C an..9
090 3207 COUNTRY, CODED
C an..3
Segment Group 2: STA-RFF-LOC-TDT-DTM-STS-SG3-SG4 A segment group to give traffic/travel data for a specific location. Either SG2 or SG5 shall be used at least once in TRAILS. When sending traffic data using measurement points which are fully referenced in a traffic measurement point catalogue by the use of a measurement point reference are advised to use SG5 which has been optimised for this usage. STA, Statistics This segment shall be used once in SG2 to indicate the type of data given in this segment group. 010 6331 STATISTIC TYPE, CODED
M an..3
TRAFFIC DATA TYPE (value of TDT)
M a..3
020 C527 STATISTICAL DETAILS
Example: CUR
C
6314 Measurement value
C an..18
6411 Measure unit qualifier
C an..3
6313 Property measured, coded
C an..3
6321 Measurement significance, coded
C an..3
The following values can be used in STA (data element 6331):
current data
CUR
measurement point data
MPD
RFF, Reference The segment can optionally be used in SG2 to indicate direction and/or lane position for traffic data; to give an extended location type code; to specify the data object defining the type of traffic data; to specify the units that are associated with the associated measurement point; or to specify a measurement traffic equipment reference. 010 C506 REFERENCE
M
1153 Reference qualifier
M an..3
1154 Reference number
C an..35
Reference value
Example: LNP
M an..35 Example: 3
Page 127 ENV 13777:2000 1156 Line number
C an..6
4000 Reference version number
C an..35
1060 Revision number
C an..6
The following values can be used in RFF (data element 1153):
direction bearing
DIR
compass point direction
DRC
ALERT C direction
RDI
lane
LNP
traffic equipment type
TET
extended location type code
ELT
measurement point reference
F
measurement point value
V
unit
UNI
data object
DOB
measurement equipment reference
MTQ
Alert C location table version number
LTV
LOC, Location This segment shall be used at least once to define a location about which details are given in this segment group. It can also be used one or more times to indicate the distribution and/or presentation areas of route guidance data for a specific location. 010 3227 PLACE/LOCATION QUALIFIER LOCATION USAGE (value of LOT - see below)
020 C517 LOCATION IDENTIFICATION
3225
M an..3 M an..3
C
LOCATION IDENTIFICATION
M
Place/location identification
C an..25
ALERT C location code (primary) (value of LCO)
M an..25
1131 Code list qualifier Location referencing method (value of LRM) 3055 Code list responsible agency, coded Alert C location table reference (value of LTR) 3224 Place/location ALERT C location name
Example: TDL
C an..3 M an..3
Example: 2
C an..3 M an..3 C an..70 C an..70
Example: F17
Page 128 ENV 13777:2000 030 C519 RELATED LOCATION ONE IDENTIFICATION 3223 Related place/location one identification
C C an..25
- see 13.3 -
C an..25
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
3222 Related place/location one
C an..70
ALERT C location name
C an..70
040 C553 RELATED LOCATION TWO IDENTIFICATION 3233 Related place/location two identification
C C an..25
ALERT C direction (value of RDI)
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
3232 Related place/location two
C an..70
ALERT C direction, named (value of LDN)
C an..70
050 5479 RELATION, CODED
C an..3
The following qualifiers can be used in LOC occurrences (data element 3227):
traffic data location
TDL
distribution area
DIL
presentation area
PAL
measurement point location
MPL
The first and second locations and additional location details are all defined relative to the same code list, so data elements 1131 and 3055 are never needed more than once each. Senders can select default code lists and code list responsible agencies in the interchange agreement. Code lists, etc., for secondary location and direction are the same as for primary location unless otherwise indicated, and shall normally be included only once. Where the defaults apply, data elements 1131 and/or 3055 can be omitted entirely. Where the extent is zero, data element 3223/3222 can be omitted. Where the area includes both directions of travel, data elements 3233/3232 can be omitted. Where location referencing methods 3 and 4 (see 13.3) are used the offset distance (distance from primary location and distance from secondary location) are contained within the QTY segment in SG3. Data element 3232 (direction, named) is given to provide additional information concerning the positive direction. The positive direction described in data element 3232 (direction, named) shall be coherent with the positive direction described in the location referencing method used.
Page 129 ENV 13777:2000 TDT, Details of transport This optional segment can be used in SG2 to specify the vehicle class or classification to which the data apply. 010 8051 TRANSPORT STAGE QUALIFIER
M an..3
Vehicle class qualifier (VCL)/ vehicle classification qualifier (CLA)
M an..3
020 8028 CONVEYANCE REFERENCE NUMBER
C an..17
030 C220 MODE OF TRANSPORT
C
8067 Mode of transport, coded
C an..3
8066 Mode of transport
C an..17
040 C228 TRANSPORT MEANS 8179 Type of means of transport identification Vehicle class (value of VCL or CLA) 8178 Type of means of transport
050 C040 CARRIER
C C an..8 C an..8 C an..17
C
3127 Carrier identification
C an..17
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
3128 Carrier name
C an..35
060 8101 TRANSIT DIRECTION, CODED
C an..3
070 C401 EXCESS TRANSPORTATION INFORMATION
C
8457 Excess transportation reason, coded
M an..3
8459 Excess transportation responsibility, coded
M an..3
7130 Customer authorization number
C an..17
080 C222 TRANSPORT IDENTIFICATION
Example: VCL
C
8213 Id. of means of transport identification
C an..9
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
8212 Id. of the means of transport
C an..35
Example: KX1
Page 130 ENV 13777:2000 8453 Nationality of means of transport, coded
C an..3
090 8281 TRANSPORT OWNERSHIP, CODED
C an..3
The following qualifiers can be used in TDT occurrences (data element 8051):
vehicle class
VCL
vehicle classification
CLA
If the data relate to all vehicles, this segment shall be omitted. DTM, Date/time/period This optional segment can be used in SG2 to indicate times relating to data for a specific location. It can also be used to indicate a link time and/or a turn delay for current data. 010 C507 DATE/TIME/PERIOD
M
2005 Date/time/period qualifier
M an..3
2380 Date/time/period
C an..35
Date/time/period
Example: LTT
M an..35 Example: 20
2379 Date/time/period format qualifier
C an..3
Example: 806
The following qualifiers can be used in DTM within SG2 (data element 2005): Qualifier Default format link time
LTT
806 MMMM
measurement time
MTI
303 CCYYMMDDHHMMZZZ
expiry time
EXP
401 HHMM
start time
STA
303 CCYYMMDDHHMMZZZ
stop time
STO
303 CCYYMMDDHHMMZZZ
input time
INP
303 CCYYMMDDHHMMZZZ
measurement period
MEP
401 HHMM
delay time value
DLT
401 HHMM
travel time numerical value
TTV
402 HHMMSS
coded delay time
DLC
N
Use of default formats and data element 2379 shall be as specified for DTM on the top level. It is recommended that the date/time/period format qualifier is given in data element 2379.
Page 131 ENV 13777:2000 STS, Status This segment may optionally be used to specify the characteristics of the traffic data being reported. This will normally indicate the data object associated with the specified class of traffic data. 010 C601 STATUS CATEGORY 9015 Status category, coded Qualifier
C M an..3 M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
020 C555 STATUS
C
4405 Status, coded
M an..3
Coded value
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
4404 Status
C an..35
030 C556 STATUS REASON
C
9013 Status reason, coded
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
9012 Status reason
C an..35
040 C556 STATUS REASON
C
9013 Status reason, coded
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
9012 Status reason
C an..35
050 C556 STATUS REASON
C
9013 Status reason, coded
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
9012 Status reason
C an..35
060 C556 STATUS REASON 9013 Status reason, coded
Example: DOB
C M an..3
Example: OCC
Page 132 ENV 13777:2000 1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
9012 Status reason
C an..35
070 C556 STATUS REASON
C
9013 Status reason, coded
M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
9012 Status reason
C an..35
The following qualifiers can be used in STS segments (data element 9015):
data object
DOB
phrase
PHR
Segment Group 3: QTY-DTM A segment group to give link speed, link speed adjustment or scaling factor, for use with route guidance systems. When used with DTM below, the data relate to a specific time in the future. This segment group can also be used to indicate the accuracy of traffic data, and/or the measurement length (for traffic concentration). QTY, Quantity This segment shall be used in SG3 to give data indicated above. 010 C186 QUANTITY DETAILS
M
6063 Quantity qualifier
M an..3
Example: DPL
6060 Quantity
M n..15
Example: 200
6411 Measure unit qualifier
C an..3
Unit qualifier
C an..3
Example: MTR
The following qualifiers can be used in QTY (data element 6063): Qualifier
Default units
accuracy
ACU
%
measurement length
MLE
km
speed reduction
SPV
km/h
speed reduction ratio
SPR
%
capacity remaining
CYR
%
average speed numerical value
AVV
km/h
Page 133 ENV 13777:2000
distance from primary location
DPL
m
distance from secondary location
DSL
m
DTM, Date/time/period This segment is not currently used. Segment Group 4: LIN-RFF-DTM-QTY-TDT-GDS A segment group to give link time and/or turn delay relating to a specific time in the future; or a table of periodic traffic data; or a table of individual vehicle data. LIN, Line item This segment shall be used once in SG4 to provide a reference number to the set of data given in this segment group (Example: each line of a table of data). 010 1082 LINE ITEM NUMBER Set of data number
C an..6 C an..6
020 1229 ACTION REQUEST/NOTIFICATION, CODED
C an..3
030 C212 ITEM NUMBER IDENTIFICATION
C
7140 Item number
C an..35
7143 Item number type, coded
C an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
040 C829 SUB-LINE INFORMATION
C
5495 Sub-line indicator, coded
C an..3
1082 Line item number
C an..6
050 1222 CONFIGURATION LEVEL
C n..2
060 7083 CONFIGURATION, CODED
C an..3
Page 134 ENV 13777:2000 RFF, Reference This segment can be used to indicate lane number and/or direction for individual vehicle data. 010 C506 REFERENCE
M
1153 Reference qualifier
M an..3
1154 Reference number
C an..35
Reference value
Example: LNP
M an..35 Example: 1
1156 Line number
C an..6
4000 Reference version number
C an..35
1060 Revision number
C an..6
The following qualifiers can be used in RFF within SG4 (data element 1153):
direction bearing
DIR
compass point direction
DRC
ALERT C direction
RDI
lane
LNP
DTM, Date/time/period This segment can be used to indicate the beginning time or end time of the period described by the line; or it can be used for times associated with an individual vehicle. For route guidance applications, it can be used to indicate a prediction interval or prediction period, plus a link time and/or turn delay. 010 C507 DATE/TIME/PERIOD
M
2005 Date/time/period qualifier
M an..3
2380 Date/time/period
C an..35
Date/time/period
Example: ATS
M an..35 Example: 125417
2379 Date/time/period format qualifier
C an..3
Example: 402
The following qualifiers can be used in DTM within SG4 (data element 2005): Qualifier Default format
arrival time (sensor)
ATS
402
HHMMSS
presence time
PRT
807
SSSS
passage time
PAS
807
SSSS
time headway
TIH
807
SSSS
link time
LTT
806
MMMM
delay time value
DLT
401
HHMM
travel time numerical value
TTV
402
HHMMSS
Page 135 ENV 13777:2000
coded delay time
DLC
N
Use of default formats and data element 2379 shall be as specified for DTM on the top level. It is recommended that the date/time/period format qualifier is given in data element 2379. QTY, Quantity This segment can be used in SG4 to indicate quantities within a line of traffic data; Example: individual vehicle data; periodic data. 010 C186 QUANTITY DETAILS
M
6063 Quantity qualifier
M an..3
Example: GAP
6060 Quantity
M n..15
Example: 17.43
6411 Measure unit qualifier
C an..3
Unit qualifier
C an..3
Example: MTR
The following qualifiers can be used in QTY within SG4 (data element 6063): Qualifier
Default units
average speed numerical value
AVV
km/h
concentration numerical value
CTV
veh/km
occupancy numerical value
OCV
%
axle flow numerical value
AFV
axles/h
PCU flow numerical value
FLV
pcu/h
vehicle flow numercial value
VFV
veh/day
speed reduction
SPV
km/h
speed reduction ratio
SPR
%
capacity remaining
CYR
%
measurement length
MLE
km
accuracy
ACU
%
queue length
QUE
km
vehicle speed
IVS
km/h
The following individual vehicle data (IVD) qualifiers can also be used:
vehicle height
HEI
m
vehicle width
WID
m
vehicle length
VLN
m
distance headway
DIH
m
distance gap
GAP
m
gross vehicle weight
GVW
tonnes
Page 136 ENV 13777:2000
axle 1 weight
AX1
tonnes
axle 2 weight
AX2
tonnes
axle 3 weight
AX3
tonnes
axle 4 weight
AX4
tonnes
axle 5 weight
AX5
tonnes
axle 6 weight
AX6
tonnes
axle spacing 1
AS1
m
axle spacing 2
AS2
m
axle spacing 3
AS3
m
axle spacing 4
AS4
m
axle spacing 5
AS5
m
vehicle speed
IVS
km/h
axle number
AXN
-
TDT, Details of transport This optional segment can be used in SG4 to specify the vehicle class and/or ID of an individual vehicle. 010 8051 TRANSPORT STAGE QUALIFIER
M an..3
Vehicle class identifier
M an..3
020 8028 CONVEYANCE REFERENCE NUMBER
C an..17
030 C220 MODE OF TRANSPORT
C
8067 Mode of transport, coded
C an..3
8066 Mode of transport
C an..17
040 C228 TRANSPORT MEANS 8179 Type of means of transport identification Vehicle class (value of VCL) 8178 Type of means of transport
i.e. VCL
C C an..8 C an..8 C an..17
Example: KX1
Page 137 ENV 13777:2000 050 C040 CARRIER
C
3127 Carrier identification
C an..17
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
3128 Carrier name
C an..35
060 8101 TRANSIT DIRECTION, CODED
C an..3
070 C401 EXCESS TRANSPORTATION INFORMATION
C
8457 Excess transportation reason, coded
M an..3
8459 Excess transportation responsibility, coded
M an..3
7130 Customer authorization number
C an..17
080 C222 TRANSPORT IDENTIFICATION 8213 Id. of means of transport identification Individual vehicle Id (VID)
C C an..9 C an..9
Example: N971NYB
1131 Code list qualifier
C an..3
Example: NL
3055 Code list responsible agency, coded
C an..3
8212 Id. of the means of transport
C an..35
8453 Nationality of means of transport, coded
C an..3
Nationality
090 8281 TRANSPORT OWNERSHIP, CODED
C an..3
Example: GB
C an..3
The usage of data element 8179 is defined in the DATEX Data Dictionary. GDS, Nature of cargo This optional segment can be used in SG4 to indicate the type of load carried by an individual vehicle. 010 C703 NATURE OF CARGO 7085 Nature of cargo, coded Type of load (value of LOA)
C M an..3 M an..3
1131 Code list qualifier
C an..3
3055 Code list responsible agency, coded
C an..3
Example: OIL
Page 138 ENV 13777:2000 Segment Group 5: RFF-QTY A segment group to give one value for a known type and unit of traffic/travel data for specified measurement point. Either SG2 or SG5 shall be used at least once in TRAILS. RFF, Reference The segment shall be used in SG5 to indicate the measurement point reference. 010 C506 REFERENCE 1153 Reference qualifier Measurement point reference qualifier (F) 1154 Reference number Reference value
M M an..3 M an..3
i.e. F
C an..35 M an..35 Example: 3
1156 Line number
C an..6
4000 Reference version number
C an..35
1060 Revision number
C an..6
QTY, Quantity This segment shall be used in SG5 to indicate a quantity associated with a measurement point; Example: average speed, occupancy, as specified in the measurement point catalogue and indicated by the measurement point reference. 010 C186 QUANTITY DETAILS 6063 Quantity qualifier Measurement point value qualifier (V)
M M an..3 M an..3
i.e. V
6060 Quantity
M n..15
Example: 17.43
6411 Measure unit qualifier
C an..3
In SG5 data element 6411 (unit qualifier) is not used, as the unit is implicitly defined within the definition of a measurement point. UNT, Message trailer This mandatory service segment ends a message, giving the total number of segments in the message and the message reference number: 0074
NUMBER OF SEGMENTS IN THE MESSAGE
M n..6
software generated
0062
MESSAGE REFERENCE NUMBER
M an..14 software generated
Page 139 ENV 13777:2000 13.5.2.2 Message Structure [normative] Branching diagram Figure 29 shows the branching diagram for the TRAILS message.
UNH BGM M1 M1
UNT M1 SG1 M9
DTM M9
GIS C9
LOC C 99
RFF M1
DTM C9
NAD M9
SG2
SG5
C 9999
C 99999
STA M1
RFF M1
RFF C9
LOC M 99
TDT C1
DTM C9
STS C1
SG4
SG3 C 99
C 9999
QTY M1
LIN M1
DTM C1
RFF C9
QTY M1
DTM C9
Figure 29 - Branching Diagram for TRAILS message
QTY C 99
TDT C1
GDS C1
Page 140 ENV 13777:2000 Segment table TAG
NAME
S
REPT
UNH
Message header
M
1
BGM
Beginning of message
M
1
DTM
Date/time/period
M
9
GIS
General indicator
C
9
LOC
Place/location identification
C
99
Segment Group 1 RFF
Reference
M
1
DTM
Date/time/period
C
9
NAD
Name and address
M
9
Segment Group 2 STA
Statistics
M
1
RFF
Reference
C
9
LOC
Place/location identification
M
99
TDT
Details of transport
C
1
DTM
Date/time/period
C
9
STS
Status
C
1
Segment Group 3 QTY
Quantity
M
1
DTM
Date/time/period
C
1
Segment Group 4 LIN
Line item
M
1
RFF
Reference
C
9
DTM
Date/time/period
C
9
QTY
Quantity
C
99
TDT
Details of transport
C
1
GDS
Nature of cargo
C
1
Segment Group 5 RFF
Reference
M
1
QTY
Quantity
M
1
UNT
Message trailer
M
1
S
REPT
M
9
C
9999
C
99
C
9999
C
99999
Page 141 ENV 13777:2000 13.5.2.3 Data Segment Index (Alphabetic Sequence) [informative] BGM Beginning of message
DTM
Date/time/period
GDS
Nature of cargo
GIS
General indicator
LIN
Line item
LOC
Place/location identification
NAD
Name and address
QTY
Quantity
RFF
Reference
STA
Statistics
STS
Status
TDT
Details of transport
UNH
Message header
UNT
Message trailer
13.6 Traffic/Travel Location Definition Message (TRALOC) 13.6.1 SCOPE 13.6.1.1 Functional Definition The Traffic/Travel Location Definition Message (TRALOC) serves parties that send and/or receive traffic/travel information (Example: traffic/travel information or control centres, telecommunications services, broadcasters, police, road authorities, public transport operators, breakdown/rescue services, freight operators, individual travellers), conveying one or more traffic/travel location definitions, which support related messages by giving details such as the names and location codes of highways, public transport routes, road junctions, stations, route guidance links, towns, cities, areas or regions. 13.6.1.2 Principles Many ATT applications require location references. TRALOC defines the locations used in the exchange of traffic/travel information. The message can be used to download location names, references, distance markers or coordinates to users. Location definitions can be pre-stored in receiver memory, or downloaded using TRALOC. TRALOC allows new locations to be defined, to deal with unusual situations. It can also support mobile or portable receivers with little permanent memory.
Page 142 ENV 13777:2000 The message is meant to comply with the operational requirements of organisations concerning the notification/dissemination of traffic/travel location definitions. 1.
One TRALOC message conveys information about one or more locations. Typically, TRALOC is used to define locations in support of other traffic/travel messages.
2.
A message can be used to define travel situation locations (roads, areas, public transport or parking), route guidance locations, public transport timetable locations, individual traveller locations, etc.
3.
A location can be a point, a length of route, or an area; also, its spatial limits may be exactly known, or only approximately defined.
4.
One message may relate to all relevant information about the locations, or to a part of that information. Location definitions may be split in different messages, Example: as required at different times. Note: To define all traffic/travel locations in a region might imply accumulation of many traffic/travel location definition messages from the same or several information sources.
5.
The TRALOC message shall be based on agreed operating practices regarding the notification of relevant traffic/travel location definitions to the receiving party. Note: This may mean that in a certain application, a data element (or qualifier) that is conditional according to this specification becomes mandatory for that application. DATEX-Net specifies the nature of data elements in use.
6.
A traffic/travel location definition may contain either one or two names describing each location, plus one or more references to attributes of the location.
7.
A traffic/travel location definition may also contain other ways of defining the location, such as latitude/longitude or distance marker information.
8.
The TRALOC message has to cater for both temporary and permanent updates, including cancellation of previous data. For these purposes, the following functions are defined, within the context of TRALOC: validity start time - the time from which the information in the message will become effective. validity stop time - the time from which the information in the message will cease to be effective.
9.
When updating the definition of a specific location, it is permissible to add further detail or clarification, but not to change the meaning of a previously-distributed location, prior to its validity stop time. Where no stop time was specified, a message function of “end” may be utilized to indicate that information is no longer effective. New information can then be issued, as necessary. The message function “cancel” shall be used only to signify that information was distributed in error. Such information shall be treated as if it had not been distributed.
Page 143 ENV 13777:2000 10.
A TRALOC message may be sent according to existing agreements with the recipient, or in response to an earlier traffic/travel information request (TRAREQ) message. Requester
Supplier
-----
Traffic/Travel Information Request Message
- - - - ->
