EN 15430-1:2007/FprA1

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

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

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

General Information

• Status: Not Published
• ICS: 35.240.60 - IT applications in transport
• ICS: 43.160 - Special purpose vehicles
• Technical Committee: CEN/TC 337 - Winter maintenance and road service area maintenance equipment
• Drafting Committee: CEN/TC 337/WG 3 - Interface between tools and vehicle
• Current Stage: 5060 - Closure of Vote - Formal Approval
• Start Date: 26-Nov-2010
• Due Date: 25-Dec-2011
• Completion Date: 26-Nov-2010
• Ref Project: SIST EN 15430-1:2008/kprA1:2010 - Winter and road service area maintenance equipments - Data acquisition and transmission - Part 1: In vehicle data acquisition

Relations

• Merged Into: EN 15430-1:2007+A1:2011 - Winter and road service area maintenance equipments - Data acquisition and transmission - Part 1: In vehicle data acquisition
• Effective Date: 19-Jan-2023
• Amends: EN 15430-1:2007 - Winter and road service area maintenance equipments - Data acquisition and transmission - Part 1: In vehicle data acquisition
• Effective Date: 17-Apr-2010

Standards Content (Sample)

SLOVENSKI STANDARD
01-november-2010
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
Winter and road service area maintenance equipments - Data acquisition and
transmission - Part 1: In vehicle data acquisition
Winterdienst- und Straßenbetriebsdienstausstattung - Datenerfassung und -übertragung
- Teil 1: Datenerfassung im Fahrzeug
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
Ta slovenski standard je istoveten z: EN 15430-1:2007/FprA1
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
43.160 Vozila za posebne namene Special purpose vehicles
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
FINAL DRAFT
EN 15430-1:2007
NORME EUROPÉENNE
EUROPÄISCHE NORM
FprA1
August 2010
ICS 35.240.60; 43.160
English 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 Winterdienst- und Straßenbetriebsdienstausstattung -
dépendances routières - Acquisition et transmission des Datenerfassung und -übertragung - Teil 1: Datenerfassung
données - Partie 1: Acquisition des données véhiculaires im Fahrzeug
This draft amendment is submitted to CEN members for unique acceptance procedure. It has been drawn up by the Technical Committee
CEN/TC 337.
This draft amendment A1, if approved, will modify the European Standard EN 15430-1:2007. If this draft becomes an amendment, CEN
members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for inclusion of this amendment
into the relevant national standard without any alteration.

This draft amendment 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 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.

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

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2010 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 15430-1:2007/FprA1:2010: E
worldwide for CEN national Members.

Contents Page
Foreword . 3
1 Modification to Clause 2, Normative references . 4
2 Modification to Clause 3, Terms and abbreviations . 4
3 Modification to 4.2.3, Communication protocol . 4
4 Modification to Clause 5, Definitions of variables, records and report . 6
5 Modification to 5.3, Variable types (former 5.2) . 6
6 Modification to 5.5.2, General variables (former 5.4.2) . 7
7 Modification to 5.5.8, Spreader / sprayer variables (former 5.4.8) . 8
8 Modification to 5.6.6 to 5.6.15 (former 5.5.6 to 5.5.15) . 11

Foreword
This document (EN 15430-1:2007/FprA1:2010) 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 document is currently submitted to the Unique Acceptance Procedure.
1 Modification to Clause 2, Normative references
Add at the beginning of the clause the following standard paragraph:
"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."

2 Modification to Clause 3, Terms and abbreviations
Add the following abbreviation under CRC-16 reference:
"CRC-32 Cyclic Redundancy Code with 32 bits".

3 Modification to 4.2.3, Communication protocol
Delete the existing text in 4.2.3 until Figure 3 and replace it with the following:
"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.
Remark: 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).
Remark: 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
16 12 5 0
bytes, starting with the record code, ending with CR+LF. The polynomial used is x + x + x + x = 11021
h
(i.e. XOR mask 1021 ) and initial value FFFF .
h h
Remark: 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
32 26 23 22 16 12 11 10 8 7 5 4 2
x + x + x + x + x + x + x + x + x + x + x + x + x + x + 1
Remark: 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 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.1) 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 CR+LF CRC-16 End
Data (codes + values, “;” separated) (x bytes)
(1 byte) (2 bytes) (2 bytes) (1 byte)
SOH 1;10;1602048;0461021;5;Abc;Equip1;;; CR LF 66D9 EOT
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 0D 0A 36 36 44 39 04
31 3B 35 3B 41 62 63 3B 45 71 75 69 70 31 3B 3B 3B
"
4 Modification to Clause 5, Definitions of variables, records and report
After Table 1 and before 5.2 “Variables types” add the following sub-clause:
"
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.
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.5)."

5 Modification to 5.3, Variable types (former 5.2)
After Table 4 and before 5.4 “Recommended SLOTs for variables definitions” add the following part:
"Example of BASIC_TIME and BASIC_DATE format:
BASIC_TIME
EXAMPLE 16:02:12 (hh:mm:ss).
As the seconds are to be stated in quarters of a second these have to be written as 48. Combined
value 16 | 02 | 48. Because the maximum of the last value can be 239 (59,75 seconds * 4) 3 characters are
reserved for this value.
Combined value of BASIC_TIME = 16|02|048 = 1602048.
BASIC_DATE
th
EXAMPLE 11-10-2006 (October 11 2006).
The day value has to be stated in quarters. The time is 16:02, being in the third quarter of the day, so the total
value is 11,5 (= 46 quarters). Because the maximum of this value can be 127 (31,75 days * 4) 3 characters
are reserved for this value.
The month value is 10.
The year value has to be stated in years since 1985: 2006-1985 = 21.
Combined value of BASIC_DATE = 046|10|12 = 0461012."

6 Modification to 5.5.2, General variables (former 5.4.2)
Replace Table 6 with the following table:
"
No Name Description BASIC data format or
SLOT
1 Version Protocol version num
...