ISO 14827-2:2022

INTERNATIONAL ISO
STANDARD 14827-2
Second edition
2022-12
Intelligent transport systems —
Data interfaces between centres for
transport information and control
systems —
Part 2:
AP-DATEX
Reference number
© ISO 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms.2
5 Conformance . 3
6 Exchange framework.3
6.1 General . 3
6.2 Basic pull with TCP/UDP datagrams exchange PSM . 5
6.2.1 Overview . 5
6.2.2 Exchange pattern messages definition . 6
6.2.3 State diagrams. 7
6.2.4 Features implementation description . 7
6.3 Basic push TCP/UDP datagrams exchange PSM . 8
6.3.1 Overview . 8
6.3.2 Exchange pattern messages definition . 9
6.3.3 State diagrams. 9
6.3.4 Features implementation description . 10
7 Data exchange procedures .11
7.1 General . 11
7.2 General datagrams procedures . 11
7.2.1 General . 11
7.2.2 Sessions . 11
7.2.3 Transport requirements .12
7.2.4 Response time-outs .12
7.2.5 Retransmission .12
7.2.6 Duplicate datagrams .12
7.3 General file procedures. 12
7.4 Sessions .12
7.4.1 General .12
7.4.2 Establishing a session .13
7.4.3 Maintaining a session . . 14
7.4.4 Terminating a session .15
7.5 Requesting information . 16
7.5.1 General . 16
7.5.2 Offline subscriptions . 16
7.5.3 Online subscriptions . 16
7.6 Publication of information . 17
7.6.1 General . 17
7.6.2 General procedures . 17
7.6.3 Single subscriptions . 19
7.6.4 Registered subscriptions . 19
Annex A (normative) Message definition requirements .21
Annex B (normative) Datagram structures .25
Annex C (normative) Data dictionary .33
Annex D (normative) Value domains .64
Annex E (normative) TCP/UDP datagrams exchange implementation considerations .77
Annex F (normative) TCP/UDP datagrams exchange over internet protocols .78
iii
Annex G (normative) Protocol requirements list .79
Bibliography .83
iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
This second edition cancels and replaces the first edition (ISO 14827-2:2005), which has been technically
revised.
The main changes are as follows:
— the title has been modified;
— the concept of a platform-independent model (PIM) as defined in ISO/TS 19468 has been integrated;
— the message format previously defined in ISO 14827-1:2005 (to be withdrawn) has been included.
A list of all parts in the ISO 14827 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
Introduction
Data exchange among centres is a baseline service for implementing intelligent transport system
(ITS) services. For interoperability purposes, data delivery and collaborative ITS services need to be
implemented according to certain specifications based on fully-described interfaces.
This document has been revised based on the concept of a platform-independent model (PIM) as
defined in ISO/TS 19468, maintaining backward compatibility with ISO 14827-2:2005 and taking into
consideration the future withdrawal of ISO 14827-1:2005.
The development of the first editions of ISO 14827-1 and ISO 14827-2 began in the 1990s. These
documents were published in 2005 based on European DATEX. Since then, the exchange environment
of traffic information and traffic data has made a great deal of progress and DATEX II has been
developed, enabling the distribution of traffic information and traffic management information
in a way that is not dependent on language and presentation format. DATEX II is closely related to
ISO/TS 19468. ISO/TS 19468 aims to describe the general exchange specification technology and to
describe interaction through a high-level model which is not dependent on a specific technology in a
model-driven approach; it defines functional exchange profiles by several possible exchange patterns.
According to this concept, ISO 14827-2 (this document) was revised as a platform-specific model for AP-
DATEX (application profile-data exchange) and other Internet protocol (IP) networks. The relationship
between ISO/TS 19468 and the ISO 14827 series (including this document) is shown in Figure 1. This
document aims to define and describe the data exchange requirements using TCP/UDP (transmission
control protocol/user datagram protocol) datagrams (defined as “DATEX-ASN”) and the basics of ASN.1
messages, as defined in ISO 14827-1.
This document is not intended to conflict with existing International Standards on interfaces of data
exchange among ITS centres.
Key
PIM platform-independent model
EP exchange pattern
FEP functional exchange profile
PSM platform-specific model
Figure 1 — Relationship between exchange-related documents
vi
INTERNATIONAL STANDARD ISO 14827-2:2022(E)
Intelligent transport systems — Data interfaces between
centres for transport information and control systems —
Part 2:
AP-DATEX
1 Scope
This document defines a platform-specific model (PSM) for data exchange, which specifically uses
ASN.1 and TCP/UDP (transmission control protocol/user datagram protocol) datagrams which were
defined as “DATEX-ASN” in the first edition of this document for AP-DATEX (application profile-data
exchange) and other Internet protocol (IP) networks. A PSM is an actual implementation of a platform-
independent model (PIM) for exchange. This document specifies the message rules and procedures for
communication between different systems for ITS using TCP/UDP datagrams.
This document deals mainly with the communication interfaces. It has been designed to meet the
unique requirements of intelligent transport systems (ITS). However, it has also been designed in a
generic fashion and thus can be used for other data exchanges as well.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/TS 19468, Intelligent transport systems — Data interfaces between centres for transport information
and control systems — Platform-independent model specifications for data exchange protocols for
transport information and control systems
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1) — Part 1: Specification
of basic notation
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/TS 19468 and the following
apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
DATEX-ASN
data exchange protocol in abstract syntax notation as TCP/UDP (transmission control protocol/user
datagram protocol) datagrams exchange
Note 1 to entry: This was initially defined in ISO 14827-2:2005 (first edition of this document).
3.2
DatexDatapacket
TCP/UDP (transmission control protocol/user datagram protocol) datagrams which are defined
in ASN.1 as application layer data packets and can be exchanged using any compatible lower-layer
combination
Note 1 to entry: See Annex B.
3.3
guaranteed delivery
TCP/UDP (transmission control protocol/user datagram protocol) datagrams exchange mechanism in
which the client acknowledges the receipt of a publication (reply)
3.4
heartbeat
data packet sent to indicate that the sending system is still alive and communicating
3.5
publication
information (usually contained in payload) exchange from a supplier
Note 1 to entry: “Payload publication” is defined in ISO/TS 19468.
3.6
subscription
request to a supplier from a client for information exchange
3.7
transport profile
set of services which are responsible for providing a virtually error-free, point-to-point connection so
that host A can send data packets to host B and they will arrive uncorrupted
4 Symbols and abbreviated terms
AP-DATEX application profile-data
BER basic encoding rule
CORBA common object request broker architecture
DATEX-ASN data exchange in abstract syntax notation
DTLS datagram transport layer security
EDIFACT electronic data interchange for administration, commerce and transport
EP exchange pattern
FDDI fibre distributed data interface
FEP functional exchange profile
FrED friendly exchange of data
FTP file transfer protocol
IP Internet protocol
ISDN integrated services digital network
NTCIP National Transportation Communications for ITS (intelligent transport systems)
OID object identifier
PIM platform-independent model
PN port number
PPP point-to-point protocol
PRL protocol requirements list
PSM platform-specific model
SNMP simple network management protocol
TCP transmission control protocol
TCIP transit communications interface profiles
TFTP trivial file transfer protocol
TICS transport information and control systems
TLS transport layer security
UDP user datagram protocol
VMS variable message sign
5 Conformance
There is no explicit conformance test in this document. Conformance is achieved if the exchange data
conform to the messaging rules of this document.
6 Exchange framework
6.1 General
TCP/UDP datagrams exchange allows different systems to exchange relevant data. The data are
contained in end-application messages. Each end-application message shall be defined according
to message definition requirements laid out in Annex A. TCP/UDP datagrams exchange defines how
these end-application messages are packaged to form complete datagrams and also defines the rules
and procedures for exchanging these datagrams. Systems using TCP/UDP datagrams exchange may
implement additional end-application functionalities according to the user requirements.
A TCP/UDP datagrams exchange network comprises a certain number of systems, an example of which
is provided in Figure 2. It is typically exchanged using well-known IPs, such as UDP/IP or TCP/IP, then
may use IPsec, DTLS, TLS, etc. for security.
Key
1 weather system 4 emergency management system
2 traffic management system 5 information service provider
3 transit management system
Figure 2 — An example of TCP/UDP datagrams exchange network
Each system can be viewed as consisting of the interfaces, as shown in Figure 3.
Key
1 application interface 5 communications cloud
2 operator interface 6 client system
3 communication interface 7 supplier system
4 database interface
Figure 3 — System interfaces
The data exchange environment and actors can be viewed as shown in Figure 4.
Figure 4 — Communication interfaces
Systems implementing this document sometimes operate simultaneously as a client and supplier, using
multiple sessions. The communications cloud between the two systems can be complex or simple.
When implementing a specific PSM, a functional exchange profile (FEP), which is a selection of data
exchange features, is identified.
The model driven approach defined in ISO/TS 19468 is summarized in Figure 5.
Figure 5 — Business scenario and functional exchange profile (FEP)
This document describes the mapping rules in order to implement specific platform push and pull and
FEP+EP based PIM in TCP/UDP datagrams exchange which is based on ASN.1 message PSM. A PIM-level
description of FEP+EP is detailed in ISO/TS 19468 and is referenced in this document.
6.2 Basic pull with TCP/UDP datagrams exchange PSM
6.2.1 Overview
The basic pull EP+FEP is based on an information request by a client from a supplier which delivers
requested information to the client. It can be implemented in IPs. A selection of features for basic pull is
shown in Table 1.
Table 1 — Selection of features for basic pull
Features area Feature Basic pull implemented
Subscription contract Contract Log in/Log out
See 7.4.2, 7.4.4
Catalogue N
TTabablele 1 1 ((ccoonnttiinnueuedd))
Features area Feature Basic pull implemented
Session Session life cycle Log in/Log out/Maintain
See 7.4.2, 7.4.4, 7.4.3
Link monitoring N
Information management Operating modes Periodic or on occurrence
(i.e. triggered by client conditions)
Update methods N
Life cycle management N
Data delivery Data delivery Y
Data request Y
Large datasets handling Y
Synchronization Y
(periodic mode)
Self-description Handshake N
Communication Security N
Compression N
Communication N
6.2.2 Exchange pattern messages definition
6.2.2.1 Overall presentation
Exchange systems are used which provide tools enabling message generation and their transfer
between supplier and client. A data flow between the supplier system and client system is shown in
Figure 6.
Figure 6 — Basic pull exchange actors
6.2.2.2 Exchange pattern definition
The basic pull client and supplier shall establish, maintain, or terminate a session according to the
procedure described in 7.4 of this document.
The basic pull client shall request information according to the procedure described in 7.5 of this
document.
The basic pull supplier shall provide information according to the procedure described in 7.6 of this
document.
6.2.2.3 Relevant exchange information in exchange data model
No exchange information is needed in this pattern to implement data delivery features.
6.2.2.4 Exchange messages
Exchange messages are included in the payload and defined in Annex B.
6.2.3 State diagrams
State diagrams are not needed, and relevant procedures are described in Clause 7.
6.2.4 Features implementation description
6.2.4.1 Overview
This subclause provides a description and the corresponding specification for each feature identified
in the context diagram according to the basic pull exchange architecture. The following features are
specified:
— subscription contract;
— subscription (also known as session);
— information management;
— data delivery;
— communication/protocol.
6.2.4.2 Subscription contract
6.2.4.2.1 Contract
The session is established or terminated according to the procedure described in 7.4.
6.2.4.2.2 Catalogue
Catalogue is not managed.
6.2.4.3 Session
6.2.4.3.1 Session life cycle
The session is managed according to the procedure described in 7.4.
6.2.4.3.2 Link monitoring
Link monitoring is not provided.
6.2.4.4 Information management
6.2.4.4.1 Operating modes
The available operating mode for client pull is periodic, or on occurrence as described in 7.6.
6.2.4.4.2 Update methods
The update method is not provided.
6.2.4.4.3 Life cycle management
The life cycle is not managed.
6.2.4.5 Data delivery
6.2.4.5.1 Data delivery scheme
The data delivery scheme is described in 7.6.
6.2.4.5.2 Data request scheme
The data request scheme is described in 7.5.
6.2.4.5.3 Large datasets handling
The large datasets are handled as a data file. The data file scheme is described in 7.6.
6.2.4.5.4 Synchronization
Under periodic mode, publication cycle synchronization is available, and its scheme is described in 7.6.4.
6.2.4.6 Self-description
Handshake is not available.
6.2.4.7 Communication
Communication feature may be implemented at IP level.
6.2.4.8 General optimization issues
Implementation considerations and IP usages for TCP/UDP datagrams exchange shall be as shown in
Annex E and Annex F. Requirements of protocol shall be as shown in Annex D.
6.3 Basic push TCP/UDP datagrams exchange PSM
6.3.1 Overview
The basic push EP+FEP is performed from a supplier which delivers information to a client without
request by the client. It can be implemented in internet protocols. A selection of features for basic push
is shown in Table 2.
Table 2 — Selection of features for basic push
Features area Feature Basic push implemented
Subscription contract Contract Log in/Log out
See 7.4.2, 7.4.4
Catalogue N
Session Session life cycle Log in /Log out/Maintain
See 7.4.2, 7.4.4, 7.4.3
Link monitoring N
Information management Operating modes Periodic or on occurrence
(i.e. triggered by supplier conditions)
Update methods N
TTabablele 2 2 ((ccoonnttiinnueuedd))
Features area Feature Basic push implemented
Life cycle management N
Data delivery Data delivery Y
Data request N
Large datasets handling Y
Synchronization Y
(periodic mode)
Self-description Handshake N
Communication Security N
Compression N
Communication N
6.3.2 Exchange pattern messages definition
6.3.2.1 Overall presentation
Exchange systems are used which provide tools enabling message generation and their transfer
between supplier and client. A data flow between supplier and client is shown in Figure 7.
Figure 7 — Basic push exchange actors
6.3.2.2 Exchange pattern definition
The basic push client and supplier shall establish, maintain, or terminate a session according to the
procedure described in 7.4 of this document.
The basic push supplier may request receiving information to client and shall provide information
according to the procedure described in 7.6 of this document.
6.3.2.3 Relevant exchange information in exchange data model
No exchange information is needed in this pattern to implement data delivery features.
6.3.2.4 Exchange messages
Exchange messages are included in payload and defined in Annex B.
6.3.3 State diagrams
State diagrams are not needed, and procedures are described in Clause 7.
6.3.4 Features implementation description
6.3.4.1 Overview
This subclause provides a description and the corresponding specification for each feature identified
in the context diagram, according to the basic pull exchange architecture. The following features are
specified:
— subscription contract;
— subscription (also known as session);
— information management;
— data delivery;
— communication/protocol.
6.3.4.2 Subscription contract
6.3.4.2.1 Contract
The session is established or terminated according to the procedure described in 7.4.
6.3.4.2.2 Catalogue
Catalogue is not managed.
6.3.4.3 Session
6.3.4.3.1 Session life cycle
The session is managed according to the procedure described in 7.4.
6.3.4.3.2 Link monitoring
Link monitoring is not provided.
6.3.4.4 Information management
6.3.4.4.1 Operating modes
Available operating mode for client pull is periodic, or on occurrence as described in 7.6.
6.3.4.4.2 Update methods
The update method is not provided.
6.3.4.4.3 Life cycle management
The life cycle is not managed.
6.3.4.5 Data delivery
6.3.4.5.1 Data delivery scheme
The data delivery scheme is described in 7.6.
6.3.4.5.2 Data request scheme
Not implemented in this pattern.
6.3.4.5.3 Large datasets handling
The large datasets are handled as a data file. The data file scheme is described in 7.6.
6.3.4.5.4 Synchronization
Under periodic mode, publication cycle synchronization is available, and its scheme is described in 7.6.4.
6.3.4.6 Self-description
Handshake is not available.
6.3.4.7 Communication
The communication feature may be implemented at other internet protocol level.
6.3.4.8 General optimization issues
Implementation considerations and IP usages for TCP/UDP datagrams exchange shall be as shown in
Annex E and Annex F. Requirements of protocol shall be as shown in Annex D.
7 Data exchange procedures
7.1 General
This document defines an application layer protocol by which data elements are exchanged between a
client and supplier. Communication between client and supplier shall be accomplished by the exchange
of datagrams and files as defined in this clause.
7.2 General datagrams procedures
7.2.1 General
TCP/UDP datagrams shall be constructed according to the formally defined ASN.1 data structure as
DatexDataPacket, defined in Annex B.
The data dictionary for each field of DatexDataPacket is accordance with Annex C. The value domain
specified in the data dictionary is accordance with Annex D.
7.2.2 Sessions
This document requires all datagrams to be transmitted in an application session. Within each session,
one system shall act as a client and the other shall act as the supplier. Multiple sessions may exist
simultaneously.
NOTE A pair of systems will have two concurrent sessions, one where System A acts as the client and System
B acts as the supplier and the other where System A acts as the supplier and System B acts as the client. These
sessions would be distinguished by lower layer protocols (e.g. TCP or UDP port numbers).
7.2.3 Transport requirements
Data may be exchanged over connectionless or connection-oriented transport profiles, but a single
transport profile shall be used for all datagrams exchanged within a session.
EXAMPLE If the first datagram in establishing a session is transmitted using UDP, then all datagrams within
that session will use UDP. Likewise, if the initial transmission is TCP, then all datagrams will be TCP.
7.2.4 Response time-outs
The client and supplier shall negotiate the response time-out period for each session. The response
time-out period should be long enough to accommodate the network propagation delays for both
datagrams as well as the turn-around time required to handle the message on the receiving end. In
theory, this should be measured from when the last byte is transmitted to when the last response byte
is received. However, it is expected that most implementations will measure the time from the return
from the system write call to the return from the system read call.
NOTE A typical implementation is to set the time-out to be an integral multiple of the turn-around time and
the multiplier is typically set to three. When some communications media and networks experience significant
delays, the system will allow this multiplier to be set at run-time.
7.2.5 Retransmission
If a specific datagram requires a response and an appropriate response is not received within the
response time-out period, the identical datagram (e.g. same datagram number, same time stamp, etc.)
shall be retransmitted one time only. If no response is received to the second datagram, prior to a
subsequent response time-out period, the datagram transmission shall be considered unsuccessful. If a
response is received after the time-out period, it may be ignored.
7.2.6 Duplicate datagrams
Any time a client or supplier receives a datagram that requires a response, a new response datagram
shall be prepared and transmitted as soon as possible, even if the received datagram was a duplicate
datagram.
7.3 General file procedures
The client may request the publication (reply) data to be sent within the publication datagram, or
the client may request the publication data to be stored in a file on the supplier with the publication
datagram indicating the filename of the publication file. The file can then be retrieved by the
client within the constraints set by the supplier. Such a publication file shall only contain the “TICS
information” as defined by the publication datagram structure as defined in B.2.9.
7.4 Sessions
7.4.1 General
Within each session, one system is a client and the other is a supplier. A supplier with a given domain
name shall not accept more than one session with any client domain name with a given transport
profile. However, as a single system may have multiple domain names, multiple sessions can potentially
exist between a given client system and supplier system pair. Multiple sessions may exist on a single
physical link simultaneously.
NOTE 1 For an example of multiple sessions, system A can act as a supplier in one session with system B while
also acting as a client in a second session.
NOTE 2 When a single client has sessions with multiple suppliers simultaneously, the complete session
number over any given transport profile is defined by the supplier domain name followed by the client domain
name.
NOTE 3 When some implementations have a need to frequently publish relatively large datagrams, there are
various ways to achieve this, including: (1) increasing the UDP/IP datagram size to support the required size; or
(2) maintaining a prolonged TCP connection over which the large datagrams are periodically sent. The preferred
solution will depend on a number of implementation-specific issues such as media quality and required reliability
of transmission.
NOTE 4 The usage of different transport profiles (e.g. one UDP and one TCP) will allow simultaneous sessions
between a single client and supplier pair.
7.4.2 Establishing a session
The supplier may wish to establish a session. For example, this may be in order to publish information
for a registered subscription (request) or allow a receipt of a subscription if the supplier is protected by
a firewall. In this case, the supplier shall transmit an “Initiate” datagram, as defined in B.2.3, with the
datex-Destination-txt and datex-Sender-txt fields set to the proper name.
A supplier should not terminate a session it initiated for a period of one heartbeat duration after final
publication.
If the client receives an “Initiate” datagram or if the client wishes to establish a session, the client shall
transmit a “Login” datagram, as defined in B.2.4.
Upon receiving a “Login” datagram, a supplier shall determine if the domain names, username,
password, maximum heartbeat duration, response time-out period, allowed encoding rules, datagram
size and login reason are valid for the request. The supplier shall also ensure that a session with the
given domain name and transport profile does not already exist. If the request is found to be invalid,
the supplier shall either:
— respond with a “reject” datagram, as defined in B.2.12, with the “error-code” set to the most
appropriate code number which applies to the denial, or
— not respond if the supplier determines this is appropriate due to security reasons.
If the request is valid, the supplier shall respond with an “accept” datagram, as defined in B.2.11, and
shall identify the selected encoding rules from the list of options in the login request. This completes
the procedures to establish a session.
The procedure to establish a session is summarized in Figure 8. All datagrams exchanged during this
procedure shall use the encoding rules that were agreed upon offline. All datagrams exchanged after
the successful completion of this procedure shall use the encoding rules, as negotiated within the
“Login” and “Accept” datagrams.
EXAMPLE As per Annex F, if the session is established over TCP/IP on Port 355, datagrams exchanged during
this procedure will use BER encoding; datagrams exchanged after the successful completion of the login process
would then use the encoding rules negotiated by the “Login” and “Accept” datagrams.
Figure 8 — Establishing a session
7.4.3 Maintaining a session
Sessions are maintained by the client and supplier exchanging “FrED” datagrams. If, at any point during
a session, no datagrams are received from the other system for a period exceeding the maximum
heartbeat duration, as specified in the login request, the session shall be immediately terminated by
both the client and the supplier without exchanging any data. This type of termination is generally only
encountered due to unusual circumstances, e.g. a system crash.
NOTE 1 FrED stands for a “Friendly Exchange of Data”. The datagram is generally used as an acknowledgement
datagram, but it is also used as a system heartbeat when there has been a prolonged period of silence. Thus, the
term “ack” does not truly apply to this datagram and the term “FrED” has been considered more appropriate.
NOTE 2 A session can be kept open permanently by meeting the requirements of this subclause.
The client shall maintain the session until the termination procedures are initiated as indicated in
7.4.4. The client shall keep track of the elapsed time since it received a datagram from the supplier and
shall ensure that this time does not exceed the maximum heartbeat duration by generating “FrED”
datagrams, as defined in B.2.5, as needed. The DATEX.FrED_ConfirmPacket_number-ulong shall be zero
(0) for such FrED datagrams, hereinafter referred to as “FrED heartbeat datagrams". It is recommended
that the client transmit FrED heartbeat datagrams roughly three times more often than the time
specified by the maximum heartbeat duration.
The supplier shall acknowledge a “FrED” heartbeat datagram by transmitting a “FrED” datagram
with the DATEX.FrED_ConfirmPacket_number-ulong set to the packet number of the “FrED” heartbeat
datagram which is being acknowledged. This shall complete the session maintenance procedure.
When desired, the session shall be terminated according to the procedure described in 7.4.4.
The procedure to maintain a session is summarized in Figure 9.
Figure 9 — Maintaining a session
7.4.4 Terminating a session
A session may be actively terminated by either the client or the supplier. If the supplier wishes to
terminate a session, it shall transmit a “Terminate” datagram, as defined in B.2.6. If the supplier does
not receive any response after two tries, the supplier shall terminate the session on its end.
If the client receives a valid “Terminate” datagram, or if the client wishes to terminate a session, it shall
transmit zero or more subscription cancellations, as defined in 7.5 and B.2.8, if it wishes to cancel any
persistent subscriptions, followed by a “Logout” datagram, as defined in B.2.7.
NOTE 1 Registered subscriptions do not expire with the termination of a session if the “Persistent” flag was
set in the subscription. This allows systems to keep subscriptions active when the session is not active. For
example, this can be useful for dial-up connections or to minimize the impact of system crashes.
NOTE 2 A supplier does not need to wait for a FrED for a guaranteed publication to a non-persistent
subscription.
Upon receipt of a valid “Logout” datagram, the supplier shall terminate the associated session and issue
a FrED, as defined in B.2.5. The client shall terminate the associated session upon receipt of the FrED.
This shall complete the session termination procedure.
NOTE If the client does not receive the FrED, despite following the retransmission rules, it will terminate the
session according to the provisions of 7.4.3.
The procedure to terminate a session is summarized in Figure 10.
Figure 10 — Terminating a session
7.5 Requesting information
7.5.1 General
Clients and suppliers shall provide for offline subscriptions (requests) as defined in 7.5.2, online
subscriptions as defined in 7.5.3, or both.
NOTE The subscription process will take place offline or online. This allows a supplier to transmit
publications (replies) (e.g. accident publications) without having to support the associated subscription datagram.
This can potentially be desirable in order to bring legacy systems into conformance or for security purposes.
7.5.2 Offline subscriptions
Suppliers may provide local mechanisms to register any and all subscriptions to which the supplier
claims compliance. This feature shall be supported for all clients known to the supplier.
Clients may provide local configuration mechanisms to accept publications from a remote supplier so
that the client may accept publications related to an offline subscription.
7.5.3 Online subscriptions
A client may support the ability to transmit “subscription” datagrams, as defined in B.2.8. If the client
claims conformance for online subscriptions, it shall support this service for all subscriptions to which
it claims conformance.
A supplier may accept “subscription” datagrams in order to allow for online requests to be processed. If
the supplier claims conformance for online subscriptions, it shall support “subscription” datagrams for
all subscriptions to which it claims conformance.
Upon receipt of a subscription datagram, the supplier shall respond with either an "accept" or "reject"
datagram, as defined in B.2.11 and B.2.12. An "accept" datagram shall only indicate that the data was
properly received and understood by the system; it does not guarantee that the end-application will
accept the subscription. For example, if a valid subscription is received, but the owner of the given
session is not authorized to receive the requested data, an “accept” datagram would be transmitted, but
...