prEN 15430-3

Winter and road service area maintenance equipment - Data acquisition and transmission - Part 3: Protocol for data transfer between application servers

The function of EN 15430 is to combine any vehicle equipment with different board computers to any client application server.
This document specifies the interface and protocol needed between the information supplier server and the client application server (flow 3 as illustrated in Figure 1) to allow distribution of data without any restrictions to the technology used to gather the data like manufacturer specific protocols, WLANS systems, memory cards, etc.

Winterdienst- und Straßenbetriebsdienstausstattung - Datenerfassung und -übertragung - Teil 3: Protokoll für den Datentransfer zwischen Client Anwenderservern

Die Funktion von EN 15430 besteht darin, beliebige Fahrzeugausrüstungen mit verschiedenen Bordcomputern zu einem beliebigen Client-Anwendungsserver zu verbinden.
Dieses Dokument legt die Schnittstelle und das Protokoll fest, die zwischen dem Server des Informationsanbieters und dem Client-Anwendungsserver benötigt werden (Fluss 3, wie in Bild 1 dargestellt), um die Verteilung von Daten ohne Einschränkungen hinsichtlich der zur Datenerfassung verwendeten Technologie wie herstellerspezifische Protokolle, WLANS Systeme, Speicherkarten usw. zu ermöglichen.

Matériels de viabilité hivernale et d'entretien des dépendances routières - Acquisition et transmission des données - Partie 3: Protocole pour le transfert de données entre les serveurs d'application

La fonction de l'EN 15430 est de combiner tout équipement de véhicule ayant différents ordinateurs embarqués avec tout serveur d'applications clientes.
Le présent document spécifie l'interface et le protocole nécessaires entre le serveur fournisseur d'informations et le serveur d'applications clientes (flux 3 tel qu'illustré sur la Figure 1) pour permettre une distribution de données sans aucune restriction à la technologie utilisée pour collecter les données comme des protocoles spécifiques au fabricant, des systèmes WLAN, des cartes mémoires, etc.

Oprema za vzdrževalna dela zimske službe in službe za vzdrževanje cest - Zajem in prenos podatkov - 3. del: Protokol za prenos podatkov med aplikacijskimi strežniki

Funkcija EN 15430 je združiti katero koli vozilo opremo z različnimi vgrajenimi računalniki s katerim koli strežnikom za odjemalske aplikacije.
Ta dokument določa vmesnik in protokol, potrebna med strežnikom za dobavo informacij in strežnikom za odjemalske aplikacije (tok 3, kot je prikazano na Sliki 1), da omogoči distribucijo podatkov brez kakršnih koli omejitev glede tehnologije, uporabljene za zbiranje podatkov, kot so proizvajalčevi specifični protokoli, WLAN sistemi (brezžični lokalni omrežni sistemi), pomnilniške kartice itd.

General Information

• Status: Not Published
• Publication Date: 01-Jun-2027
• 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: 4020 - Submission to enquiry - Enquiry
• Start Date: 30-Apr-2026
• Due Date: 14-Jan-2026
• Completion Date: 30-Apr-2026
• Ref Project: oSIST prEN 15430-3:2026 - Winter and road service area maintenance equipment - Data acquisition and transmission - Part 3: Protocol for data transfer between application servers

Standards Content (Sample)

SLOVENSKI STANDARD
01-julij-2026
Oprema za vzdrževalna dela zimske službe in službe za vzdrževanje cest - Zajem
in prenos podatkov - 3. del: Protokol za prenos podatkov med aplikacijskimi
strežniki
Winter and road service area maintenance equipment - Data acquisition and
transmission - Part 3: Protocol for data transfer between application servers
Winterdienst- und Straßenbetriebsdienstausstattung - Datenerfassung und -übertragung
- Teil 3: Protokoll für den Datentransfer zwischen Client Anwenderservern
Matériels de viabilité hivernale et d'entretien des dépendances routières - Acquisition et
transmission des données - Partie 3: Protocole pour le transfert de données entre les
serveurs d'application
Ta slovenski standard je istoveten z: prEN 15430-3
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
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.

DRAFT
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM
April 2026
ICS 35.240.60; 43.160
English Version
Winter and road service area maintenance equipment -
Data acquisition and transmission - Part 3: Protocol for
data transfer between application servers
Matériels de viabilité hivernale et d'entretien des Winterdienst- und Straßenbetriebsdienstausstattung -
dépendances routières - Acquisition et transmission Datenerfassung und -übertragung - Teil 3: Protokoll für
des données - Partie 3: Protocole pour le transfert de den Datentransfer zwischen Client Anwenderservern
données entre les serveurs d'application
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 337.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 15430-3:2026 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Abbreviated terms . 7
5 System overview . 7
5.1 General. 7
5.2 Flow . 8
6 Interface Design . 11
6.1 General. 11
6.2 Time information handling . 11
6.3 Message structure . 12
6.4 Acknowledgement . 12
6.5 Requests . 12
7 Classification, designation and coding . 24
7.1 Data integrity. 24
7.2 Versioning . 24
8 Testing . 24
9 Cyber security . 24
Annex A (informative) Guidelines Data Exchange . 25
Annex B (normative) Message body examples . 26
Annex C (normative) Calculation of missing fields and rounding of data . 35
Annex D (normative) 64-bit integer when using java script . 36
Annex E (informative) Examples of implementation missing message flow . 37
E.1 Example 1 . 37
E.2 Example 2 . 37
E.3 Missing data . 37
Annex F (informative) Test interface examples. 38
Bibliography . 39
European foreword
This document (prEN 15430-3:2026) has been prepared by Technical Committee CEN/TC 337 “Road
operation equipment and products”, the secretariat of which is held by AFNOR.
This document is currently submitted to the CEN Enquiry.
This document is part of the series EN 15430 "Winter and road service area maintenance equipment - Data
acquisition and transmission" which consists of the following parts:
— Part 1: In vehicle data acquisition
— Part 3: Protocol for data transfer between application servers
A list of all parts in a series can be found on the CEN website: www.cencenelec.eu.
Introduction
This document is the third part of EN 15430, the standard for data acquisition and transmission in the
field of municipal vehicles. The goal of EN 15430 is to allow interoperability between systems (hardware
and software) of different vendors. A customer should be able to combine:
— any equipment (e.g. spreaders and ploughs),
— any data acquisition systems (e.g. board computers or enhanced control boxes),
— any client application software (e.g. data bases, analysing or accounting software),
as long as they follow EN 15430.
EN 15430-1:2024 defines the on-board communication (flow 1) between equipment (data handler) and
data acquisition systems (board computer). This document is meant to describe the data structure, types,
ranges, protocol and initial settings required by the Producer and Consumer to be able to send data
generated by vehicles in near real time to any third-party data client over the internet. Figure 1
represents the whole data flow chain from vehicle to office system.

Key
1 flow 1
2 flow 2
3 flow 3
4 data handler 1
5 data handler n
6 board computer
7 gsm/gprs
8 wlan
9 m-card
10 producer
11 consumer
12 client application 1
13 client application n
Figure 1 — Transmission flow
Data collected is operating data of the vehicles, which contain time information, geo reference data and
machine status data. This data is stored in different memories: on the vehicle, in the facility where the
vehicles are maintained and in office, where data is retrieved and analysed. Because the collected data is
used not only to supervise work contents and results, but also as proof in case of accidents, the integrity
and the correctness of the data is important and indispensable.
This document contains seamless integration of mechanisms to deliver data secure from a Producer to a
Consumer (flow 3). It does not define any specific rules for items belonging to flow 1 or flow 2. During
data transfer between Producer and Consumer, the reduction of data or use of lossy compression
methods is not allowed.
Figure 1 defines the interface between devices and board computer, as described in EN 15430-1:2024,
and addresses the combination of data from different streams and the transmission to a generic
information supplier server. The blue section addresses the data transfer (flow 3) between the Producer
and the Consumer and is the purpose of this document.
1 Scope
The function of EN 15430 is to combine any vehicle equipment with different board computers to any
client application server.
This document specifies the interface and protocol needed between the information supplier server and
the client application server (flow 3 as illustrated in Figure 1) to allow distribution of data without any
restrictions to the technology used to gather the data like manufacturer specific protocols, WLANS
systems, memory cards, etc.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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.
EN 15430-1:2024, Winter and road service area maintenance equipment — Data acquisition and
transmission — Part 1: In-vehicle data acquisition
ISO 8601-1:2019, Date and time — Representations for information interchange — Part 1: Basic rules
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp/
— IEC Electropedia: available at https://www.electropedia.org/
3.1
producer
entity able to distribute previously stored vehicle and/or equipment information to Consumers using the
interface and protocol described in this document
3.2
consumer
entity able to retrieve the information provided by the producer (3.1)
3.3
64-bit Integer
signed integer with a maximum value of 9223372036854775807 and a minimum value of
−9223372036854775808
Note 1 to entry: A known issue exists when JavaScript is used as the programming language. Guidance on how to
address this issue is provided in Annex D.
[SOURCE: https://en.wikipedia.org/wiki/Integer_(computer_science)]
4 Abbreviated terms
For the purposes of this document, the following abbreviations apply.
ASCII American national Standard Code for Information Interchange
API Application Programming Interface
HTTP Hyper Text Transfer Protocol
HTTPS Hyper Text Transfer Protocol Secure
JSON JavaScript Object Notation
REST Representational state transfer
RFC Request For Comments
UTC Coordinated Universal Time
WAN Wide Area Network
5 System overview
5.1 General
A system is built of one or more Producers connected to one or more Consumers. See Figure 2.

Figure 2 — System overview
Each Consumer and Producer should have an Application Programming interface (API) that listens to and
handles configuration and other messages, and a client that dispatches messages to its corresponding
API. Together they form a DataExchange system.
The API should be REST-web services. The protocol used is JSON (ECMA-4-4) over HTTPS. Data should
be provided in EN 15430-1 format converted to JSON enhanced with meta info like unique and record
identifier.
The Consumers client should connect to the Producers API to manage configuration information and
complete (missing) data.
The Producer’s API should provide an interface to manage configuration information and to get data.
The Producer’s client should Post (push) new data to the Consumer’s API.
The Consumer’s API should provide an interface to receive new data.
With this data exchange system (from here on called DataExchange) it is possible to stream data to
partner systems. It is a one-way data stream.
When configuring API and client systems to assume both the Consumer and the Producer roles, it is
possible to create a two-way system.
A Keep-Alive Message shall be posted every minute to the Consumer. A Keep-Alive message is a message
with serialNumberId 1 and does not contain EN 15430 data. Using this Keep-Alive Message, the
Consumer can check if the post mechanism is running. If no Keep-Alive messages are received, the
Consumer shall switch to a get mechanism, and the Consumer shall notify the support parties.
5.2 Flow
5.2.1 Normal operation flow
Normal operational flow is shown in the following sequence diagram. See Figure 3.
Figure 3 — Normal operation flow
New data should be posted by the Producer’s client at a maximum rate of once per second. When there is
no new data, there should be no posts. The Consumer’s API should check the id for gaps in the data flow
and other parameters of the data and store/process it. New data should only be posted once. At most
every minute, the Consumer’s client process requests the last messages for all the serial numbers it is
expecting data from and checks if all data is complete.
At most once per minute, and should be once every hour or even once a day, the Consumer’s client process
requests if there are any new serial numbers available.
5.2.2 Missing messages detected flow
In case the Consumer’s API detects data is missing, normal flow is interrupted. See Figure 4.

Figure 4 — Missing messages detected flow
The completeness of the data shall be ensured by the Consumer (see Annex E for examples).
5.2.3 A new serial number is available flow
In case the Consumers client detects that a new serial number is available for message retrieval, normal
program flow is not interrupted. The following sequence diagram shall apply. See Figure 5.
Figure 5 — A new serialNumber is available flow
When the Consumer’s client system detects a new serial number it shall add that number to a group with
serial numbers. As a result of adding the serial number to a group, the Producers client shall start posting
messages to the Consumer’s API. Posting messages for this new serial number shall start with the first
message that is presented to the Producer’s system after the number is added to the group. This is to
prevent that the system shall be flooded with old data. When older data is needed, action is required by
a person supporting the system.
6 Interface Design
6.1 General
DataExchange is a system that uses REST, JSON and HTTPS to be able to send machine data quickly and
reliably from parties collecting data to parties processing it. In essence, functionality of the interface can
be divided into two parts. Functions about how and what data to send and functions sending the data.
Data is sent in a JSONified version of EN 15430-1. The data records are enriched with the unique identifier
of the board computer and two id fields to guard data completeness.
6.2 Time information handling
In contrast to true EN 15430-1 data, all date, time and timestamp fields in the described interface have to
contain UTC. The timestamp shall be the true time of the creation of the message, for example the GPS
timestamp in UTC but not the internal clock of the board computer. Local timestamps are avoided to be
able to compare data generated in different time zones.
6.3 Message structure
Messages are built according to the REST architecture definition. Messages shall be lowercase, capitals
are not allowed. Message type and parameters are contained in the message URL. For example, to get the
serial numbers of all the vehicles contained in the group with id 3 you would use:
https://examplecompany.com/api/groups/3. Data is contained in the Body part of the HTTPS
request. In case of the above example in Figure 6:

Figure 6 — Body part of a group{id} message
6.4 Acknowledgement
Each exchange message is responded to by the receiving system with a HTTPS status code following
HTTPS protocol. Additional HTTPS status codes are added to a message to provide extra information, e.g.
404 stands for group not found when asking for a group with an unknown id. See RFC 2616, Chapter 10
for a complete overview of HTTPS status codes.
6.5 Requests
6.5.1 General
The requests in the protocol are grouped into six categories: Groups, SerialNumbers, Messages, Logs,
Time and Version. See Figure 7.

Figure 7 —API Overview
6.5.2 Groups
See Figure 8.
Figure 8 — Group requests
A group contains serial numbers. Groups are used to enquire large numbers of vehicles in one API call to
reduce the total number of API calls needed. See Figure 9 and Table 1.

Key
[ ] body
Figure 9 — Group object body
Table 1 — Group object parameters
Parameter Explanation Reference
Id Unique identifier for group
Serialnumbers Array of all serial numbers in the See 6.4.2
group
name Name of the group
Available requests:
(GET : /api/groups)
Get a list of all available groups including the serial numbers those groups contain.
Extra Response Messages:
404  No groups found.
(POST : /api/groups)
Create a new group. A body containing the new group name and eventual serial numbers is added to
the request. The id provided in that body has to be set to 0. A new id shall be provided by the API.
Extra Response Messages:
400 Group id invalid.
(DELETE : /api/groups/{id})
Delete the group with id: {id}. {id} shall be replaced with the id of the group that should be deleted.
EXAMPLE https://examplecompany.com/api/groups/3
Extra Response Messages:
204 Group is deleted.
(GET : /api/groups/{id})
Get the group with id: {id}. {id} shall be replaced with the id of the group that is requested.
Extra Response Messages:
404 Group not found.
(PUT : /api/groups)
Change the name of the group with id: {id}. {id} shall be replaced with the id of the group of which
the name has to be changed.
Extra Response Messages:
204 Group is updated.
400 Group is invalid.
404 Group not found.
6.5.3 Serial numbers (SerialNumbers)
See Figure 10.
Figure 10 — SerialNumber Requests
Each serial number contains an Id, a manufId and an equipId. The Id is a unique identifier used as a link
to the data source as identified by the manufId and equipId. The combination of manufId and equipId
shall also be unique over a Producer/Consumer pair. The Id is used for all calls requesting data and as
serial number identifier in groups in this protocol. See Figure 11 and Table 2.

Key
[ ] body
Figure 11 — SerialNumber object body
Table 2 — SerialNumber object parameters
Parameter Explanation Reference
Id Unique identifier for the Serial
number
ManufID Manufacturer identification. EN 15430-1:2024, Table 6 No 6.
EquipID Manufactures serial identification EN 15430-1:2024, Table 6 No 7.
code of vehicle/equipment
Available requests:
(GET : /api/serialnumbers)
Get a list of all available serial numbers. This list is provided for by the Producer and cannot be changed
by the Consumer.
Extra Response Messages:
404 No serial numbers found.
(GET : /api/groups/{groupid}/serialnumbers)
Get a list of all available serial numbers contained in the group with id: {groupId}. {groupId} shall be
replaced with the id of the group the serial numbers are requested for.
EXAMPLE https://examplecompany.com/api/groups/1/serialnumbers
Extra Response Messages:
404 Group not found.
(POST : /api/groups/{groupid}/serialnumbers)
Add a serial number to the group with id: {groupid}. {groupid} shall be replaced with the id of the group
the serial numbers should be added to. The serial number added has to be a member of the list provide
by (Get : /api/serialnumbers)
Extra Response Messages:
404 Group or serial number not found.
(DELETE : /api/groups/{groupid}/serialnumbers/{id})
Delete the serial number with id {id} from the group with id: {groupid}. {groupid} shall be replaced with
the id of the group the serial numbers have to be deleted from. The serial number added has to be a
member of the list provide by (Get : /api/serialnumbers)
EXAMPLE https://examplecompany.com/api/groups/1/serialnumbers/1
Extra Response Messages:
204 The serial number is removed from the group.
404 Group or serial number not found.

6.5.4 Messages
See Figure 12.
Figure 12 — Messages Request Overview
A message contains (see Figure 13):
Figure 13 — Messages Overview
The message has
• serialNumberId
• id
• previousId
• Header record
• Gps record
• Keep-Alive record
• Vehicle and route record
• Weather and road record
• Spreader record
• Snowplough Broom record
• Snow blower/cutter record
• Grass/branch cutter record
• Sweeper record
• Safety post cleaning machine record
• Boat plant cutter record
• Free definable record
• Footer record
The examples in Annex B shall be used for transmitting the records listed above. Annex C shall be used
for the calculation of missing fields and the rounding of data.
The id is unique per serial number. Messages have to be sent in an ascending order. The previousId is the
id of the previous message. Gaps are allowed between two consecutive ID’s. Gaps are not allowed in the
chain between the id and the previousId.
Records are records as defined in EN 15430-1 with two exceptions. The record string is converted to a
JSON object and the fields id and bcId are added. id is identical to the id field of the Message. bcId is a
unique identifier string for the board computer that collects the data. Only one record of each type can be
present in a message except for Snowplough Broom records which is an array. Often a vehicle has more
than one plough and/or broom present.
It is allowed to combine multiple EN 15430-1 records into one message. The consumer needs to be aware
and consider that it is possible to receive multiple EN 15430-1 records in one message.
When combining records, all records should have the same timestamp.
For example, Snowplough Broom records are usually combined with spreader records and the vehicle
route record are usually combined with the header and spreader record.
See Figure 14 for a typical message body. Table 3 summarizes the message parameters.

Key
{ } body
Figure 14 — Message Body
Table 3 — Message object parameters
Field Explanation Reference
serialNumberId Id of the serial number this message
belongs to.
Id Unique number in combination
with serialNumberId that identifies
this message.
previousID Id of the message this message
should follow up to. This Field
makes it possible to detect if data is
missing.
Header EN 15430 header record Annex B
Gps EN 15430 GPS record Annex B
Keep-Alive record Keep-Alive re
...