EN 15969-1:2017
(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.
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¬einrichtungen und Büros, verwendet werden.
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
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 vmesnik za prenos podatkov med cisterno in stacionarnimi napravami - 1. del: Opredelitev protokola - Upravljanje, merjenje in zajem podatkov
Ta evropski standard določa podatkovne protokole in obliko zapisa podatkov za vmesnike za prenos podatkov med elektronsko opremo (TVE), računalnikom (OBC) v cisterni in stacionarno opremo 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.
Ta podatkovni protokol se lahko uporablja za druge aplikacije, npr. med opremo stacionarne cisterne in pisarnami.
General Information
Relations
Frequently Asked Questions
EN 15969-1:2017 is a standard published by the European Committee for Standardization (CEN). Its full title is "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 standard covers: 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.
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.
EN 15969-1:2017 is classified under the following ICS (International Classification for Standards) categories: 35.240.60 - IT applications in transport. The ICS classification helps identify the subject area and facilitates finding related standards.
EN 15969-1:2017 has the following relationships with other standards: It is inter standard links to EN 15969-1:2015, EN 15969-1:2022. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase EN 15969-1:2017 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of CEN standards.
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 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
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
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
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
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
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
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
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
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
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
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
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). The application layer shall decide what action shall be taken. As the client does not know whether the server has received the last ACK-frame before the timeout the last record may be repeated upon the next request to this node. 5.4 CRC16 Checksum Since a frame might have been corrupted during transmission, a checksum shall be included in each frame. It shall cover all characters from Start—Flag to End—Flag including these flags. The calculation algorithm for CRC16 shall be according to EN 14116:2012+A1:2014, Annex B. 6 Data protocol layer (FTL-data protocol) 6.1 Client (OBC) and server (TVE) The TVE shall act as server, providing data to the client, usually the OBC. Only the client shall initiate data exchange. Each frame from the client shall be followed by one frame from the server. SIST EN 15969-1:2018
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
« s t Value:
« s t
Examples for invalid coding (for N3):
1234 more than three characters
+123 more than three characters
0.1
separator not allowed
1E2
invalid character 'E' Nx.y
Floating point value max. x digits in front of the period (including ±) max. y digits behind the period Only characters 0 to 9 and period are allowed. At least one digit in front and behind the period shall be used. No exponential expressions. Examples for valid coding (for N3.2):
1.0 Value:
+1,0
001.2 Value:
+1,2
001.23 Value:
+1,23
000.12 Value:
+0,12
0.1 Value:
+0,1
+01.23 Value:
+1,23
« r sä t u Value:
« sá t u Valid examples for longitude GPS values N4.6 in degrees:
+007.512500 7,512500° E =
y ¹
u rB"
v wò E
±
y ¹
u rá y w rï E
7. 5125
yá w s t w r r ¹ E
±
y ¹
u rB"
v wò E
« r r yä
w s t w r r 7,512500° W =
y ¹
u rB"
v wò W Valid examples for latitude GPS values N3.6:
+07.512500
yá w s t w r r ¹ N
±
y ¹
u rB"
v wó N
Examples for invalid coding (for N3.2):
1234.5
more than 3 digits in front of period
+123.4
more than 3 digits in front of period
« s t uä v
more than 3 digits in front of period SIST EN 15969-1:2018
123.456
more than 2 digits behind period
0,1
separating character not allowed (use period)
separating character missing
.12
minimum number of digits missing in front of period
123.
minimum number of digits missing behind period
1.E5
invalid character Cx
Text with maximum number of x bytes. UTF-8 according to ISO/IEC 10646:2014 except for codes less than 0x20 and except for comma 0x2C; All other characters are embedded similar to the mechanism of the C programming language using the “\” character followed by a two nibble hex value (examples \n for LF, \x1B for ESC, \, for comma). Following codes shall be implemented: \\ (“\”)
\n
\r
\f
\t
\, and \xNN (0xNN) Examples for valid coding (for C12):
abcdoCD=12 < abcdoCD = 12 <
a\n\x0A
a < 0x0A >
< 0x0A > “
(<.> . hex value for control character)
a\n\x0A\x1B
12345\,67890 12345,67890
1\,2 Ab\\yz
1,2 Ab\yz Examples for invalid coding (for C12):
abcdCD12.3456
more than 12 characters
abCD12,345
comma not allowed S Time stamp – CCYYMMDDhhmmss Shortened forms of the time stamp string such as (CCYYMMDD) are not allowed. In this case unused fields shall be filled with 00. However a single digit 0 shall be used to represent no time stamp. Is a higher resolution than seconds needed fractions of seconds may be appended at the end of the time stamp string. Examples for valid coding:
09. January 1999 23:02:01
20001224013159.75
24. December 2000 1:31:59,75 Examples for invalid coding:
shortened time stamp string
seconds are missing
20001224013159,75
comma not allowed – use period
D Date – CCYYMMDD
see description for format identifier S above
Examples for valid coding:
19990109 09. January 1999
20001224 24. December 2000
Examples for invalid coding:
shortened date string
see description for format identifier S above
Examples for valid coding:
23:02:59
013159.75
1:31:59,75 Hx Unsigned hexadecimal value with max x characters, representing a bit pattern with x · 4 bits Bit 0 is encoded as value 1 Bit 1 is encoded as value 2 Bit 2 is encoded as value 4 and so on Examples for valid coding:
10A8
represents a field of 16 bits where bits 12, 7, 5 and 3 are
set. All other Bits are zero. Examples for invalid coding:
10a8
lower case character “a” used
0x10A8
invalid character “x” used
$10A8
invalid character “$” used
6.5 Types of variable values 6.5.1 Single-Field-Type represents exactly one field with any one of the variable types given in Table 3. No separators or special codes for quoting are needed. 6.5.2 CSV Records and quoting ,,,… In this case, consists of a list of fields separated by the character comma “,”. Each field is of one-field-type. The formatting of a CSV record shall follow the guidelines below: 1) concatenation is done with the separator character comma (“,”); 2) numeric field of zero-length (empty field) shall be interpreted as not available; 3) trailing commas can optionally be omitted. 6.6 Kinds of nodes 6.6.1 General When accessing or the behaviour of the server depends on the kind of or . The three kinds in 6.6.2 to 6.6.4 shall be supported. 6.6.2 Values The simplest kind is a value, which consists of exactly one line, which can either be of type CSV or of any other single-field type, see Table 4. SIST EN 15969-1:2018
ENQ,FTL,SYSTEM,NodeList
REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,NODELIST
REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,FTL_VERS
REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,FTL_FORMAT
REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,DATETIME 6.6.4 Arrays Arrays may be accessed according to Table 6 either: — as value, as described in 6.6.2, when an index is specified in the enquiry or set command (see 6.3); EXAMPLE 1
ENQ,FTL,AUX,In(1)
REP,FTL,AUX,In(1)=2 — or without index, in which case every answer shall contain the requested variable or subnode and the appropriate index. EXAMPLE 2
ENQ,FTL, AUX,In
REP,FTL, AUX,In(1)=2
REP,FTL, AUX,In(2)=2 SIST EN 15969-1:2018
REP,FTL, AUX,In(3)=2 Table 6 — Operation applicable to arrays Operation Effect (if operation allowed in this context) Enquiry with index: shall return the addressed array element without index: return entire array, starting with the lowest, and ending with the highest index Set with index: replace the contents of the given array element without index: append the new elements after the last used element Clear with index: not allowed without index: clears the contents of all array elements Examples can be found in Clause 10. 7 FTL-Data 7.1 General The root node shall be called FTL. (see 8.2 for exceptions). The structure of this node shall be fixed. Thus, subnodes and variables not described in this European Standard shall not be implemented. However, it is allowed to only implement a subset of the structures mentioned in this specification. Please refer to 7.16 for list of variables, which shall be present in every system. All mentioned subnodes belong to node FTL, see Annex A. Unless otherwise noted, when the description of TVE-variable refers to a L—FILE-record type, the first two fields (record type and timestamp) shall be omitted (see example in 7.3.1). 7.2 Record and field types In this document record types are referred to by #L_. Thus, #L01_DEVICE_ID refers to record type 01, called DEVICE_ID, which can be found in the L_FILE specification in Table 15. Meaning and formats of fields are referred to by #L[_]. Thus, #L0202_veh_type refers to field 2 (called veh_type) in record type 2 (VEHICLE_ID). 7.3 Systemwide variables (subnode SYSTEM) 7.3.1 FTL version (variable FTL_VERS) Variable FTL,SYSTEM,FTL_Vers=V Kind Value, Read Only, required Enquiry (item) Returns the version of FTL implemented on the TVE. Value V #L00_FTL_VERS
EXAMPLE
ENQ,FTL,SYSTEM,FTL_Vers
REP,FTL,SYSTEM,FTL_Vers=1.00 SIST EN 15969-1:2018
EXAMPLE
ENQ,FTL,SYSTEM,DateTime
REP,FTL,SYSTEM,DateTime=20070820104933 7.3.4 Timeout for OBC alive-test (variable TIMEOUT) Variable FTL,SYSTEM,TIMEOUT=V Kind Value, optional Enquiry Returns current timeout setting for alive-test. Set Sets a new timeout for alive-test Value V Timeout in seconds or 0 to deactivate alive-test. Default value 60 s, maximum time for absence 99999 s (N5) After each transaction the internal timer shall be reset. When this internal timer exceeds the current timeout setting: — the connection shall be regarded as timed out; — the TVE is allowed to initiate processes to be able to work without OBC. It is recommended to protect the value against power outages to prevent tampering. 7.3.5 Status of OBC alive-test (variable TIMEDOUT) Variable FTL,SYSTEM,Timedout=V Kind Value, optional Enquiry Returns the timestamp when connection to OBC was lost. Set Reset Timedout condition (V = 0 only) Value V Timestamp, when connection was lost. 0 stands for “no timeout since SIST EN 15969-1:2018
REP,FTL,SYSTEM,BAUD=9600
SET,FTL,SYSTEM,BAUD=115200 Verify new baudrate after 5 s:
ENQ,FTL,SYSTEM,BAUD
REP,FTL,SYSTEM,BAUD=115200 7.3.7 Last system error (variable SYS_ERR) Variable FTL,SYSTEM,SYS_ERR=V Kind Value, read only, cleared on read, optional Enquiry Returns the last system error on TVE. Value V #L09_SYS_ERR
EXAMPLE
(problem with sensor for product code occurred):
ENQ,FTL,SYSTEM,SYS_ERR
REP,FTL,SYSTEM,SYS_ERR=90,10301,44326 SIST EN 15969-1:2018
EXAMPLE
ENQ,FTL,SYSTEM,NodeList
REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,NODELIST
REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,FTL_VERS
REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,FTL_FORMAT
...
EN 15969-1:2017 표준은 위험물 운송을 위한 탱크의 디지털 인터페이스에 관한 중요한 지침을 제공합니다. 이 문서는 탱크 차량과 정적인 시설 간의 데이터 전송을 위한 프로토콜 사양 및 데이터 포맷을 명확히 규정하고 있으며, 전자 장비(TVE), 탱크 차량의 온보드 컴퓨터(OBC), 그리고 정적 장비 간의 모든 연결 통신 경로를 포함한 범위를 다룹니다. 이 표준의 강점 중 하나는 기본 프로토콜 FTL에 대한 명확한 정의입니다. 기본 프로토콜 레이어, 데이터 전송에 필요한 FTL 데이터의 형식 및 구조, 그리고 FTL 데이터의 내용 설명 등으로 구성되어 있어 통신의 일관성을 보장합니다. 이러한 구조적 접근은 데이터 전송의 신뢰성과 정확성을 높이는 데 큰 기여를 합니다. 또한, EN 15969-1:2017 표준은 탱크 장비와 사무실 간의 통신 등 다른 응용 프로그램에도 활용될 수 있는 가능성을 제시합니다. 이는 표준의 유연성 및 확장성을 강조하며 다양한 산업에서의 적용을 더욱 용이하게 만듭니다. 결론적으로, EN 15969-1:2017은 위험물 운송 분야에서 안전하고 효율적인 데이터 전송을 위한 필수 표준으로, 해당 산업의 과정 전반에 걸쳐 주목할 만한 중요성을 지니고 있습니다.
The EN 15969-1:2017 standard provides essential guidelines for the digital interface necessary for data transfer between tank vehicles and stationary facilities, specifically targeting the management of dangerous goods transportation. Its scope is comprehensive, addressing the technical requirements for communication between electronic equipment (TVE), on-board computers (OBC), and stationary equipment. One of the notable strengths of this standard is its detailed specification of the basic protocol FTL, which is foundational for effective communication. By establishing a standard protocol layer, it ensures that various systems can operate cohesively, thus enhancing interoperability-a critical factor in the safe transport of dangerous goods. Additionally, the standard meticulously outlines the FTL-data format and structure, facilitating the accurate transmission of vital control, measurement, and event data. This clarity is crucial for organizations involved in the logistics of hazardous materials, as it minimizes the risk of miscommunication and errors during data exchange. Furthermore, the adaptability of the FTL-data protocol for other applications, such as interaction between stationary tank equipment and office systems, underscores its relevance across broader industrial contexts. This versatility enhances the standard's applicability and ensures that it remains an essential resource in the evolving landscape of dangerous goods transportation. Overall, the EN 15969-1:2017 standard highlights a significant advancement in the protocols governing the transportation of hazardous materials, offering robust frameworks that are crucial for safety, efficiency, and regulatory compliance within the industry. The document "SIST EN 15969-1:2018" serves as a reliable reference for organizations aiming to align their technological processes with established communication standards.
標準EN 15969-1:2017は、危険物輸送用タンクにおけるデジタルインターフェースのデータ転送に関するものであり、その範囲は非常に広範です。この欧州標準は、タンク車両の電子機器（TVE）と車両搭載コンピュータ（OBC）、および各種固定設備との間の通信パスにおけるデータプロトコルとデータフォーマットを規定しています。 この標準の強みは、基本プロトコルFTLを使用した通信の仕様が明確に定義されている点です。基本プロトコル層、FTLデータを伝送するためのフォーマットおよび構造を含むデータプロトコル層、およびFTLデータの内容について詳述されています。このように、標準はプロトコルの構造を体系的に示すことで、異なる機器間の相互運用性を高める役割を果たしています。 さらに、EN 15969-1は、静的タンク設備とオフィス間のデータ通信といった他のアプリケーションにおいても使用できる可能性があるため、標準の適用範囲は広がります。この点は、業界におけるデジタル化を推進する上で重要です。 総じて、EN 15969-1:2017は、危険物輸送に関する安全性と効率性を確保するための基盤を提供する非常に重要な標準です。その明確なプロトコル仕様と柔軟な適用性は、デジタルインターフェースの発展に寄与するものといえるでしょう。
Le document SIST EN 15969-1:2018 établit des standards essentiels pour le transport de marchandises dangereuses, en se concentrant sur l’interface numérique pour le transfert de données entre les véhicules-citernes et les installations stationnaires. Ce standard européen précise les protocoles de données et les formats nécessaires pour les interfaces entre l'équipement électronique (TVE) du véhicule-citerne et l'ordinateur de bord (OBC), garantissant une communication fluide sur tous les chemins de communication interconnectés. Parmi les points forts de cette norme, on retrouve la spécification du protocole de base FTL, qui constitue la fondation de la couche de communication. Ce protocole assure une transmission efficace et fiable des données, renforçant ainsi la sécurité et l'efficacité des opérations de transport de produits dangereux. De plus, le document décrit en détail le format et la structure des données FTL à transmettre, ce qui facilite la compréhension et l'implémentation par les différents acteurs du secteur. La portée de cette norme dépasse la seule communication entre véhicules-citernes et installations stationnaires ; elle peut également être appliquée à d'autres interactions, comme celles entre l'équipement de tank stationnaire et les bureaux. Cela démontre la flexibilité et la pertinence du standard EN 15969-1:2017 dans divers contextes opérationnels. En conclusion, la norme SIST EN 15969-1:2018 est un document clé qui assure une harmonisation nécessaire dans le secteur du transport de marchandises dangereuses, en garantissant que les communications numériques soient précises, standardisées et sécurisées. Son application est non seulement pertinente mais essentielle pour l'amélioration des pratiques actuelles dans le domaine.
Die Norm EN 15969-1:2017 bietet eine umfassende Grundlage für die Standardisierung von Datenprotokollen und Datenformaten, die für die Schnittstellen zwischen elektronischen Geräten (TVE), On-Board-Computern (OBC) von Tankfahrzeugen und stationären Einrichtungen erforderlich sind. Der Geltungsbereich dieser Norm ist sowohl auf die Kommunikationswege zwischen Tankfahrzeugen als auch auf stationäre Geräte ausgelegt, wodurch sie eine zentrale Rolle bei der sicheren und effizienten Übertragung von Kontroll-, Mess- und Ereignisdaten spielt. Ein wesentlicher Stärke der Norm ist die klare Definition des Basisprotokolls FTL, welches die Grundlage für die Kommunikation darstellt. Durch die spezifische Beschreibung der Struktur und des Formats der FTL-Daten wird sichergestellt, dass verschiedene Systeme effizient miteinander kommunizieren können. Dies ermöglicht nicht nur eine standardisierte Datenübertragung, sondern auch die Integration in bestehende Systeme, was die Flexibilität und Benutzerfreundlichkeit verschiedener Anwendungen erhöht. Darüber hinaus ist die Norm von hoher Relevanz für Unternehmen und Institutionen, die im Bereich des Transports gefährlicher Güter tätig sind. Die klare Spezifikation der Kommunikationsprotokolle und der Dateninhalte fördert die Sicherheit und Nachvollziehbarkeit der Datenübertragung, was entscheidend ist, um gesetzliche Anforderungen zu erfüllen und das Risiko von Zwischenfällen zu minimieren. Ein weiterer positiver Aspekt ist die Möglichkeit, das FTL-Datenprotokoll auch für andere Anwendungen zu nutzen, beispielsweise zwischen stationären Tankanlagen und Büros. Dies zeigt die Vielseitigkeit der Norm und ihre Anwendungsmöglichkeiten über den ursprünglichen Geltungsbereich hinaus. Insgesamt stellt die EN 15969-1:2017 eine bedeutende Ressourcen dar, die nicht nur die technischen Anforderungen an eine sichere und effiziente Datenübertragung definiert, sondern auch eine Grundlage für die zukünftige Entwicklung innovativer Anwendungen im Bereich des Gefahrguttransports bietet.
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...