EN 15969-1:2015

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Cisterne za prevoz nevarnega blaga - Digitalni vmesniki za prenos podatkov med vozilom cisterno in stacionarnimi napravami - 1. del: Opredelitev protokola - Upravljanje, merjenje in zajem podatkovTanks 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 EreignisdatenCiternes pour le transport de matières dangereuses - Interface numérique pour le transfert de données entre le véhicule-citerne et les installations fixes - Partie 1: Spécification du protocole - Contrôle, mesurage et donées d'évènementsTanks 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 data35.240.60Uporabniške rešitve IT v transportu in trgoviniIT applications in transport and trade23.020.10UH]HUYRDUMLStationary containers and tanks13.300Varstvo pred nevarnimi izdelkiProtection against dangerous goodsICS:Ta slovenski standard je istoveten z:EN 15969-1:2015SIST EN 15969-1:2015en,fr,de01-oktober-2015SIST EN 15969-1:2015SLOVENSKI
STANDARDSIST EN 15969-1:20111DGRPHãþD

EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 15969-1
July 2015 ICS 35.240.60 Supersedes EN 15969-1:2011English 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 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
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 This European Standard was approved by CEN on 6 June 2015.
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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre:
Avenue Marnix 17,
B-1000 Brussels © 2015 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 15969-1:2015 ESIST EN 15969-1:2015

Page European foreword .4 Introduction .5 1 Scope .6 2 Normative references .6 3 Terms and definitions, abbreviations and conventions .6 3.1 Abbreviations .6 3.2 Terms and definitions .7 3.3 Conventions .8 4 Hardware interface.9 5 Basic protocol layer .9 5.1 FTL-frame (frame) .9 5.2 Frame flow (handshake) . 10 5.3 Delay and timeout . 15 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 . 16 6.3 Nodes, subnodes, variables . 16 6.4 Format identifiers. 17 6.5 Types of variable values . 19 6.6 Kinds of nodes . 20 7 FTL-Data . 21 7.1 General . 21 7.2 Record and field types . 21 7.3 Systemwide variables (subnode SYSTEM) . 22 7.4 Variables related to global positioning system (subnode GPS) . 25 7.5 Accessing a printer on TVE-side (subnode PRN) . 25 7.6 Compartment information (subnode COMP) . 28 7.7 Notification about changes (subnode NOTIFY) . 29 7.8 Information about driver (subnode DRIVER) . 30 7.9 Information about the vehicle (variable VEHICLE_ID) . 31 7.10 Access to filesystem on TVE (subnode FS) . 31 7.11 Auxiliary (subnode AUX) . 36 7.12 Order management (subnode ORDER) . 36 7.13 Goods and service database . 40 7.14 FTL—logfile (subnodes LOG) . 42 7.15 Required variables . 68 7.16 NAK ID . 69 8 Routing for multiple TVE . 70 8.1 Purpose . 70 8.2 Routing solution . 70 8.3 Routing example . 70 9 Communication with office . 71 9.1 General . 71 9.2 Simple file transfer. 72 9.3 FTL over TCP/IP . 74 SIST EN 15969-1:2015

Test FTL . 82 B.1 Overview . 82 B.2 Basic Protocol Layer . 82 B.2.1 Frame Tests . 82 B.2.2 CRC-error . 83 B.2.3 Delay and Timeout . 83 B.3 Data Protocol Layer . 83 B.3.1 Test of Toggling . 83 B.3.2 Test of the FTL data layer . 84 B.3.3 Test of the required FTL nodes . 85 B.3.4 Optional System Subnodes . 88 B.3.5 Optional Node Prn . 89 B.3.6 Node Comp . 91 B.4 Application Layer . 97 B.4.1 Test of the L-File . 97 B.4.2 Test of the LH-File . 97 B.4.3 Test for the Filling of the NodeList . 98 B.4.4 Sequence Test . 98 Bibliography . 100
Key : direction of communication bclient : serverc a may be either two independent units or one single unit which incorporates both functions OBC and TVE Figure 1 SIST EN 15969-1:2015

NOTE
One party in the FTL-communication (the client). PID product identification device according to EN 14116 SYN synchronisation controlframe SPDS sealed parcel delivery system according to EN 15208 TEF CRC transmission error controlframe TVE tank-vehicle-equipment
NOTE
One party in the FTL-communication (the server). OpCode
operation code 3.2 Terms and definitions 3.2.1 downgrade intentional loading and discharge of a higher grade product (substance) into a lower grade product of the same group 3.2.2 answer time time between last frame character transmitted from OBC (client) and first character frame received from TVE (server) 3.2.3 array collection of elements which have the same structure and are able to be accessed individually by means of an index 3.2.4 client responsible for initiation and control of data exchange 3.2.5 field element of a datagram delimited by separators 3.2.6 frame data packet with variable length and defined structure 3.2.7 list type of variables consisting of a number of records SIST EN 15969-1:2015

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 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 9600 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) SIST EN 15969-1:2015

end of record frame EOR data R, V r, v additional dataframe following frame ADF data L, P l, p end of transmission frame EOT data E, I e, i Controlframe
acknowledge frame ACK no A a synchronisation/wait frame SYN no -a s cancel frame
CAN no C c CRC transmission error frame TEF no T t not acknowledge frame NAK NAK-ID according to Table 17 -a n 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 a controlframe from 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. SIST EN 15969-1:2015

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 SIST EN 15969-1:2015

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. Multiple SYN—frame are possible but always a final acknowledge shall follow, see Figure 8. tW shall be between 30 % and 90 % of the maximum answer time Rt, see 5.3. SIST EN 15969-1:2015

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, 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 SIST EN 15969-1:2015

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. NOTE 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 bûqc 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. SIST EN 15969-1:2015

EN 14116:2012+A1:2014, 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 defines 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; SIST EN 15969-1:2015

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
001 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 has to 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 SIST EN 15969-1:2015
+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 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:2014 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) Cx 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 have to 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 Examples for invalid coding:
001224013159 shortened time stamp string
200012240131 seconds are missing
20001224013159,75 comma not allowed – use period SIST EN 15969-1:2015

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. SIST EN 15969-1:2015

ENQ,FTL,SYSTEM,SYS_ERR
REP,FTL,SYSTEM,SYS_ERR=90,10301,44326 7.3.8 List of supported nodes and variables (list NODELIST) Variable FTL,SYSTEM,NodeList=V Kind List, read only, required Enquiry Returns a list of nodes and subnodes supported by the answering TVE. Value V All supported nodes (including their path) 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 7.3.9 Certificate for electronic signature Variable FTL,SYSTEM,CERTIFICATE=V Kind List, read only, optional Enquiry Returns the certificate of the unit used for electronic signature Format V Base64 encoded according to 6.8 of RFC 2045a). a) RFC 2045 is explained in the document " Multi purpose internet mail extension (MIME) subclause 6.8. This document is available at web site, accessed through : www.ietf.org/rfc/rfc2045.txt 7.3.10 Remote popup message Variable FTL,SYSTEM,MESSAGE=V Kind Variable, Read/w
...