EP3869471A1

EP3869471A1 - Communication method comprising a server and a plurality of on-board units and on-board unit

Info

Publication number: EP3869471A1
Application number: EP20465509.6A
Authority: EP
Inventors: Cristian - c/o Continental Automotive GmbH Bilcea; Sorin - c/o Continental Automotive GmbH Soare
Original assignee: Continental Automotive Technologies GmbH
Current assignee: Aumovio Germany GmbH
Priority date: 2020-02-24
Filing date: 2020-02-24
Publication date: 2021-08-25

Abstract

The invention is concerned with a method of communication between a server (10) on one side and a plurality of On-Board-Units (20), OBUs, on the other side for use in the automotive field, wherein each OBU (20) is being installed in a different vehicle (30) and identified by a unique Serial Number, and wherein the communication is taking place within a mobile communication system. The invention is characterized in that the communication between each OBU (20) and the server (10) takes place over an HTTP connection based on a specific format of communication messages comprising mandatory and optional parameters defined by the server (10), and wherein at least the following steps are performed: for the communication to take place, one or several messages of request Request<sub>i</sub> are repetitively made at a preconfigured time by the OBU (20) to the server (10) when the OBU (20) is in an activated state and specific messages of response Response<sub>i</sub> triggered by the server (10) are sent to the OBU (20).

Description

The current invention is concerned with the automotive field. In particular, the invention refers to a communication method between a server on one side and a plurality of On-Board-Units (OBUs) on the other side over an HTTP connection. The invention is also concerned with an On-Board Unit for applying the steps of the method and a computer program running on the On-Board Unit.
On-Board-Units (OBUs) are known for many years in the automotive industry, especially in connection with the methods for tolling vehicles in an open-road toll system where vehicles are provided/equipped with such units and the roads are provided with roadside radio beacons and the authority that cashes the tolls operates a server also known as central office, or backend server.
Apart from their use in the tolling system, OBUs are used in the automotive industry to measure a variety of operational parameters of the vehicle (such as but not limited to state of the switches, energy consumption, motor parameters). For this reason, OBUs are used in On-Board Diagnostics (OBD) as well as in Remote Vehicle Diagnostics (RVD).
Known technical solutions have some disadvantages such as:

OBU is the only one which can initiate communication with the server. Although, a connection between the OBU and the server may be configured for bidirectional data transmission, this does not involve the server initiating a communication with the OBU. In some cases, the server sends acknowledgements of receipt of the data packets sent by OBU to the server, and in others, the acknowledgement of receipt is missing.
There are no known methods and corresponding configurations of the OBU to respond to the needs of the server arising from practice such as:
- configuring the OBU whenever needed in such way as to change what kind of information is sent to the server and when said information is sent;
- sending OBU specific information and diagnostic data algorithms;
- updating the OBU software Over The Air (OTA);
- sending debug information from the OBU to the server.

The above mentioned Hypertext Transfer Protocol (HTTP) is a known protocol which is used for communication in a request-response manner between a client and a server over the internet for presenting text to a user who operates the client.
An OBU can be an electronic device comprising at least a processor which can be programmed to gather information regarding the vehicle and transfer the same to the server in messages of request.
It is an object of the present invention to provide an efficient and flexible communication between the OBU and the server.
The object is accomplished by the subject-matter of the independent claims. Further advantageous embodiments of the invention are described by features of the dependent claims, the following description as well as the figures.
The invention provides a method for communication between a server on one side and a plurality of the OBUs on the other side for use in the automotive field. Such a communication can, for example, be a point to point communication where the server communicates with a single OBU or it can be a point to multipoint communication where the server may broadcast messages/instructions intended for multiple OBUs. The server in this communication can alternatively be a physical server or a logical cloud computing server.
Each OBU is being installed in a different vehicle and identified by a unique Serial Number. The OBU can, for example, be mounted on the top or the outer side of the vehicle or it can be placed in the inner side of the vehicle. The unique Serial Number can, for example, be a physical address, i.e. Media Access Control (e.g. using a MAC address), of the unit or it can be any serial number.
The communication is taking place within a mobile communication system. The mobile communication can alternatively be any wireless communication using a communication standard e.g. GSM, UMTS, LTE or 5G.
The communication between each OBU and the server takes place over a respective HTTP connection based on a specific format of communication messages comprising mandatory and optional parameters defined by the server. Alternatively, the communication can be held over any client-server protocol where requests are usually initiated by the client. The compulsory parameters, e.g. a MAC address of an OBU, and/or diagnostic data (DiagData) are always appended to every message of the communication, while the optional parameters, e.g. status parameter (i.e. when the server has something to transmit to the OBU), can be used if and when necessary.
For the communication to take place, requests Request_i are repetitively made at respective pre-configured times by the OBU to the server when the OBU is in an activated state. The index i is defined here as a counter for identifying individual request messages. Alternatively, the exchange of communication messages over the HTTP connection is initiated as and when the respective OBU is turned on and particularly when the OBU is required as a matter of routine to communicate with the server at a fixed period time. In other words, the OBU keeps the communication connection alive by sending the messages of Request_i, e.g. a so-called POST Request_i message.
Specific messages of response Response_i triggered by the server are sent to the OBU. In other words, the server provides a response for each request which is sent by the OBU to the server. The response can be an instruction for the OBU to perform a particular action according to the requirements of the server or it can be a mere acknowledgment of the receipt of the request message.
The advantage here is to provide an optimized communication between the OBU and the server.
The present invention also comprises embodiments that provide additional technical advantages.
In an embodiment, the OBU sends the repetitive messages of Request_i each at a preconfigured time to update the server on activity data regarding the vehicle. Additionally or alternatively, the OBU transmits the collected data related to the status and/or activities of the respective vehicle to the server at an interval of time and the time interval could be a fixed period of time, e.g. every 10 seconds or every minute or once a day.
In one embodiment, the collected data sent to the server are a normalized raw data, wherein at least two OBUs use raw data that express a physical quantity (e.g. temperature) on the basis of different units (e.g. Celsius and Fahrenheit) and the normalized raw data are based on the same unit (e.g. Celsius only).The collected activity data are not decoded at the respective OBU, rather the raw data measurements are normalized and then transmitted to the server. The decoding would mean that the OBU provides explanation what these data mean. For example, if the normalized raw data are "FE010046", this could mean: FE01 = Parameter "Temperature" and "0046" could mean "46 °C". Normally, an OBU would decode this to obtain a text message "Temperature = 46°C". This translation is omitted. In other words, the normalized raw data are not self-explanatory. Instead, the raw data can be based on different encodings, depending on the OBU that generates them. The advantage here is that less computational processing is required on the OBU while the decoding of the collected data is performed at the server and, thus, the OBU resources are available for further processing of collecting the activity data regarding the vehicle.
In one embodiment, at least once or each time the OBU sends the Request_i, the server sends the Response_i to the OBU with a server status parameter corresponding to at least one instructing action to be carried out by the OBU. In other words, the server response can be an instruction to alert the OBU whether an action based on the server needs is to be taken on the part of the OBU or not. The advantage here is that the OBU is informed on regular basis as to whether its functionality has any conflict with the server. In other words, the OBU can determine its course of action based on the server instruction, and thus the working of the OBU is made compatible with the server demands.
In one embodiment, depending on the server status parameter, the instructing actions are chosen by the OBU. The first instructing action embodies "no action required" which defines the continuation of collecting the regular activity data regarding the vehicle by the OBU and sending the same to the server. In other words, the server has no instruction for the OBU or, in other words, the working of the OBU is fully compatible with the server needs and, therefore, the OBU may continue to carry out its routine task of collecting and sending the activity data regarding the vehicle at the preconfigured times. A further instructing action relates to a configuration change of the OBU according to the needs of the server. Alternatively, the OBU is instructed to install a new configuration available at the server. In other words, the new configuration refers to the parameters which define the way (e.g. type, format) the collected activity data is to be sent to the server. Another instructing action relates to a software update of the OBU from the server. In other words, the server informs the OBU if the current version of the software (e.g. boot software, new Base software, new low cost processor software) working on the OBU is malfunctioning or a new software version is available for the respective OBU. The status parameter provides an advantage of a controlled monitoring of the OBUs so that the working status of the respective OBUs can be verified and enhanced by the server.
So far it has only been described how the communication can be initiated by the OBU. In one embodiment, an additional communication between the respective OBU and the server is triggered by the server by sending to the OBU a wakeup message over an auxiliary connection, different from the HTTP connection, in particular when the server has any new instructions for the OBU. In other words, the server has a capacity to initiate the process of establishing a communication connection between the OBU and the server whenever the server needs to transfer data on its own initiative. The advantage here is to provide a flexible and bidirectional communication between the OBU and the server.
In one embodiment, the server triggers the wakeup message via a mobile communication system, when the OBU has gone into a sleep mood, and in particular when the OBU is no longer sending the repetitive messages of the Request_i to the server at the pre-configured times, and/or when the server has an immediate instructing action for the OBU. In other words, the server can re-establish the communication connection using a mobile communication network by sending a message (e.g. an SMS) to the communication module (e.g. subscriber identity module) built into the OBU if the existing regular connection (i.e. the one which is stablished by the OBU) is assumed to be broken or it is idle for a specific amount of time and/or when the server has, in particular, any immediate action to perform on the OBU. The advantage here is to provide a network redundancy to maintain the communication connection if the regular connection is not functioning.
In one embodiment, the auxiliary connection is established when the wakeup message contains the valid Serial Number matching a corresponding OBU (20), and when a server Passphrase (an ASCII command instruction) contained in the wakeup message is set to a predefined default status parameter, and wherein a forced event is triggered based on the server Passphrase. The server Passphrase can be any command instruction of the string data type. The auxiliary connection between the server and the intended OBU is validated based on the authentication parameters i.e. Serial Number and the server Passphrase. In other words, the auxiliary connection is intended when the server wants to force the OBU to perform an event, in particular when any previous server instruction (e.g. configuration change or a software update) have been partially performed. This provides an advantage of ensuring a secure connection and a controlled monitoring of the OBU activities by the server.
In one embodiment, the OBU is a Control Unit for Telematics with Enhanced function, CUTE, which performs the remote diagnostics of a vehicle, and wherein the server is an End Customer Server, ECS, which performs the gathering and processing of the diagnosed remote information. In other words, the CUTE performs on-board diagnostics of a vehicle to record information about the behaviour (e.g. speed and location) of the vehicle, and whereas the ECS server decodes and interprets the recorded information.
The monitoring of on-board diagnostics of a vehicle provides an advantage of finding location, movements, status and behaviour of a vehicle or fleet of vehicles in real time. CUTE is an On-board Unit (OBU) with a functionality of Telematics, especially an OBU with an integrated modem. Telematics is a known field which involves the integrated use of telecommunications and informatics for automotive applications, in particular for controlling vehicles on the move. It provides the advantage of fast communication.
In one embodiment, the CUTE/OBU provides a status to ECS/server containing information about its current configuration, its current software version, and/or functioning status of the most recent configuration or software upgrade. In other words, the CUTE sends in every POST Request_i a status parameter containing information related to the current configuration of the OBU, the installed software version, and/or the result of the most recent configuration and/or the result of the recent software update, in particular when any errors are detected in the functioning of the installed software version at the OBU. The advantage here is provide a synchronized communication between the OBU and the server such that the functioning of the can be made error free and/or compatible with any changing demands of the server.
In one embodiment, the ECS/server initiates a new software update for the CUTE/OBU, if the status provides a notification of errors in the functioning of the current software version. Based on the status parameter, the server can instruct the CUTE/OBU for a reinstallation of the current software version or an upgraded version if the status parameter indicates that the current software version is malfunctioning and/or the previous software version is not fully installed and/or a new software version is available. This provides an advantage of a flexible and controlled operation of the CUTE/OBU.
In one embodiment, the ECS/server communicates with a Diagnostics Configuration Server, CDCS, to obtain valid authentication token to be used by the CUTE/OBU for all POST Requesti sent to the ECS/server. In other words, an authentication of a CUTE/OBU is required if and when the CUTE/OBU intends to communicate with the server, in particular when the CUTE/OBU executes a POST Request_i. The advantage here is that the communication between the server and the multiple OBUs can be facilitated by assigning tokens to the corresponding OBUs.
In one embodiment, an On-board unit, OBU, comprising at least one processor and a memory, characterized in that the OBU is adapted to perform the steps of a method according to any of the claims 1 to 11 that concern the OBU, in particular when the OBU is in an activated state.
In one embodiment, computer program being stored on a physical data carrier, wherein the computer program is designed for being performed on a computer, in particular on an OBU, for making the computer execute a method, wherein the computer program comprises instructions for performing steps of a method according to any of claims 1 to 11.
Advantages of the invention are particularly the following:

The communication server - OBU is faster because the server can initiate also communication and it is more adjusted to the needs of the server;
The OBU can be configured according to the needs of each server-considered as a customer, thus making it more competitive;
The OBU is more robust because of it can send information regarding errors to the server and the server can respond with solutions such as new configuration or software update Over the Air.

Further features and advantages of the invention will stem from the following description with reference to the accompanying drawings in which like reference characters designate the same component or a component of the same functionality or the same step of the method throughout the figures thereof.
The invention will hereafter be described with reference to the drawings where:

Fig. 1: shows a schematic diagram of the HTTP communication between a server and multiple OBUs over a telecommunications network;
Fig. 2: shows a schematic diagram of the steps of the method according to the invention, corresponding to daily activity of collection of data regarding the vehicle by the OBU and sending them to the server;
Fig. 3: shows a schematic diagram of the steps of the method according to the invention, corresponding to the configuration of the OBU by the server;
Fig. 4: shows a schematic diagram of the steps of the method according to the invention, corresponding to new software update by the OBU;
Fig.5: shows one example of communication comprising a Get Request_i requesting software update in step 105 and its corresponding Response_i in step 105' according to the preferred embodiment.

Detailed description of the implementation of invention including a preferred embodiment.
Fig.1 explains exemplarily how a communication between a server 10 and one or multiple OBUs 20 over a mobile communications network is conducted using a HTTP protocol. Each OBU 20 installed in a different vehicle 30 is identified by a unique Serial Number so that the server 10 can communicate with the corresponding OBU 20 without having any conflict in identifying the respective OBU 20 for which a response from the server 10 is intended.
Fig.1 illustrates an example of the simplest form of communication in which the OBU 20 communicates with the server 10 through a network comprising at least one Base Transceiver Station 50, BTS. The BTS 50 is a network element which connects the OBU 20 to the web or the internet cloud 60 and then to the server 10 based on a HTTP protocol. The HTTP protocol provides a network connectivity between the OBU 20 and the server 10 and facilitate the exchange of mutual communication over the web.
The OBU 20, integrated with a wireless modem, transmits messages of Request_i to the BTS 50 using a mobile connection. The BTS 50 forwards the request messages of the OBU 20 to the server 10 through the intermediate network elements (i.e. not shown in the Fig.1) which form web as a whole. The intermediate elements may be a set of wireless access points, routers and/or switches which provide an arrangement for a physical (i.e. based on a hardware server) or a virtual (i.e. based on a software server) connectivity between the OBU 20 and the server 10.
The role of the OBU 20 is to provide the server 10 with relevant data regarding the vehicle 30 on which it is installed, depending on the purpose of the communication (e.g. vehicle diagnostics, tolling system).
Each OBU 20 is installed on a different vehicle 30 and is identified by a unique Serial Number.
The OBU 20 has the active role to open the communication channel 40 via mobile communication systems. Said communication channel 40 is secured, for example by using HTTP protocol.
A general rule of communication between the OBU 20 and the server 10 according to the invention is that the OBU 20 initiates the opening of the communication channel 40 with a message of request, and the server sends a message of response, the message of request being sent regularly at preconfigured times, such as but not limited to any 5 or 10 minutes.
Various communications between the two parties that take place at different moments are identified as Request (generic), Request_i or Request_j or Request_n and respectively Response (generic), Response_i or Response_j or Response_n, with:

Request_i = request sent by the OBU 20 to the server 10 via the communication channel 40 according to HTTP.
Response_i = response to the POST Request_i sent by the server 10 to the OBU 20 via the communication channel 40 according to HTTP.

The most frequently used HTTP Request sent by the OBU 20 to the server 10 is a POST Request and refers to a data submission from the OBU 20 to the server 10 to be processed by a specified resource of said server 10. This is illustrated in Fig. 2 by POST Request_i opening the communication channel 40 and triggering Response_i.
OBU 20 may equally make other HTTP Requests to the server 10 apart from the POST Request, such as for example the GET request or the HEAD request.
For the ease of understanding of the method, Fig. 2, 3 and 4 depict one server and one OBU. However it shall be clearly understood that the method of the invention shall be worked in a system having a plurality of the OBUs.
The OBU 20 shall make HTPP requests by default, if not specified in other way. The security certificate of the server 10 is not validated.
The format of the messages Request_i and Response_i include the corresponding header according to HTTP standard: Content-Type: application/json
The communication between the OBU 20 and the server 10 respects the REST standard, the payload (body) of the message being carried within a transmission unit is encoded using Java Script Object Notation (JSON) and Unicode Transformation Format 8 (UTF-8).
The content of the data exchanged during communication between the server 10 and the OBU 20 is established by the server 10 depending on the needs of the server 10. It is like a set of procedures of a corporation (that is the server 10) for various types of tasks that people (that is the plurality of OBUs 20) must carry out. In this respect the server contains in its Application Programming Interface (API) endpoints several types of data exchanged corresponding to different purposes:

for the purpose of authentication - called "/authenticate" type,
for conducting daily work, namely collection and sending of data regarding the vehicle - called /diaginfo" type,
for the purpose of informing the server 10 about the status of the OBU
called "/status" type,
for the purpose of configuration of the OBU - called "/config" type and
for the update of the software - called "/swupdate" type.

The selection between the afore-mentioned five types of data exchanged during communication is made by the OBU 20. The server 10 shall always respond with the same type of content. For example if the OBU 20 sends a "/diaginfo" POST Request_i, the server 10 shall respond with a "/diaginfo" Response_i. "/diaginfo" POST Request_i, is the most frequently used type of request made by the OBU 20 because it corresponds to the current activity of the OBU 20 of gathering and processing data regarding the vehicle 30.
The body of the messages Request_i and Response_i comprise mandatory parameters and optional parameters, each parameter being defined either as a parent one or a child one. The parameters considered mandatory must be used every time, and the parameters considered optional should be used only if necessary. If some child parameter is mandatory, inside a parent object which is optional, meaning that either the optional parent is not selected at all or it is selected along with all the mandatory children parameters. By example in /cuteconfig inside "VehicleConfiguration", it is not necessary to have a certain parameter called "CDCS", but if in case it is, then it is mandatory to have also "Root", "Port" and "Path".
Further on, according to the invention, the server 10 contains different set of instructions for the OBU 20 triggering different set of steps of the method. These instructions are written in a parameter of the server called "server status" where each type of instruction receiving a specific code.
There are three types of instructions:

"no action required", corresponding to the instruction that the OBU 20 shall carry out normal work that is collection and sending of data regarding the vehicle 30 and corresponding to the first set of steps of the method;
"new configuration" corresponding to the instructions that the OBU 20 shall receive a new configuration from the server 10 and corresponding to the second set of steps of the method;
"new software update" corresponding to the instruction that the OBU 20 shall receive software update from the server 10 and corresponding to the third set of steps of the method.

"No action required" signifies that neither a new configuration nor a software update is requested at the time when the Request_i was received by the server 10 and the corresponding Response_i was sent back to the OBU 20 and consequently the OBU 20 may continue to carry out its usual task of collecting and sending the activity data regarding the vehicle 30 at the preconfigured times.
Some minutes later after having sent the Response_i with the code "no action required", the server 10 may have either a new configuration or a software update for the OBU 20.
"New configuration" refers to the parameters configuring the way in which OBU 20 is sending the vehicle information: what type of information is to be collected and sent, in what format and when it should be done.
"New software update" includes any type of software to be installed or updated that is needed for the functioning of the OBU 20, such as but not limited to new Boot software, new Base software, new Low Cost Processor (LCP) software, etc. For this purpose, each type of software update may receive a different server status code.
A typical sequence of messages between the OBU 10 and the server 20 in case server status code is set to "no action required", the following basic steps of the method are performed (Fig.2):

In step 001 of the method, the OBU 20 sends a regular, "/diaginfo" Request, usually a POST Request_i to the server 10 that includes data collected regarding the vehicle 30;
In step 002 of the method, the server 10 sends the corresponding "/diaginfo" Response_i to the OBU 20 including server status code "no action required".

During the lifetime of the OBU 20, it is needed to carry out at least one configuration and at least one software update, preferably numerous configurations and numerous software updates in order to customize the OBU 20 to the needs of the server 10 and to use latest versions of software.
In a case, when the server status code is "new configuration" the following set of steps of the method are applied (Fig. 3):

In step 102 the OBU 20 sends the"/diaginfo" POST Requestj to the server 10. This step is identical with step 001 of the first set of the method;
In step 103 the server 10 informs the OBU 20 in its"/diaginfo" Response_j, that new configuration is available by showing corresponding code in the status of the server 10;
In step 104 the OBU 20 sends the "/config" POST Request_j+1 to the server 1 asking for the new configuration;
In step 105 the server 10 sends the corresponding "/config" Response_j+1 to OBU 20 that contains new configuration;
In step 106 the OBU 20 performs a verification if the configuration requirements are fulfilled, and, if conditions are respected, installs said configuration;
In step 107 the OBU 20 sends the "/status" POST Request_j+2 to the server 10; informing the server 10 on the outcome of the new configuration ;
In step 108 the server 10 replies to the OBU 20 in the"/status" Response_j+2.

Once steps 102-108 are completed, the regular repetitive sequence of messages Request_i-Response_i, as described in steps 001 and 002 of the method, is continued over the communication channel 40, until a new necessity arises for a new configuration or a new software update.
In case, the server status code is set to "new software update" the following set of steps of the method are applied (Fig. 4):

In step 102 the OBU 20 sends its the "/diaginfo" POST Requestj to the server 10;
In step 103 the server 10 informs the OBU 20 in its "/diaginfo" Response_j, that new software update is available by showing corresponding code in the status of the server 10;
In step 104 the OBU 20 sends a "/swupdate" HEAD Request_j+1 to the server 10 in order to receive the response header information;
In step 104' the server 10 sends the corresponding "/swupdate" Response_j+1 to OBU 20 with the header information;
In step 105 the OBU 20 sends a "/swupdate" GET Request_j+2 in order to download the software update files from the server 10;
In step 105' the corresponding"/swupdate" Response_j+2 from the server 10 in respect to downloading the software update;
In step 106 the OBU 20 performs a verification if the requirements for software update are fulfilled;
In step 107 the OBU 20 sends the "/status" POST Request_j+2 to the server 10; informing the server 10 on the outcome of the verification of the fulfilment of the requirements for software update;
In step 108 the server 10 replies to the OBU 20 with a "/status" Response_j+2;
In step 109 the OBU 20 is restarted to apply the new software.
In step 110 the OBU 20 sends the "/status" POST Request_j+3 to the server 10 of type; informing the server 10 on the new running software version.

The preferred embodiment of the present invention is described in the context of automotive telematics and a mobile communication system defined by the OSI System Layer 7, in particular for the remote vehicle diagnostics. In this context, the OBU is a Control Unit for Telematics with Enhanced diagnostics function (in short CUTE), whereas the server is the End Customer Server (in short ECS) that has a role in decoding and interpreting diagnose of vehicles whose information is received through each respective CUTE 20. ECS may belong for example to the car manufacturer or an entity in charge with maintenance of the vehicles, but it may belong to any other entity in charge with processing data in respect to the diagnose of the vehicles.
Thus, it shall be understood that all functions and configurations described for the OBU 20 shall be equally carried out by the CUTE and all functions and configurations described for the server 10 shall be equally carried out by the ECS, which explains why reference 10 for the server is equally used for ECS and correspondingly reference 20 for the OBU is equally used for the CUTE.
However, the present invention is not limited to the CUTE and the ECS described in the preferred embodiment. In this respect, all the other embodiments disclosed in this invention are described using the particular configurations of the preferred embodiment where the two communicating parties are the CUTE and the ECS. The person skilled in the art shall understand that the said other embodiments described using the configurations of the preferred embodiment shall equally apply to all situations where the OBU 20 is required to communicate with the server 10.
One of the major improvements of the invention over prior art is that whenever the server 10 needs to have a rapid communication with the OBU 20 for a new configuration or a new software update, the server 10 does no longer have to wait for the repetitive Request_i from the OBU 10.
With reference to Fig.3 and 4, in step 101 of the method, in case the server 10 needs to initiate rapid communication with the OBU 20, the server 10 sends a SMS to the OBU 20 in order to trigger opening of the communication channel 40.
In order to communicate by the SMS, the server 10 is configured to support transmission of the SMS to the OBU 20 and the OBU 20 is configured to be able to receive the SMS when a specific parameter called "EnableGSMWake" is equal to 1.
The OBU 20 shall check the data inside the SMS in order to see if it is a valid SMS. The structure of the SMS must be:

<SMS_SerialNumber>: <SMS_ServerPassphrase> where
< SMS_SerialNumber> is a 10 digit number from the [0:9] range.

The SMS is valid if this number is equal to the Serial Number of the CUTE/OBU (20); and where < SMS_ServerPassphrase> is a 15 ASCII character passphrase or a 20 ASCII character command. The SMS is valid if the Server Passphrase default value is "Connect to server".
If the SMS is considered valid and the SMS_ServerPassphrase is equal to the ServerPassphrase the OBU 20 software shall execute a "/diaginfo" POST Request_i
If the SMS is considered as valid and the ServerPassphrase is equal to "Trigger Event Nr. <XX>" such as configuration or software update, the OBU 20 software shall execute a POST Request to /diaginfo like event <XX> was generated. Basically this forces an event triggering, in this case either configuration or update.
Here is an example of a valid forced event triggering:

1396.000000000000000000000000000: Trigger Event Nr. 01 -> event is triggered.
1396.000000000000000000000000000: Trigger Event Nr. 10 -> event 10 is triggered;

OBU

After step 101 as described in the preceding paragraphs, either the second set of steps or the third set of steps of the method is carried out, as they were detailed above.
If the configuration was not successfully installed or respectively the software was not successfully updated- including the situations of partial configuration successful or partial update of software successful, the server 10 can reinitiate the steps of the method corresponding to new configuration or update of software at a later date, depending on specific rules defined in the server 10. The reinitiating can be either waiting for the regular "/diaginfo" POST Request_i from the OBU 10, thus starting with step 102 of the method or by triggering immediate action by sending a new SMS, thus starting with step 101 of the method.
The "/status" -type of communication initiated by CUTE/OBU 20 is used to inform ECS/server 10 about status of CUTE/OBU 20 at the moment when the corresponding "/status" POST Request_i is sent. This includes information about current configuration of the CUTE/OBU, current versions of software installed, result of the most recent configuration or the most recent new software update.
A configuration is successfully applied both following conditions are met:

The configuration is applied individually for each CUTE/OBU 20 functionality (main wrapper) and
If inside a CUTE/OBU 20 functionality wrapper object there is a parameter which has an invalid value, then all the data inside the wrapper is discarded.

In step the 107 CUTE/OBU 20 informs the ECS/server 10 in a "/status" Request_j+2 message the result of application of the new configuration: either successfully installed if all conditions were met, or partially installed if only part of the conditions were met, or totally discarded if no condition was met in respect to each functionality.
The "/status" -type of communication initiated by CUTE/OBU 20 may also be used to inform ECS/server 10 about errors in the functioning of the software installed on CUTE/OBU 20. In this case, in step 102 the type of message is no longer of "/diaginfo" type but of "/status" type indicating the error(s).
In case in step 001 the CUTE/OBU 20 sends the /status" POST Request_i informing the ECS/server 10 about errors, said ECS/server 10 takes a decision about the way to resolve (debug) each error. This decision may involve for example sending new software update- thus applying the third set of steps of the method or new configuration thus applying the second set of steps of the method. The reinitiating may be either waiting for the regular "/diaginfo" POST Request_i from the OBU 10, thus starting with step 102 of the method or by triggering immediate action by sending a new SMS, thus starting with step 101 of the method. Restart of the CUTE/OBU 20 may be necessary in case of particular configurations, corresponding to step 109 of the method in the second set of steps referring to configuration of the OBU 20.
The ECS/server 10 needs to communicate with a Diagnostics Configuration Server (CDCS), not represented graphically, in order to provide valid authentication tokens which will be used by the CUTE/OBU 20 in all POST Request_i it makes to the ECS/server 10. The CDCS generates, via authentication process, tokens which have to be used for subsequent "/authenticate" POST Request_i to the ECS/server's 10 (API) endpoints. The tokens are transmitted via an Authorization attribute in the HTTP header by using "Token" as authentication scheme:
Authorization: Token xxx
This header shall be present on all the subsequent requests sent by the CUTE/OBU 20.
In case of the second set of steps of the method for the new software update, the verification method carried out in step 106 may be based on the CRC Cyclical Redundancy Check code.
In case of the third set of steps of the method for the new software update, in some cases, depending on the type of new software update, it may be necessary that the method include several sub-steps in steps 105 and 105', that is sequences of GET_i swupdate and Response_i swupdate until the software is downloaded.
The diagram in Fig.4 illustrates the third steps of the method corresponding to the case when there is a new software available. The update of the software is made using the Over the Air (OTA) standard for the transmission and reception of application-related information in a wireless communications system.
When a new software is available, the CUTE/OBU 20 is informed by the ECS/server 10 in step 103 of the method by Response_j to the request software update in the next step of the method (104) through "/diaginfo" POST Request_j+1.
The CUTE/OBU 20 is informed in the ECS/server status 10 code what type of software should be updated and will download the appropriate file. In this respect, the server should support HTTP Partial Content for these files and the serial number of the CUTE/OBU 20 must be present in the request header, as follows:

Key Value Description

SerialNumber XXXXXXXXXXXXXXXXXXXXXXX The serial number of the CUTE/OBU 20, 32 characters long

The CUTE/OBU 20 firstly perform a HEAD request in step 104 in order to get exclusively the response header information. This is mainly done in order to get the file size. The response header should also contain the following information:

Key	Value	Description
SW Version	xx.yy.zz	The version of the new. Uses the Software version format
SWReleaseDate	dd/mm/yyyy	The software release date. Uses the Software release date format
CRC16	FFFF	The CRC of the file. Two Bytes hexadecimal value

The CUTE/OBU 20 performs one or several GET requests in step 105 of the method in order to download the files. Fig.5 illustrates a typical message GET /swupdate and its corresponding response from the ECS/Server 10.
After the download is complete, in step 106 of the method, the CUTE/OBU 20 makes a verification using preferably the method Cyclic Redundancy Check (CRC). A positive result will contain the message "CRC OK, therefore the CUTE/OBU 20 informs the ECS/server 10 in step 107 in the "/status" POST Request message that the update was successful.
If the result is negative, the ECS/server 10 may ask the CUTE/OBU 20 to perform the software update by repeating the steps 103-106 of the method.
It is necessary to restart CUTE/OBU 20 in order to run the new software. This is done in step 109 of the method, whereas in step 110 of the method CUTE/OBU 20 informs the ECS/server 10 on the new running software version.
In order to properly work the method of the invention, the second objective of the invention is to provide for an OBU 20 whose configurations serve the purpose of the method. For this purpose, the OBU is configured as follows:

to send to the server 10 repetitive sequence of messages of request Request_i, the type of data exchanged being chosen by the OBU 20 between options defined in the Application Programming Interface (API) endpoints of the server 10:
- data for the purpose of authentication ("/authenticate");
- data for the purpose of collection and sending of data regarding the vehicle ("/diaginfo");
- data for the purpose of informing the server 10 on the status of the OBU 20 ("/status");
- data for the purpose of configuration of the OBU 20 according to the needs of the server 10 ("/config") and
- data for the purpose of update of the software of the OBU 20 ("/swupdate).
to receive from the server 10 for each messages of request Request_i a Response_l of the same type of data exchanged as the Request_i ;
to apply the following format to the messages the header:
"Content-Type: application/json" according to HTTP standard and a payload encoded using JSON and UTF-8 comprising mandatory parameters and optional parameters defined by the server; said parameters being parent parameters and child parameters; when one of the child parameters is mandatory inside a parent object which is optional, a selection must take place between two possibilities: either the optional parent parameter is not selected at all, or it is selected along with all mandatory child parameters.
to receive from the server 10 SMSs having the following format:
<SMS_SerialNumber>: <SMS_ServerPassphrase>, where < SMS_SerialNumber> is a 10 digit number from the [0:9] range and where the SMS is valid if this number is equal to the Serial Number of the OBU (20); where < SMS_ServerPassphrase> is a 15 ASCII character passphrase or a 20 ASCII character command and where the Server Passphrase default value is "Connect to Server"
to receive configuration messages from the server 10;
to download software updates from the server 10;
to inform the server 10 in "/status" type of messages of the actual status of the configuration, software version and errors during functioning.

The OBU 20 according to the present invention is more robust as compared to the OBUs from the state of art because the majority of the errors can be resolved as a consequence of new software update or new configuration.
The OBU 20 according to the invention is more versatile, that is it more adaptable to the needs of the server, as a result of numerous configurations and software updates that are provided by the method.
In order to work the method of the invention using the OBU 20 of the invention, a computer program is provided as a third objective of the invention executed on at least one processor of the OBU 20 in order to configure said OBU 20 to carry out the steps of the method.
The vehicle diagnostic data is normalized in order to have a standard format for all vehicles.
The normalized data is sent such that it will be decoded and interpreted by the server. This relives the OBU of large tables in flash memory used to decode and interpret the data, as well as processing time to do this.
The server can inform the OBUs to make specific requests (e.g. configuration and software update). However, the server does not have to wait to receive a data upload from the OBU. It can send an SMS which triggers an empty data upload, which speeds up the process.
The server can configure differently each OBU device according to specific customer needs. Certain types of vehicles also need specific configuration like the ones with smart alternators which need different power threshold and timings. Among many other parameters, the OBU can configure exactly what diagnostic information is sent to the server, and it can define events for which to send this data. The events are triggered by a parameter which exceeds a value specified by the configuration.
The OBU can also send additional data (e.g. GNSS position and acceleration) beyond vehicle diagnostics by encoding it in a way that is similar to the vehicle diagnostics data. It can also send eco-driving information based on the vehicle diagnostics data.
The OBU can send any kind of debugging information along with specific software status for special procedures (i.e. configuration and software update) to the server.
The OBU software can be update over the Air using the HTTP partial Content protocol.
List of references in the drawings:

10- Server; End Customer Server (ECS)
20- OBU; CUTE
30- Vehicle
40- HTTP connection / Communication channel between ECS/Server 10 and CUTE/OBU 20
50- Base station
60- Internet cloud

Claims

Method of communication between a server (10) on one side and a plurality of On-Board-Units (20), OBUs, on the other side for use in the automotive field, wherein each OBU (20) is being installed in a different vehicle (30) and identified by a unique Serial Number, and wherein the communication is taking place within a mobile communication system, characterized in that:
- the communication between each OBU (20) and the server (10) takes place over an HTTP connection (40) based on a specific format of communication messages comprising mandatory and optional parameters defined by the server, and wherein at least the following steps are performed:
- for the communication to take place, one or several messages of request Request_i are repetitively made at a preconfigured times by the OBU (20) to the server (10) when the OBU (20) is in an activated state;

- specific messages of response Response_i triggered by the server (10) are sent to the OBU (20).
Method according to claim 1, wherein the OBU (20) sends the repetitive messages of Request_i at the preconfigured times to update the server (10) on activity data regarding the vehicle (30), wherein the activity data is collected at predefined regular intervals of time, wherein the collected data sent to the sever (20) are a normalized raw data, wherein at least two OBUs use raw data that express a physical quantity on the basis of different units and the normalized raw data are based on the same unit.
Method of communication according to any of the preceding claims, wherein each time the OBU (20) sends the Request_i, the server (10) sends the Response_i to the OBU (20) with a server status parameter corresponding to at least one instructing action to be carried out by the OBU (20).
Method according to claims 2 and 3, wherein depending on the server status parameter, the instructing actions to be chosen by the OBU (20) are:
- no action required and continuation of collecting the daily activity data at the preconfigured times regarding the vehicle (30) by the OBU (20) and sending the same to the server (10);

- a configuration change of the OBU (20) according to the needs of the server (10);

- a software update of the OBU (20) from the server (10).
Method according to any of the preceding claims, wherein an additional communication between the respective OBU (20) and the server (10) is triggered by the server (10) by sending to the OBU (20) a wakeup message over an auxiliary connection, different from the HTTP connection (40), in particular when the server (10) has any new instructions for the OBU (20).
Method according to claim 5, wherein the server (10) triggers the wakeup message via a mobile communication system, when the OBU (20) has gone into a sleep mode, and in particular when the OBU (20) is no longer sending the repetitive messages of the Request_i to the server (10) at the pre-configured times, and/or when the server has an immediate instructing action for the OBU (20).
Method according to claims 5 and 6, wherein the auxiliary connection is established when the wakeup message contains the valid Serial Number matching the corresponding OBU (20), and when a server Passphrase (an ASCII command instruction) contained in the wakeup message is set to a predefined default status parameter, and wherein a forced event is triggered based on the server Passphrase.
Method of communication according to any of the preceding claims, wherein the OBU (20) is a Control Unit for Telematics with Enhanced Diagnostics function, CUTE, which performs the remote diagnostics of a vehicle (30), and wherein the server (10) is an End Customer Server, ECS, which performs the gathering and processing of the diagnosed remote information.
Method according to claim 8, wherein the CUTE/OBU (20) provides a status to the ECS/server (10) containing information about its current configuration, its current software version, and/or the functioning status of the most recent configuration or software update.
Method according to claim 9, wherein the ECS/server (10) initiates a new software update for the CUTE/OBU (20), if the status provides a notification of errors in the functioning of the current software version.
Method according to any of the preceding claims, wherein the ECS/server (10) communicates with a Diagnostics Configuration Server, CDCS, to obtain valid authentication tokens to be used by the CUTE/OBU (20) for all POST requests Request_i sent to the ECS/server (10).
On-board unit, OBU (20), comprising at least one processor and a memory, characterized in that the OBU (20) is adapted to perform the steps of a method according to any of the claims 1 to 11 that concern the OBU (20), in particular when the OBU (20) is in an activated state.
Computer program being stored on a physical data carrier, wherein the computer program is designed for being performed on a computer, in particular on an OBU (20), for making the computer execute a method, wherein the computer program comprises instructions for performing steps of a method according to any of claims 1 to 11.