EP3869471A1 - Procédé de communication comprenant un serveur et une pluralité d'unités embarquées et unité embarquée - Google Patents

Procédé de communication comprenant un serveur et une pluralité d'unités embarquées et unité embarquée Download PDF

Info

Publication number
EP3869471A1
EP3869471A1 EP20465509.6A EP20465509A EP3869471A1 EP 3869471 A1 EP3869471 A1 EP 3869471A1 EP 20465509 A EP20465509 A EP 20465509A EP 3869471 A1 EP3869471 A1 EP 3869471A1
Authority
EP
European Patent Office
Prior art keywords
obu
server
communication
request
cute
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP20465509.6A
Other languages
German (de)
English (en)
Inventor
Cristian - c/o Continental Automotive GmbH Bilcea
Sorin - c/o Continental Automotive GmbH Soare
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Continental Automotive Technologies GmbH
Original Assignee
Continental Automotive GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Continental Automotive GmbH filed Critical Continental Automotive GmbH
Priority to EP20465509.6A priority Critical patent/EP3869471A1/fr
Publication of EP3869471A1 publication Critical patent/EP3869471A1/fr
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808—Diagnosing performance data
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/06—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems
    • G07B15/063—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems using wireless information transmission between the vehicle and a fixed station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station

Definitions

  • the current invention is concerned with the automotive field.
  • 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.
  • OBUs On-Board-Units
  • 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 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.
  • 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).
  • OBD On-Board Diagnostics
  • RVD Remote Vehicle Diagnostics
  • HTTP Hypertext Transfer Protocol
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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 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.
  • 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.
  • the OBU is instructed to install a new configuration available at the server.
  • the new configuration refers to the parameters which define the way (e.g.
  • Another instructing action relates to a software update of the OBU from the server.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • CDCS Diagnostics Configuration Server
  • 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.
  • an On-board unit 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.
  • 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.
  • 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 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.
  • Request (generic), Request i or Request j or Request n and respectively Response (generic), Response i or Response j or Response n , with:
  • 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.
  • 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).
  • JSON Java Script Object Notation
  • UTF-8 Unicode Transformation Format
  • 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.
  • the server contains in its Application Programming Interface (API) endpoints several types of data exchanged corresponding to different purposes:
  • 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.
  • /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”.
  • 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.
  • 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.
  • 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.
  • LCP Low Cost Processor
  • each type of software update may receive a different server status code.
  • the OBU 20 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.
  • steps 102-108 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.
  • the server status code is set to "new software update” the following set of steps of the method are applied ( Fig. 4 ):
  • the OBU is a Control Unit for Telematics with Enhanced diagnostics function (in short CUTE)
  • 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.
  • the present invention is not limited to the CUTE and the ECS described in the preferred embodiment.
  • 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.
  • 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.
  • 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:
  • 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".
  • the OBU 20 software shall execute a "/diaginfo" POST Request i
  • 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.
  • 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.
  • 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.
  • step 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.
  • the type of message is no longer of "/diaginfo” type but of "/status” type indicating the error(s).
  • 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.
  • the verification method carried out in step 106 may be based on the CRC Cyclical Redundancy Check code.
  • the method 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.
  • OTA Over the Air
  • 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.
  • 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 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
  • 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.
  • the CUTE/OBU 20 makes a verification using preferably the method Cyclic Redundancy Check (CRC).
  • CRC Cyclic Redundancy Check
  • 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.
  • the ECS/server 10 may ask the CUTE/OBU 20 to perform the software update by repeating the steps 103-106 of the method.
  • the second objective of the invention is to provide for an OBU 20 whose configurations serve the purpose of the method.
  • the OBU is configured as follows:
  • 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.
  • 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.
  • specific requests e.g. configuration and software update
  • 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.
  • additional data e.g. GNSS position and acceleration
  • 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.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
EP20465509.6A 2020-02-24 2020-02-24 Procédé de communication comprenant un serveur et une pluralité d'unités embarquées et unité embarquée Pending EP3869471A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP20465509.6A EP3869471A1 (fr) 2020-02-24 2020-02-24 Procédé de communication comprenant un serveur et une pluralité d'unités embarquées et unité embarquée

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP20465509.6A EP3869471A1 (fr) 2020-02-24 2020-02-24 Procédé de communication comprenant un serveur et une pluralité d'unités embarquées et unité embarquée

Publications (1)

Publication Number Publication Date
EP3869471A1 true EP3869471A1 (fr) 2021-08-25

Family

ID=70110260

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20465509.6A Pending EP3869471A1 (fr) 2020-02-24 2020-02-24 Procédé de communication comprenant un serveur et une pluralité d'unités embarquées et unité embarquée

Country Status (1)

Country Link
EP (1) EP3869471A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1699031A1 (fr) * 2003-12-15 2006-09-06 Hitachi, Ltd. Procede de mise a jour des informations contenues dans un appareil de commande monte sur vehicule, systeme de communication de la mise a jour des informations, appareil de commande monte sur vehicule et station de base de gestion des informations
US20110112717A1 (en) * 2009-11-11 2011-05-12 Benjamin Resner Methods and Apparatus for Automatic Internet Logging and Social Comparison of Vehicular Driving Behavior
EP2381695A2 (fr) * 2008-12-24 2011-10-26 Doosan Infracore Co., Ltd. Système et procédé de télécommande d un engin de chantier pour commander la transmission-réception de données pendant que le moteur de l engin de chantier est arrêté
US20130104186A1 (en) * 2010-02-22 2013-04-25 Continental Automotive Gmbh System and method for preventing an attack on a networked vehicle

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1699031A1 (fr) * 2003-12-15 2006-09-06 Hitachi, Ltd. Procede de mise a jour des informations contenues dans un appareil de commande monte sur vehicule, systeme de communication de la mise a jour des informations, appareil de commande monte sur vehicule et station de base de gestion des informations
EP2381695A2 (fr) * 2008-12-24 2011-10-26 Doosan Infracore Co., Ltd. Système et procédé de télécommande d un engin de chantier pour commander la transmission-réception de données pendant que le moteur de l engin de chantier est arrêté
US20110112717A1 (en) * 2009-11-11 2011-05-12 Benjamin Resner Methods and Apparatus for Automatic Internet Logging and Social Comparison of Vehicular Driving Behavior
US20130104186A1 (en) * 2010-02-22 2013-04-25 Continental Automotive Gmbh System and method for preventing an attack on a networked vehicle

Similar Documents

Publication Publication Date Title
EP3726806B1 (fr) Procédé de commande à distance d'un véhicule sur la base d'un appareil intelligent
US11082421B2 (en) Bootstrap mechanism for endpoint devices
US9323546B2 (en) Targeted vehicle remote feature updates
CN108701039B (zh) 用于无线更新车辆的软件的方法和设备
CN104980490B (zh) 车辆远程信息处理数据交换
US20150281374A1 (en) Remote vehicle connection status
EP1860899B1 (fr) Station mobile, système et serveur pour la gestion d'une station mobile par liaison radio
JP6219301B2 (ja) テレマティックサービスを提供するためのシステムおよび対応する方法
US20040163008A1 (en) Remote system management and operation services in a computer network
US20140123124A1 (en) Cloud-based firmware distribution service
US20100100876A1 (en) Wireless device provisioning hardware tool
CN112040443A (zh) 多客户端ota升级处理方法及系统
JP2023090981A (ja) ゲートウェイ装置、車載ネットワークシステム及びファームウェア更新方法
CN115242825A (zh) 一种远程控制方法及装置
CN111866063B (zh) 一种工业物联网ai算法的在线更新系统、方法及装置
CN111638704A (zh) 远程唤醒车辆的方法、系统以及装置
CN106453629B (zh) 一种基于移动网络的汽车电子系统远程升级系统及其方法
CN113965904B (zh) 设备注册方法、装置和存储介质
EP3869471A1 (fr) Procédé de communication comprenant un serveur et une pluralité d'unités embarquées et unité embarquée
CN114884935A (zh) 数据升级方法、装置、电子设备和存储介质
CN113396600B (zh) 信息验证方法、装置、设备及存储介质
CN115903758A (zh) 远程诊断系统、方法、电子设备及存储介质
CN115052252A (zh) 一种ota升级方法、系统及装置
CN111434100B (zh) 用于与IoT设备进行数据收发的装置、方法及计算机可读存储介质
CN115315377A (zh) 车载信息处理装置、信息处理方法及服务器程序

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220225

RBV Designated contracting states (corrected)

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: CONTINENTAL AUTOMOTIVE TECHNOLOGIES GMBH

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20231108

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: CONTINENTAL AUTOMOTIVE TECHNOLOGIES GMBH