SIST EN 15430-1:2008+A1:2011
(Main)Winter and road service area maintenance equipments - Data acquisition and transmission - Part 1: In vehicle data acquisition
Winter and road service area maintenance equipments - Data acquisition and transmission - Part 1: In vehicle data acquisition
This European Standard specifies a standardized protocol for downloading data from the equipment control box to an in vehicle board computer to ensure interchangeability between a vehicle and different equipments that the same vehicle can carry.
It specifies the interface connection as well as variables, records and reports which permit standardized protocol to cover applications with the greatest possible variety of equipments for performing winter maintenance and road service area maintenance.
Winterdienst- und Straßenbetriebsdienstausstattung - Datenerfassung und -übertragung - Teil 1: Datenerfassung im Fahrzeug
Dieses Europäische Norm legt ein genormtes Protokoll für das Übertragen von Betriebsdaten von der Anbau-Gerätesteuerung (Steuergerät) zu einem im Fahrzeug befindlichen Bord-Computer fest, um die Kompatibilität zwischen dem Fahrzeug und den verschiedenen Anbau-Geräten, die an diesem Fahrzeug betrieben werden können, sicherzustellen. Diese Norm legt sowohl Schnittstellen (Anschlüsse) fest wie auch Variablen, Datensätze und Meldungen, die es in dem genormten Protokoll ermöglichen, eine größtmögliche Vielfalt bei Anwendungen von Anbau-Geräten beim Straßenbetriebs- und Winterdienst abzudecken.
Matériels de viabilité hivernale et d'entretien des dépendances routières - Acquisition et transmission des données - Partie 1 : Acquisition des données véhiculaires
Cette Norme européenne spécifie un protocole normalisé pour le téléchargement de données à partir du boîtier de commande d'un matériel vers un ordinateur embarqué afin d'assurer l'interchangeabilité entre un véhicule et les différents matériels que ce véhicule peut embarquer.
Elle spécifie l'interface de connexion, ainsi que les variables, les enregistrements et les rapports qui permettent au protocole normalisé de couvrir des applications avec des matériels les plus variés pour réaliser la viabilité hivernale et l'entretien des dépendances routières.
Oprema za vzdrževalna dela zimske službe in službe za vzdrževanje cest - Zajem in prenos podatkov - 1. del: Zajem podatkov v vozilu
Ta evropski standard določa standardiziran protokol za snemanje podatkov iz škatle za nadzor opreme do računalnika, vgrajenega v vozilu, za zagotovitev zamenljivosti med vozilom in različnimi opremami, ki jih lahko ista vozila prenašajo.
Določa vmesniško povezavo in spremenljivke, zapise in poročila, ki dovoljujejo standardiziran protokol z uporabo največje mogoče raznolikosti opreme za izvajanje zimske službe in službe za vzdrževanje cest.
General Information
Relations
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Oprema za vzdrževalna dela zimske službe in službe za vzdrževanje cest - Zajem in prenos podatkov - 1. del: Zajem podatkov v voziluWinterdienst- und Straßenbetriebsdienstausstattung - Datenerfassung und -übertragung - Teil 1: Datenerfassung im FahrzeugMatériels de viabilité hivernale et d'entretien des dépendances routières - Acquisition et transmission des données - Partie 1 : Acquisition des données véhiculairesWinter and road service area maintenance equipments - Data acquisition and transmission - Part 1: In vehicle data acquisition43.160Vozila za posebne nameneSpecial purpose vehicles35.240.60Uporabniške rešitve IT v transportu in trgoviniIT applications in transport and tradeICS:Ta slovenski standard je istoveten z:EN 15430-1:2007+A1:2011SIST EN 15430-1:2008+A1:2011en,fr,de01-maj-2011SIST EN 15430-1:2008+A1:2011SLOVENSKI
STANDARD
SIST EN 15430-1:2008+A1:2011
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 15430-1:2007+A1
February 2011 ICS 35.240.60; 43.160 Supersedes EN 15430-1:2007English Version
Winter and road service area maintenance equipments - Data acquisition and transmission - Part 1: In vehicle data acquisition Matériels de viabilité hivernale et d'entretien des dépendances routières - Acquisition et transmission des données - Partie 1: Acquisition des données véhiculaires
Winterdienst- und Straßenbetriebsdienstausstattung - Datenerfassung und -übertragung - Teil 1: Datenerfassung im Fahrzeug This European Standard was approved by CEN on 21 October 2007 and includes Amendment 1 approved by CEN on 27 December 2010.
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 15430-1:2007+A1:2011: ESIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E)
2 ContentsForeword . 3Introduction . 41Scope . 62Normative references . 63Terms and abbreviations . 64Communication between vehicle/equipment and board-computer . 74.1General . 74.2Communication through RS232 . 74.2.1RS232 interface on vehicle/equipment “Data transmission handler” . 74.2.2RS232 interface on “Board-computer” . 74.2.3Communication protocol . 85Definitions of variables, records and report . 125.1General . 125.2Data integrity check . 125.3Variable types . 135.4Recommended SLOTs for variable definitions . 165.5Definition of variables. 195.5.1General . 195.5.2General variables . 205.5.3General geographic position system variables . 215.5.4General vehicle and route variables . 225.5.5General road weather and road condition variables . 225.5.6Plough / Broom variables . 235.5.7Snow blower or cutter variables . 245.5.8Spreader / sprayer variables . 245.5.9Grass or branch cutting machine variables . 275.5.10Sweeper variables . 285.5.11Safety post cleaning machine variables . 295.5.12Boat plants cutter variables . 305.6Definition of records . 305.6.1General . 305.6.2Time synchronisation record (record code 0) . 315.6.3Standard header record (record code 1) . 325.6.4Standard footer record (record code 2) . 335.6.5Trigger conditions for record code 3 and higher . 335.6.6Geographic position data record (record code 3) . 345.6.7Vehicle and route data record (record code 4) . 355.6.8Weather and road condition data record (record code 5) . 375.6.9Snowplough / broom data record (record code 6 / 7) . 385.6.10Spreader / sprayer data record (record code 8) . 405.6.11Snow blower / cutter data record (record code 9) . 425.6.12Grass / branch cutter data record (record code 10) . 445.6.13Sweeper data record (record code 11) . 465.6.14Safety post cleaning machine data record (record code 12) . 485.6.15Boat plants cutter data record (record code 13) . 495.6.16Free definable data record (record code 10000 and higher) . 505.7Report definition . 51Bibliography . 52 SIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E) 3
Foreword This document (EN 15430-1:2007+A1:2011) has been prepared by CEN/TC 337/WG 3 "Interface between tools and vehicle", the secretariat of which is held by UNI-CUNA, under the direction of Technical Committee
CEN/TC 337 "Winter maintenance and road service area maintenance equipment", 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 August 2011, and conflicting national standards shall be withdrawn at the latest by August 2011. 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 includes Amendment 1, approved by CEN on 2010-12-27. This document supersedes EN 15430-1:2007. The start and finish of text introduced or altered by amendment is indicated in the text by tags
!". According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom. SIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E)
4 Introduction This protocol is meant to be used for data acquisition in fleet management applications in the field of municipal vehicles. The purpose of the protocol is to define how data of a vehicle or equipment is generated, stored and transferred to a board-computer system in the vehicle and from the board-computer to the software application in the office (refer to Figure 1). On the equipment or vehicle the data is generated by a “Data generator”. This data is stored, if present, into a buffer-memory. The “Data transmission handler” will send the data present in the buffer-memory to the “Board-computer” or “Data Acquisition System”. The buffer-memory is there to ensure that data does not get lost in case there is no transmission possible. The size or type of the buffer is not defined in this proposal. If there is no buffer or the buffer is too small to store new data, data will get lost. To synchronise time-stamps of the vehicle/equipment with the Board-computer, a special record for time synchronisation is defined. In this part the data acquisition and communication from vehicle/equipment to the Board-computer is defined.
Figure 1 – Architecture
In general, the data is a semi-colon (“;”) separated ASCII text for separation of record codes and values of variables. CR+LF is used for separation of records (one record is one line of text).
SIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E) 5 Examples of an on-board system configuration
Figure 2 – Diagram of possible connections SIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E)
6 1 Scope This European Standard specifies a standardized protocol for downloading data from the equipment control box to an in-vehicle board computer to ensure interchangeability between a vehicle and different equipments that the same vehicle can carry. It specifies the interface connection as well as variables, records and reports which permit standardized protocol to cover applications with the greatest possible variety of equipments for performing winter maintenance and road service area maintenance. 2 Normative references !The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies." !ISO/IEC 8859-1", Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin alphabet No. 1 NMEA 0183, Interface Standard TIA-232-F, Interface between data terminal equipment and data circuit-terminating equipment employing serial binary data interchange (RS232) SAE J1939/71, Recommended practice for serial control and communications vehicle network — Vehicle application layer 3 Terms and abbreviations ACK Acknowledge (ASCII control code 06h) ASCII American national Standard Code for Information Interchange Bps Bits per second CRC-16 Cyclic Redundancy Code with 16 bits !CRC-32
Cyclic Redundancy Code with 32 bits" CR Carriage Return (ASCII control code 0Dh) EOT End Of Transmission (ASCII control code 04h) h Number before h is in hexadecimal notation IEEE Institute of Electrical and Electronics Engineers LF Line Feed (ASCII control code 0Ah) NAK Negative acknowledge (ASCII control code 15h) SOH Start Of Header (ASCII control code 01h) TBD To Be Defined ↵ CR + LF (carriage return + line feed) SIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E) 7 4 Communication between vehicle/equipment and board-computer 4.1 General The data exchange between vehicle/equipment “Data transmission handler” and the “Board-computer” must follow at least one of the communication standards described in the present document version or future release. Until now, only the RS232 standard (TIA-232-F) is defined as a communication standard so that means that at the present a compliant EN 15430
“Data transmission handler”
has to supply a RS232 interface , if in the future other standard interfaces will be defined
(e.g. CAN BUS, USB .) a compliant EN 15430 future “Data transmission handler” will have to supply at least one of the communication standard until that time is defined. 4.2 Communication through RS232 4.2.1 RS232 interface on vehicle/equipment “Data transmission handler” • Connector: SUB-D 9p female o Pin 2 = Transmit Data
o Pin 3 = Receive Data o Pin 5 = Signal Ground • Baud rate: 1 200 Bps.115 200 Bps, default 9 600 Bps. Rate can be programmable (optional) Remark: the baud rate must be sufficient for a worst case amount of data to be send with retries. • Data bits: 8 • Stop bits: 1 • Parity: No • Data format: according to !ISO/IEC 8859-1" (ASCII) • Handshaking: by software with ACK, NAK ASCII control codes, refer to 4.2.3 • Transmission control by SOH and EOT ASCII control codes, refer to 4.2.3 • Data validity check: CRC-16/CCITT, refer to 4.2.3
4.2.2 RS232 interface on “Board-computer” • Connector: SUB-D 9p male o Pin 2 = Receive Data o Pin 3 = Transmit Data o Pin 5 = Signal Ground • Baud rate: 1 200 Bps.115 200 Bps, default 9 600 Bps. Rate must be programmable or automatically detected (autobaud) • Data bits: 8 • Stop bits: 1 SIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E)
8 • Parity: No • Data format: according to !ISO/IEC 8859-1" (ASCII) • Handshaking: by software with ACK, NAK ASCII control codes, refer to 4.2.3 • Transmission control by SOH and EOT ASCII control codes, refer to 4.2.3 • Data validity check: CRC-16/CCITT, refer to 4.2.3
4.2.3 Communication protocol ! Transmission of a record. In this definition a message to be communicated consists of one record. Records are terminated by CR+LF (a record is one line of text). In general, a message is sent by the sender (e.g. the “Data transmission handler” of a spreader) and received by the receiver (e.g. the Board-computer). After power up, communication is always started by the vehicle/equipment “Data transmission handler” sending its first message (this is the time synchronisation record). Refer to Figure 4 for flow charts of the sender and receiver algorithms. The receiver will check the validity of a message by testing if the CRC-16 value corresponds to the data in the message received. If the data is valid, the receiver sends an ACK. The sender can now send a new message. If the data is invalid, the receiver sends a NAK. Then, the sender will try to send the same message again for a maximum of 2 times. If the message still fails, the message is considered to be lost. Preferably, a notification is given to the user (operator) that data has been lost by the sender and/or the receiver. NOTE 1 The receiver sends an ACK or a NAK as a single character without other data. The ACK or NAK refers to the latest message sent by the sender. To avoid record synchronisation problems between sender and receiver, the sender must ignore any ACK or NAK received during the transmission of a message until the last byte is sent (EOT character). Also, the receiver is not allowed to send an ACK or NAK during the reception of a message until the last byte is received (EOT character). NOTE 2 Numerical values have to be transmitted with ASCII characters in decimal code. Calculation of the CRC-16 value. The CRC value is calculated according to the CCITT definition. The CRC value is calculated over all record bytes, starting with the record code, ending with CR+LF. The polynomial used is x16 + x12 + x5 + x0 = 11021h (i.e. XOR mask 1021 h) and initial value FFFFh. NOTE 3 The value is written in ASCII characters in hexadecimal code with capitals (0.9,A.F). Calculation of the CRC-32 value. The CRC-32 value is calculated according to the CCITT definition. The CRC-32 value is calculated over all record bytes, starting with the record code, ending with CR+LF. The polynomial used is x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
NOTE 4 The value is written in ASCII characters in hexadecimal code with capitals (0.9,A.F). Sender without receiving options for handshaking. For old vehicle/equipment “Data transmission handlers”, it may be impossible to receive data. In this case the sender cannot respond to an ACK or NAK, i.e. there is no handshaking feature. Hence, the sender will send a new message. This may cause in the result that data gets lost, e.g. in case the Board-computer was not started up yet SIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E) 9 or if transmission failed. It is up to the user to handle this problem (for example to connect power supply such that power-up is always at the same time for sender and transmitter). Synchronisation of communication. To synchronise communication between sender and receiver, a message always starts with an SOH and ends with an EOT. If the receiver is not synchronised yet but the sender is already transmitting a message (e.g. when the Board-computer starts up while the spreader “Data transmission handler” is sending), all data before the first SOH will be ignored. If the receiver is synchronised but detects an SOH before an EOT, the previous, unfinished message is ignored. Time synchronisation between sender and receiver. In general, the sender system time and the receiver system time are not equal. To synchronise messages to the system clock of the receiver, a time synchronisation record is introduced. This Time Sync record (refer to 5.5.2) contains the actual system time of the sender at the start of record transmission (with a maximum error of ± 0,5 s). The receiver must record its system time at the moment of reception of a message. In case of the reception of a Time Sync record, the receiver can calculate the difference between its own system clock and the system clock of the sender. Now, the receiver can time-synchronise every message received from the sender and thereby synchronise this data to other data generated by other sources. The board computer must contain a real time clock which runs even if the board computer has no power. The electronic system on the vehicle/equipment must have a real time clock which runs even when this system has no power, or, a software clock must be implemented made which starts at date 1-1-2000 and time 00:00:00 and is updated every second. A Time Sync record, is sent by the sender: - as the first message starting the communication; - after 10 s if the receiver does not respond to a message with an ACK or a NAK; after a successful transmission of this record, the latest message before the time synchronisation record is transmitted again; - if the system clock of the sender is adjusted, reset or set to any value which would cause a jump in time. Loss of data. Data will get lost in case of: - a “Data transmission handler” without handshaking feature which is sending while reliable communication is not possible; - an overflow of the buffer-memory; - 2 unsuccessful retransmissions after a NAK. In case the “Data transmission handler” supports handshaking, it is mandatory sending the header record as the first record of a report (note: the Time Sync record is not part of the report). i.e. the header record may not get lost. Example of a message is shown in graphical form: Start (1 byte) Data (codes + values, “;” separated) (x bytes) CR+LF (2 bytes) CRC-16 (2 bytes) End (1 byte) SOH 1;10;1602048;0461021;5;Abc;Equip1;;; CR LF 66D9 EOT SIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E)
10 ASCII characters in hexadecimal notation: 01 31 3B 31 30 3B 31 36 30 32 30 34 38 3B 30 34 36 31 30 32 31 3B 35 3B 41 62 63 3B 45 71 75 69 70 31 3B 3B 3B 0D 0A 36 36 44 39 04 " Communication example:
Figure 3 – Flow diagram SIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E) 11
Sender algorithm:
Receiver algorithm:
Figure 4 - Flow chart
SIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E)
12 5 Definitions of variables, records and report 5.1 General A report is a file of records which in general is used to describe one ride. A report starts with a header record, one or more status records of the vehicle/equipment(s) and a footer record. A record is a structure of coherent variables in a predefined order. A member of a record is called a “field”. Table 1 - Application or equipment types Equipment Source ref.nr.RemarkBoard computer 1
Vehicle 2 On board vehicle electronic generating data Snow plough or broom 3 It is assumed that if there is more than one snow-plough, the data is generated by one source only. Snow blower or cutter 4
Spreader or sprayer 5 Remark: this equipment could also generate the data for example for a snow plough, however, the source reference number stays 5 (as the spreader is the data generator). Road weather and road condition information system 6
Grass or branch cutting machine 7
Sweeper 8
Safety post cleaning machine 9
Boat plants cutter 10 Used for cutting plants in canals or rivers Other 11 To be used for any equipment not defined ! 5.2 Data integrity check There are at least two methods required to assure integrity: a) Data have to be checked for manipulation of the contents themselves. b) Data have to be checked for completeness: Data have to be checked against any deletion of any parts of them. In the present standard these two requirements lead to the following methods of covering: - Data manipulation (a) is checked by CRC. - Data deletion (b) is checked by including the previously calculated CRC value into the new CRC value. SIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E) 13 In order to ensure data integrity two CRC variables (CRC_REC and CRC_STREAM) are defined for each record and generated by the board computer. CRC_REC contains the CRC-32 value calculated over all the data contents of the record itself and CRC_STREAM contains the CRC-32 value calculated over the CRC_STREAM of the preceding record and the current CRC_REC value. CRC_REC and CRC_STREAM are both optional and are not available in the Time synchronisation record (record code 0), Standard header record (record code 1) and Standard footer record (record code 2) (see 5.6)." 5.3 Variable types All variables defined, have to comply to one of the following variable types. The column “Format” shows how a variable is represented in one or more examples. A full stop is defined as a decimal separator. Data ranges are defined in the same way as SAE J1939/71 defines them: SIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E)
14 Table 2 - Ranges Range Name 1 byte2 bytes4 bytesASCIIValid Signal 0 to 250 0 to 64 255 0 to 4211081215 1 to 254 00h to FAh 0000h to FAFFh 00000000h to FAFFFFFFh 01h to FEh Parameter specific indicator 251 64256 to 64 511 4211081216 to 4227858431 None FBh FB00h to FBFFh FBxxxxxxh Reserved range for future indicator bits 252 to 253 64512 to 65 023 4227858432 to 4261412863 None FCh to FDh FC00h to FDFFh FC000000h to FDFFFFFFh Error indicator 254 65 024 to 65 279 4261412864 to 4278190079 0 FEh FExxh FExxxxxxh 00h Not available or not requested 255 65280 to 65 535 4278190080 to 4294967294255 255 FFh FFxxh FFxxxxxxh FFh Table 3 - Basic variable types Type Range LengthFormatRemarkBOOLEAN 0, 1 2 Bits 00 = Value is 0, no errors 01 = Value is 1, no errors 10 = Error 11 = not available Definition taken from SAE J1939 CHAR -125.+125 1 byte 0.250, Offset -125 254 = Error 255 = not available Definition taken from SAE J1939 UNSIGNED CHAR 0.250 1 byte 0.250, Offset 0 254 = Error 255 = not available Definition taken from SAE J1939 SIGNED SHORT -32 127.+ 32 127 2 bytes 0.64255, Offset 32768 65024.65279 = Error 65280.65535 = not available Definition taken from SAE J1939 UNSIGNED SHORT 0.64255 2 bytes 0.64255, Offset 0 65024.65279 = Error 65280.65535 = not available Definition taken from SAE J1939 SIGNED LONG - 2105540608 .
+2105540608 4 bytes 0 to 4211081215,
Offset -2105540608, 4261412864 to 4278190079 = Error, 4278190080 to Definition taken from SAE J1939 SIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E) 15 Type Range LengthFormatRemark4294967295 = not available UNSIGNED LONG 0.4211081215 4 bytes 0 to 4211081215,
Offset -2105540608, 4261412864 to 4278190079 = Error, 4278190080 to 4294967295 = not available Definition taken from SAE J1939 BASIC_DATE 1.31,75 day 1.12 month 1985.2235 year 3 bytes 0,25 day/bit, 0 day offset 1 month/bit, 0 month offs. 1 year/bit, +1985 offset Definition taken from SAE J1939 Remarks: day = 0 is forbidden day = 1,2,3,4 are first day of month day = 5,6,7,8 are second day of month. month = 0 is forbidden year = 0 is 1985, year = 1 is 1986, . BASIC_TIME 0.23 h 0.59 min 0.59,75 s 3 bytes 1 h/bit, 0 h offset 1 min/bit, 0 min offset 0,25 s/bit, 0 s offset Definition taken from SAE J1939 STRING_X
ASCII-characters (character set is ISO Latin I) The string length must be <=
X Allowed char values: 01h.FEh 00h = Error FFh = not available Definition taken from SAE J1939 SAEat1728 Any string with max. 255 characters. NOTE The STRING_X type has to follow these additional rules: • If a transmission handler returns a valid string field the first character may not be 00h or FFh.
The predefined string length has to be covered completely with valid characters.
• If the valid string content is shorter than the predefined length ( X characters), the rest of the predefined length has to be filled with FFh characters to indicate that these characters are not valid. • If a transmission handler cannot supply the string filed the first character has to be either 00h, when the contents are incorrect, or FFh, when the contents are not available. In these two special cases the string length may be only one character in size, although it is also allowed to fill the rest of the predefined string length with FFh characters. SIST EN 15430-1:2008+A1:2011
EN 15430-1:2007+A1:2011 (E)
16 Table 4 - ISO LATIN I Character set definition
x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB x
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.