EN 15969-1:2022

SLOVENSKI STANDARD
01-december-2022
Nadomešča:
SIST EN 15969-1:2018
Cisterne za prevoz nevarnega blaga - Digitalni vmesnik za prenos podatkov med
cisterno in stacionarnimi napravami - 1. del: Opredelitev protokola - Upravljanje,
merjenje in zajem podatkov
Tanks for transport of dangerous goods - Digital interface for the data transfer between
tank vehicle and with stationary facilities - Part 1: Protocol specification - Control,
measurement and event data
Tanks für die Beförderung gefährlicher Güter - Digitale Schnittstelle für den
Datenaustausch zwischen Tankfahrzeugen und stationären Einrichtungen - Teil 1:
Protokollspezifikation - Steuerungs-, Mess- und Ereignisdaten
Citernes destinées au transport de matières dangereuses - Interface numérique pour le
transfert de données entre des véhicules-citernes et des installations fixes - Partie 1 :
Spécifications du protocole - Contrôle, données de mesure et d’événements
Ta slovenski standard je istoveten z: EN 15969-1:2022
ICS:
13.300 Varstvo pred nevarnimi Protection against dangerous
izdelki goods
23.020.10 Nepremične posode in Stationary containers and
rezervoarji tanks
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 15969-1
EUROPEAN STANDARD
NORME EUROPÉENNE
October 2022
EUROPÄISCHE NORM
ICS 13.300; 23.020.10; 35.240.60 Supersedes EN 15969-1:2017
English Version
Tanks for transport of dangerous goods - Digital interface
for the data transfer between tank vehicle and with
stationary facilities - Part 1: Protocol specification -
Control, measurement and event data
Citernes destinées au transport de matières Tanks für die Beförderung gefährlicher Güter - Digitale
dangereuses - Interface numérique pour le transfert de Schnittstelle für den Datenaustausch zwischen
données entre des véhicules-citernes et des Tankfahrzeugen und stationären Einrichtungen - Teil
installations fixes - Partie 1 : Spécifications du 1: Protokollspezifikation - Steuerungs-, Mess- und
protocole - Contrôle, données de mesure et Ereignisdaten
d'événements
This European Standard was approved by CEN on 19 September 2022.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2022 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 15969-1:2022 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 6
1 Scope . 7
2 Normative references . 7
3 Terms and definitions, abbreviations and conventions . 7
3.1 Terms and definitions . 7
3.2 Abbreviations . 9
3.3 Conventions . 9
4 Hardware interface . 10
5 Basic protocol layer . 10
5.1 FTL-frame (frame) . 10
5.2 Frame flow (handshake) . 11
5.3 Delay and timeout . 16
5.4 CRC16 Checksum . 16
6 Data protocol layer (FTL-data protocol) . 16
6.1 Client (OBC) and server (TVE) . 16
6.2 Syntax of data in datagrams . 17
6.3 Nodes, subnodes, variables . 17
6.4 Format identifiers . 17
6.5 Types of variable values . 20
6.6 Kinds of nodes . 21
7 FTL-Data . 22
7.1 General . 22
7.2 Record and field types . 22
7.3 Systemwide variables (subnode SYSTEM) . 23
7.4 Variables related to global positioning system (subnode GPS) . 27
7.5 Accessing a printer on TVE-side (subnode PRN) . 27
7.6 Compartment information (subnode COMP) . 30
7.7 Notification about changes (subnode NOTIFY) . 32
7.8 Information about driver (subnode DRIVER) . 33
7.9 Information about the vehicle (variable VEHICLE_ID) . 34
7.10 Information about current operation (subnode OPERATION) . 34
7.11 Access to filesystem on TVE (subnode FS) . 36
7.12 Auxiliary (subnode AUX) . 41
7.13 Order management (subnode ORDER) . 42
7.14 Goods and service database (subnode PRODUCT) . 46
7.15 FTL—logfile (subnodes LOG) . 49
7.16 Required variables . 81
7.17 NAK ID . 82
8 Routing for multiple TVE . 83
8.1 Purpose . 83
8.2 Routing solution . 83
8.3 Routing example . 84
9 Communication with office . 84
9.1 General . 84
9.2 Simple file transfer . 85
9.3 FTL over TCP/IP . 87
10 Communication Examples . 89
10.1 Examples for Basic Protocol Layer level . 89
10.2 Examples for data protocol layer . 91
Annex A (normative) Node tree . 94
Annex B (normative) Test FTL . 95
B.1 Overview . 95
B.2 Basic Protocol Layer . 95
B.2.1 Frame Tests. 95
B.2.2 CRC-error . 96
B.2.3 Delay and Timeout . 96
B.3 Data Protocol Layer . 96
B.3.1 Test of Toggling . 96
B.3.2 Test of the FTL data layer . 98
B.3.3 Test of the required FTL nodes . 98
B.3.4 Optional System Subnodes . 101
B.3.5 Optional Node Prn . 103
B.3.6 Node Comp . 105
B.4 Application Layer. 111
B.4.1 Test of the L-File . 111
B.4.2 Test of the LH-File . 111
B.4.3 Test for the Filling of the NodeList . 111
B.4.4 Sequence Test . 112
Bibliography . 114

European foreword
This document (EN 15969-1:2022) has been prepared by Technical Committee CEN/TC 296 “Tanks for
the transport of dangerous goods”, the secretariat of which is held by AFNOR.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by April 2023, and conflicting national standards shall be
withdrawn at the latest by April 2023.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 15969-1:2017.
In comparison with the previous edition, the following technical modifications have been made:
— Figure 11 corrected;
— Subclause 7.3.11 “Trailer coupled (variable TRAILER)” added;
— Subclause 7.5.9 “Duplicate print (DUPLICATE)” added;
— Table 55 “Fields of records of ORDER.PLAN” Index 19 to 21 added;
— In subclause 7.13.4 Value V for planned transaction in process and unplanned transaction in process
added;
— Table 67 “L file record types” in Index L1137 Bit 3 added;
— Table 67 “L file record types” Index L1147 added;
— Table 67 “L file record types” Index L1205 added;
— Table 67 “L file record types” in Index L2002 event codes 80 to > 100 added;
— Table 67 “L file record types” Index L4007 and L4008 added;
— Table 67 “L file record types” in Index L4206 delivery path 25 to 36 and 80 to 86 added;
— Table 67 “L file record types” Index L4207 and L4208 added;
— Table 67 “L file record types” Index 94 Diagnose added;
— Node tree in Figure A.1 revised.
EN 15969, Tanks for transport of dangerous goods — Digital interface for the data transfer between tank
vehicle and with stationary facilities, consists of 2 parts:
— Part 1: Protocol specification — Control, measurement and event data;
— Part 2: Commercial and logistic data.
This document forms part of a coherent standards programme comprising the following standards:
— EN 13616-1, Overfill prevention devices for static tanks for liquid fuels — Part 1: Overfill prevention
devices with closure device;
— EN 13616-2, Overfill prevention devices for static tanks for liquid fuels — Part 2: Overfill prevention
devices without a closure device;
— EN 13922, Tanks for transport of dangerous goods — Service equipment for tanks — Overfill
prevention systems for liquid fuels;
— EN 14116, Tanks for transport of dangerous goods — Digital interface for product recognition devices
for liquid fuels;
— EN 15207, Tanks for the transport of dangerous goods — Plug/socket connection and supply
characteristics for service equipment in hazardous areas with 24 V nominal supply voltage;
— EN 15208, Tanks for transport of dangerous goods — Sealed parcel delivery systems — Working
principles and interface specifications;
— EN 15969-2, Tanks for transport of dangerous goods — Digital interface for the data transfer between
tank vehicle and with stationary facilities — Part 2: Commercial and logistic data.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the United
Kingdom.
Introduction
FTL is an acronym for Fuel Truck Link, the interface between electronic system(s) on board of a tank
vehicle (tank-vehicle-equipment) and any external computer, e.g. an on-board-computer installed in the
driver’s cabin; for illustration see Figure 1.

Key
→ direction of communication (client → server)
a may be either two independent units or one single unit which incorporates both functions OBC and TVE
Figure 1
1 Scope
This document specifies data protocols and data format for the communication between electronic
equipment (TVE), on-board computer (OBC) of the tank vehicle and stationary equipment.
This document specifies the basic protocol FTL used in the communication (basic protocol layer), the
format and structure of FTL-data to be transmitted (data protocol layer) and describes the content of the
FTL-data.
This data protocol can be used for other application e.g. between stationary tank equipment and offices.
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.
DIN 51757:2011, Testing of mineral oils and related materials — Determination of density
EN 13616-2, Overfill prevention devices for static tanks for liquid fuels — Part 2: Overfill prevention devices
without a closure device
EN 13922, Tanks for transport of dangerous goods — Service equipment for tanks — Overfill prevention
systems for liquid fuels
EN 14116:2012+A2:2018, Tanks for transport of dangerous goods — Digital interface for product
recognition devices for liquid fuels
EN 15208:2014, Tanks for transport of dangerous goods — Sealed parcel delivery systems — Working
principles and interface specifications
ISO 639-1, Codes for the representation of names of languages — Part 1: Alpha-2 code
3 Terms and definitions, abbreviations and conventions
For the purposes of this document, the following terms and definitions, abbreviations and conventions
apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at https://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
3.1 Terms and definitions
3.1.1
downgrade
intentional loading and discharge of a higher grade product (substance) into a lower grade product of the
same group
3.1.2
answer time
time between last frame character transmitted from OBC (client) and first character frame received from
TVE (server)
3.1.3
array
collection of elements which have the same structure and are able to be accessed individually by means
of an index
3.1.4
client
responsible for initiation and control of data exchange
3.1.5
field
element of a datagram delimited by separators
3.1.6
frame
data packet with variable length and specified structure
3.1.7
list
type of variables consisting of a number of records
3.1.8
MaxFrameSize
maximum number of characters in a frame
3.1.9
node
part of an address of a variable
3.1.10
graphic character
character, other than a control function or a format character, that has a visual representation normally
handwritten, printed or displayed
[SOURCE: ISO/IEC 10646:2020, 3.28]
3.1.11
record
ordered set of fields, stored contiguously
3.1.12
server
program which provides service to client programs
3.1.13
subnode
subpart of an address of a variable
3.1.14
datagram
instruction or answer to an instruction which comprises an OpCode and operand
3.1.15
transaction
complete request-answer-cycle
3.1.16
type identifier
character code for the frame type
3.2 Abbreviations
ACK acknowledge controlframe
ADF additional dataframe
ASCII American Standard Code for Information Interchange
CAN cancel controlframe
CRC cyclic redundancy checksum
CSV comma separated variable record
COP crossover prevention
EOR end of record dataframe
EOT end of transmission dataframe
FTL fuel-truck-link name of the interface
FTP file transfer protocol
L_FILE log file
LH_FILE log file header
NAK not acknowledge controlframe
OBC on-board-computer
NOTE 1 The OBC is one party in the FTL-communication (the client).
PID product identification device according to EN 14116
SYN synchronization controlframe
SPDS sealed parcel delivery system according to EN 15208
TEF CRC transmission error controlframe
TVE tank-vehicle-equipment
NOTE 2 The TVE is one party in the FTL-communication (the server).
OpCode operation code
3.3 Conventions
3.3.1 Syntax conventions
When describing the syntax of e.g. a datagram, some parts are required.
Every abstract part shall get a name, which is encapsulated by “<” and “>”. Optional arguments are
additionally encapsulated in square brackets.
EXAMPLE [,]
has always to be given (required). is optional, but when given, it shall be
preceded by a comma.
3.3.2 Presentation of communication exchange
In this document several examples can be found, demonstrating the flow of communication.
To illustrate the direction, data sent by the TVE (server) is shown indented.
EXAMPLE
client request 1
server response 1
server response 2
server response 3
client request 2
This means, that the command “client request n” shall be transmitted by the OBC, whereas the lines
“server response n” were transmitted by the TVE.
3.3.3 Numbers
Numbers may either be coded in decimal format (e.g. 12) or in hexadecimal format (e.g. 1Bh). In the latter
case, the number shall be followed by the character “h”.
4 Hardware interface
Communication shall only take place between two parties (point-to-point) the TVE and OBC.
For communication an asynchronous line shall be used (RS232, RS422 or RS485). The OBC and TVE start
up and default settings shall be 9 600 baud, 8 data bits, 1 stop bit and no parity.
The TVE may optionally support other baud rates (switching and switching back see 7.3.6).
5 Basic protocol layer
5.1 FTL-frame (frame)
The FTL-frame shall be according to Figure 2.

Figure 2
A frame shall have the following minimum requirements:
— always starts with a Start—Flag;
— always followed by type identifier;
— 1 End-Flag;
— 4 character Checksum (valid or invalid);
— frame length limited to MaxFrameSize.
Frames which do not fulfil these requirements shall be ignored and not answered. A new frame starts
upon the receipt of a Start-Flag. Any character received before the Start-Flag shall be ignored. All devices
using the FTL-protocol shall be able to receive complete frames of MaxFrameSize characters. A frame
shall be answered even if it contains an invalid checksum or incorrect characters (see 5.2).
If the type identifier in a frame is unknown a NAK shall be sent.
MaxFrameSize
The MaxFrameSize shall be 255 characters.
Start—Flag
The ASCII code 02h (start of text ) shall be used as the Start-Flag.
Type identifier
The type identifier shall be according to Table 1.
Content
The content may be empty or shall contain up to MaxFrameSize minus 7 characters. All characters in the
content shall be printable characters.
End-Flag
The ASCII code 03h (End of Text ) shall be used as the End—Flag.
Checksum
The Checksum verifies the integrity of a frame. It covers all characters from Start—Flag to End—
Flag including these flags. A CRC16 (16 bit) value in hexadecimal format (always 4 characters long) is
used and shall consist of the printable ASCII character “0” “9” or “A” “F” (example: the value 1AC9h shall
be sent with 4 ASCII character “1AC9”). The algorithm for the calculation is described in 5.4.
5.2 Frame flow (handshake)
The character immediately following the Start-Flag specifies the frame type. The different frame groups
and their frame types are described in Table 1.
Table 1 — Frame groups and frame types
Type identifier
Additional
Frame group Frame type Abbreviation
Client to Server to
fields
server client
Dataframe end of record frame EOR data R, V r, v
additional dataframe
ADF data L, P l, p
following frame
end of transmission
EOT data E, I e, i
frame
Controlframe acknowledge frame ACK no A a

synchronization/wait
a
SYN no s
—
frame
cancel frame CAN no C c
CRC transmission error
TEF no T t
frame
not acknowledge frame NAK-ID
a
NAK according to n
—
Table 71
a
Not applicable.
To distinguish the direction of data (client to server or server to client) upper and lower case type
character shall be used.
Every communication shall start with a dataframe.
Every dataframe from the server shall be answered by the client.
Every frame from the client shall be answered by a frame from the server.
If a dataframe is received by the server when an acknowledge is expected it shall be treated as a cancel
frame (CAN) regarding the preceding transaction.
Every data frame on each side, independently, shall be flagged alternatively (toggled) with the secondary
(V,P,I) and primary (R,L,E) type identifier. If subsequent dataframes with identical type identifier are
received, these shall be treated as a repetition with identical data but shall be answered as the original,
see Figure 11. This prevents redundant entries in lists resulting from communication faults.
After the startup of the system the first dataframe on each side shall start with the primary type identifier
(R,L,E). The first request after startup shall not be a SET-request to a list.
Examples of frame flows:
— Transaction that requires only one datagram in either direction, each fitting into a single frame,
see Figure 3.
a) b)
Figure 3
— Transactions that require more than one datagram (e.g. multi record transfer), EOR—frames shall
indicate that additional datagrames will follow. An EOT—frame shall be the last dataframe of the
transaction, see Figure 4.
a) b)
Figure 4
— Datagrams that require more than one frame, because MaxFrameSize is too small to hold a complete
datagram shall be split into one or more ADF—frames and an EOT—frame or EOR-frame as
appropriate, see Figure 5.
a) b)
Figure 5
— The preceding examples may be combined as in Figure 6.

a) b)
Figure 6
TEF—frame
In case of a CRC error all frametypes shall be answered with a TEF— frame. The frame shall then be
repeated, see Figure 7.
a) b)
Key
1 controlframe is repeated
2 dataframe is repeated
Figure 7
SYN-frame
A SYN—frame is not a final acknowledgement. It notifies a busy status of the server while preparing the
answer to prevent a timeout.
t
Multiple SYN—frame are possible but always a final acknowledge shall follow, see Figure 8. shall be
w
between 30 % and 90 % of the maximum answer time Rt, see 5.3.
Figure 8
CAN—frame
Transactions can be cancelled if procedures with higher priorities have to be serviced from the higher
application layer. Then a CAN—frame shall be sent. It terminates the transaction but does not act as an
ACK-frame, see Figure 9.
Figure 9
NAK-ID frame
If any problems (except for CRC error) occur with the frame or with the “execution” of the frame a NAK-
ID frame shall be sent. The NAK ID, see Table 71, which shall be transmitted in its content, shall identify
the reason for the NAK, see Figure 10. The application layer shall decide how to continue.

Figure 10
a) b)
Figure 11
Figure 11 shows the use of the alternating type ID (toggle), which accompanies the record, to identify the
receipt of duplicated records.
5.3 Delay and timeout
Figure 12
If the answer time (AT), see Figure 12, exceeds Rt, a timeout shall be detected by the client. For short
distance (e.g. RS 232, RS485, Low Power Radio) communication “Rt” value shall be 1 s.
This value may not be sufficient for long distance (e.g. GSM/GPRS) communication, where additional
routing delays may occur.
Figure 13
Within a frame transmitted by the server, the delay (ΔT) between two subsequent characters shall not
exceed three character times, see Figure 13. For frames transmitted by the client there is no limitation.
If a timeout occurs after a transmission of a dataframe, the previous dataframe shall be repeated by the
client. If a timeout occurs after a transmission of a controlframe, a repetition shall be requested by
transmission of a TEF-frame.
After three consecutive timeouts (1 initial + 2 retries), the transaction shall be cancelled without a CAN-
frame (see 5.2). The application layer shall decide what action shall be taken.
As the client does not know whether the server has received the last ACK-frame before the timeout the
last record may be repeated upon the next request to this node.
5.4 CRC16 Checksum
Since a frame might have been corrupted during transmission, a checksum shall be included in each
frame. It shall cover all characters from Start—Flag to End—Flag including these flags.
The calculation algorithm for CRC16 shall be according to EN 14116:2012+A2:2018, Annex B.
6 Data protocol layer (FTL-data protocol)
6.1 Client (OBC) and server (TVE)
The TVE shall act as server, providing data to the client, usually the OBC. Only the client shall initiate data
exchange. Each frame from the client shall be followed by one frame from the server.
Thus, the only way for the server to transmit information to the client is to let the client poll the
appropriate variables in intervals.
6.2 Syntax of data in datagrams
6.2.1 General
Every datagram shall have the following syntax:
,[,],[()][ = ].
Except for all other are not case-sensitive. Thus, “ENQ” shall be handled equally to “Enq”.
may consist of a number of subnode levels. may be empty.
6.2.2 Operation codes (OpCodes)
The OpCode specifies the type of operation. OpCode according to Table 2 shall be supported:
Table 2 — Operation of FTL protocol
Operation Opcode Description
Enquiry ENQ Sent by the client to retrieve
data from the server (“=” is not
allowed)
Set SET Sent by the client to set data in
the server (“=” shall be present)
Clear CLR Sent by the client to delete a list
of records (“=” is not allowed)
Report REP Sent by the server as a response
to a Enquiry (followed by “=”
with value). An empty list is
identified by a missing equal-
sign and no value.
NOTE A further optional Operation “NEW”, which is for channel 3 use only, is given in 9.3.4.
6.3 Nodes, subnodes, variables
All data provided by server shall be stored in variables which may be accessed by the client (see Clause 7).
Each name identifying , and shall:
— be limited to 10 characters;
— only consist of the characters “A” to “Z”, “0” to “9” and “_”;
— never start with numerical characters “0” to “9”.
Some variables are arrays. By specifying a numerical index enclosed by brackets (), one particular array
element shall be accessible.
Indexing shall always start with 1.
6.4 Format identifiers
The formatting of values depends on the corresponding variable. The codes according to Table 3 for
format identifiers are used in this document.
Table 3 — Format identifiers
Format identifier Description
B Boolean value (0 or 1)
Only the values 0 and 1 are valid
Examples for valid coding:
0 False
1 True
Examples for invalid coding:
2 invalid value
A invalid value
0.1 separator not allowed/more than one character not allowed
Nx Integer decimal value with max x characters (including sign character)
Examples for valid coding (for N3):
1 Value: +1
01 Value: +1
123 Value: +123
+12 Value: +12
−12 Value: −12
Examples for invalid coding (for N3):
1234 more than three characters
+123 more than three characters
0.1 separator not allowed
1E2 invalid character 'E'
Nx.y Floating point value
max. x digits in front of the period (including ± )
max. y digits behind the period
Only characters 0 to 9 and period are allowed. At least one digit in front
and behind the period shall be used. No exponential expressions.
Examples for valid coding (for N3.2):
1.0 Value: +1,0
001.2 Value: +1,2
001.23 Value: +1,23
000.12 Value: +0,12
0.1 Value: +0,1
+01.23 Value: +1,23
−01.23 Value: −1,23
Valid examples for longitude GPS values N4.6 in degrees:
+007.512500 7,512500° E = 7° 30′ 45“ E = 7° 30,750’ E
7.5125 7,512500° E = 7° 30′ 45“ E
−007.512500 7,512500° W = 7° 30′ 45“ W
Format identifier Description
Valid examples for latitude GPS values N3.6:
+07.512500 7,512500° N = 7° 30′ 45” N
Examples for invalid coding (for N3.2):
1234.5 more than 3 digits in front of period
+123.4 more than 3 digits in front of period
−123.4 more than 3 digits in front of period
123.456 more than 2 digits behind period
0,1 separating character not allowed (use period)
123 separating character missing
.12 minimum number of digits missing in front of period
123. minimum number of digits missing behind period
1.E5 invalid character
Cx Text with maximum number of x bytes.
UTF-8 according to ISO/IEC 10646:2020 except for codes less than 0x20
and except for comma 0x2C;
All other characters are embedded similar to the mechanism of the C
programming language using the “\” character followed by a two nibble
hex value (examples \n for LF, \x1B for ESC, \, for comma).
Following codes shall be implemented: \\ (“\”) \n \r \f \t \, and \xNN
(0xNN)
Examples for valid coding (for C12):
abcdoCD = 12 < abcdoCD = 12 <
a\n\x0A a < 0x0A > < 0x0A > “
(<.> . hex value for control character)
a\n\x0A\x1B
12345\,67890 12345,67890
1\,2 Ab\\yz 1,2 Ab\yz
Examples for invalid coding (for C12):
abcdCD12.3456 more than 12 characters
abCD12,345 comma not allowed
S Time stamp – CCYYMMDDhhmmss
Shortened forms of the time stamp string such as (CCYYMMDD) are not

allowed. In this case unused fields shall be filled with 00. However a single

digit 0 shall be used to represent no time stamp.
Is a higher resolution than seconds needed fractions of seconds may be
appended at the end of the time stamp string.
Examples for valid coding:
19990109230201 09. January 1999 23:02:01
20001224013159.75 24. December 2000 1:31:59,75
Format identifier Description
Examples for invalid coding:
001224013159 shortened time stamp string
200012240131 seconds are missing
20001224013159,75 comma not allowed – use period
D Date – CCYYMMDD
see description for format identifier S above
Examples for valid coding:
19990109 09. January 1999
20001224 24. December 2000
Examples for invalid coding:
001224 shortened date string
T Time – hhmmss
see description for format identifier S above
Examples for valid coding:
230259 23:02:59
013159.75 1:31:59,75
Hx Unsigned hexadecimal value with max x characters, representing a bit
pattern with x · 4 bits
Bit 0 is encoded as value 1
Bit 1 is encoded as value 2
Bit 2 is encoded as value 4 and so on
Examples for valid coding:
10A8 represents a field of 16 bits where bits 12, 7, 5 and 3 are
set. All other Bits are zero.
Examples for invalid coding:
10a8 lower case character “a” used
0x10A8 invalid character “x” used
$10A8 invalid character “$” used
6.5 Types of variable values
6.5.1 Single-Field-Type
represents exactly one field with any one of the variable types given in Table 3.
No separators or special codes for quoting are needed.
6.5.2 CSV Records and quoting
,,,…
In this case, consists of a list of fields separated by the character comma “,”. Each field is of one-
field-type.
The formatting of a CSV record shall follow the guidelines below:
1) concatenation is done with the separator character comma (“,”);
2) numeric field of zero-length (empty field) shall be interpreted as not available;
3) trailing commas can optionally be omitted.
6.6 Kinds of nodes
6.6.1 General
When accessing or the behaviour of the server depends on the kind of
or . The three kinds in 6.6.2 to 6.6.4 shall be supported.
6.6.2 Values
The simplest kind is a value, which consists of exactly one line, which can either be of type CSV or of any
other single-field type, see Table 4.
Table 4 — Operation applicable to simple values
Operation Effect (if operation allowed in this context)
Enquiry shall return the current variable contents ()
Set shall replace the current variable contents () by the new value given behind
the “=”-character
Clear Not allowed
Examples can be found in Clause 10.
6.6.3 Lists
Some subnodes or variables are accessed as lists, which mean that more than one value or line may be
stored or read, see Table 5.
Table 5 — Operation applicable to lists
Operation Effect (if operation allowed in this context)
Enquiry shall return the current variable contents, line by line.
Set shall add the new value given behind the “=”—character to the list
Clear shall make the list empty
An enquiry of an empty list (list without elements) shall be answered with a report without equal-sign.
In contrast, an enquiry of a list with empty element shall be answered with a report with equal-sign
without .
If more than one record is to be added to the list it is recommended to send all frames within one
transaction using EOR-frames.
EXAMPLE ENQ,FTL,SYSTEM,NodeList

REP,FTL,SYSTEM,NodeList = FTL,SYSTEM,NODELIST
REP,FTL,SYSTEM,NodeList = FTL,SYSTEM,FTL_VERS
REP,FTL,SYSTEM,NodeList = FTL,SYSTEM,FTL_FORMAT
REP,FTL,SYSTEM,NodeList = FTL,SYSTEM,DATETIME
6.6.4 Arrays
Arrays may be accessed according to Table 6 either:
— as value, as described in 6.6.2, when an index is specified in the enquiry or set command (see 6.3);
EXAMPLE 1 ENQ,FTL,AUX,In(1)
REP,FTL,AUX,In(1) = 2
— or without index, in which case every answer shall contain the requested variable or subnode and
the appropriate index.
EXAMPLE 2 ENQ,FTL, AUX,In
REP,FTL, AUX,In(1) = 2
REP,FTL, AUX,In(2) = 2
REP,FTL, AUX,In(3) = 2
Table 6 — Operation applicable to arrays
Operation Effect (if operation allowed in this context)
Enquiry with index: shall return the addressed array element
without index: return entire array, starting with the lowest, and ending with the highest
index
Set with index: replace the contents of the given array element
without index: append the new elements after the last used element
Clear with index: not allowed
without index: clears the contents of all array elements
Examples can be found in Clause 10.
7 FTL-Data
7.1 General
The root node shall be called FTL. (see 8.2 for exceptions). The structure of this node shall be fixed. Thus,
subnodes and variables not described in this document shall not be implemented.
However, it is allowed to only implement a subset of the structures mentioned in this specification. Please
refer to 7.16 for a list of variables which shall be present in every system.
All mentioned subnodes belong to node FTL, see Annex A.
Unless otherwise noted, when the description of TVE-variable refers to a L—FILE-record type, the first
two fields (record type and timestamp) shall be omitted (see example in 7.3.1).
7.2 Record and field types
In this document record types are referred to by #L_. Thus, #L01_DEVICE_ID refers
to record type 01, called DEVICE_ID, which can be found in the L_FILE specification in Table 67.
Meaning and formats of fields are referred to by #L[_]. Thus,
#L0202_veh_type refers to field 2 (called veh_type) in record type 2 (VEHICLE_ID).
7.3 Systemwide variables (subnode SYSTEM)
7.3.1 FTL version (variable FTL_VERS)
Table 7 — Specification of node SYSTEM,FTL_Vers
Variable FTL,SYSTEM,FTL_Vers = V
Kind Value, Read Only, required
Enquiry (item) Returns the version of FTL implemented on the TVE.
Value V #L00_FTL_VERS
EXAMPLE ENQ,FTL,SYSTEM,FTL_Vers

REP,FTL,SYSTEM,FTL_Vers = 1.00
7.3.2 Form
...