SIST EN 15969-1:2015
(Main)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 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.
NOTE This data protocol may be used for other application e.g. between stationary tank equipment and offices.
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 Europäische 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.
Diese Europäische Norm 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.
Dieses Datenprotokoll darf auch für andere Anwendungen, z. B. zwischen stationären Tank¬ein¬richtungen 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 donées d'évènements
La présente Norme européenne spécifie les protocoles de communication de données et le format de données pour les interfaces entre l'équipement électronique (TVE), l'ordinateur de bord (OBC) du véhicule-citerne et un équipement fixe pour toutes les voies de communication d'interconnexion.
La présente norme européenne spécifie le protocole FTL de base utilisé dans la communication (couche de protocole de base), le format et la structure des données FTL devant être transmises (couche de protocole de données) et décrit le contenu des données FTL.
Ce protocole de données peut être utilisé pour une autre application, par exemple entre un équipement de citerne fixe et des bureaux.
Cisterne za prevoz nevarnega blaga - Digitalni vmesniki za prenos podatkov med vozilom cisterno in stacionarnimi napravami - 1. del: Opredelitev protokola - Upravljanje, merjenje in zajem podatkov
Ta evropski standard določa podatkovne protokole in obliko podatkov za vmesnike za prenos podatkov med elektronsko opremo (TVE), računalnikom (OBC) v cisterni in stacionarnimi napravami za vse medsebojno povezane komunikacijske poti. Ta evropski standard določa osnovni protokol FTL, uporabljen pri komunikaciji (plast osnovnega protokola), in obliko ter strukturo podatkov FTL za prenos (plast podatkovnega protokola) in opisuje vsebino podatkov FTL. OPOMBA: Ta podatkovni protokol se lahko uporablja za druge aplikacije, npr. med opremo stacionarne cisterne in pisarnami.
General Information
Relations
Standards Content (Sample)
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
SIST EN 15969-1:2015
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
EN 15969-1:2015 (E) 2 Contents
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
EN 15969-1:2015 (E) 3 10 Communication Examples. 76 10.1 Examples for Basic Protocol Layer level . 76 10.2 Examples for data protocol layer . 77 Annex A (normative) Node tree . 80 Annex B (normative)
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
SIST EN 15969-1:2015
EN 15969-1:2015 (E) 4 European foreword This document (EN 15969-1:2015) 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 January 2016 and conflicting national standards shall be withdrawn at the latest by January 2016. 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 document supersedes EN 15969-1:2011. In comparison with EN 15969-1:2011, the following fundamental changes have been made: — the following fields in Table 13 added: L0403, L2004, L4106 and L4208; — Table 13 in field L2002 event codes added and in field L4203 access paths added; — figures in 5.2 corrected; — examples in 10.2 and Annex B corrected. EN 15969, Tanks for transport of dangerous goods — Digital interface for the data transfer between tank vehicle and with stationary facilities consists of the following 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, 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:2012+A1:2014, Tanks for transport of dangerous goods — Digital interface for the product recognition device 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, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. SIST EN 15969-1:2015
EN 15969-1:2015 (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 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
EN 15969-1:2015 (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. 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, 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: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: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: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 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 SIST EN 15969-1:2015
EN 15969-1:2015 (E) 7 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 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
EN 15969-1:2015 (E) 8 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:2014 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. 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. SIST EN 15969-1:2015
EN 15969-1:2015 (E) 9 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 — 4 character Checksum (valid or invalid) SIST EN 15969-1:2015
EN 15969-1:2015 (E) 10 — 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:2015
EN 15969-1:2015 (E) 11 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 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
EN 15969-1:2015 (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.
a) b) Figure 5 SIST EN 15969-1:2015
EN 15969-1:2015 (E) 13 — 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. tW shall be between 30 % and 90 % of the maximum answer time Rt, see 5.3. SIST EN 15969-1:2015
EN 15969-1:2015 (E) 14
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
EN 15969-1:2015 (E) 15
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 15969-1:2015 (E) 16 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 acc
...
SLOVENSKI STANDARD
oSIST prEN 15969-1:2014
01-marec-2014
Cisterne za prevoz nevarnega blaga - Digitalni vmesniki za prenos podatkov med
vozilom s posodo 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 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è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:2014 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
oSIST prEN 15969-1:2014
---------------------- Page: 2 ----------------------
oSIST prEN 15969-1:2014
EUROPEAN STANDARD
DRAFT
prEN 15969-1
NORME EUROPÉENNE
EUROPÄISCHE NORM
January 2014
ICS 35.240.60 Will supersede EN 15969-1:2011
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 doné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-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.
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.
Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
shall not be referred to as a European Standard.
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
© 2014 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 15969-1:2014 E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (E)
Contents Page
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 . 16
5.4 CRC16 Checksum . 16
6 Data protocol layer (FTL-data protocol) . 17
6.1 Client (OBC) and server (TVE) . 17
6.2 Syntax of data in datagrams . 17
6.3 Nodes, subnodes, variables . 17
6.4 Format identifiers. 18
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) . 26
7.5 Accessing a printer on TVE-side (subnode PRN) . 26
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 Access to filesystem on TVE (subnode FS) . 33
7.11 Auxiliary (subnode AUX) . 39
7.12 Order management (subnode ORDER) . 39
7.13 Goods and service database . 43
7.14 FTL—logfile (subnodes LOG) . 45
7.15 Required variables . 73
7.16 NAK ID . 73
8 Routing for multiple TVE . 74
8.1 Purpose . 74
8.2 Routing solution . 74
8.3 Routing example . 74
9 Communication with office . 75
9.1 General . 75
9.2 Simple file transfer. 76
9.3 FTL over TCP/IP . 77
10 Communication Examples . 79
10.1 Examples for Basic Protocol Layer level . 79
2
---------------------- Page: 4 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (E)
10.2 Examples for data protocol layer . 81
Annex A (normative) Node tree . 83
Annex B (normative) Test FTL . 84
B.1 Overview . 84
B.2 Basic Protocol Layer . 84
B.2.1 Frame Tests . 84
B.2.2 CRC-error . 85
B.2.3 Delay and Timeout . 85
B.3 Data Protocol Layer . 86
B.3.1 Test of Toggling . 86
B.3.2 Test of the FTL data layer . 87
B.3.3 Test of the required FTL nodes . 87
B.3.4 Optional System Subnodes . 91
B.3.5 Optional Node Prn . 92
B.3.6 Node Comp . 94
B.4 Application Layer . 100
B.4.1 Test of the L-File . 100
B.4.2 Test of the LH-File . 100
B.4.3 Test for the Filling of the NodeList . 101
B.4.4 Sequence Test . 101
3
---------------------- Page: 5 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (E)
Foreword
This document (prEN 15969-1:2014) 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.
This document will supersede EN 15969-1:2011.
According to edition EN 15969-1:2011 the following fundamental changes are given:
• The following fields in Table 13 added: L0403, L2004, L4106 and L4208;
• Table 13 in field L2002 event codes added and in field L4203 access paths added;
• Figures in 5.2 corrected;
• Examples in 10.2 and Annex B corrected.
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 European Standard "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, 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, Tanks for transport of dangerous goods — Digital interface for the product recognition device 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
4
---------------------- Page: 6 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (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
5
---------------------- Page: 7 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (E)
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 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, 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
6
---------------------- Page: 8 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (E)
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
7
---------------------- Page: 9 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (E)
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.
8
---------------------- Page: 10 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (E)
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
9
---------------------- Page: 11 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (E)
• 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.
10
---------------------- Page: 12 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (E)
Table 1 — Frame groups and frame types
Type identifier
client server
Frame group Frame type Abbreviation Additional fields
to to
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 frame EOT data E, I e, i
Controlframe acknowledge frame ACK no A a
1)
synchronisation/wait frame SYN no - s
cancel frame CAN no C c
CRC transmission error
TEF no T t
frame
not acknowledge frame NAK-ID according
1)
NAK - n
to Table 17
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.
11
---------------------- Page: 13 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (E)
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.
12
---------------------- Page: 14 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (E)
a) b)
Figure 5
• The preceding examples may be combined as in Figure 6:
a) b)
Figure 6
13
---------------------- Page: 15 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (E)
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. t 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.
14
---------------------- Page: 16 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (E)
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.
15
---------------------- Page: 17 ----------------------
oSIST prEN 15969-1:2014
prEN 15969-1:2014 (E)
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, s
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.