ISO 14827-2:2005

INTERNATIONAL ISO
STANDARD 14827-2
First edition
2005-11-01
Transport information and control
systems — Data interfaces between
centres for transport information and
control systems —
Part 2:
DATEX-ASN
Systèmes de commande et d'information des transports — Interfaces
de données entre les centres pour systèmes de commande et
d'information des transports —
Partie 2: DATEX-ASN
Reference number
©
ISO 2005
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2005
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2005 – All rights reserved

Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Normative references . 2
3 Terms and definitions. 3
4 Symbols and abbreviated terms . 5
5 Implementation considerations. 6
6 Data exchange procedures. 6
6.1 General data packet procedures . 7
6.2 General file procedures. 7
6.3 Sessions . 8
6.4 Requesting information. 11
6.5 Publication of information . 12
Annex A (normative) Data packet structures . 16
Annex B (normative) Data dictionary . 23
Annex C (normative) Value domains. 45
Annex D (normative) DATEX-ASN over internet protocols. 55
Annex E (normative) Protocol requirements list . 56
Annex F (informative) Implementation guidance . 61
Annex G (informative) Advantages of DATEX-ASN . 62

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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
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.
ISO 14827-2 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems, Working
Group 9, with the collaboration of:
⎯ European Road Transport Telematics Implementation Coordination Organization (ERTICO);
⎯ Comité Européen de Normalisation (CEN);
⎯ American Association of State Highway and Transportation Officials (AASHTO);
⎯ Institute of Transportation Engineers (ITE);
⎯ National Electrical Manufacturers Association (NEMA).
ISO 14827 consists of the following parts, under the general title Transport information and control systems —
Data interfaces between centres for transport information and control systems:
⎯ Part 1: Message definition requirements
⎯ Part 2: DATEX-ASN
iv © ISO 2005 – All rights reserved

Introduction
In the 1980s and 1990s, transport networks became increasinigly congested and computer technologies were
deployed to more efficiently manage the limited transport network. As these systems were deployed, it
became more important to integrate nearby systems to properly provide the required services.
One of the first efforts to standardize the interface between transport control centres was a European Union
effort led by the DATEX Task Force. In May 1993, this group was established as a horizontal activity to
coordinate the diverging developments which were ongoing within the framework of the Advanced Transport
Telematics (ATT) Programme. Within the ATT Programme, three different data exchange systems were
developed: INTERCHANGE, EURO-TRIANGLE and STRADA. The group produced a set of basic tools to
meet existing needs, including a common data dictionary, a common set of EDIFACT messages and a
common geographical location referencing system.
The initial solution provided a common interface which satisfied the basic requirements of existing systems,
and was named the Data Exchange Network (DATEX-Net) Specifications for Interoperability. During the initial
efforts to deploy this International Standard, there was a growing sense that the message structure should be
better organized and should be defined using Abstract Syntax Notation One (ASN.1) rather than EDIFACT.
ASN.1 presents a standard notation for the definition of data types and values. A data type is a class of
information (e.g. numeric, textual, still image or video information). A data value is an instance of such a class.
ASN.1 defines several basic types and their corresponding values, and rules for combining them into more
complex types and values. These types and values can then be encoded into a byte stream according to any
of several standardised encoding rules.
Efforts to standardize communications between transport control centres were also underway in other parts of
the world. In 1997, all of these efforts began to merge, with the United States developing the initial draft of the
ASN.1 structures for the Data Exchange in Abstract Syntax Notation (DATEX-ASN). These structures, called
data packets, were then placed within a procedural context and submitted to the ISO standardization process.
A portion of the submittal dealt with the specification of messages. As this portion of the document could apply
to various protocols, it was placed in ISO 14827-1 — Message definition requirements. The remainder of the
original submittal formed the basis of the application layer protocol and was placed in this part of ISO 14827.
Thus, this part defines only one way to implement the messages that are specified in the format defined by
ISO 14827-1. This resulting International Standard supports existing and foreseen data exchange needs using
modern design concepts.
Due to the flexibility required by the rapidly developing transport information and control systems (TICS)
environment, this part of ISO 14827 uses a very generic structure. Thus, although initially intended to be an
International Standard for TICS, it is flexible enough to be used for virtually any data exchange.
ISO 14827-1 explains how to define end-application messages that are to be exchanged between centres for
TICS. This definition has been designed to be relatively generic to the selected protocol (e.g. DATEX-ASN,
CORBA, etc.) This part of ISO 14827 provides the specification of the Data Exchange protocol in ASN.1
(DATEX-ASN) used to exchange data between central systems. DATEX-ASN was the first protocol
standardized because:
⎯ the development of DATEX-Net could be leveraged, and
⎯ there was sufficient market interest to perform the required technical work.
INTERNATIONAL STANDARD ISO 14827-2:2005(E)

Transport information and control systems — Data interfaces
between centres for transport information and control
systems —
Part 2:
DATEX-ASN
1 Scope
DATEX-ASN allows different systems to exchange relevant data. This is contained in end-application
messages. Each end-application message is defined as either a “subscription” or a “publication” according to
the format as specified in ISO 14827-1. DATEX-ASN defines how these end-application messages are
packaged to form a complete data packet and also defines the rules and procedures for exchanging these
data packets. Systems using DATEX-ASN are free to implement additional end-application functionalities
according to the user requirements.
A DATEX-ASN network comprises a certain number of systems, an example of which is provided in Figure 1.

Key
1 weather system
2 traffic management system
3 transit management system
4 emergency management system
5 information service provider
Figure 1 — An example of a DATEX-ASN network
Each system can be viewed as consisting of the interfaces, as shown in Figure 2:

Key
1 application interface
2 operator interface
3 communication interface
4 database interface
5 communications cloud
6 client system
7 server system
Figure 2 — System interfaces
This part of ISO 14827 deals only with the communications interface. It has been designed to meet the unique
requirements of TICS; however, it has been designed in a generic fashion and thus could be used for other
data exchanges as well.
Systems implementing this part of 14827 sometimes operate simultaneously as a client and server, using
multiple sessions. The communications cloud between the two systems may be complex or simple.
2 Normative references
The following referenced documents are indispensable for the application 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 4217, Codes for the representation of currencies and funds
ISO 8824-1, Information technology — Abstract Syntax Notation One (ASN.1) — Part 1: Specification of basic
notation
ISO 8825-2, Information technology — ASN.1 encoding rules — Part 2: Specification of Packed Encoding
Rules (PER)
ISO 14827-1, Transport information and control systems — Data interfaces between centres for transport
information and control systems — Part 1: Message definition requirements
2 © ISO 2005 – All rights reserved

3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 14827-1 and the following apply.
3.1
connectionless transport profile
service that provides end-system to end-system communications without any connection set-up
EXAMPLE UDP/IP.
3.2
connection-oriented transport profile
service that allows one end-system to exchange a continuous stream of data with another end-system, the
data of which is guaranteed to be delivered in the same order in which it was sent without any duplication
NOTE This service is typically achieved by first establishing a connection, then sending the data, and finally
terminating the connection.
EXAMPLE TCP/IP.
3.3
data element
syntactically formal representation of some single unit of information of interest (such as a fact, proposition,
observation, etc) about some (entity) class of interest (e.g. a person, place, process, property, concept,
association, state, event, etc.)
3.4
datagram
entity of data containing enough information to be routed from source to destination without relying on
previous network configuration
EXAMPLE IP datagram.
3.5
datagram publication
DATEX-ASN publication (reply) that is sent directly over the given transport profile, in contrast with a file
publication
3.6
destination
system or device to which the information in the data packet is intended to be sent
3.7
encoding rules
rules which specify the representation during transfer of the values of ASN.1 types
NOTE 1 Encoding rules also enable the values to be recovered from the representation, given knowledge of the type.
NOTE 2 For the purpose of specifying encoding rules, the various referenced type (and value) notations, which can
provide alternative notations for built-in types (and values), are not relevant.
3.8
Ethernet
specific combination of physical and data link layer protocols as defined in IEEE 802.3 that allow multiple
systems to gain access to a shared medium and communicate with one another
3.9
file
data storage object, which may be located on any file system such as a hard-disk, a floppy-disk, a RAM-drive,
etc.
3.10
file publication
DATEX-ASN publication (reply) that is stored on the server’s file system until the client has an opportunity to
retrieve it via a file transfer protocol, in contrast with datagram publication
3.11
guaranteed delivery
DATEX-ASN mechanism in which the client acknowledges the receipt of a publication (reply)
3.12
heartbeat
data packet sent to indicate that the sending system is still alive and communicating
3.13
maximum turn-around time
maximum amount of time a system is given to provide an appropriate response to the incoming data packet
3.14
origin
system or device which was the source for all of the information in the data packet
NOTE In many cases, this will be the same as the sender, but could be different. For example, a bridge (or proxy
agent) may translate between protocols; in this case the bridge (or proxy agent) would be the sender, while the system
generating the data would be the origin.
3.15
port
logical channel in a communications system
NOTE UDP and TCP use port numbers to multiplex data packets from a variety of applications onto a single
communications system.
3.16
response time-out period
maximum duration a system is required to wait for a response data packet prior to assuming that the
previously sent data packet was never received by the other application
3.17
sender
system which created and sent the DATEX-ASN data packet
3.18
session
period of time during which a client and a server exchange multiple data packets
3.19
silently drop
to ignore a data packet
NOTE A data packet that is silently dropped does not cause any action to occur within the receiving system, nor is
any response sent to the subject data packet.
4 © ISO 2005 – All rights reserved

3.20
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
NOTE Connection-oriented transport profiles may also ensure that the data packets arrive in the correct order.
3.21
turn-around time
period of time it takes a client or server to produce and transmit a response data packet, measured starting
from the point at which the last byte of data is received from the other system to the point when the last
response byte is transmitted
4 Symbols and abbreviated terms
For the purposes of this document, the abbreviated terms of ISO 14827-1 and the following apply.
CMIP Common Management Information Protocol (RFC 1189)
CORBA Common Object Request Broker Architecture
D-COM Distributed Communications Object Model
FDDI Fibre Distributed Data Interface (ANSI X3T9.5)
FrED Friendly Exchange of Data
FTP File Transfer Protocol (RFC 959)
HTML Hyper Text Mark-up Language (RFC 2854)
HTTP Hyper Text Transfer Protocol (RFC 2616)
IP Internet Protocol (RFC 791)
ISDN Integrated Services Digital Network
NTCIP National Transportation Communications for Intelligent Transportation Systems (ITS) Protocol
PPP Point-to-Point Protocol (RFC 1661)
SNMP Simple Network Management Protocol (RFC 1157)
SQL Structured Query Language
TCP Transmission Control Protocol (RFC 793)
TCIP Transit Communications Interface Profiles
TFTP Trivial File Transfer Protocol (RFC 1350)
TICS Transport Information and Control Systems
UDP User Datagram Protocol (RFC 768)
5 Implementation considerations
Before exchanging data, transportation centres must agree on the specific issues that are described in the list
below.
NOTE Some of these issues (e.g. lower layer protocols) may be specified elsewhere. For example, Annex D provides
a definition of these traits for standardized IP implementations.
a) General:
1) time period throughout which the overall agreement is valid;
2) rules for terminating the agreement before the expiry time of the agreement;
3) server and client domain names and off-line contact addresses, telephone, fax and e-mail details.
b) Access (DATEX-ASN requires a user-name and associated password.):
1) IP address of the client, assigned by the Internet Assigned Number Authority if the link uses a public
network;
2) IP address of the server, assigned by the Internet Assigned Number Authority if the link uses a public
network;
3) a list of authorized client user-names, referred to as the user-name used throughout this part of
ISO 14827;
4) a password associated with each client user-name.
c) Protocols:
1) selection of lower layer protocols, including:
i) presentation (e.g. BER, EDIFACT, or others) and session layers;
ii) transport and network layers (e.g. UDP/IP, TCP/IP, etc.);
iii) data link and physical layers (e.g. Ethernet, FDDI, PPP over ISDN).
2) maximum datagram size;
3) selection of preferred file transfer protocols.
d) Management of background information:
1) specification of the Data Registry to be used.
e) Message management:
1) messages which must be supported, which may include messages that are standardized in other
documents and/or messages unique to the specific implementation.
6 Data exchange procedures
This part of ISO 14827 defines an application layer protocol by which data elements are exchanged between
a client and server. Communication between client and server shall be accomplished by the exchange of data
packets and files as defined in this section.
6 © ISO 2005 – All rights reserved

6.1 General data packet procedures
DATEX-ASN data packets shall be constructed according to the formally defined ASN.1 data structures
defined in Annex A.
6.1.1 Sessions
This part of ISO 14827 requires all data packets to be transmitted in an application session. Within each
session, one system shall act as a client and the other shall act as the server.
NOTE Multiple sessions may exist simultaneously. Thus, a pair of systems may have two concurrent sessions, one
where System A acts as the client and System B acts as the server and the other where System A acts as the server and
System B acts as the client. These sessions would be distinguished by lower layer protocols (e.g. TCP or UDP port
numbers).
6.1.2 Transport requirements
Data may be exchanged over connection-less or connection-oriented transport profiles, but a single transport
profile shall be used for all data packets exchanged within a session.
EXAMPLE If the first data packet in establishing a session is transmitted using UDP, then all data packets within that
session will use UDP. Likewise, if the initial transmission is TCP, then all data packets will be TCP.
6.1.3 Response time-outs
The client and server 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 data packets 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. However, as some communications media and networks may experience significant
delays, the system should allow this multiplier to be set at run-time.
6.1.4 Retransmission
If a specific data packet requires a response and an appropriate response is not received within the response
time-out period, the identical data packet (e.g. same data packet number, same time stamp, etc.) shall be
retransmitted one time only. If no response is received to the second data packet, prior to a subsequent
response time-out period, the data packet transmission shall be considered unsuccessful. If a response is
received after the time-out period, it may be ignored.
6.1.5 Duplicate data packets
Any time a client or server receives a data packet that requires a response, a new response data packet shall
be prepared and transmitted as soon as possible, even if the received data packet was a duplicate data
packet.
6.2 General file procedures
The client may request the publication (reply) data to be sent within the publication data packet, or it may
request the publication data to be stored in a file on the server with the publication data packet indicating the
file name of the publication file. The file can then be retrieved by the client within the constraints set by the
server. Such a publication file shall only contain the “TICS information” as defined by the PublicationData
structure as defined in A.9.
6.3 Sessions
Within each session, one system is a client and the other is a server. A server 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 could exist between a given client system
and server system pair.
NOTE 1 Multiple sessions may exist on a single physical link simultaneously. For example, system A may act as a
server in one session with system B while acting as a client in a second session.
NOTE 2 A single client may have sessions with multiple servers simultaneously; thus, the complete session number
over any given transport profile is defined by the server domain name followed by the client domain name.
NOTE 3 Some implementations may have a need to frequently publish relatively large data packets. 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 data packets 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 Simultaneous sessions between a single client and server pair may exist if the sessions use different transport
profiles (e.g. one UDP and one TCP).
6.3.1 Establishing a session
The server 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 server is protected by a firewall. In
this case, the server shall transmit an “Initiate” data packet, as defined in A.3, with the datex-Destination-txt
and datex-Sender-txt fields set to the proper name.
A server should not terminate a session it initiated for a period of one heartbeat duration after final publication.
If the client receives an “Initiate” data packet or if the client wishes to establish a session, the client shall
transmit a “Login” data packet, as defined in A.4.
Upon receiving a “Login” data packet, a server shall determine if the domain names, user-name, password,
maximum heartbeat duration, response time-out period, allowed encoding rules, datagram size and login
reason are valid for the request. The server 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 server shall either:
⎯ respond with a “reject” data packet, as defined in A.12, with the “error-code” set to the most appropriate
code number which applies to the denial, or
⎯ not respond if the server determines this is appropriate due to security reasons.
If the request is valid, the server shall respond with an “accept” data packet, as defined in A.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 3. All data packets exchanged during this
procedure shall use the encoding rules that were agreed to off-line. All data packets exchanged after the
successful completion of this procedure shall use the encoding rules, as negotiated within the “Login” and
“Accept” data packets.
EXAMPLE Per Annex D, if the session is established over TCP/IP on Port 355, data packets exchanged during this
procedure shall use BER encoding; data packets exchanged after the successful completion of the login process would
then use the encoding rules negotiated by the “Login” and “Accept” data packets.
8 © ISO 2005 – All rights reserved

Figure 3 — Establishing a session
6.3.2 Maintaining a session
Sessions are maintained by the client and server exchanging “FrED” data packets. If, at any point during a
session, no data packets 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 server without exchanging any data. This type of termination should only be encountered due to unusual
circumstances, e.g. a system crash.
NOTE 1 FrED stands for a “Friendly Exchange of Data”. The data packet is generally used as an acknowledgement
data packet, but it is also used as a system heartbeat when there has been a prolonged period of silence. Thus, the term
“ack” did not truly apply to this data packet and the committee determined that it should be termed a “FrED”.
NOTE 2 A session may 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 by 6.3.3. The
client shall keep track of the elapsed time since it received a data packet from the server and shall ensure that
this time does not exceed the maximum heartbeat duration by generating “FrED” data packets, as defined in
A.5, as needed. The DATEX.FrED_ConfirmPacket_number-ulong shall be zero (0) for such “FrED” data
packets, hereinafter referred to as “FrED” heartbeat data packets. It is recommended that the client transmit
“FrED” heartbeat data packets roughly three times more often than the time specified by the maximum
heartbeat duration.
The server shall acknowledge a “FrED” heartbeat data packet by transmitting a “FrED” data packet with the
DATEX-FrED_ConfirmPacket_number-ulong set to the packet number of the “FrED” heartbeat data packet
which is being acknowledged. This shall complete the session maintenance procedure.
When desired, the session shall be terminated according to the procedure described in 6.3.3.
The procedure to maintain a session is summarized in Figure 4.
Figure 4 — Maintaining a session
6.3.3 Terminating a session
A session may be actively terminated by either the client or the server. If the server wishes to terminate a
session, it shall transmit a “Terminate” data packet, as defined in A.6. If the server does not receive any
response after two tries, the server shall terminate the session on its end.
If the client receives a valid “Terminate” data packet, or if the client wishes to terminate a session, it shall
transmit zero or more subscription cancellations, as defined in 6.4 and A.8, if it wishes to cancel any persistent
subscriptions, followed by a “Logout” data packet, as defined in A.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 may be
useful for dial-up connections or to minimize the impact of system crashes.
NOTE 2 A server does not need to wait for a FrED for a guaranteed publication to a non-persistent subscription.
Upon receipt of a valid “Logout” data packet, the server shall terminate the associated session and issue
a ”FrED” data packet, as defined in A.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 rules of 6.3.2.
The procedure to terminate a session is summarized in Figure 5.
10 © ISO 2005 – All rights reserved

Figure 5 — Terminating a session
6.4 Requesting information
Clients and servers shall provide for off-line subscriptions (requests), as defined in 6.4.1, on-line subscriptions
as defined in 6.4.2, or both.
NOTE The subscription process may take place off-line or on-line. This allows a server to transmit publications
(replies) (e.g. accident publications) without having to support the associated subscription data packet. This may be
desirable in order to bring legacy systems into compliance or for security purposes.
6.4.1 Off-line subscriptions
Servers may provide local mechanisms to register any and all subscriptions to which the server claims
compliance. This feature shall be supported for all clients known to the server.
Clients may provide local configuration mechanisms to accept publications from a remote server so that the
client may accept publications related to an off-line subscription.
6.4.2 On-line subscriptions
A client may support the ability to transmit “subscription” data packets, as defined in A.8. If the client claims
compliance for on-line subscriptions, it shall support this service for all subscriptions to which it claims
compliance.
A server may accept “subscription” data packets in order to allow for on-line requests to be processed. If the
server claims compliance for on-line subscriptions, it shall support “subscription” data packets for all
subscriptions to which it claims compliance.
Upon receipt of a subscription data packet, the server shall respond with either an ”accept” or ”reject” data
packet, as defined in A.11 and A.12. An “accept” 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” data packet would be transmitted, but the end-application would immediately
transmit a “publication”, as defined in 6.5, indicating that the subscription has been terminated with a reason of
accessDenied.
This shall complete the subscription procedure.
If the subscription was accepted, the server shall publish data according to 6.5. A subscription can be
cancelled by setting the datexSubscribe-CancelReason-cd field to one of the cancel reasons.
The procedure to request information is summarized in Figure 6.

Figure 6 — Subscribing a session
6.5 Publication of information
Publication of information is partially dependent upon the type of request. The general procedure is described
in 6.5.1; the specific procedures for the different types of requests are described in:
⎯ 6.5.2 for single subscriptions, and
⎯ 6.5.3 for registered subscriptions.
For each subscription to which a system claims compliance, the associated publication shall be supported.
Support of the publication data packet is mandatory for all data packets less than the maximum datagram size.
If the system claims compliance to publications that exceed the maximum datagram size, the system shall
support the “publication-notice” (see 6.5.1.3) and the file transfer mechanism (see 6.5.1.5); otherwise, support
for the “publication-notice” and file transfer mechanism are optional. If a system claims compliance to the
“publication-notice” and file transfer mechanism, the system shall support these features for all subscriptions
to which it claims compliance. Support for multiple publications within a single data packet or single file is
mandatory for clients to receive and optional for servers to send.
6.5.1 General procedures
The server shall generate a “publication” data packet, as defined in A.9, at times specified in 6.5.2-6.5.3.
6.5.1.1 Guaranteed flag
The datexPublish-Guaranteed-bool shall be set to “true” if the associated “subscription” data packet requested
guaranteed delivery; otherwise, it shall be set to “false”.
12 © ISO 2005 – All rights reserved

6.5.1.2 Datagram publications
If the client subscribed for datagram publications, the publication data packet shall contain the publication data
if the resulting datagram is smaller than the maximum datagram size defined in the Interchange agreement.
NOTE A memory table would most typically be transmitted as a datagram, although it could also be transferred as a
file by creating a virtual disk in memory.
6.5.1.3 Publication-notice datagram
If the client subscribed for file publications, or if the resulting datagram is larger than the maximum datagram
size, the data shall be stored in a file and the publication data packet shall indicate the path and filename of
the publication data.
NOTE The file transfer uses standard file transfer protocols; thus, the file is exchanged in a separate session from
the one used for the DATEX-ASN data packets described in this part of ISO 14827.
6.5.1.4 Client response
If the client determines that the publication is improperly encoded, except for any PublicationData structure
that may be present, it shall issue a “reject” data packet, as defined in A.12. Otherwise, if datexPublish-
Guaranteed-bool is set to true, the client shall issue an “accept” data packet, and if datexPublish-Guaranteed-
bool is set to false, no response shall be sent.
NOTE Any errors within the PublicationData structure are handled by the procedures in 6.5.1.6.
This shall complete the publication procedures if the “publication” data packet was invalid or if the “publication”
data packet indicated a filename and that file was previously downloaded and not yet acknowledged with a
transfer done data packet. If the “publication” data packet indicated a file that has not been previously
downloaded, the procedures of 6.5.1.5 and 6.5.1.6 shall follow in order. If the “publication” data packet
contained the publication data, the procedures of 6.5.1.6 shall follow.
NOTE A duplicate file name may be received due to a duplicate message being sent because of a communications
error or due to a recycling of message names. Servers may wish to name files with large sequential numbers to avoid
duplicate file names and prevent any loss of data. If the client has already been notified of the publication, there is no
reason to start another file transfer process.
6.5.1.5 File transfer mechanism
If the “publication” data packet indicated a new filename (i.e. it was not a duplicate message), the client shall
immediately retrieve the indicated file after sending the accept data packet, if required. The file transfer shall
be via one of the supported file transfer mechanisms, as negotiated in the “subscription” and “publication” data
packets. Once the file has been transferred (or the client has exceeded its maximum number of tries to
download the file), the client shall transmit a “transfer-done” data packet, as defined in A.10, to verify the
receipt (or notify the server of failure). The server shall acknowledge the “transfer-done” data packet with an
“FrED” data packet, as defined in A.5. The server shall attempt to keep the file available for downloading until
the transfer done notice is received.
6.5.1.6 Reject invalid publication data
For each invalid PublicationData structure contained within the publication (due to invalid encoding), the client
shall send a reject data packet. This shall complete these procedures.
The procedure to publish information is summarized in Figure 7. A server may cancel any subscription at any
time by sending a publication data packet with the publicationType field of the PublicationData structure set to
one of the terminate codes.
Figure 7 — Publishing information
NOTE The file transfer in the above exchange is a complex procedure, as defined by the associated file transfer
standard. The file transfer is requested by the client, but is shown as an arrow from the server to indicate that the file is on
the server and is being sent to the client.
6.5.2 Single subscriptions
For one-time, or “single” requests, the server shall publish the requested data as soon as possible after
completion of the “subscription” process. The publication shall contain all data fulfilling the subscription
request.
NOTE Historical data are considered to be separate data elements; thus, historical data can be retrieved as any
other information.
14 © ISO 2005 – All rights reserved

6.5.3 Registered subscriptions
Subscriptions can also be “registered” in order to request information as it becomes available or on a periodic
basis.
6.5.3.1 Registered subscriptions shall either be continuous or daily (i.e. activated on specific days of the
week).
a) If the subscription is continuous, the subscription shall activate at the datexRegistered-StartTime and
remain activated 24 hours a day, seven days a week, until the subscription expires (i.e. reaches the
datexRegistered-EndTime) or is explicitly cancelled by a subsequent subscription. If the datexRegistered-
EndTime is less than or equal to the datexRegistered-StartTime, then no publication shall be made.
b) If the subscription is “daily”, the subscription shall become active within the server at the start time
(datexRegistered-StartTime) on each valid day of week (datexRegistered-DaysOfWeek-cd) occurring on
or after the specified start date (datexRegistered-StartDate) and before or on the specified end date
(datexRegistered-EndDate). It shall be immediately activated if the current time is valid when the
subscription is registered. The subscription shall deactivate at the end of the period defined by the start
time (datexRegistered-StartTimeOfDay) plus the duration (datexRegistered-Duration). The end date shall
not be earlier than the start date. A daily subscription may also be deactivated by a request that cancels
or modifies the subscription. If the datexRegistered-EndDate is less than the datexRegistered-StartDate,
then no publication shall be made.
6.5.3.2 Upon subscription activation (or re-activation), the server shall publish an initial publication
message. If the server can not provide information at the indicated start time, it shall provide information as
soon as possible.
6.5.3.3 Registered subscriptions shall also be classified as either: a) event-driven (i.e. provides
information when a specific event occurs); or b) periodic (i.e. provides information at a defined frequency).
6.5.3.4 After the initial publication is produced, the server shall attempt to produce a subsequent
publication message as follows.
6.5.3.4.1 Ifthe mode is “periodic”, the server shall attempt to produce a new publication periodically at a
frequency as defined by datexRegistered-UpdateDelay-qty. If the subscription is sent after the start time, the
cycle shall be synchronized with the datexRegistered-StartTime.
NOTE In this case, the initial publication will be at a random point in the cycle, and the second publication may follow
at any fraction of the cycle later, but will occur on a cycle point as measured from the datexRegistered-StartTime.
In the periodic mode, a server should publish information at every cycle point. If the server is unable to publish
the information within a period of 60 % of a cycle beyond the cycle point, the publication should not be
transmitted. Both the server and the client should terminate less important subscriptions (e.g. as reflected in
the datexSubscription-Priority field) to minimize the probability of this occuring.
NOTE For example, it is assumed that there is a periodic subscription for data every second. The server responds
orig
...