EN 15969-1:2011

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Posode za prevoz nevarnih snovi - Digitalni vmesniki za prenos podatkov med vozilom s posodo in stacionarnimi napravami - 1. del: Opredelitev protokola - Upravljanje, meritev in zajem podatkovTanks für die Beförderung gefährlicher Güter - Digitale Schnittstelle für den Datenaustausch zwischen Tankfahrzeugen und stationären Einrichtungen - Teil 1: Protokollspezifikation - Steuerungs-, Mess- und EreignisdatenCiternes pour le transport de matières dangereuses
- Interface numérique pour le transfert de données entre le véhicule-citerne et les installations fixes - Partie 1 : Spécification du protocole - Contrôle, mesurage et données d'évènementsTanks for transport of dangerous goods - Digital interface for the data transfer between tank vehicle and with stationary facilities - Part 1: Protocol specification - Control, measurement and event data35.240.60Uporabniške rešitve IT v transportu in trgoviniIT applications in transport and trade23.020.10UH]HUYRDUMLStationary containers and tanksICS:Ta slovenski standard je istoveten z:EN 15969-1:2011SIST EN 15969-1:2011en,fr,de01-november-2011SIST EN 15969-1:2011SLOVENSKI
STANDARD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 15969-1
September 2011 ICS 35.240.60 English Version
Tanks for transport of dangerous goods -Digital interface for the data transfer between tank vehicle and with stationary facilities -Part 1: Protocol specification -Control, measurement and event data
Citernes pour le transport de matières dangereuses - Interface numérique pour le transfert de données entre le véhicule-citerne et les installations fixes - Partie 1 : Spécification du protocole - Contrôle, mesurage et données d'évènements
Tanks für die Beförderung gefährlicher Güter - Digitale Schnittstelle für den Datenaustausch zwischen Tankfahrzeugen und stationären Einrichtungen - Teil 1: Protokollspezifikation - Steuerungs-, Mess- und Ereignisdaten This European Standard was approved by CEN on 18 June 2011.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre:
Avenue Marnix 17,
B-1000 Brussels © 2011 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 15969-1:2011: ESIST EN 15969-1:2011

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

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

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
DIN 51757:2011, Testing of mineral oils and related materials  Determination of density 3 Terms and definitions, abbreviations and conventions For the purposes of this document, the following terms and definitions, abbreviations and conventions apply. 3.1 Abbreviations ACK acknowledge controlframe ADF additional dataframe ASCII American Standard Code for Information Interchange CAN cancel controlframe CRC cyclic redundancy checksum CSV comma separated variable record SIST EN 15969-1:2011

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

3.2.9 node part of an address of a variable 3.2.10 graphic character according to Annex D of ISO/IEC 10646-1:2011 3.2.11 record ordered set of fields, stored contiguously 3.2.12 server program which provides service to client programs 3.2.13 subnode subpart of an address of a variable 3.2.14 datagram instruction or answer to an instruction, which comprises an OpCode and operand 3.2.15 transaction
complete request-answer-cycle 3.2.16 type identifier character code for the frame type 3.3 Conventions 3.3.1 Syntax conventions When describing the syntax of e.g. a datagram, some parts are required. Every abstract part shall get a name, which is encapsulated by “<” and “>”. Optional arguments are additionally encapsulated in square brackets. EXAMPLE [,] has always to be given (required). is optional, but when given, it shall be preceded by a comma. SIST EN 15969-1:2011

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
The ASCII code 02h (start of text ) shall be used as the Start-Flag. Type identifier The type identifier shall be according to Table 1. Content The content may be empty or shall contain up to MaxFrameSize minus 7 characters. All characters in the content shall be printable characters. End-Flag The ASCII code 03h (End of Text ) shall be used as the End—Flag. Checksum The Checksum verifies the integrity of a frame. It covers all characters from Start—Flag to End—Flag including these flags. A CRC16 (16 bit) value in hexadecimal format (always 4 characters long) is used and shall consist of the printable ASCII character “0”.”9” or “A”.”F” (example: the value 1AC9h shall be sent with 4 ASCII character “1AC9”). The algorithm for the calculation is described in 5.4. 5.2 Frame flow (handshake) The character immediately following the Start-Flag defines the frame type. The different frame groups and their frame types are described in Table 1. SIST EN 15969-1:2011

end of record frame EOR data R, V r, v additional dataframe following frame ADF data L, P l, p end of transmission frame EOT data E, I e, i Controlframe
acknowledge frame ACK no A a synchronisation/wait frameSYN no -1)
s cancel frame CAN no C c CRC transmission error frame TEF no T t not acknowledge frame NAK NAK-ID according to Table 17 -1) n 1) Not applicable. To distinguish the direction of data (client to server or server to client) upper and lower case type character shall be used. Every communication shall start with a dataframe. Every dataframe from the server shall be answered by a controlframe from the client. Every frame from the client shall be answered by a frame from the server. If a dataframe is received by the server when an acknowledge is expected it shall be treated as a cancel frame (CAN) regarding the preceding transaction. Every data frame on each side, independently, shall be flagged alternatively (toggled) with the secondary (V,P,I) and primary (R,L,E) type identifier. If subsequent dataframes with identical type identifier are received, these shall be treated as a repetition with identical data but shall be answered as the original, see Figure 11. This prevents redundant entries in lists resulting from communication faults. After the startup of the system the first dataframe on each side shall start with the primary type identifier (R,L,E). The first request after startup shall not be a SET-request to a list. EXAMPLES Examples of frame flows: • Transaction that requires only one datagram in either direction, each fitting into a single frame, see Figure 3. SIST EN 15969-1:2011

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 • The preceding examples may be combined as in Figure 6:
a) b) Figure 6 SIST EN 15969-1:2011

a) b) Key 1 controlframe is repeated
2 dataframe is repeated Figure 7 SYN-frame A SYN—frame is not a final acknowledgement. It notifies a busy status of the server while preparing the answer to prevent a timeout. Multiple SYN—frame are possible but always a final acknowledge shall follow, see Figure 8. tW shall be between 30 % and 90 % of the maximum answer time Rt, see 5.3.
Figure 8 CAN—frame Transactions can be cancelled if procedures with higher priorities have to be serviced from the higher application layer. Then a CAN—frame shall be sent. It terminates the transaction but does not act as an ACK-frame, see Figure 9. SIST EN 15969-1:2011

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.
Figure 12 If the answer time (AT), see Figure 12, exceeds Rt, a timeout shall be detected by the client. For short distance (e.g. RS 232, RS485, Low Power Radio) communication “Rt” value shall be 1 s. NOTE This value may not be sufficient for long distance (e.g. GSM/GPRS) communication, where additional routing delays may occur.
Figure 13 Within a frame transmitted by the server, the delay (ûT) between two subsequent characters shall not exceed three character times, see Figure 13. For frames transmitted by the client there is no limitation. If a timeout occurs after a transmission of a dataframe, the previous dataframe shall be repeated by the client. If a timeout occurs after a transmission of a controlframe, a repetition shall be requested by transmission of a TEF-frame. After three consecutive timeouts (1 initial + 2 retries), the transaction shall be cancelled without a CAN-frame (see 5.2). The application layer shall decide what action shall be taken.
As the client does not know whether the server has received the last ACK-frame before the timeout the last record may be repeated upon the next request to this node.
5.4 CRC16 Checksum Since a frame might have been corrupted during transmission, a checksum shall be included in each frame. It shall cover all characters from Start—Flag to End—Flag including these flags. The calculation algorithm for CRC16 shall be according to Annex C of EN 14116:2007+A2:2010. NOTE
The CRC 16 of EN 14116:2007+A2:2010 was corrected by a later amendment. SIST EN 15969-1:2011

6.3 Nodes, subnodes, variables All data provided by server shall be stored in variables which may be accessed by the client (see Clause 7). Each name identifying , and shall: • be limited to 10 characters; • only consist of the characters “A” to “Z”, “0” to “9” and “_”; • never start with numerical characters “0” to “9”. Some variables are arrays. By specifying a numerical index enclosed by brackets ( ), one particular array element shall be accessible. Indexing shall always start with 1. SIST EN 15969-1:2011

Examples for valid coding:
0 False
1 True Examples for invalid coding:
2 invalid value
A invalid value
0.1 separator not allowed/more than one character not allowed Nx Integer decimal value with max x characters (including sign character) Examples for valid coding (for N3):
1 Value:
+1
001 Value:
+1
123 Value:
+123
+12 Value:
+12
-12 Value:
-12 Examples for invalid coding (for N3):
1234 more than three characters
+123 more than three characters
0.1 separator not allowed
1E2 invalid character 'E' Nx.y Floating point value max. x digits in front of the period (including +/-) max. y digits behind the period Only characters 0 to 9 and period are allowed. At least one digit in front and behind the period has to be used. No exponential expressions. Examples for valid coding (for N3.2):
1.0 Value:
+1,0
001.2 Value:
+1,2
001.23 Value:
+1,23
000.12 Value:
+0,12
0.1 Value:
+0,1
+01.23 Value:
+1,23
-01.23 Value:
-1,23 Valid examples for longitude GPS values N4.6 in degrees:
+007.512500 7,512500° E = 7° 30’ 45“ E = 7° 30,750’ E
7. 5125 7,512500° E = 7° 30’ 45“ E
-007. 512500 7,512500° W = 7° 30’ 45“ W Valid examples for latitude GPS values N3.6:
+07.512500 7,512500° N = 7° 30’ 45“ N
Examples for invalid coding (for N3.2):
1234.5 more than 3 digits in front of period
+123.4 more than 3 digits in front of period
-123.4 more than 3 digits in front of period
123.456 more than 2 digits behind period
0,1 separating character not allowed (use period)
123 separating character missing
.12 minimum number of digits missing in front of
period
123. minimum number of digits missing behind
period
1.E5 invalid character Cx Text with maximum number of x bytes. UTF-8 according to ISO/IEC 10646-1:2011 except for codes less than 0x20 and except for comma 0x2C;
All other characters are embedded similar to the mechanism of the Cprogramming language using the “\” character followed by a two nibble hex value (examples \n for LF, \x1B for ESC, \, for comma). Following codes shall be implemented: \\ (“\”)
\n
\r
\f
\t
\, and \xNN (0xNN) Cx Examples for valid coding (for C12):
abcdoCD=12 < abcdoCD=12 <
a\n\x0A a<0x0A><0x0A>“
(<.> . hex value for control character)
a\n\x0A\x1B
12345\,67890 12345,67890
1\,2 Ab\\yz 1,2 Ab\yz Examples for invalid coding (for C12):
abcdCD12.3456 more than 12 characters
abCD12,345 comma not allowed S Time stamp – CCYYMMDDhhmmss Shortened forms of the time stamp string such as (CCYYMMDD) are not allowed. In this case unused fields have to be filled with 00. However a single digit 0 shall be used to represent no time stamp. Is a higher resolution than seconds needed fractions of seconds may be appended at the end of the time stamp string. Examples for valid coding:
19990109230201 09. January 1999 23:02:01
20001224013159.75 24. December 2000 1:31:59,75 Examples for invalid coding:
001224013159 shortened time stamp string
200012240131 seconds are missing
20001224013159,75 comma not allowed – use period SIST EN 15969-1:2011

see description for format identifier S above Examples for valid coding:
19990109 09. January 1999
20001224 24. December 2000 Examples for invalid coding:
001224 shortened date string T Time – hhmmss
see description for format identifier S above
Examples for valid coding:
230259 23:02:59
013159.75 1:31:59,75 Hx Unsigned hexadecimal value with max x characters, representing a bit pattern with x · 4 bits Bit 0 is encoded as value 1 Bit 1 is encoded as value 2 Bit 2 is encoded as value 4 and so on Examples for valid coding:
10A8
represents a field of 16 bits where bits 12, 7, 5 and 3 are set. All other Bits are zero. Examples for invalid coding:
10a8 lower case character "a" used
0x10A8 invalid character "x" used
$10A8 invalid character "$" used
6.5 Types of variable values 6.5.1 Single-Field-Type represents exactly one field with any one of the variable types given in Table 3. No separators or special codes for quoting are needed. 6.5.2 CSV Records and quoting ,,,… In this case, consists of a list of fields separated by the character comma “,”. Each field is of one-field-type. The formatting of a CSV record shall follow the guidelines below: 1) concatenation is done with the separator character comma (“,”); 2) numeric field of zero-length (empty field) shall be interpreted as not available; 3) trailing commas can optionally be omitted. SIST EN 15969-1:2011

Examples can be found in Clause 10. 6.6.3 Lists Some subnodes or variables are accessed as lists, which mean that more than one value or line may be stored or read, see Table 5. Table 5 — Operation applicable to lists Operation Effect (if operation allowed in this context) Enquiry shall return the current variable contents, line by line.
Set shall add the new value given behind the “=”—character to the list Clear shall make the list empty
An enquiry of an empty list (list without elements) shall be answered with a report without equal-sign. In contrast, an enquiry of a list with empty element shall be answered with a report with equal-sign without . NOTE If more than one record is to be added to the list its recommended to send all frames within one transaction using EOR-frames. EXAMPLE ENQ,FTL,SYSTEM,NodeList REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,NODELIST REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,FTL_VERS REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,FTL_FORMAT REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,DATETIME SIST EN 15969-1:2011

REP,FTL,COMP,Status(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,COMP,Status
REP,FTL,COMP,Status(1) = 2 REP,FTL,COMP,Status(2) = 2 REP,FTL,COMP,Status(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 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.15 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 13. SIST EN 15969-1:2011

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 7.3.2 Format for dataframes (variable FTL_FORMAT) Variable FTL,SYSTEM,FTL_Format=V Kind Value, Read Only, optional Enquiry
Returns the current format used for dataframes. Value V “CSV” (default): data is transmitted FTL-formatted
7.3.3 Date and time on TVE (variable DATETIME) Variable FTL,SYSTEM,DateTime=V Kind Value, Read/Write, optional Enquiry Returns the timestamp for current date and time on TVE. Set Tries to change the timestamp for current date and time on TVE. May also be used to synchronise TVE real time clock Format S (see Table 3) 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, Read/Write, 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; SIST EN 15969-1:2011

EXAMPLE ENQ,FTL,SYSTEM,BAUD REP,FTL,SYSTEM,BAUD=19200
SET,FTL,SYSTEM,BAUD=115200 Verify new baudrate after 5 s: ENQ,FTL,SYSTEM,BAUD REP,FTL,SYSTEM,BAUD=115200 SIST EN 15969-1:2011

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 7.3.8 List of supported nodes and variables (list NODELIST) Variable FTL,SYSTEM,NodeList = V Kind List, read only, required Enquiry
Returns a list of nodes and subnodes supported by the answering TVE. Value V All supported nodes (including their path) EXAMPLE ENQ,FTL,SYSTEM,NodeList REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,NODELIST REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,FTL_VERS REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,FTL_FORMAT REP,FTL,SYSTEM,NodeList=FTL,SYSTEM,DATETIME 7.3.9 Certificate for electronic signature
Variable FTL,SYSTEM,CERTIFICATE = V Kind List, read only, optional Enquiry
Returns the certificate of the unit used for electronic signature Format V Base64 encoded according to 6.8 of RFC 2045a). a) RFC 2045 is explained in the document " Multi purpose internet mail extension (MIME) subclause 6.8.
This document is available at web site, accessed through : www.ietf.org/rfc/rfc2045.txt
7.3.10 Remote popup message Variable FTL,SYSTEM,MESSAGE = V Kind Variable, Read/write, optional Set message number and text to be displayed as popup information on TVE screen Enquiry read back the value previously set Format V ,
where nr is of format N3 and text is of format C255
optional Enquiry Returns the value, that has been stored there by OBC last time. Set
Simply stores V in this variable for usage by TVE. Format #L08_GPS_INFO The OBC shall write GPS-data to the TVE. To avoid excessive traffic on the bus, it is usually sufficient to set the node value only once by the OBC when a phase of movement ends and the tank vehicle comes to rest. 7.4.3 GPS on TVE-side (variable TVE) Variable FTL,GPS,TVE=V Kind Value, read only, optional Enquiry
If TVE includes a GPS receiver, the GPS-data shall be available for use by the OBC. Format #L08_GPS_INFO
7.5 Accessing a printer on TVE-side (subnode PRN) 7.5.1 General When the TVE includes an on board printer (e.g. ticket printer as part of a metrological approved metering system), it may also be used by the OBC to print lists or any other data. In order to avoid conflicts while printing a document, the printer shall be reserved by the OBC before accessing it. Any attempt by the OBC to set a printer node without reserving it first, shall be reject
...