SIST EN 15969-1:2011

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

This European Standard specifies data protocols and data format for the interfaces between electronic equipment (TVE), on-board computer (OBC) of the tank vehicle and stationary equipment for all interconnecting communication paths. This European Standard 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.

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

Diese Norm legt die Datenprotokolle und -formate für die Schnittstellen zwischen elektronischen Einrichtungen
(TVE), Bordcomputer (OBC) des Tankfahrzeugs und stationären Einrichtungen für alle Kommunikationswege
fest.
Dieses Dokument legt das für die Kommunikation verwendete Basisprotokoll FTL (basic protocol layer) sowie
die Formate und die Struktur der übertragenen FTL-Daten (data protocol layer) fest und beschreibt die Inhalte
der FTL-Daten.
ANMERKUNG Dieses Datenprotokoll darf auch für andere Anwendungen z. B. zwischen stationären Tankeinrichtungen
und Büros verwendet werden.

Citernes 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 données d'évènements

Posode za prevoz nevarnih snovi - Digitalni vmesniki za prenos podatkov med vozilom s posodo in stacionarnimi napravami - 1. del: Opredelitev protokola - Upravljanje, meritev in zajem podatkov

Ta evropski standard določa podatkovne protokole in podatkovni format za vmesnike med elektronsko opremo (TVE), računalnikom na vozilu (OBC) s posodo in stacionarno opremo za vse medsebojno povezane komunikacijske poti. Ta evropski standard določa osnovni protokol FTL za uporabo pri komunikaciji (plast osnovnega protokola), format in strukturo podatkov FTL, ki se bodoprenesli (plast podatkovnega protokola), in opisuje vsebino podatkov FTL.

General Information

• Status: Withdrawn
• Public Enquiry End Date: 24-Nov-2009
• Publication Date: 13-Oct-2011
• Withdrawal Date: 01-Sep-2015
• ICS: 23.020.10 - Stationary containers and tanks
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: TLP - Pressure vessels
• Current Stage: 9900 - Withdrawal (Adopted Project)
• Start Date: 02-Sep-2015
• Due Date: 25-Sep-2015
• Completion Date: 02-Sep-2015
• Ref Project: EN 15969-1:2011 - 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

Relations

• Replaced By: SIST EN 15969-1:2015 - 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
• Effective Date: 01-Oct-2015

Standards Content (Sample)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Posode za prevoz nevarnih snovi - Digitalni vmesniki za prenos podatkov med vozilom s posodo in stacionarnimi napravami - 1. del: Opredelitev protokola - Upravljanje, meritev 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 donné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 tanksICS:Ta slovenski standard je istoveten z:EN 15969-1:2011SIST EN 15969-1:2011en,fr,de01-november-2011SIST EN 15969-1:2011SLOVENSKI
STANDARD



SIST EN 15969-1:2011



EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 15969-1
September 2011 ICS 35.240.60 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 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 données 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 18 June 2011.
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, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre:
Avenue Marnix 17,
B-1000 Brussels © 2011 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 15969-1:2011: ESIST EN 15969-1:2011



EN 15969-1:2011 (E) 2 Contents
Page Foreword .4Introduction .51Scope .62Normative references .63Terms and definitions, abbreviations and conventions .63.1Abbreviations .63.2Terms and definitions .73.3Conventions .84Hardware interface.95Basic protocol layer .95.1FTL-frame (frame) .95.2Frame flow (handshake) . 105.3Delay and timeout . 165.4CRC16 Checksum . 166Data protocol layer (FTL-data protocol) . 176.1Client (OBC) and server (TVE) . 176.2Syntax of data in datagrams . 176.3Nodes, subnodes, variables . 176.4Format identifiers. 186.5Types of variable values . 206.6Kinds of nodes . 217FTL-Data . 227.1General . 227.2Record and field types . 227.3Systemwide variables (subnode SYSTEM) . 237.4Variables related to global positioning system (subnode GPS) . 267.5Accessing a printer on TVE-side (subnode PRN) . 267.6Compartment information (subnode COMP) . 307.7Notification about changes (subnode NOTIFY) . 317.8Information about driver (subnode DRIVER) . 327.9Information about the vehicle (variable VEHICLE_ID) . 337.10Access to filesystem on TVE (subnode FS) . 337.11Auxiliary (subnode AUX) . 397.12Order management (subnode ORDER) . 397.13Goods and service database . 437.14FTL—logfile (subnodes LOG) . 457.15Required variables . 737.16NAK ID . 738Routing for multiple TVE . 748.1Purpose . 748.2Routing solution . 748.3Routing example . 749Communication with office . 759.1General . 759.2Simple file transfer. 769.3FTL over TCP/IP . 7710Communication Examples . 7910.1Examples for Basic Protocol Layer level . 79SIST EN 15969-1:2011



EN 15969-1:2011 (E) 3 10.2Examples for data protocol layer . 81Annex A (normative)
Node tree . 83Annex B (normative)
Test FTL . 84B.1Overview . 84B.2Basic Protocol Layer . 84B.2.1Frame Tests . 84B.2.2CRC-error . 85B.2.3Delay and Timeout . 85B.3Data Protocol Layer . 86B.3.1Test of Toggling . 86B.3.2Test of the FTL data layer . 87B.3.3Test of the required FTL nodes . 87B.3.4Optional System Subnodes . 91B.3.5Optional Node Prn . 92B.3.6Node Comp . 94B.4Application Layer . 100B.4.1Test of the L-File . 100B.4.2Test of the LH-File . 100B.4.3Test for the Filling of the NodeList . 101B.4.4Sequence Test . 101 SIST EN 15969-1:2011



EN 15969-1:2011 (E) 4 Foreword This document (EN 15969-1:2011) has been prepared by Technical Committee CEN/TC 296 “Tanks for 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 March 2012, and conflicting national standards shall be withdrawn at the latest by March 2012. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights. This European Standard EN 15969, Tanks for transport of dangerous goods – Digital interface for the data transfer between tank vehicle and with stationary vehicles, is divided into the following parts: Part 1 — Protocol Specification – Control, measurement and event data Part 2 — Commercial and logistic data According to the CEN/CENELEC Internal Regulations, the national standards organizations 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, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and the United Kingdom.
SIST EN 15969-1:2011



EN 15969-1:2011 (E) 5 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
SIST EN 15969-1:2011



EN 15969-1:2011 (E) 6 1 Scope This European Standard specifies data protocols and data format for the interfaces between electronic equipment (TVE), on-board computer (OBC) of the tank vehicle and stationary equipment for all interconnecting communication paths. This European Standard 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. NOTE This data protocol may be used for other application e.g. between stationary tank equipment and offices. 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. EN 13616, Overfill prevention devices for static tanks for liquid petroleum fuels EN 13922, Tanks for transport of dangerous goods — Service equipment for tanks — Overfill prevention systems for liquid fuels EN 14116:2007+A2:2010, Tanks for transport of dangerous goods — Digital interface for the product recognition device EN 15208:2007, Tanks for transport of dangerous goods — Sealed parcel delivery systems — Working principles and interface specifications EN 15969-2:2011, 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 ISO 639-1, Codes for the representation of names of languages — Part 1: Alpha-2 code ISO/IEC 10646: 2011, Information technology — Universal Coded Character Set (UCS)
DIN 51757:2011, Testing of mineral oils and related materials  Determination of density 3 Terms and definitions, abbreviations and conventions For the purposes of this document, the following terms and definitions, abbreviations and conventions apply. 3.1 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 SIST EN 15969-1:2011



EN 15969-1:2011 (E) 7 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 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 SIST EN 15969-1:2011



EN 15969-1:2011 (E) 8 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 3.2.8 MaxFrameSize maximum number of characters in a frame
3.2.9 node part of an address of a variable 3.2.10 graphic character according to Annex D of ISO/IEC 10646-1:2011 3.2.11 record ordered set of fields, stored contiguously 3.2.12 server program which provides service to client programs 3.2.13 subnode subpart of an address of a variable 3.2.14 datagram instruction or answer to an instruction, which comprises an OpCode and operand 3.2.15 transaction
complete request-answer-cycle 3.2.16 type identifier character code for the frame type 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. SIST EN 15969-1:2011



EN 15969-1:2011 (E) 9 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 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
SIST EN 15969-1:2011



EN 15969-1:2011 (E) 10 • 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 defines the frame type. The different frame groups and their frame types are described in Table 1. SIST EN 15969-1:2011



EN 15969-1:2011 (E) 11 Table 1 — Frame groups and frame types Frame group Frame type AbbreviationAdditional fields Type identifier client to server server to client Dataframe
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 frameSYN no -1)
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 -1) n 1) 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 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:2011



EN 15969-1:2011 (E) 12
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.
SIST EN 15969-1:2011



EN 15969-1:2011 (E) 13
a) b) Figure 5 • The preceding examples may be combined as in Figure 6:
a) b) Figure 6 SIST EN 15969-1:2011



EN 15969-1:2011 (E) 14 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.
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. SIST EN 15969-1:2011



EN 15969-1:2011 (E) 15
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 must 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.
SIST EN 15969-1:2011



EN 15969-1:2011 (E) 16 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 (û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 Annex C of EN 14116:2007+A2:2010. NOTE
The CRC 16 of EN 14116:2007+A2:2010 was corrected by a later amendment. SIST EN 15969-1:2011



EN 15969-1:2011 (E) 17 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; • only consist of the characters “A” to “Z”, “0” to “
...

SLOVENSKI STANDARD
oSIST prEN 15969-1:2009
01-november-2009
5H]HUYRDUML]DSUHYR]QHYDUQLKVQRYL'LJLWDOQLYPHVQLNL]DSUHQRVSRGDWNRYPHG
YR]LORPFLVWHUQRLQQHSUHPLþQRLQãWDODFLMRGHO6SHFLILNDFLMDSURWRNROD
8SUDYOMDQMHPHUMHQMHPHULWYHLQ]DMHPSRGDWNRY
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 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 données d'évènements
Ta slovenski standard je istoveten z: prEN 15969-1
ICS:
23.020.10 1HSUHPLþQHSRVRGHLQ Stationary containers and
UH]HUYRDUML tanks
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
oSIST prEN 15969-1:2009 en,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
oSIST prEN 15969-1:2009

---------------------- Page: 2 ----------------------
oSIST prEN 15969-1:2009
EUROPEAN STANDARD
DRAFT
prEN 15969-1
NORME EUROPÉENNE
EUROPÄISCHE NORM
July 2009
ICS 35.240.60

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 pour le transport de matières dangereuses - Tanks für die Beförderung gefährlicher Güter - Digitale
Interface numérique pour le transfert de données entre le Schnittstelle für den Datenaustausch zwischen
véhicule-citerne et les installations fixes - Partie 1 : Tankfahrzeugen und stationären Einrichtungen - Teil 1:
Spécification du protocole - Contrôle, mesurage et données Protokollspezifikation - Steuerungs-, Mess- und
d'évènements Ereignisdaten
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee CEN/TC 296.
If this draft becomes a European Standard, 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.
This draft European Standard was established by CEN 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 Management Centre has the
same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,
Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to
provide supporting documentation.
: This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
Warning
shall not be referred to as a European Standard.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2009 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 15969-1:2009: E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)
Contents
Page
Foreword .3
Introduction .4
1 Scope .5
2 Normative references .5
3 Terms and definitions, abbreviations and conventions .5
3.1 Abbreviations .5
3.2 Terms and definitions .6
3.3 Conventions .7
4 Hardware interface.8
5 Basic protocol layer .8
5.1 FTL-frame (frame) .8
5.2 Frame flow (handshake) .9
5.3 Delay and timeout . 13
5.4 CRC16 Checksum . 13
6 Data protocol layer (FTL-data protocol) . 14
6.1 Client (OBC) and server (TVE) . 14
6.2 Syntax of data in datagrams . 14
6.3 Nodes, subnodes, variables . 14
6.4 Format identifiers. 15
6.5 Types of variable values . 17
6.6 Kinds of nodes . 18
7 FTL-Data . 19
7.1 General . 19
7.2 Record and field types . 20
7.3 Systemwide variables (subnode SYSTEM) . 20
7.4 Variables related to global positioning system (subnode GPS) . 22
7.5 Accessing a printer on TVE-side (subnode PRN) . 23
7.6 Compartment information (subnode COMP) . 26
7.7 Notification about changes (subnode NOTIFY) . 27
7.8 Information about driver (subnode DRIVER) . 28
7.9 Information about the vehicle (variable VEHICLE_ID) . 29
7.10 Access to filesystem on TVE (subnode FS) . 29
7.11 Auxiliary (subnode AUX) . 33
7.12 Order management (subnode ORDER) . 34
7.13 Compatibility matrix (subnode COMPATMAT) . 37
7.14 FTL—logfile (subnodes LOG) . 39
7.15 Required variables . 67
7.16 NAK ID . 67
8 Routing for multiple TVE . 68
8.1 Purpose . 68
8.2 Routing solution . 68
8.3 Routing example . 68
9 Communication with office . 69
9.1 General . 69
9.2 Simple file transfer. 69
9.3 FTL over TCP/IP . 71
10 Communication Examples . 73
10.1 Examples for Basic Protocol Layer level . 73
10.2 Examples for data protocol layer . 74
Annex A (normative) Node tree . 76

2

---------------------- Page: 4 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)
Foreword
This document (prEN 15969-1:2009) has been prepared by Technical Committee CEN/TC 296 “Tanks for
transport of dangerous goods”, the secretariat of which is held by AFNOR.
This document is currently submitted to the CEN Enquiry.
3

---------------------- Page: 5 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)
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
4

---------------------- Page: 6 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)
1 Scope
This standard specifies data protocols and data format for the interfaces between electronic equipment (TVE),
on-board computer (OBC) of the tank vehicle and stationary equipment for all interconnecting communication
paths.
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.
NOTE This data protocol may be used for other application e.g. between stationary tank equipment and offices.
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.
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 the product recognition device
EN 15208:2006, 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
ISO 8859-15, Information technology — 8-bit single-byte coded graphic character sets — Part 15: Latin
alphabet No. 9
DIN 51757, Testing of mineral oils and related materials; determination of density
3 Terms and definitions, abbreviations and conventions
For the purposes of this document, the following terms and definitions, abbreviations and conventions apply.
3.1 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
5

---------------------- Page: 7 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)
LH_FILE log file header
NAK not acknowledge controlframe
OBC on-board-computer
NOTE One party in the FTL-communication (the client).
PID product identification device according to EN 14116
SYN synchronisation controlframe
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 a same structure and 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
3.2.8
MaxFrameSize
maximum number of characters in a frame
3.2.9
node
part of an address of a variable
6

---------------------- Page: 8 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)
3.2.10
graphic character
according to ISO 8859-15
3.2.11
record
ordered set of fields, stored contiguously
3.2.12
server
program which provides service to client programs
3.2.13
subnode
subpart of an address of a variable
3.2.14
datagram
instruction or answer to an instruction, which comprises an OpCode and operand
3.2.14
transaction
complete request-answer-cycle
3.2.15
type identifier
character code for the frame type
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, a comma shall precede.
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.
7

---------------------- Page: 9 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)
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 take place between exactly two parties (point-to-point) the TVE and OBC.
For communication an asynchronous line shall be used. The OBC and TVE start up and default settings shall
apply 9600 baud, 8 data bits, 1 stop bit and no parity. It shall be ensured that the two communication points
are of the same standard.
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. Whenever a Start—Flag is
received a new frame started. All possibly received character before a Start-Flag shall be ignored. Only the
remaining frame shall be the base for a response.
Each device which takes part off the FTL-protocol shall be able to receive at least one complete frame which
may have MaxFrameSize characters. Therefore all kind of low level handshake shall be omitted. 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.
8

---------------------- Page: 10 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)
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—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 following the Start-Flag describes the type of the frame. Depending on this character 2 different
framegroups with different frametypes shall be distinguished according to Table 1.
Table 1 — Frame groups and frame types
Type identifier
client server
Framegroup Frametype AbbreviationAdditional fields
to to
server client
Dataframe end of record frame EOR data R r
additional dataframe

ADF data L l
following frame
end of transmission frame EOT data E e
Controlframe acknowledge frame ACK no A a
synchronisation/wait frame SYN no S s

cancel frame CAN no C c
CRC transmission error
TEF no T t
frame
not acknowledge frame NAK-ID according
NAK N n
to Table 17
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 shall be acknowledged. An EOT—frame can be answered by either a controlframe or
acknowledged by another dataframe. All other dataframes shall be answered by controlframes only.
9

---------------------- Page: 11 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)
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
• Transaction that requires 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 requires more than one frame, because MaxFrameSize is too small to hold a complete
datagram, it shall be split into one or more ADF—frames and an EOT—frame, see Figure 5.

Figure 5
10

---------------------- Page: 12 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)
• The preceding examples may be combined as in Figure 6:


a) b)
NOTE The numbers in the brackets [m/n] have the following meaning:
m datagram sequence within transaction
n indicates the sequence number of the dataframe within the datagram (if splitting is required)
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 acknowledge. It notifies a busy status while preparing the answer to prevent a
timeout.
Multiple SYN—frame are possible but always a final acknowledge shall follow, see Figure 8. t shall be
W
between 30 % and 90 % of the maximum answer time Rt, see 5.3.
11

---------------------- Page: 13 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)

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. Regarding the data it shall act like an ACK—frame but
shall terminate the current datagram, see Figure 9.

a) b)
Figure 9
NAK-frame
In case that any problems (except for CRC error) occur with the frame or with the “execution” of the frame a
NAK-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 has to decide how to continue.

a) b)
Figure 10
If a NAK-frame is sent the last datagram shall be cancelled. All frames which are acknowledged before with
an ACK-frame shall be accepted by this layer. The application layer has to decide whether an incomplete
transaction is accepted or not. For NAK ID see Table 17.
12

---------------------- Page: 14 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)
5.3 Delay and timeout

Figure 11
If the answer time (AT), see Figure 11, 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 1s.
NOTE This value may not be sufficient for long distance (e.g. GSM/GPRS) communication, where additional routing
delays may occur.
The server shall have no timeout.

Figure 12
Within a frame transmitted by the server, the delay (∆T) between two subsequent characters shall not exceed
three character times, see Figure 12. 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 3 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 is uncertain if 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 Annex C of EN 14116:2007+A1:2008.
13

---------------------- Page: 15 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)
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
• 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 starts with 1.
14

---------------------- Page: 16 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)
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 standard.
Table 3 — Format identifiers
Format Description
identifier
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
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
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
Valid examples for latitude GPS values N3.6:
+07.512500 7,512500° N = 7° 30’ 45“ N
15

---------------------- Page: 17 ----------------------
oSIST prEN 15969-1:2009
prEN 15969-1:2009 (E)
Table 3 — Format identifiers continued
Format Description
identifier
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 length x
Only printable ASCII characters of ISO 8859-15 (>= 0x20 to <=0x7E and >=
0xA1 to 0xAC and 0xAE to <=0xFF) except for comma, are allowed.
All other characters are embedded similar to the mechanism of the C
programming language using the “
...