prEN 15430-3

• Abstract:

  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.

• Status: Not Published
• Publication Date: 27-Apr-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: 4060 - Closure of enquiry - Enquiry
• Start Date: 23-Jul-2026
• Due Date: 08-Apr-2026
• Completion Date: 23-Jul-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

prEN 15430-3 is a CEN draft European Standard for winter and road service area maintenance equipment data acquisition and transmission. It specifies the interface and protocol between an information supplier server and a client application server so vehicle and equipment data can be exchanged independently of the technology used to collect it. The document is aimed at producers and consumers of the data, including system suppliers and data-processing applications.

What does prEN 15430-3 specify?

prEN 15430-3 specifies the flow 3 interface between the information supplier server and the client application server. It is the part of EN 15430 that handles data transfer after the data has already been collected, so different board computers, WLAN systems, memory cards, and vendor-specific collection protocols can still feed the same client side.

The document does not set rules for flow 1 or flow 2. It also states that data reduction and lossy compression are not allowed during transfer between Producer and Consumer, because the exchanged data may be used for supervision and as evidence after incidents.

The document is organized into clauses 1 to 9 and six annexes.

Annex	What it covers
Annex A	Guidelines for Data Exchange, including performance and best practices
Annex B	Normative message body examples
Annex C	Normative calculation of missing fields and rounding of data
Annex D	Normative handling of 64-bit integers when using JavaScript
Annex E	Informative examples of missing-message flow
Annex F	Informative test interface examples

What are the key requirements of prEN 15430-3?

prEN 15430-3 requires a REST-based DataExchange system with one or more Producers connected to one or more Consumers. In practice, this means the parties exchange configuration and data through Application Programming Interfaces (API), and the same structure can support one-way streaming or, if both roles are implemented, a two-way arrangement.

• REST, JSON and HTTPS communication (Clauses 5 and 6) - The API should use REST web services, JSON, and HTTPS. Data is sent as a JSON version of EN 15430-1 with added metadata such as unique identifiers. For users, this means the implementation is tied to common web technologies and the payload stays machine-readable.

• UTC time handling (Clause 6.2) - All date, time and timestamp fields in the interface use Coordinated Universal Time (UTC). The timestamp is the actual creation time of the message, not a local board-computer clock. This matters when comparing data from vehicles working in different time zones.

• Message structure and acknowledgements (Clauses 6.3 and 6.4) - Message types and parameters are carried in the URL, while the body carries the data. Replies use HTTP status codes, including application-specific uses such as a not-found response. For implementers, this keeps transport behavior predictable and makes error handling explicit.

• Request families (Clause 6.5) - The interface groups requests into six areas: Groups, SerialNumbers, Messages, Logs, Time and Version. This gives clear access paths for administration, data retrieval, diagnostics, clock checks and version negotiation.

• Message integrity and sequencing (Clause 6.5.4 and Clause 7.1) - Each message has a serialNumberId, an id and a previousId. The id is unique for a serial number, messages are sent in ascending order, and the previousId chain is used to detect gaps. In practice, this is how the Consumer checks whether data has been lost and can request it again.

• Keep-Alive and completeness checks (Clause 5.1 and Clause 5.2) - A Keep-Alive message is posted every minute to the Consumer, and the Consumer switches to a get mechanism if Keep-Alive messages stop arriving. The Consumer also checks for missing data and, if needed, retrieves the latest messages and old data by serial number or group.

• Version control and testing (Clause 7.2 and Clause 8) - The document requires versioning of the document, protocol, API, client and other components, and the API exposes supported versions so Producer and Consumer can negotiate the highest common version. Each API also needs a test interface, which supports integration and validation work.

• Local security handling (Clause 9) - The document says local regulations can apply for security. For projects, that means the implementation must be aligned with the security rules of the operating environment, not only with the protocol text.

Annex A adds practical guidance on request rate, response time, message delay, availability and support notification. It also recommends omitting empty fields and empty records from JSON, and ignoring messages that contain unsupported EN 15430-1 records.

What terms does prEN 15430-3 define?

prEN 15430-3 defines the main roles and technical terms used in the exchange.

• Producer - The entity that distributes previously stored vehicle and/or equipment information to Consumers through the protocol.
• Consumer - The entity that retrieves the information provided by the Producer.
• Application Programming Interface (API) - The REST endpoint used to manage configuration, receive data, request logs, and check versions.
• JSON (JavaScript Object Notation) - The message format used for the transferred records and metadata.
• HTTPS (Hyper Text Transfer Protocol Secure) - The transport used for requests and responses, including status-code acknowledgements.
• UTC (Coordinated Universal Time) - The common time base for all timestamps in the interface.
• 64-bit Integer - The signed integer type used for message indexes and other values that need JavaScript-safe handling guidance.
• DataExchange - The system name used for the Producer-Consumer exchange described in Clause 5.

Who uses prEN 15430-3?

prEN 15430-3 is used by parties that collect, transmit, store, process or analyze operating data from winter and road service area maintenance equipment. The most direct users are the Producer and Consumer roles defined by the document.

Typical users include:

• equipment manufacturers and telematics suppliers that generate or publish vehicle data
• software developers who build the client application server, API, or data-processing tools
• fleet operators, municipal vehicle managers and maintenance organizations that need data from spreaders, ploughs and related equipment
• integrators and support teams who configure groups, serial numbers, version negotiation and data recovery
• organizations that use vehicle operating data for supervision, analysis, accounting or incident evidence

Which standards are used with prEN 15430-3?

prEN 15430-3 is used together with EN 15430-1:2024 and ISO 8601-1:2019.

• EN 15430-1:2024 - Defines the in-vehicle data acquisition side and provides the record structure that this part converts into JSON for transfer between servers.
• ISO 8601-1:2019 - Defines the date and time representation used for UTC timestamps and time-range queries.
• RFC 2616, Chapter 10 - The document points to this chapter for the HTTP status-code overview used in acknowledgements.

What does the prEN 15430-3 document contain?

The document contains a system overview, interface design rules, request definitions, and message handling rules for the Producer-Consumer exchange. Clause 6 gives the request paths and query parameters for groups, serial numbers, messages, logs, time and version.

It also includes normative examples for message bodies and for handling missing fields, plus a normative note on 64-bit integer handling in JavaScript. Annex E shows example flows for missing data recovery, and Annex F points to test-interface examples such as Swagger for API testing and documentation.

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
...