METHOD FOR DETERMINING A SUITABLE TIME FOR TRANSMITTING DATA PACKETS FROM A BACKEND TO AT LEAST A FIRST CONTROL UNIT OF A MOTOR VEHICLE

Description

[0001] The invention relates to methods for transmitting data packets from a backend to at least one first control device of a motor vehicle according to the preamble of patent claim 1.

[0002] Current vehicles or motor vehicles have numerous networked control devices or control units that exchange data with a vehicle backend, whereby a distinction can be made between two types of functionalities.

[0003] On the one hand, such an exchange can be "offboard-triggered," meaning that the exchange is initiated outside the vehicle. The initial data transmission for implementing the corresponding functionalities takes place from the backend to the vehicle. The overall process typically corresponds to a "request / response pattern," in which the backend sends a data packet to the vehicle. An example of a "request" would be a command to lock the vehicle, and the vehicle subsequently confirms successful processing of the data packet. An example of a "response" would be a confirmation: "Vehicle successfully locked." The customer initiates these functionalities not in / on the vehicle itself, but via a remote interface, such as a smartphone app, correspondingly "offboard."

[0004] On the other hand, such an exchange can be "onboard-triggered," meaning that the exchange is initiated within the vehicle. The initial data transmission for implementing the corresponding functionalities takes place from the vehicle to the backend. The overall process usually also corresponds to a "request / response pattern," in which the vehicle sends a data packet to the backend. Another example of a "request" would be a command to update status data such as an ignition change or the locking status, with the backend subsequently confirming the successful processing of the data packet to the vehicle (response). These functionalities are initiated either by the customer in / on the vehicle, for example, when the customer unlocks the vehicle, or by the vehicle itself, for example, when the battery level drops, correspondingly "onboard."

[0005] The backend typically does not communicate directly with the control unit, which processes the data packet in the vehicle, but rather via a so-called telecommunications unit (TCU) equipped with a cellular module. While the TCU ensures a secure connection to the backend, the protocols used do not guarantee successful transmission or delivery of the data packet, at least not at the application level. Furthermore, messages can only be received by the TCU if it is reachable. Thus, given the current state of technology, it is possible for a data packet to be lost along the communication path, both on the way from the backend to the control unit and in the opposite direction.

[0006] Due to external influences, it is possible that data packets cannot be delivered to the vehicle in the case of offboard-triggered functionalities, such as a lack of or poor cellular connection. Nevertheless, there are data packets that must be delivered to a vehicle for the successful provision of various offboard-triggered customer functionalities. Depending on the customer functionality, however, the data packets do not necessarily have to be delivered immediately.

[0007] JP 2007 074017 A discloses a remote control system configured to properly execute the application of remote control to vehicle devices. In the remote control system, in which the remote control is applied to an on-board power supply, execution is performed by requesting a vehicle to remotely control the on-board device via a central control unit from an operating terminal operated by the vehicle user.

[0008] US Pat. No. 9,179,488 B2 already discloses a method for restoring a cellular connection between a vehicle telematics unit and a wireless carrier system. This method comprises detecting a loss of the cellular connection between a vehicle telematics unit and a wireless carrier system and accessing a technology ordering table (TOT) that ranks a plurality of radio access technologies (RATs) according to desirability, which in turn are capable of use with the vehicle telematics unit. Likewise, the method attempts to restore the cellular connection, in particular through various method steps.

[0009] US 2019 / 0141023 A1 discloses a method for configuring access to a vehicle network from a mobile device. In the event of an error, a corresponding signaling sequence is restarted.

[0010] US 2015 / 0133108 A1 discloses a method for off-board control of a vehicle's telematics unit via a backend. Resending a request is briefly discussed without further explanation.

[0011] The object of the invention is to provide a method in which data packets transmitted to the vehicle but not delivered are retransmitted to the vehicle at a suitable time so that the data packets are more likely to be received by the vehicle.

[0012] This object is achieved by a method having the features of patent claim 1. Advantageous embodiments with expedient further developments of the invention are specified in the remaining patent claims.

[0013] The invention relates to a method for determining a suitable time for transmitting data packets from a backend to at least one first control device of a vehicle, in particular a motor vehicle, in particular a passenger car, for controlling at least one functionality of the at least one control device. Data packets are transmitted and received between the backend and the at least one control device, with the initiation of the transmission being triggered offboard and / or onboard. It is also possible to transmit all data packets to different control devices for controlling different functionalities, with the transmission structure being prioritized, for example.

[0014] To achieve the object of the invention, the invention provides that, upon an offboard-triggered transmission of at least one data packet to the first control device, a timer is triggered, in which timer confirmation information regarding the receipt of the transmitted offboard-triggered data packet by the backend is awaited. Upon receipt of the confirmation information, the control of the functionality is confirmed, and if the confirmation information is not received, the data packet is temporarily stored in a buffer of the backend for future transmission. Upon an onboard-triggered transmission of further data packets from the same or another control device to the backend, the temporarily stored data packets are retransmitted to the first control device.In particular, the timer is intended to ensure that, from the backend's perspective, messages that were not delivered to the vehicle or data packets that were not transmitted to the respective control unit are resent / transmitted at an appropriate time. The timer detects that a message was most likely not delivered. Retransmission at an appropriate time is enabled via the onboard-triggered message and the buffer.

[0015] The solution for determining a suitable time for resending data packets in the case of offboard-triggered functionalities is implemented with the aid of the onboard-triggered functionalities and under the assumption that communication between the backend and the vehicle takes place via a request / response pattern and that the vehicle can handle receiving the same data packets multiple times. In other words, the onboard-triggered functionality triggers a new attempt to transmit the data packets that were not transmitted in the case of the failed offboard-triggered functionality. If the response in the case of an offboard-triggered functionality is missing for a certain period of time or after the timer has expired, the backend must assume that the corresponding data packet has not reached the vehicle or the control device.The backend must therefore temporarily store the data packet intended for the vehicle or for the control device.

[0016] The appropriate time or trigger for resending or retransmitting the data packet is then the successful receipt of data packets that the vehicle or the respective control units send to the backend as part of an onboard-triggered functionality. The transmission of these data packets is triggered by the vehicle or the respective control units themselves and thus independently of the offboard-triggered functionality, for example, when the customer unlocks the vehicle or changes the ignition, and usually occurs in a different context than the offboard-triggered functionality.The receipt of a data packet from the vehicle or the respective control devices justifies the assumption that the vehicle or the control devices is / are accessible again, and thus data packets sent from the backend are also received with a very high probability. This means that the probability of a single transmission without a query is lower than that of the method according to the invention, since at least one further transmission is performed here.

[0017] In an advantageous embodiment of the invention, a check is performed to determine whether the retransmitted data packets are necessary. This means that certain functionalities are checked in the cache for their necessity at the time the onboard-triggered functionality appears. For example, securing a lock is no longer necessary after entering the car, which means this can be deleted from the cache. To ensure security, for example, every function that is not performed can be logged and saved for further processing, thus requiring less storage space and RAM.

[0018] In a further advantageous embodiment of the invention, the buffer is deleted after a successful onboard-triggered transmission. The deletion of the buffer can be performed either as a direct consequence of the onboard-triggered functionality or as a delayed consequence, with the deletion specified by the OEM. In particular, vehicle safety should be prioritized here.

[0019] A further advantageous embodiment of the invention is one in which, in the event of unconfirmed transmissions of offboard-triggered data packets, information about this is transmitted to a data recipient. This is advantageous due to the security precaution at the application level, as a user of the application receives a warning as soon as the backend receives confirmation information. This can lead to greater security for various functionalities, for example, if the vehicle is not locked.

[0020] Finally, an advantageous embodiment of the invention provides that after a confirmed onboard-triggered transmission of data packets, a second timer and / or further timers are triggered, in which the backend again awaits confirmation information about the receipt of the previously buffered data packet of the offboard-triggered transmission. If the data packet is not received again, a signal is generated to trigger an error message. The error message confirms, with a certain degree of probability, a possible interruption of an interface between the backend and the control device and alerts the user or the OEM that a possible physical connection(s) or other components is / are defective.

[0021] This invention is in the field of telematics and describes a method which allows messages which, from the perspective of a vehicle backend, have not been delivered to the vehicle to be sent to the vehicle again at a suitable time. Further advantages, features and details of the invention will become apparent from the following description of a preferred embodiment and from the drawing. The features and combinations of features mentioned above in the description as well as the features and combinations of features mentioned below in the description of the figures and / or shown alone in the single figure can be used not only in the respective combination specified, but also in other combinations or on their own, without departing from the scope of the invention.

[0022] The single figure (Fig.) shows a schematic diagram illustrating a method according to the invention. In the figures, identical and functionally equivalent elements are provided with the same reference numerals.

[0023] The single figure (Fig.) shows an example of the application of the method according to the invention, in which a suitable time for transmitting data packets 10 from a backend 12 to at least one first control device 14a of a vehicle 16, in particular a motor vehicle, for controlling at least one functionality of the at least one control device 14a is determined. The data packets 10 are transmitted and received between the backend 12 and the at least one control device 14a, wherein the initiation of the transmission is triggered offboard B1 and / or onboard B2.Upon an offboard-triggered B1 transmission of at least one data packet 10 to the first control device 14a, a timer T is triggered, during which confirmation information 18 regarding the receipt of the transmitted offboard-triggered B1 data packet 10 by the backend 12 is awaited. Upon receipt of the confirmation information 18, the control of the functionality is confirmed. If the confirmation information 18 is not received, and thus if non-confirmation information 28 is transmitted, the data packet 10 is temporarily stored in a buffer 20 of the backend 12 for future transmission. The non-confirmation information 28 from the vehicle 16 to the backend 12 is, in particular, the expiration of the timer T, which can be forwarded to other entities.Finally, the buffered data packets 10 are retransmitted to the at least one control device 14a during an onboard-triggered B2 transmission of further data packets 10b.

[0024] The sole figure (Fig.) uses an example in which a customer / user 22 wishes to configure a functionality represented as pre-conditioning of his vehicle 16, which is designed as an electric vehicle, via the OEM's smartphone app 26 in such a way that the pre-conditioning is activated in the vehicle 16 on a specified afternoon at 2 p.m., whereby this functionality is transmitted via an offboard-triggered B1 transmission of data packets 10. For the pre-conditioning, a pre-conditioning command 24 is transmitted via the backend 12 to the vehicle 16. First, a request data packet 10a is sent to the backend 12, then this data packet 10, designed as a command data packet, is sent from the backend 12 to the vehicle 16 and / or the control device 14a.In other words, the data packets 10, 10a differ in that the command data packet or data packet 10 applies between vehicle 16 and backend 12 and the data packet 10a applies between backend 12 and customer / user 22.

[0025] As soon as the customer / user 22 configures a desired activation time in the smartphone app 26, the backend 12 sends a corresponding data packet 10 with a pre-conditioning command 24 for configuring the pre-conditioning to the vehicle 16, which contains, among other things, the activation time. If the backend 12 does not receive the expected confirmation information 18 or a "response" to the sent data packet 10 within a certain period of time or within the timer T, it can be assumed that the data packet 10 has not reached the vehicle 16 or the control device 14a, and the pre-conditioning 24 has not been configured according to the customer's request.

[0026] Instead of sending the data packet 10 to the vehicle 16 or to the control device 14a at cyclical intervals or having the customer / user 22 configure the activation time again, the backend 12, according to the present method, waits until it receives another data packet 10b from the vehicle 16, which was sent as part of an onboard-triggered B2 functionality, for example, when the vehicle 16 connected for charging sends a new charge state to the backend 12. This data packet 10b, which is not related to the pre-conditioning 24, thus triggers a repetition of the buffered data packet 10, which is very likely to be received by the vehicle 16 or by the control device 14a and thus leads to a configuration of the pre-conditioning 24 in the vehicle 16 and corresponding confirmation information 18 to the backend 12.

Claims

1. Method for determining a suitable time for transmitting data packets (10) from a backend (12) to at least one first control device (14a) of a motor vehicle (16) for controlling at least one functionality of the at least one control device (14a), in which data packets (10) are transmitted and received between the backend (12) and the at least one control device (14a), wherein the transmission is triggered offboard (B1) and / or onboard (B2), characterized in that an offboard-triggered (B1) transmission of at least one data packet (10) to the first control device (14a) results in a timer (T) being initiated, in which confirmation information (18) about the reception of the at least one transmitted and offboard-triggered (B1) data packet (10) is awaited by the backend (12), wherein reception of the confirmation information (18) results in the control of the functionality being confirmed and non-reception of the confirmation information (18) results in the at least one data packet (10) being temporarily stored in a cache (20) of the backend (12) for future transmission, and the at least one temporarily stored data packet (10) is retransmitted to the control device (14a) in the event of an onboard-triggered (B2) transmission of further data packets (10b) to the backend (12).

2. Method according to claim 1, characterized in that a check is carried out as to the necessity of the at least one retransmitted data packet (10).

3. Method according to either of the preceding claims 1 and 2, characterized in that the cache (20) is deleted after a successful onboard-triggered (B2) transmission of data packets (10b).

4. Method according to any of the preceding claims, characterized in that in the event of unconfirmed offboard-triggered (B1) transmissions of data packets (10), non-confirmation information (28) is transmitted to a data receiver (30).

5. Method according to any of the preceding claims 2 to 4, characterized in that after a confirmed onboard-triggered (B2) transmissions of data packets (10b), a further second timer is initiated, in which the confirmation information (18) about the reception of the previously temporarily stored data packet (10) of the offboard-triggered (B1) transmission is again awaited by the backend (12), and, if it is not received again, a signal for initiating an error message is generated.