SIST EN 15969-1:2018

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Cisterne za prevoz nevarnega blaga - Digitalni vmesnik za prenos podatkov med 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 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é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 prometuIT applications in transport23.020.10UH]HUYRDUMLStationary containers and tanks13.300Varstvo pred nevarnimi izdelkiProtection against dangerous goodsICS:Ta slovenski standard je istoveten z:EN 15969-1:2017SIST EN 15969-1:2018en,fr,de01-maj-2018SIST EN 15969-1:2018SLOVENSKI
STANDARDSIST EN 15969-1:20151DGRPHãþD



SIST EN 15969-1:2018



EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 15969-1
December
t r s y ICS
u wä t v rä x r Supersedes EN
s w { x {æ sã t r s wEnglish Version
Tanks for transport of dangerous goods æ Digital interface for the data transfer between tank vehicle and with stationary facilities æ Part
sã 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
sã Spécifications du protocole æ Contrôleá données de mesure et d 5é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
sã Protokollspezifikation æ Steuerungsæá Messæ und Ereignisdaten This European Standard was approved by CEN on
s w October
t r s yä
egulations 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ä
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á Serbiaá 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
9
t r s y CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Membersä Refä Noä EN
s w { x {æ sã t r s y ESIST EN 15969-1:2018



EN 15969-1:2017 (E) 2 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 . 18 6.4 Format identifiers . 18 6.5 Types of variable values . 21 6.6 Kinds of nodes . 21 7 FTL-Data . 23 7.1 General . 23 7.2 Record and field types . 23 7.3 Systemwide variables (subnode SYSTEM) . 23 7.4 Variables related to global positioning system (subnode GPS) . 26 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) . 31 7.8 Information about driver (subnode DRIVER) . 32 7.9 Information about the vehicle (variable VEHICLE_ID) . 33 7.10 Information about current operation (subnode OPERATION) . 33 7.11 Access to filesystem on TVE (subnode FS) . 35 7.12 Auxiliary (subnode AUX) . 39 7.13 Order management (subnode ORDER) . 40 7.14 Goods and service database (subnode PRODUCT) . 44 7.15 FTL—logfile (subnodes LOG) . 47 7.16 Required variables . 78 7.17 NAK ID . 78 8 Routing for multiple TVE . 79 8.1 Purpose . 79 8.2 Routing solution . 79 8.3 Routing example . 80 SIST EN 15969-1:2018



EN 15969-1:2017 (E) 3 9 Communication with office . 81 9.1 General . 81 9.2 Simple file transfer . 81 9.3 FTL over TCP/IP . 83 10 Communication Examples . 85 10.1 Examples for Basic Protocol Layer level . 85 10.2 Examples for data protocol layer . 87 Annex A (normative)
Node tree . 90 Annex B (normative)
Test FTL . 91 B.1 Overview . 91 B.2 Basic Protocol Layer . 91 B.2.1 Frame Tests. 91 B.2.2 CRC-error . 92 B.2.3 Delay and Timeout . 92 B.3 Data Protocol Layer . 92 B.3.1 Test of Toggling . 92 B.3.2 Test of the FTL data layer . 93 B.3.3 Test of the required FTL nodes . 94 B.3.4 Optional System Subnodes . 97 B.3.5 Optional Node Prn . 99 B.3.6 Node Comp . 101 B.4 Application Layer. 107 B.4.1 Test of the L-File . 107 B.4.2 Test of the LH-File . 107 B.4.3 Test for the Filling of the NodeList . 107 B.4.4 Sequence Test . 108 Bibliography . 110
SIST EN 15969-1:2018



EN 15969-1:2017 (E) 4 European foreword This document (EN 15969-1:2017) 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 June 2018, and conflicting national standards shall be withdrawn at the latest by June 2018. 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:2015. With regard to EN 15969-1:2015, the following fundamental changes are given: — fields for air craft refilling added. 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 European Standard 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. 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, Former Yugoslav Republic of Macedonia, SIST EN 15969-1:2018



EN 15969-1:2017 (E) 5 France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. SIST EN 15969-1:2018



EN 15969-1:2017 (E) 6 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 B\
a may be either two independent units or one single unit which incorporates both functions OBC and TVE Figure 1 SIST EN 15969-1:2018



EN 15969-1:2017 (E) 7 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. This data protocol may be used for other application e.g. between stationary tank equipment and offices. 2 Normative references The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. 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+A1:2014, 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 EN 15969-2:2017, 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:2014, 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 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) SIST EN 15969-1:2018



EN 15969-1:2017 (E) 8 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 defined 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:2014, 4;29] 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 SIST EN 15969-1:2018



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



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



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



EN 15969-1:2017 (E) 12 Table 1 — Frame groups and frame types Frame group Frame type Abbreviation Additional 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 synchronization/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 19 —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 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:2018



EN 15969-1:2017 (E) 13
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:2018



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



EN 15969-1:2017 (E) 15
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
a) b) Figure 11 SIST EN 15969-1:2018



EN 15969-1:2017 (E) 16 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 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).
...