DE102024114877A1 - Procedures for the transmission of driving data and driving data management arrangement - Google Patents

Abstract

The invention relates to a method for transmitting driving data 11 with a vehicle 2, wherein the vehicle 2 generates the driving data 11, with a mobile device 3, wherein the mobile device 3 is connectable to and/or connected to the vehicle 2 via a first data connection 5, with a server 4, wherein the server 4 is connectable to and/or connected to the mobile device 3 via a second data connection 6, wherein the vehicle 2 encodes and signs the driving data 11 in order to form a data packet 15 from the driving data 11, wherein the driving data 11 is transmitted as the data packet 15 via the first data connection 5 to the mobile device 3 and wherein the driving data 11 is transmitted via the second data connection 6 to the server 4, wherein the mobile device 3 has a digital key 7, wherein a communication channel 9 is established between the mobile device 3 and the vehicle 2 based on the digital key 7, wherein the driving data 11 is transmitted as the data packet 15 via the Communication channel 9 is used as the first data connection 5.

Description

The invention relates to a method for transmitting driving data with a vehicle for generating driving data and a driving data management arrangement for carrying out the method.

The recording of driving data during a journey is typically subject to data protection restrictions. Therefore, it is only permitted to collect and use driving data in exceptional cases. One such exception is the management of vehicle fleets, where a user can explicitly consent to the transfer of driving data. The transfer of driving data can, for example, include data relevant for billing purposes that is collected during a journey.

The printed matter WO 2011/053357 A1 Disclosing a process for providing pay-as-you-drive (PAYD) insurance using information collected by a vehicle access control system, the process involves collecting trip information. In various embodiments, this trip information includes, for example, the vehicle's speed and acceleration profile, as well as information about the vehicle's location. In various embodiments, the trip information is reported back from the access control system of the vehicle used for the trip to a central server. In various embodiments, the trip information is reported back to the central server, for example, via the long-range wireless communication interface of a wireless communication device connected to the vehicle access control system.

The invention is based on the objective of proposing a method for transmitting driving data which offers high data security in conjunction with strong control of data transmission by a user.

This problem is solved by a method for transmitting driving data with the features of claim 1 and by a driving data management arrangement with the features of claim 9.

Preferred or advantageous embodiments of the invention will become apparent from the dependent claims, the following description and/or the accompanying figures.

According to the invention, a method for transmitting driving data is proposed. The method includes a vehicle that generates the driving data. The vehicle can be, for example, a passenger car, commercial vehicle, truck, bus, etc. In particular, the driving data relates to a journey or a usage interval of the vehicle by a user. The driving data describes, for example, measurement data of the journey and/or the vehicle during the journey.

The method uses a mobile device, whereby the vehicle is connected to and/or connectable to the mobile device via an initial data connection. This initial data connection can be temporary or permanent. The mobile device can be, for example, a mobile phone, smartphone, PDA, tablet, wearable, smartwatch, etc.

The process uses a server, which in this context primarily represents a cloud service that provides server services. The server can therefore also be implemented as a server farm. The server is connected to, and/or connectable to, the mobile device via a second data connection. This second data connection can be temporary or permanent. Specifically, this second data connection uses the internet.

The method provides that the vehicle encodes and signs the driving data, thereby creating a data packet containing the encoded and signed driving data. Preferably, a single data packet is created from all the driving data of the trip. If the driving data is very large, several sub-data packets can be created as the single data packet, with each sub-data packet being larger than 5 MB, preferably larger than 10 MB, and particularly larger than 20 MB. The encryption is implemented, in particular, as end-to-end encryption (E2EE) and/or as content encryption.

The driving data is transmitted as a data packet from the vehicle to the mobile device via the first data connection. The data packet is then stored on the mobile device. The driving data – particularly in encoded/signed form (as a data packet) or in decoded form – is transmitted to the server via the second data connection.

It is proposed that the mobile device possess a digital key. The digital key is located on the mobile device, specifically stored there. The digital key is specifically designed as a certificate.

The mobile device can include a wallet or a secure element, with the digital key stored in the wallet or the secure element. The mobile device with the digital key is specifically designed as a mobile unit that, as intended, is removed from the vehicle after use. The vehicle has a keying device, which is located within the vehicle. The keying device is preferably designed as a software module. For example, the vehicle has a digital data processing device on which the keying device is installed as an executable software module.

The digital key and the key device form a key system, which is designed in accordance with CCC (Car Connectivity Consortium) specifications, specifically at least Release 3.0. The carrier device and the vehicle feature a software structure for implementing the key system, in particular an ecosystem consisting of a number of software solutions that organize the activities and transactions of the actors. The key system is designed in accordance with CCC specifications for key management and the provision of key-based services, such as secure communication, key management with user profile management, and/or key tracking.

The mobile device and the keying device are configured to establish a communication channel between the mobile device and the keying device. This communication channel facilitates communication between the vehicle and the mobile device containing the digital key. The communication channel is preferably a standardized communication channel compliant with CCC specifications, which is established, authorized, authenticated, and/or verified based on the digital key. The communication channel establishes a secure and/or protected connection. The communication channel is established wirelessly using BLE, UWB, and/or NFC. In particular, the communication channel features point-to-point or transport encryption.

The mobile device with the digital key can control additional vehicle functions via the communication channel. For this purpose, control data, in particular commands, are transmitted to the vehicle via the communication channel to, for example, activate these additional vehicle functions or provide them with parameters. These additional vehicle functions include, in particular, unlocking or starting the vehicle.

It is proposed that the driving data be transmitted as a data packet via the communication channel as the first data connection. This method has the advantage that the data packet can be transmitted between the vehicle and the mobile device with the highest level of security. Furthermore, authentication and/or authorization for receiving the data packet is guaranteed and/or ensured through the use of a digital key. Because the data packet is encoded and signed, data security is also very high. The driving data travels along the data path to the server through the mobile device, giving the user at least the option to interrupt the data path, thus providing a minimum level of control over the driving data. Optionally, the mobile device can have an app that allows control over the driving data, thereby giving the user maximum control over the driving data.

During priority training, the transmission of driving data as a data packet to the mobile device is authorized by the digital key. Specifically, it is ensured that the data packet is only transmitted if the transmission is permitted by the digital key.

In a preferred embodiment of the invention, the vehicle has a user profile management device, wherein at least one user profile, preferably several user profiles for the vehicle, are stored on the user profile management device. The user profile management device is particularly designed as a software module which is arranged to run on one or more digital data processing devices in the vehicle.

The digital key is linked to the associated user profile. Specifically, the digital key can be used to activate the associated user profile in the user profile management system. User profile activation can occur, for example, when unlocking or starting the vehicle with the digital key.

Preferably, the vehicle has a driving data app for recording driving data. The driving data app can be designed as a software module that is executable on one or more of the digital data processing devices in the vehicle. It is intended that the digital key, via the user profile, The driving data app is automatically launched, and the transmission of driving data as a data package to the mobile device is authorized. Key supplement data can be transmitted to the vehicle, particularly the key unit, via the digital key. This key supplement data controls and, in particular, initiates the launch of the driving data app. Thus, unlocking and/or starting the vehicle is linked to launching the driving data app, ensuring reliable recording of driving data. Furthermore, using the digital key authorizes the transmission of driving data as a data package to the mobile device. In this way, a user can operate the vehicle during a journey, with driving data recording and transmission occurring automatically in the background.

In particular, the server is designed to generate the digital key (e.g., as a friend key), with the key supplement data for starting the driving data app forming part of the digital key.

In a first embodiment of the invention, the driving data is encoded in the vehicle using a public terminal key and signed using a private vehicle key. The mobile device is configured to decode the data packet with a private terminal key and verify the signature with a public vehicle key. The decoded driving data, as well as the verified driving data, is then stored on the mobile device. The driving data is subsequently transmitted to the server via the second data connection. This configuration has the advantage that the user has access to the unencrypted and/or decoded driving data on the mobile device for unrestricted viewing.

In a second embodiment of the invention, the driving data is encoded in the vehicle using a public server key and signed using a private vehicle key. The mobile device forwards the driving data as a data packet to the server. Specifically, the mobile device does not perform any decoding or signature verification steps. The server is configured to decode the data packet using a private server key and to verify the signature using a public vehicle key, so that the server then has access to the decoded driving data with a verified signature. This configuration has the advantage that the driving data is available to the server in its unaltered form.

In a preferred configuration, the private and public endpoint keys (as an endpoint key pair), the private and public vehicle keys (as a vehicle key pair), and/or the private and public server keys (as a server key pair) are based on a Public Key Infrastructure (PKI). The principle of a PKI is based on asymmetric encryption. With asymmetric encryption, a key pair is generated for everyone who wants to communicate using encryption. This key pair consists of a private (secret) and a public key. These keys are generated in such a way that a file encrypted with the public key can only be decrypted with the corresponding private key. Furthermore, it is possible to digitally sign a file with the same private key. The corresponding public key can then be used to verify whether the file has remained unchanged since it was signed.

In a preferred embodiment of the invention, the driving data is selected from a group comprising: vehicle odometer, vehicle control messages, vehicle tire pressure, state of charge, fuel gauge and other state of charge, fuel gauge and other vehicle states that are of interest for a fleet management/server.

In a preferred embodiment of the invention, it is configured as a server for fleet management, wherein the method, as previously described, is carried out with a large number of vehicles.

A further aspect of the invention is a vehicle data management arrangement configured to carry out the method. The vehicle data management arrangement comprises, in particular, the vehicle, the mobile device, and the server, which are configured to perform the method. In particular, the vehicle data management arrangement is configured as a fleet management arrangement.

Alternatively or additionally, the invention can be described as follows: When a user takes possession of a rental vehicle or a vehicle from a fleet, the data for each trip must normally be recorded and updated in the fleet management system to document the vehicle usage of each trip. This data includes, for example, mileage, damage, cleaning status, tire condition, etc. This data is usually recorded manually by the user by checking it on the vehicle's head unit or a key fob. However, there is no efficient digital way to transmit this data to the fleet management system.

The basic idea is to use the digital key ecosystem to store trip data and transmit this data back to the fleet management system/server that manages vehicle dispatch. Trip data includes, but is not limited to: vehicle odometer reading, vehicle control messages, tire pressure, charge level, fuel level, and other vehicle statuses relevant to the fleet management system/server. Security: Security should be guaranteed by the digital key Public Key Infrastructure (PKI). A private/public key pair (vehicle key pair) is issued for encryption for each vehicle. The fleet management system/server should be able to validate the vehicle's identity and decrypt the trip data from the vehicle. Alternatively, the trip data can be encrypted by the vehicle and only decrypted by the server. Data generation and transmission: Trip data generation could be triggered by the customer in the native digital key app or automatically at the end of the trip. The trip data is generated and encrypted by the vehicle and transmitted via secure digital key communication channels. The secure communication channel refers to the NFC/Bluetooth channels used for digital key communication between the vehicle and the digital key device. The device should be able to subsequently transmit the data file via the customer interface of the rental/fleet management system, for example, in a format compatible with a third-party app or the digital key's native app. Additional data can be manually created by the user and sent to the fleet management system/server.

In a potential application, the user selects a vehicle from the fleet. At the end of the trip, the user generates the trip data using the digital key's native app. This command to generate the trip data is sent to the vehicle via the digital key's communication channel. The vehicle receives this command and generates the trip data. The vehicle encrypts the data and sends it back to the digital key device via the same channel. The user then submits the trip data via the native app. The Fleet Management Server validates the received data and processes the trip.

• 1 ein schematisches Blockdiagramm von einer Datenübertragungsanordnung als ein erstes Ausführungsbeispiel der Erfindung;
• 2 ein schematisches Blockdiagramm von einer Datenübertragungsanordnung als ein zweites Ausführungsbeispiel der Erfindung.

Further features, advantages, and effects of the invention will become apparent from the following description of preferred embodiments of the invention. These include:

• 1 a schematic block diagram of a data transmission arrangement as a first embodiment of the invention;
• 2 a schematic block diagram of a data transmission arrangement as a second embodiment of the invention.

Corresponding or identical parts are each provided with the same reference symbols in the figures.

The 1 Figure 1 shows a schematic block diagram of a driving data management arrangement 1 as an embodiment of the invention and to illustrate an embodiment of the method.

The vehicle data management system comprises at least one vehicle 2. When configured as a fleet management system, the vehicle data management system 1 includes a plurality of vehicles 2 as a vehicle fleet; for example, it is connected and/or connectable to more than 100, preferably more than 500, vehicles 2 via data technology.

The vehicle data management system 1 comprises a mobile device 3 and a server 4. The mobile device 3 is connected to the vehicle 2 via a first data connection 5. Furthermore, the mobile device 3 is connected to the server 4 via a second data connection 6.

The mobile device 3 has a digital key 7, and the vehicle 2 has a key device 8. The digital key 7 and the key device 8 form a key system, which is designed in accordance with CCC specifications, specifically Release 3.0 or higher. The key system comprises the digital key 7 and the key device 8 and forms a communication channel 9, which is the standardized communication channel according to CCC specifications. The communication channel 9 is established wirelessly, in particular via UWB and/or BLE. The first data connection 5 is established via the communication channel 9.

Vehicle 2 is equipped with a driving data app 10, which is designed to collect driving data 11 during a journey of vehicle 2. The driving data 11 includes, in particular, billing-relevant data such as kilometers driven, but also speed, acceleration, energy consumption, etc. The driving data 11 can be recorded depending on the time and/or location (GPS-based).

It may be intended that the driving data app 10 is started manually by a user of vehicle 2. It is also possible that the driving The data app 10 is automatically started via the mobile device 3 with the digital key 7 when the communication channel 9 is established, for example to open and/or start the vehicle 2.

Furthermore, it is possible that the vehicle 2 has a user profile management device 12, wherein the user profile management device 12 has at least one user profile, and the user profile is data-technically linked to the digital key 7. In particular, the user profile belonging to the digital key 7 is loaded or activated in the user profile management device 12 by establishing the communication channel 9. It may be provided that the user profile contains the setting to start the driving data app 10.

The digital key 7 can be issued by the server 4 and can contain key supplement data, the key supplement data causing the driving data app 10 to be started either directly and/or via the user profile management facility 12.

The driving data 11 is encoded and signed in the vehicle 2. The encoding is performed using a public terminal key 13a, where the mobile terminal 3 has the corresponding private terminal key 13b. The terminal keys 13a and 13b form a terminal key pair.

The signing is performed using a private vehicle key 14a, whereby the mobile device 3 has a public vehicle key 14b, and the vehicle keys 14a and 14b form a vehicle key pair. The encryption and signing process creates a data packet 15. The data packet 15 contains the driving data 11 in encoded, specifically encrypted and signed, form. The encryption is specifically designed as end-to-end encryption (E2EE).

The data packet 5 is then transmitted to the mobile device 3 via the first data connection 5, i.e., communication channel 9. Using communication channel 9 ensures that the mobile device 3 is authorized to receive the data packet 15. The mobile device 3 decodes the data packet 15 and verifies its signature with the public vehicle key 14b, so that the driving data 11 is ultimately available in decoded form with a verified signature on the mobile device 3.

The driving data 11 is then transmitted via the second data connection 6 to server 4 for further processing. The second data connection 6 preferably uses transport encryption.

The process steps in vehicle 2 are implemented digitally via a digital data processing device, such as a computer, microcontroller, or cloud connection. Specifically, the key device 8, the user management device 12, the driving data app 10, and the modules for encrypting and signing the driving data 11 are implemented as software modules on the digital data processing device.

The decoding and verification of the signature are implemented on the mobile device 3 via corresponding software modules or apps, which are configured to run on the mobile device 3. Optionally, a further user app can be provided on the mobile device 3, through which the driving data 11 can be viewed, checked and/or edited. The embodiment in the 1 convinces through a high level of data security in the processing of driving data 11 in conjunction with a strong control option for data transmission by the user of the mobile device 3.

The 2 Figure 1 shows an alternative embodiment of the invention, wherein the driving data 11 are encrypted using a public server key 16a. Signing is again performed with the private vehicle key 14a. The server 4 comprises the private server key 16b and the public vehicle key 14b, wherein the server keys 16a and 16b together form a server key pair.

In the alternative in the 2 Data packet 15 is transmitted via the first data connection 5 as communication channel 9 to the mobile device 3. Here, however, it is in encoded and signed form. Optionally, the signature can be verified using the public vehicle key 14b, but decoding is not possible. Instead, data packet 15, containing the encoded driving data 11, is forwarded to server 4 via the second data connection 6. Server 4 decodes data packet 15 using the private server key and can verify the signature using the public vehicle key 14b.

This design has the advantage that the driving data 11 is always available unaltered on server 4; the user's control over the driving data 11 is limited to the authorized The handover to the mobile device 3 and the possibility of preventing the forwarding of data packet 15 to server 4 are also included. The key pairs are specifically designed as asymmetric key pairs in a PKI structure.

Reference symbol list

1

Driving data management arrangement

2

vehicle

3

mobile device

4

server

5

first data connection

6

second data connection

7

digital key

8

Key device

9

Communication channel

10

Driving data app

11

Driving data

12

User profile management setup

13a

public terminal key

13b

private device key

14a

private car key

14b

public vehicle key

15

Data package

16a

public server key

16b

private server key

QUOTES INCLUDED IN THE DESCRIPTION

This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions.

Cited patent literature

• WO 2011/053357 A1 [0003]

Claims (10)

Method for transmitting driving data (11) with a vehicle (2), wherein the vehicle (2) generates the driving data (11), with a mobile device (3), wherein the mobile device (3) is connectable to and/or connected to the vehicle (2) via a first data connection (5), with a server (4), wherein the server (4) is connectable to and/or connected to the mobile device (3) via a second data connection (6), whereby the vehicle (2) encodes and signs the driving data (11) to form a data packet (15) from the driving data (11), whereby the driving data (11) is transmitted as the data packet (15) to the mobile device (3) via the first data connection (5) and wherein the driving data (11) is transmitted to the server (4) via the second data connection (6), whereby the mobile device (3) has a digital key (7), wherein a communication channel exists between the mobile device (3) and the vehicle (2). (9) is established on the basis of the digital key (7), whereby the driving data (11) is transmitted as the data packet (15) via the communication channel (9) as the first data connection (5). Procedure according to Claim 1 , characterized in that the transmission of the driving data (11) as a data packet (15) to the mobile device (3) is authorized by the digital key (7). Procedure according to Claim 1 or 2 , characterized in that the vehicle (2) has a user profile management system (12) with at least one user profile, wherein the user profile is linked to the digital key (7), wherein the vehicle (2) has a driving data app (10) for recording the driving data (11), wherein the driving data app (10) is automatically started via the user profile by means of the digital key (7) and the transmission of the driving data (11) as the data package (15) to the mobile device (3) is authorized. Method according to one of the preceding claims, characterized in that the encoding of the driving data (11) in the vehicle (2) is carried out on the basis of a public terminal key (13a) and the signing on the basis of a private vehicle key (14a), wherein the mobile terminal (3) decodes the data packet (15) with a private terminal key (13b) and is checked via a public vehicle key (14b) in order to have access to the decoded driving data (11), wherein the decoded driving data (11) is transmitted to the server (4) via the second data connection (6). procedure according to one of the preceding Claims 1 until 3 , characterized in that the encoding of the driving data (11) in the vehicle (2) is carried out on the basis of a public server key (16a) and the signing is carried out on the basis of a private vehicle key (14a), wherein the mobile device (3) forwards the driving data (11) as the data packet (15) to the server (4), wherein the server (4) decodes the data packet (15) with a private server key (16b) and checks it via a public vehicle key (14b) in order to have access to the decoded driving data (11). Procedure according to one of the Claims 4 or 5 , characterized in that the private and public terminal key (13a,b) are configured as terminal key pairs and/or the private and public vehicle key (14a,b) as vehicle key pairs and/or the private and public server key (16a,b) as server key pairs are configured as PKI key pairs. Method according to one of the preceding claims, characterized in that the driving data (11) are selected from the group comprising: vehicle odometer, vehicle control messages, vehicle tire pressure, state of charge, fuel gauge and other charge states, fuel gauge. Method according to one of the preceding claims, characterized in that the server (4) is configured for fleet management and performs the method with a plurality of vehicles (2). Driving data management arrangement (1) for carrying out the method according to one of the preceding claims, characterized by the vehicle (2) for generating driving data, by the mobile device (3), wherein the vehicle (2) can be connected to the vehicle via the first data connection (5), by the server (4), wherein the server (4) can be connected to the mobile device (3) via the second data connection (6), wherein the vehicle (2) is configured to encode and sign the driving data (11) in order to form the data packet (15) from the driving data (11), wherein the driving data management arrangement (1) is configured to transmit the driving data (11) as the data packet (15) to the mobile device (3) via the first data connection (6) and to transmit the driving data (11) to the server (4) via the second data connection (6), wherein the mobile device (3) has a digital key (7), wherein a communication channel (9) is established between the mobile device (3) and the vehicle (2) based on of the digital key (7) for the transmission of the driving data (11) can be established as the data packet (15) via the communication channel (9) as the first data connection (5). Driving data management order (1) according to Claim 9 , characterized in that the vehicle data management arrangement (1) is designed as a fleet management arrangement.