Data management method and device, vehicle-mounted equipment and terminal equipment

Abstract

The invention discloses a data management method and device, vehicle-mounted equipment and terminal equipment. The method can be applied to a vehicle-mounted controller. The vehicle-mounted controller receives a data analysis instruction sent by the first equipment, wherein the data analysis instruction comprises a data analysis category; the vehicle-mounted controller analyzes source data of the vehicle based on a data analysis category in the data analysis instruction to obtain a data analysis result; and the vehicle-mounted controller sends the data analysis result to the first equipment.

Description

Data management method and device, vehicle-mounted equipment and terminal equipment Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a data management method and apparatus, vehicle-mounted equipment, and terminal equipment. Background Art

[0002] The black box is a device installed on the vehicle with high damage resistance. The function of the black box is to record the vehicle's operating information.

[0003] In related technologies, the source data stored in the black box will be backed up to a cloud server, and the cloud server will analyze the source data according to a preset method and push the data analysis results to the user's terminal.

[0004] The solution provided by the related technology requires backing up the source data to a cloud server, which causes the risk of source data leakage.

[0005] Summary of the Invention

[0006] The present application provides a data management method and apparatus, vehicle-mounted equipment, and terminal equipment that can avoid the risk of source data leakage.

[0007] In a first aspect, the present application provides a data management method applied to a vehicle, the vehicle including an on-board controller, the method comprising: the on-board controller receiving a data analysis instruction sent by a first device, the data analysis instruction including a data analysis category; the on-board controller analyzing the source data of the vehicle based on the data analysis category in the data analysis instruction to obtain a data analysis result; the on-board controller sending the data analysis result to the first device.

[0008] The vehicles here include not only road vehicles but also other types of vehicles such as drones and aircraft. This application does not limit the form of vehicles.

[0009] In the data management method provided herein, the vehicle controller receives a data analysis instruction from a first device, performs data analysis based on the data analysis category in the data analysis instruction, and then feeds the data analysis results back to the first device. This process eliminates the need to back up the vehicle's source data to the cloud or perform data analysis in the cloud, thereby avoiding the risk of leaking the source data stored in the black box.

[0010] The data analysis category is used to indicate the target of data analysis or the function to be achieved by the vehicle controller, and different data analysis categories correspond to different targets or functions to be achieved.

[0011] Optionally, the method also includes: the on-board controller receives a data export instruction sent by the second device; the on-board controller performs identity authentication on the second device; when the identity authentication is passed, the on-board controller sends the source data of the vehicle to the second device according to the data export instruction.

[0012] In this implementation, the data in the black box can be exported with authorization. For example, in the event of an accident, data can be exported after being authenticated by the police. Due to the high level of data export, this application can use certificate authentication when performing identity authentication, unlike the identity key verification used for device access, to ensure data security. For example, the on-board controller issues a separate certificate for terminal devices with export permission. When authenticating the terminal device, authentication is performed based on the certificate issued to the terminal device.

[0013] In a possible implementation of the present application, all source data are managed at one level, that is, as long as the identity authentication is passed, all source data can be exported.

[0014] In another possible implementation of this application, source data is managed at multiple levels. For example, different levels require different user permissions, which are determined during authentication. Generally, higher levels require higher permissions. For example, in-car call logs are assigned level 1 permissions, while all in-car data are assigned level 2 permissions.

[0015] That is to say, the source data of the vehicle is divided into multiple levels, and different levels correspond to different permissions; the on-board controller authenticates the second device, including: the on-board controller determines the permission level of the source data to be exported by the second device based on the data export instruction; the on-board controller authenticates the second device based on the permission level of the source data to be exported by the second device.

[0016] Through the above-mentioned hierarchical management and authentication, data export services with corresponding permissions can be provided to different users. On the one hand, it can meet the user's needs for exporting data, and on the other hand, it can ensure data security.

[0017] Optionally, the method further includes: the on-board controller receiving a data deletion or modification instruction sent by a third device; and the on-board controller discarding the data deletion or modification instruction.

[0018] In this implementation, the source data cannot be deleted or modified through external instructions, thereby achieving the effect of local data storage, non-writable, and tamper-proof.

[0019] Optionally, the method further includes: the on-board controller deleting data in the source data whose storage time exceeds a threshold.

[0020] While external deletion and modification commands are not accepted, source data can be deleted and overwritten by internal software processes. Because data continues to grow, and in-vehicle storage capacity is limited, certain strategic process mechanisms are in place to purge some data. For example, data can be retained for only 7 or 30 days, with deletion occurring after reaching these time limits.

[0021] Exemplarily, the onboard controller is an onboard communication module, an onboard mobile data center, a cockpit domain controller, an onboard gateway, a vehicle controller, a vehicle domain controller, or a body domain controller. Using various domain controllers for data analysis and processing can speed up processing.

[0022] Optionally, the method further includes: the vehicle-mounted controller deleting the exported data from the source data, thereby saving vehicle-mounted storage space.

[0023] Exemplarily, the source data includes at least one of the following data:

[0024] On-vehicle communication message data, electronic control unit ECU process data, ECU operation log, and key event statistics.

[0025] When the source data includes vehicle communication message data, the method further includes: the vehicle controller collecting key vehicle communication messages based on message identifiers, the message identifiers correspond to key vehicle communication messages, and the key vehicle communication messages are included in the vehicle communication message data.

[0026] In this implementation, the vehicle controller collects key vehicle messages, abandoning the large and comprehensive data collection in related technologies, saving storage space and reducing the amount of data processing required by the vehicle controller during data analysis.

[0027] Optionally, the method further includes: the vehicle controller obtaining key byte data in the key vehicle message.

[0028] In this implementation, the on-board controller collects key byte data in key on-board messages, abandons the large-scale and comprehensive data collection in related technologies, decomposes communication messages according to the vehicle architecture, and only collects key message information for storage, further saving storage space and reducing the amount of data processing required by the on-board controller during data analysis.

[0029] Exemplarily, the data analysis category in the data analysis instruction includes at least one of the following: privacy leakage judgment, security attack judgment, ECU process monitoring, data frame tracking, abnormal log statistics, and hardware security analysis.

[0030] In this implementation, in addition to storing the messages collected and sent by the in-vehicle sensors, it also records ECU processes, logs and other information. The source data content is more comprehensive and the analysis functions that can be provided are also more comprehensive.

[0031] In a second aspect, the present application provides a data management method, the method comprising:

[0032] The terminal device sends a data analysis instruction to the vehicle controller, where the data analysis instruction includes a data analysis category;

[0033] The terminal device receives a data analysis result sent by the vehicle-mounted controller, where the data analysis result is associated with a data analysis category in a data analysis instruction and source data of a vehicle, where the vehicle includes the vehicle-mounted controller.

[0034] Optionally, the method further comprises:

[0035] The terminal device sends a data export instruction to the vehicle controller;

[0036] The terminal device requests the vehicle controller to authenticate the terminal device;

[0037] When the identity authentication is passed, the terminal device receives the source data of the vehicle sent by the on-board controller.

[0038] Optionally, the method further comprises:

[0039] The terminal device sends a data deletion or modification instruction to the vehicle controller;

[0040] The terminal device determines the credibility of the vehicle controller based on whether the vehicle controller responds to the data deletion or modification instruction.

[0041] When the onboard controller responds, the onboard controller is considered untrustworthy, and when the onboard controller does not respond, the onboard controller is considered trustworthy. Because, in the solution provided by this application, the onboard controller does not accept external commands to delete or modify data, the trustworthiness of the onboard controller can be determined based on the response to the data deletion or modification command.

[0042] Exemplarily, the terminal device determines the credibility of the vehicle controller based on whether the vehicle controller responds to a data deletion or modification instruction, including:

[0043] When the terminal device receives a response confirming data deletion or confirming data modification from the onboard controller, the terminal device determines that the onboard controller is untrustworthy.

[0044] Optionally, the on-board controller is an on-board communication module, an on-board mobile data center, a cockpit domain controller, an on-board gateway, a vehicle controller, a vehicle domain controller or a body domain controller.

[0045] Optionally, the source data includes at least one of the following data:

[0046] On-vehicle communication message data, electronic control unit ECU process data, ECU operation log, and key event statistics.

[0047] Optionally, when the source data includes in-vehicle communication message data, the in-vehicle communication message data includes a key in-vehicle communication message, and the key in-vehicle communication message corresponds to the message identifier.

[0048] Optionally, the data analysis category in the data analysis instruction includes at least one of the following:

[0049] Privacy leakage judgment, security attack judgment, ECU process monitoring, data frame tracking, abnormal log statistics, and hardware security analysis.

[0050] In a third aspect, the present application provides a data management device, the device comprising:

[0051] a receiving unit, configured to receive a data analysis instruction sent by the first device, where the data analysis instruction includes a data analysis category;

[0052] a processing unit, configured to analyze source data of the vehicle based on a data analysis category in the data analysis instruction to obtain a data analysis result;

[0053] A sending unit is used to send the data analysis result to the first device.

[0054] Optionally, the receiving unit is further configured to receive a data export instruction sent by the second device;

[0055] The apparatus further includes: an authentication unit, configured to perform identity authentication on the second device;

[0056] The sending unit is further used to send the source data of the vehicle to the second device according to the data export instruction when the identity authentication is passed.

[0057] Exemplarily, the source data of the vehicle is divided into multiple levels, and different levels correspond to different permissions;

[0058] The authentication unit is used to determine the permission level of the source data to be exported by the second device based on the data export instruction; and to authenticate the second device based on the permission level of the source data to be exported by the second device.

[0059] Optionally, the receiving unit is further configured to receive a data deletion or modification instruction sent by a third device;

[0060] The processing unit is also used to discard data deletion or modification instructions.

[0061] Optionally, the processing unit is further configured to delete data in the source data whose storage time exceeds a threshold; or delete the exported data in the source data.

[0062] Exemplarily, the device is integrated into an on-board communication module, an on-board mobile data center, a cockpit domain controller, an on-board gateway, a vehicle controller, a vehicle domain controller or a body domain controller.

[0063] Exemplarily, the source data includes at least one of the following data:

[0064] On-vehicle communication message data, electronic control unit ECU process data, ECU operation log, and key event statistics.

[0065] Exemplarily, when the source data includes vehicle communication message data, the device further includes: a collection unit for collecting key vehicle communication messages based on message identifiers, the message identifiers correspond to key vehicle communication messages, and the key vehicle communication messages are included in the vehicle communication message data.

[0066] Optionally, the processing unit is further configured to obtain key byte data in a key vehicle-borne message.

[0067] Exemplarily, the data analysis category in the data analysis instruction includes at least one of the following:

[0068] Privacy leakage judgment, security attack judgment, ECU process monitoring, data frame tracking, abnormal log statistics, and hardware security analysis.

[0069] In a fourth aspect, the present application provides a data management device, comprising:

[0070] A sending unit, configured to send a data analysis instruction to the vehicle controller, the data analysis instruction including a data analysis category;

[0071] The receiving unit is used to receive a data analysis result sent by an onboard controller, where the data analysis result is associated with a data analysis category in a data analysis instruction and source data of a vehicle, and the vehicle includes the onboard controller.

[0072] Optionally, the sending unit is further configured to send a data export instruction to the vehicle controller;

[0073] The apparatus further comprises: an authentication unit, configured to request the vehicle-mounted controller to perform identity authentication on the terminal device;

[0074] The receiving unit is further used to receive the source data of the vehicle sent by the on-board controller when the identity authentication is passed.

[0075] Optionally, the sending unit is further configured to send a data deletion or modification instruction to the vehicle controller;

[0076] The device further includes: a processing unit configured to determine the credibility of the onboard controller based on whether the onboard controller responds to a data deletion or modification instruction.

[0077] Optionally, the processing unit is configured to determine that the onboard controller is untrustworthy upon receiving a response confirming data deletion or confirming data modification from the onboard controller.

[0078] Optionally, the on-board controller is an on-board communication module, an on-board mobile data center, a cockpit domain controller, an on-board gateway, a vehicle controller, a vehicle domain controller or a body domain controller.

[0079] Optionally, the source data includes at least one of the following data:

[0080] On-vehicle communication message data, electronic control unit ECU process data, ECU operation log, and key event statistics.

[0081] Optionally, when the source data includes in-vehicle communication message data, the in-vehicle communication message data includes a key in-vehicle communication message, and the key in-vehicle communication message corresponds to the message identifier.

[0082] Optionally, the data analysis category in the data analysis instruction includes at least one of the following:

[0083] Privacy leakage judgment, security attack judgment, ECU process monitoring, data frame tracking, abnormal log statistics, and hardware security analysis.

[0084] In a fifth aspect, an in-vehicle device is provided. The in-vehicle device includes a processor and a memory. The memory is used to store software programs and modules. The processor implements the method of the first aspect or any possible implementation of the first aspect by running or executing the software programs and / or modules stored in the memory.

[0085] Optionally, there are one or more processors and one or more memories.

[0086] Optionally, the memory may be integrated with the processor, or the memory may be provided separately from the processor.

[0087] In the specific implementation process, the memory can be a non-transitory memory, such as a read-only memory (ROM), which can be integrated on the same chip as the processor or be set on different chips. This application does not limit the type of memory and the setting method of the memory and the processor.

[0088] In a sixth aspect, a terminal device is provided. The terminal device includes a processor and a memory. The memory is used to store software programs and modules. The processor implements the method of the second aspect or any possible implementation of the second aspect by running or executing the software programs and / or modules stored in the memory.

[0089] In a seventh aspect, a computer program product is provided. The computer program product includes computer program code, which, when executed by a computer, causes the computer to perform the method of the first aspect or any possible implementation of the first aspect, or the method of the second aspect or any possible implementation of the second aspect.

[0090] In an eighth aspect, the present application provides a computer-readable storage medium, which is used to store program codes executed by a processor, wherein the program codes include methods for implementing the above-mentioned first aspect or any possible implementation of the first aspect, or for implementing the above-mentioned second aspect or any possible implementation of the second aspect.

[0091] In the ninth aspect, a chip is provided, comprising a processor, the processor being used to call and execute instructions stored in a memory from the memory, so that a communication device equipped with the chip executes the method of the above-mentioned first aspect or any possible implementation of the first aspect, or executes the method of the above-mentioned second aspect or any possible implementation of the second aspect.

[0092] In a tenth aspect, another chip is provided. The another chip includes an input interface, an output interface, a processor, and a memory. The input interface, the output interface, the processor, and the memory are connected via an internal connection path. The processor is configured to execute code in the memory. When the code is executed, the processor is configured to execute the method according to the first aspect or any possible implementation of the first aspect, or to execute the method according to the second aspect or any possible implementation of the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0093] FIG1 is a schematic diagram of a system architecture provided by an embodiment of the present application;

[0094] FIG2 is a flow chart of a data management method provided in an embodiment of the present application;

[0095] FIG3 is a flow chart of a data management method provided in an embodiment of the present application;

[0096] FIG4 is a flow chart of a data management method provided in an embodiment of the present application;

[0097] FIG5 is a block diagram of a data management device provided in an embodiment of the present application;

[0098] FIG6 is a block diagram of a data management device provided in an embodiment of the present application;

[0099] FIG7 shows a schematic structural diagram of a device provided by an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0100] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0101] To facilitate understanding of the technical solutions provided by the embodiments of this application, we first introduce the application scenario of this application. This application scenario can be a distributed storage system or a communication network such as a data center. The following uses a distributed storage system as an example to illustrate the application scenario of this application.

[0102] FIG1 is a schematic diagram of a system architecture provided by an embodiment of the present application. Referring to FIG1 , the system architecture includes an onboard controller 11 , at least one terminal device 12 , and multiple electronic control units (ECUs) 13 .

[0103] The onboard controller 11 is connected to the terminal device 12 for communication (eg, wired or wireless communication connection), and the onboard controller 11 is also connected to the plurality of ECUs 13 for communication (eg, wired communication connection).

[0104] Exemplarily, the ECU 13 generally refers to an ECU with communication capabilities, including at least one of the following ECUs:

[0105] Telematics box (TBox), mobile data center (MDC), cockpit domain controller (CDC), gateway (GW), battery management system (BMS), vehicle control unit (VCU), vehicle domain controller (VDC), body control module (BCM), body domain controller (BDC), power distribution unit (PDU), electronic stability program (ESP), electronic power steering (EPS), supplemental restraint system (SRS), etc.

[0106] In a possible implementation of the present application, the vehicle-mounted controller 11 may be a hardware entity independent of the above-mentioned ECU.

[0107] In another possible implementation of the present application, the vehicle-mounted controller 11 may also be integrated into one of the above-mentioned ECUs, for example, it may be a software module in the ECU.

[0108] For example, it can be integrated into domain controllers such as the vehicle communication module, vehicle mobile data center, cockpit domain controller, vehicle gateway, vehicle controller, vehicle domain controller or body domain controller.

[0109] The terminal device 12, also known as an analyzer, is a user-interface tool used to issue data analysis instructions and display data analysis results. The terminal device 12 can be a microcontroller, computer, or diagnostic instrument, or it can be implemented using a conventional mobile phone or tablet computer. By running an analyzer application (APP) on the mobile phone or tablet computer, it interacts with the vehicle controller 11.

[0110] The vehicle controller 11 may also be referred to as a monitor, which is used to collect and monitor in-vehicle data and process the data according to the data analysis instructions issued by the terminal device 12 .

[0111] In the embodiment of the present application, the above-mentioned system architecture belongs to a vehicle. In addition to road vehicles, the vehicles here may also include other forms of vehicles such as drones and aircraft. This application does not limit the form of the vehicle.

[0112] FIG2 is a flow chart of a data management method provided in an embodiment of the present application. The method is applied to the aforementioned vehicle. The method can be executed by the vehicle controller in the system architecture shown in FIG1. ​​As shown in FIG2, the method includes the following steps.

[0113] S11: The vehicle-mounted controller receives a data analysis instruction sent by the first device, where the data analysis instruction includes a data analysis category.

[0114] Among them, the first device can be the terminal device in Figure 1.

[0115] In the embodiment of the present application, the data analysis category is used to indicate the target of the data analysis or the function to be achieved by the vehicle controller, and different data analysis categories correspond to different targets or functions to be achieved.

[0116] Exemplarily, data analysis categories include privacy leakage judgment, security attack judgment, ECU process monitoring, data frame tracking, abnormal log statistics, hardware security analysis, etc.

[0117] Typically, a data analysis instruction includes only one data analysis category, and the first device can obtain analysis results corresponding to multiple data analysis categories through continuous data analysis instructions.

[0118] In other embodiments, one data analysis instruction may include two or more data analysis categories, which is not limited.

[0119] S12: The vehicle controller analyzes the source data of the vehicle based on the data analysis category in the data analysis instruction to obtain a data analysis result.

[0120] The source data of the vehicle can be stored in the vehicle controller, or in other ECUs, or in the vehicle's black box.

[0121] The source data of the vehicle refers to the data collected from the vehicle's ECU or sensors and other components without modification.

[0122] For example, the data analysis category in the data analysis instruction can be represented by a serial number, label or other symbols. After the on-board controller receives the data analysis instruction, it determines the corresponding data analysis action by identifying the serial number or label representing the data analysis category, and then analyzes the source data according to the corresponding data analysis action to obtain the data analysis result.

[0123] S13: The vehicle-mounted controller sends the data analysis result to the first device.

[0124] In the data management method provided herein, the vehicle controller receives a data analysis instruction from a first device, performs data analysis based on the data analysis category in the data analysis instruction, and then feeds the data analysis results back to the first device. This process eliminates the need to back up the vehicle's source data to the cloud or perform data analysis in the cloud, thereby avoiding the risk of leaking the source data stored in the black box.

[0125] In addition, the solution provided by this application triggers the data analysis action of the on-board controller by the data analysis instruction sent by the terminal device. The on-board controller performs analysis and provides results according to the needs of the terminal device. Compared with the related technology in which the cloud performs analysis according to a preset method, the on-board controller requires smaller processing resources and storage space, and is more suitable for on-board scenarios.

[0126] Figure 3 is a flow chart of a data management method provided by an embodiment of the present application. The method can be executed by a terminal device in the system architecture shown in Figure 1. As shown in Figure 3, the method includes the following steps.

[0127] S21: The terminal device sends a data analysis instruction to the vehicle controller, where the data analysis instruction includes a data analysis category.

[0128] S22: The terminal device receives the data analysis result sent by the vehicle controller, where the data analysis result is associated with the data analysis category in the data analysis instruction and the source data of the vehicle, where the vehicle includes the vehicle controller.

[0129] In the data management method provided in this application, a terminal device sends a data analysis instruction to an onboard controller, which then performs data analysis based on the data analysis category in the data analysis instruction and then feeds the analysis results back to the terminal device. This process eliminates the need to back up the vehicle's source data to the cloud or perform data analysis in the cloud, thus avoiding the risk of leaking the source data stored in the black box.

[0130] Figure 4 is a flow chart of a data management method provided by an embodiment of the present application. The method can be jointly executed by the vehicle controller and the terminal device in the system architecture shown in Figure 1. As shown in Figure 4, the method includes the following steps.

[0131] S30: The vehicle controller obtains source data.

[0132] Exemplarily, the source data includes at least one of the following data:

[0133] On-vehicle communication message data, electronic control unit ECU process data, ECU operation log, and key event statistics.

[0134] In one possible implementation of the present application, the source data may be stored within the vehicle controller. In another possible implementation of the present application, the source data may be stored in another storage device or ECU outside the vehicle controller. Regardless of the storage location, the source data cannot be tampered with.

[0135] Among them, vehicle communication message data refers to the message data transmitted between ECUs in the vehicle or between ECUs and vehicle-mounted devices.

[0136] In a possible implementation of the present application, the vehicle-mounted controller can monitor the message data flow in the vehicle and capture key data therein.

[0137] For example, the vehicle controller collects key vehicle communication messages based on the message identifier, the message identifier corresponds to the key vehicle communication message, and the key vehicle communication message is included in the vehicle communication message data.

[0138] Optionally, the on-board controller obtains key byte data in the key on-board message and stores the key byte data as source data.

[0139] For example, the vehicle controller defines the message identifiers of key Controller Area Network (CAN) messages and the locations of key bytes within the messages, such as the sequence numbers of key bytes within the messages. The vehicle controller collects messages with these message identifiers from the message data stream to obtain key vehicle communication messages. It then extracts the data corresponding to the sequence numbers of the key bytes from the key vehicle communication messages, i.e., the key byte data.

[0140] For example, based on the design of the vehicle architecture, messages related to vehicle safety and network security are defined as key messages. When designing the vehicle architecture, the identifiers of these key messages are determined and stored in the on-board controller so that the on-board controller can collect key on-board communication messages.

[0141] Among them, the message definitions may be different for different vehicles, so the definitions of key message identifiers and key byte positions may also be different.

[0142] In this implementation, the on-board controller collects key byte data in key on-board messages, abandons the large-scale and comprehensive data collection in related technologies, decomposes communication messages according to the vehicle architecture, and only collects key message information for storage, saving storage space and reducing the amount of data processing required by the on-board controller during data analysis.

[0143] In another possible implementation of the present application, the vehicle-mounted controller receives message data actively reported by the ECU or the vehicle-mounted device.

[0144] The ECU process data refers to data related to the processes running in the ECU, such as print information of key processes.

[0145] The ECU process data is generally invisible and cannot be collected. It needs to be displayed through system commands. The information displayed in this way is called print information.

[0146] Exemplarily, the ECU process data is reported by the ECU to the onboard controller, and the onboard controller receives the ECU process data.

[0147] ECU operation logs refer to the recorded information generated during the ECU's operation, such as the operation logs, operation logs, and alarm logs generated during the ECU program execution, operation process, and alarm conditions. These logs can be used for subsequent software fault location or other processing.

[0148] Exemplarily, the ECU operation log is reported by the ECU to the onboard controller, and the onboard controller receives the ECU operation log.

[0149] Key event statistics refer to key events that occur during the operation of the vehicle's black box and ECU. Examples include non-volatile memory (VM) erase and write counts, central processing unit (CPU) usage exceeding a threshold, memory usage exceeding a threshold, BusyBox crashes, ECU restarts, and process restarts.

[0150] Exemplarily, the ECU operation log is reported by the ECU, the vehicle-mounted device or the memory to the vehicle-mounted controller, and the vehicle-mounted controller receives the ECU operation log.

[0151] S31: The first device sends a data analysis instruction to the vehicle-mounted controller; the vehicle-mounted controller receives the data analysis instruction sent by the first device, where the data analysis instruction includes a data analysis category.

[0152] The first device may be the terminal device in Figure 1. Exemplarily, the first device may include software or a program installed therein to implement command transmission and display of feedback results. For example, the software or program may include a graphical user interface through which a user may select a command to be transmitted, such as a data analysis command, and may select a data analysis category when transmitting a data analysis command.

[0153] In the embodiment of the present application, the data analysis category is used to indicate the target of the data analysis or the function to be achieved by the vehicle controller, and different data analysis categories correspond to different targets or functions to be achieved.

[0154] Exemplarily, data analysis categories include privacy leakage judgment, security attack judgment, ECU process monitoring, data frame tracking, abnormal log statistics, hardware security analysis, etc.

[0155] Typically, a data analysis instruction includes only one data analysis category, and the first device can obtain analysis results corresponding to multiple data analysis categories through continuous data analysis instructions.

[0156] In other embodiments, one data analysis instruction may include two or more data analysis categories, which is not limited.

[0157] For example, the data analysis category in the data analysis instruction can be represented by a sequence number, label, or other symbol. Of course, the data analysis category in the data analysis instruction can also be empty, that is, without any explicit sequence number, label, or other symbol. In this case, the data analysis category included in the data analysis instruction is a default data analysis category, such as one or more of the above-mentioned data analysis categories.

[0158] Optionally, the data analysis instruction may also include the identification and authentication information (such as a key) of the terminal device, and the on-board controller may implement access control to the terminal device through the authentication information.

[0159] For example, the vehicle controller provides universal interfaces for connecting to terminal devices, such as physical interfaces such as Universal Serial Bus (USB), Ethernet (ETH), and Peripheral Component Interconnect Express (PCIE), or wireless interfaces such as Wireless Fidelity (WIFI), Bluetooth (BT), and Ultra-Wideband (UWB). Furthermore, the vehicle controller provides an application programming interface (API) for read-only data access by terminal devices.

[0160] The onboard controller can parse the data analysis instructions sent by the terminal device according to the API interface definition and authenticate the terminal device based on its identification and authentication information. If the terminal device passes the authentication and access is allowed, the onboard controller analyzes and processes the source data according to the data analysis category in the data analysis instructions according to the API interface definition. The terminal device can then obtain the analyzed data provided by the onboard controller.

[0161] In the above implementation, the terminal device identity authentication information is carried in the data analysis instruction. After receiving the data analysis instruction, the on-board controller performs identity authentication on the terminal device according to the authentication information therein.

[0162] In other implementations, the terminal device may interact with the vehicle controller through a separate message to achieve identity authentication before sending a data analysis instruction.

[0163] S32: The vehicle controller analyzes the source data of the vehicle based on the data analysis category in the data analysis instruction to obtain a data analysis result.

[0164] Among them, when the source data of the present application is stored in the ECU or other controllers, the vehicle-mounted black box of the present application is different from the traditional black box.

[0165] For example, after receiving the data analysis instruction, the on-board controller identifies the serial number or label representing the data analysis category by calling the API interface, determines the corresponding data analysis action, and then analyzes the source data according to the corresponding data analysis action to obtain the data analysis result.

[0166] Table 1 below shows the data analysis actions and related definitions corresponding to each data analysis category.

[0167] Table 1

[0168]

[0169]

[0170] When tracking data frames, key data frame numbers and abnormal data characteristics can be sent by the terminal device to the vehicle controller. When collecting abnormal log statistics, key characteristic tags can also be sent by the terminal device to the vehicle controller. When performing other types of data analysis, the terminal device can also send indicators or tags to the vehicle controller.

[0171] The above indicators or labels can be sent together in the data analysis instruction or sent separately, and this application does not impose any restrictions on this.

[0172] In other implementations, the above indicators or labels may be preset in the vehicle controller in advance without the need for the terminal device to send them.

[0173] In an embodiment of the present application, a data processing unit is integrated into the vehicle controller for performing calculations and processing in conjunction with data analysis instructions.

[0174] S33: The onboard controller sends the data analysis result to the first device; the first device receives the data analysis result sent by the onboard controller.

[0175] The on-board controller provides the analyzed data results to the terminal device through the API interface.

[0176] In the above steps, since the data analysis is completed by the on-board controller and the data analysis results are provided to the terminal device, there is no need to transfer the source data outside the vehicle, thus ensuring data security.

[0177] In other words, this application adopts a layered design. The source data stored in the vehicle cannot be directly exported. For the application layer, each time the terminal device triggers a function through a command, the on-board controller analyzes the source data, provides a processed result, and then returns it to the terminal device.

[0178] After receiving the data analysis results sent by the vehicle controller, the terminal device can display the data analysis results. This allows the user of the terminal device to understand the security status of the vehicle data and the vehicle's operating status based on the displayed data analysis results, thereby realizing vehicle monitoring and testing.

[0179] S34: The second device sends a data export instruction to the vehicle-mounted controller; the vehicle-mounted controller receives the data export instruction sent by the second device.

[0180] The second device may be the terminal device in FIG1 .

[0181] The second device and the first device may be the same device or different devices, and this application does not limit this. For ease of explanation, in this application, when describing an action performed by the first device, the second device, or even the third device, the terminal device may be used as the subject of the action.

[0182] S35: The second device requests the onboard controller to perform identity authentication on the second device; the onboard controller performs identity authentication on the second device.

[0183] For example, the terminal device sends an identity authentication request to the vehicle controller, the vehicle controller verifies the identity information carried in the identity authentication request, and returns an identity authentication response to the terminal device based on the verification result.

[0184] Due to the high level of data export, this application can use a certificate authentication method when performing identity authentication, which is different from the identity key verification used for device access. For example, the on-board controller issues a separate certificate for the terminal device with export permission, and when the terminal device is authenticated, it is authenticated based on the certificate issued for the terminal device. Exemplarily, the certificate includes summary information, summary algorithm, public key, etc. The terminal device can use the private key to encrypt the summary information to generate a signature, and carry the signature in the identity authentication request to the on-board controller. The on-board controller decrypts the signature in the identity authentication request through the public key and verifies it to determine whether the identity of the terminal device is legal, and returns an identity authentication response to the terminal device based on the verification result.

[0185] In one possible implementation, the identity authentication request can be sent after the data export instruction, that is, the terminal device first sends the data export instruction, and then the on-board controller returns a response requiring the terminal device to perform identity authentication, and the terminal device sends an identity authentication request.

[0186] In another possible implementation, the identity authentication request and the data export instruction may be the same message, that is, the identity authentication information is carried in the data export instruction.

[0187] In another possible implementation, the identity authentication request may be sent before the data export instruction, that is, the terminal device first sends the identity authentication request, and then sends the data export instruction after the identity authentication is passed.

[0188] In a possible implementation of the present application, all source data are managed at one level, that is, as long as the identity authentication is passed, all source data can be exported.

[0189] In another possible implementation of this application, source data is managed at multiple levels. For example, different levels require different user permissions, which are determined during authentication. Generally, higher levels require higher permissions. For example, in-car call logs are assigned level 1 permissions, while all in-car data are assigned level 2 permissions.

[0190] That is to say, the vehicle's source data is divided into multiple levels, different levels correspond to different permissions, and different levels correspond to different user permissions.

[0191] The vehicle controller authenticates the second device, including:

[0192] The onboard controller determines, based on the data export instruction, an authority level of the source data to be exported by the second device;

[0193] The on-vehicle controller performs identity authentication on the second device based on the authority level of the source data to be exported by the second device.

[0194] The data export instruction indicates the data range to be exported by the second device, and the on-board controller determines the permission level based on the data range, so that during identity authentication, authentication is performed according to the permission level to determine whether the user corresponding to the second device has the permission. For example, after the certificate-based authentication is passed, the permission level of the user identity is determined, and the correspondence between the user identity and the permission level can be pre-stored in the on-board controller. If the permission level of the user identity meets the permission level of the source data to be exported, it is determined that the identity authentication is passed, and step S36 is executed. If the permission level of the user identity does not meet the permission level of the source data to be exported, it is determined that the identity authentication is failed.

[0195] Through the above-mentioned hierarchical management and authentication, data export services with corresponding permissions can be provided to different users. On the one hand, it can meet the user's needs for exporting data, and on the other hand, it can ensure data security.

[0196] S36: When the identity authentication is passed, the vehicle controller sends the source data of the vehicle to the second device according to the data export instruction.

[0197] Exemplarily, the on-board controller extracts and sends the corresponding data to the second device according to the data range indicated by the data export instruction, that is, part or all of the source data is sent.

[0198] When the identity authentication fails, the vehicle-mounted controller does not send data to the second device.

[0199] In the implementation of this application, the keys, certificates, etc. required for the above-mentioned access authentication and exported data identity authentication can be updated to enhance security. This application does not limit the update method.

[0200] S37: The third device sends a data export, deletion, or modification instruction to the vehicle-mounted controller; the vehicle-mounted controller receives the data deletion or modification instruction sent by the third device.

[0201] The delete instruction is used to instruct the deletion of source data, and the modify instruction is used to instruct the modification of source data.

[0202] Among them, the third device can be the terminal device in Figure 1.

[0203] The third device and the first device (or the second device) can be the same device or different devices, and this application does not impose any restrictions on this.

[0204] Optionally, the terminal device determines the credibility of the on-board controller based on whether the on-board controller responds to a data deletion or modification instruction.

[0205] When the onboard controller responds, the onboard controller is considered untrustworthy, and when the onboard controller does not respond, the onboard controller is considered trustworthy. Because, in the solution provided by this application, the onboard controller does not accept external commands to delete or modify data, the trustworthiness of the onboard controller can be determined based on the response to the data deletion or modification command.

[0206] Exemplarily, the terminal device determines the credibility of the vehicle controller based on whether the vehicle controller responds to a data deletion or modification instruction, including:

[0207] When the terminal device receives a response confirming data deletion or confirming data modification from the onboard controller, the terminal device determines that the onboard controller is untrustworthy.

[0208] S38: The onboard controller discards the data deletion or modification instruction.

[0209] In the embodiment of the present application, the vehicle controller discarding the instruction includes: ignoring the instruction and not performing any operation or processing.

[0210] In the implementation of the present application, the source data in the black box cannot be deleted or modified by external instructions, thereby achieving the effect of local storage of data, which is non-writable and prevents tampering.

[0211] S39: The vehicle controller deletes data in the source data that has been stored for longer than a threshold.

[0212] While external deletion and modification commands are not accepted, source data can be deleted and overwritten by internal software processes (this means storing new data that has been overwritten for a period of time exceeding a threshold, which is equivalent to deleting data that has been overwritten for a period of time and storing new data). Because data will continue to increase, while in-vehicle storage capacity is limited, certain strategic process mechanisms are allowed to purge some data. For example, data may be stored for only 7 or 30 days (the aforementioned thresholds) and deleted after reaching these time limits.

[0213] Optionally, the on-board controller may also delete the exported data from the source data, thereby saving storage space.

[0214] The vehicle-wide solution for black box data management provided by the embodiments of the present application requires the ECU to proactively report data to the onboard controller, which increases the scope of source data and avoids the data range limitations of passively collected data streams. Data is stored locally and authorized to third parties through open interfaces. The authorized data analysis results can be read and displayed on terminal devices, improving the credibility of data perceived by users. The source data remains in the vehicle and does not support external write operations, preventing data tampering and ensuring data security.

[0215] Figure 5 is a block diagram of a data management device provided in an embodiment of the present application. The data management device can be implemented as all or part of an onboard controller through software, hardware, or a combination of both. The data management device may include: a receiving unit 401, a processing unit 402, and a sending unit 403.

[0216] The receiving unit 401 is configured to receive a data analysis instruction sent by the first device, where the data analysis instruction includes a data analysis category.

[0217] The processing unit 402 is configured to analyze the source data of the vehicle based on the data analysis category in the data analysis instruction to obtain a data analysis result;

[0218] The sending unit 403 is configured to send the data analysis result to the first device.

[0219] Optionally, the receiving unit 401 is further configured to receive a data export instruction sent by the second device;

[0220] The apparatus further includes: an authentication unit 404 for performing identity authentication on the second device;

[0221] The sending unit 403 is further configured to send the source data of the vehicle to the second device according to the data export instruction when the identity authentication is passed.

[0222] Exemplarily, the source data of the vehicle is divided into multiple levels, and different levels correspond to different permissions;

[0223] The authentication unit 404 is configured to determine, based on the data export instruction, the permission level of the source data to be exported by the second device; and perform identity authentication on the second device based on the permission level of the source data to be exported by the second device.

[0224] Optionally, the receiving unit 401 is further configured to receive a data deletion or modification instruction sent by a third device;

[0225] The processing unit 402 is further configured to discard the data deletion or modification instruction.

[0226] Optionally, the processing unit 402 is further configured to delete data in the source data whose storage time exceeds a threshold; or delete the exported data in the source data.

[0227] Exemplarily, the device is integrated into an on-board communication module, an on-board mobile data center, a cockpit domain controller, an on-board gateway, a vehicle controller, a vehicle domain controller or a body domain controller.

[0228] Exemplarily, the source data includes at least one of the following data:

[0229] On-vehicle communication message data, electronic control unit ECU process data, ECU operation log, and key event statistics.

[0230] Exemplarily, when the source data includes vehicle communication message data, the apparatus further includes: a collection unit 405, configured to collect key vehicle communication messages based on message identifiers, the message identifiers corresponding to the key vehicle communication messages, the key vehicle communication messages being included in the vehicle communication message data;

[0231] The processing unit 402 is further configured to obtain key byte data in the key vehicle-borne message.

[0232] Exemplarily, the data analysis category in the data analysis instruction includes at least one of the following:

[0233] Privacy leakage judgment, security attack judgment, ECU process monitoring, data frame tracking, abnormal log statistics, and hardware security analysis.

[0234] Figure 6 is a block diagram of a data management device provided by an embodiment of the present application. The data management device can be implemented as all or part of a terminal device through software, hardware, or a combination of both. The data management device can include: a sending unit 501 and a receiving unit 502.

[0235] The sending unit 501 is used to send a data analysis instruction to the vehicle controller, where the data analysis instruction includes a data analysis category;

[0236] The receiving unit 502 is configured to receive a data analysis result sent by a vehicle-mounted controller, where the data analysis result is associated with a data analysis category in a data analysis instruction and source data of a vehicle, wherein the vehicle includes the vehicle-mounted controller.

[0237] Optionally, the sending unit 501 is further configured to send a data export instruction to the vehicle controller;

[0238] The apparatus further comprises: an authentication unit 503 for requesting the vehicle-mounted controller to perform identity authentication on the terminal device;

[0239] The receiving unit 502 is further configured to receive the source data of the vehicle sent by the vehicle controller when the identity authentication is passed.

[0240] Optionally, the sending unit 501 is further configured to send a data deletion or modification instruction to the vehicle controller;

[0241] The apparatus further includes: a processing unit 504 for determining the credibility of the onboard controller based on whether the onboard controller responds to the data deletion or modification instruction.

[0242] Optionally, the processing unit 504 is configured to determine that the onboard controller is untrustworthy upon receiving a response confirming data deletion or data modification from the onboard controller.

[0243] Optionally, the on-board controller is an on-board communication module, an on-board mobile data center, a cockpit domain controller, an on-board gateway, a vehicle controller, a vehicle domain controller or a body domain controller.

[0244] Optionally, the source data includes at least one of the following data:

[0245] On-vehicle communication message data, electronic control unit ECU process data, ECU operation log, and key event statistics.

[0246] Optionally, when the source data includes in-vehicle communication message data, the in-vehicle communication message data includes a key in-vehicle communication message, and the key in-vehicle communication message corresponds to the message identifier.

[0247] Optionally, the data analysis category in the data analysis instruction includes at least one of the following:

[0248] Privacy leakage judgment, security attack judgment, ECU process monitoring, data frame tracking, abnormal log statistics, and hardware security analysis.

[0249] It should be noted that the data management device provided in the above embodiment is merely an example of the division of the aforementioned functional units when performing data management. In actual applications, the aforementioned functions can be assigned to different functional units as needed, that is, the internal structure of the device can be divided into different functional units to perform all or part of the functions described above. In addition, the data management device provided in the above embodiment and the data management method embodiment are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0250] FIG7 illustrates a schematic diagram of the structure of a device 150 provided in an embodiment of the present application. Device 150 may be an onboard controller or a terminal device. Device 150 shown in FIG7 is configured to perform the operations described in any of the data management methods shown in FIG2 through FIG4 . Device 150 may be implemented using a general bus architecture.

[0251] As shown in FIG. 7 , the device 150 includes at least one processor 151 , a memory 153 , and at least one communication interface 154 .

[0252] The processor 151 is, for example, a general-purpose central processing unit (CPU), a digital signal processor (DSP), a network processor (NP), a data processing unit (DPU), a microprocessor, or one or more integrated circuits for implementing the solution of the present application. For example, the processor 151 includes an application-specific integrated circuit (ASIC), a programmable logic device (PLD) or other programmable logic devices, a transistor logic device, a hardware component, or any combination thereof. The PLD is, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. It can implement or execute the various logic blocks, modules, and circuits described in conjunction with the disclosure of the embodiments of the present application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like.

[0253] Optionally, device 150 also includes a bus. The bus is used to transmit information between the components of device 150. The bus may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, for example. Buses can be classified as address buses, data buses, control buses, etc. For ease of illustration, FIG7 shows only one thick line, but this does not mean that there is only one bus or only one type of bus.

[0254] The memory 153 is, for example, a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including a compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 153 is, for example, independent and connected to the processor 151 via a bus. The memory 153 can also be integrated with the processor 151.

[0255] The communication interface 154 uses any transceiver-like device to communicate with other devices or communication networks. The communication network can be Ethernet, a radio access network (RAN), or a wireless local area network (WLAN). The communication interface 154 can include a wired communication interface and a wireless communication interface. Specifically, the communication interface 154 can be an Ethernet interface, a Fast Ethernet (FE) interface, a Gigabit Ethernet (GE) interface, an Asynchronous Transfer Mode (ATM) interface, a wireless local area network (WLAN) interface, a cellular network communication interface, or a combination thereof. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. In an embodiment of the present application, the communication interface 154 can be used for the device 150 to communicate with other devices.

[0256] In a specific implementation, as an example, the processor 151 may include one or more CPUs, such as CPU0 and CPU1 shown in FIG7 . Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. The processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0257] In a specific implementation, as an example, device 150 may include multiple processors, such as processor 151 and processor 155 shown in FIG7 . Each of these processors may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). A processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

[0258] In a specific implementation, as an embodiment, the device 150 may further include an output device and an input device. The output device communicates with the processor 151 and can display information in a variety of ways. For example, the output device can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device communicates with the processor 151 and can receive user input in a variety of ways. For example, the input device can be a mouse, a keyboard, a touch screen device, or a sensor device.

[0259] In some embodiments, the memory 153 is used to store program code 1510 for executing the solution of the present application, and the processor 151 can execute the program code 1510 stored in the memory 153. That is, the device 150 can implement the data processing method provided by the method embodiment by executing the program code 1510 in the memory 153 through the processor 151. The program code 1510 may include one or more software modules. Optionally, the processor 151 itself may also store program code or instructions for executing the solution of the present application.

[0260] In a specific embodiment, the device 150 of the embodiment of the present application may correspond to the controller in the above-mentioned method embodiments, and the processor 151 in the device 150 reads the instructions in the memory 153, so that the device 150 shown in Figure 7 can execute all or part of the operations performed by the controller.

[0261] Specifically, the processor 151 is used to receive a data analysis instruction sent by the first device, where the data analysis instruction includes a data analysis category; based on the data analysis category in the data analysis instruction, analyze the source data of the vehicle to obtain a data analysis result; and send the data analysis result to the first device.

[0262] For the sake of brevity, other optional implementations are not described here in detail.

[0263] Among them, each step of the data management method shown in any of Figures 2 to 4 is completed by the hardware integrated logic circuit or software instructions in the processor of device 150. The steps of the method disclosed in conjunction with the embodiments of the present application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor. The software module can be located in a storage medium mature in the art such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.

[0264] An embodiment of the present application further provides a chip comprising an input interface, an output interface, a processor, and a memory. The input interface, the output interface, the processor, and the memory are connected via an internal connection path. The processor is configured to execute code in the memory. When the code is executed, the processor is configured to perform any of the aforementioned data management methods.

[0265] It should be understood that the processor may be a CPU, or other general-purpose processor, DSP, ASIC, FPGA or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. It is worth noting that the processor may be a processor supporting the ARM architecture.

[0266] Furthermore, in an optional embodiment, there are one or more processors and one or more memories. Alternatively, the memories may be integrated with the processors, or provided separately from the processors. The memories may include read-only memory and random access memory, and provide instructions and data to the processors. The memories may also include non-volatile random access memory. For example, the memories may also store reference blocks and target blocks.

[0267] The memory may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be ROM, PROM, EPROM, EEPROM, or flash memory. The volatile memory may be RAM, which serves as an external cache. By way of example and not limitation, many forms of RAM are available, including, for example, SRAM, DRAM, SDRAM, DDR SDRAM, ESDRAM, SLDRAM, and DR RAM.

[0268] In an embodiment of the present application, a computer-readable storage medium is also provided, which stores computer instructions. When the computer instructions stored in the computer-readable storage medium are executed by a vehicle-mounted device, the vehicle-mounted device executes the data management method provided above.

[0269] In an embodiment of the present application, a computer program product containing instructions is also provided, which, when executed on a vehicle-mounted device, enables the vehicle-mounted device to execute the data management method provided above.

[0270] In the above embodiments, all or part of the embodiments may be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described herein are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, hard disk, tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive).

[0271] Those skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or by a program to instruct the relevant hardware, and the program may be stored in a computer-readable storage medium, which may be a read-only memory, a disk, or an optical disk, etc.

[0272] The above are merely optional embodiments of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

[0273] Unless otherwise defined, the technical or scientific terms used herein shall have the usual meaning understood by persons of ordinary skill in the field to which this application belongs. The words “first”, “second”, “third” and similar terms used in the patent application specification and claims of this application do not indicate any order, quantity or importance, but are only used to distinguish different components. Similarly, words such as “a” or “an” do not indicate a quantitative limitation, but rather indicate the presence of at least one. Words such as “include” or “comprising” and similar words mean that the elements or objects appearing before “include” or “comprising” cover the elements or objects listed after “include” or “comprising” and their equivalents, and do not exclude other elements or objects.

[0274] The above is only an embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A data management method, characterized in that: Applied to a vehicle, the vehicle including an onboard controller, the method comprising: The on-board controller receives a data analysis instruction sent by the first device, where the data analysis instruction includes a data analysis category; The on-board controller analyzes the source data of the vehicle based on the data analysis category in the data analysis instruction to obtain a data analysis result; The on-board controller sends the data analysis result to the first device.

2. The method according to claim 1, characterized in that The method further comprises: The on-board controller receives a data export instruction sent by the second device; The on-board controller performs identity authentication on the second device; When the identity authentication is passed, the vehicle controller sends the source data of the vehicle to the second device according to the data export instruction.

3. The method according to claim 2, characterized in that The source data of the vehicle is divided into multiple levels, and different levels correspond to different permissions; The vehicle-mounted controller performs identity authentication on the second device, including: The on-vehicle controller determines, based on the data export instruction, a permission level of the source data to be exported by the second device; The on-vehicle controller performs identity authentication on the second device based on the authority level of the source data to be exported by the second device.

4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: The on-board controller receives a data deletion or modification instruction sent by a third device; The on-board controller discards the data deletion or modification instruction.

5. The method according to any one of claims 1 to 4, characterized in that The method further comprises: The on-vehicle controller deletes data in the source data whose storage time exceeds a threshold; or deletes data derived from the source data.

6. The method according to any one of claims 1 to 5, characterized in that The on-board controller is an on-board communication module, an on-board mobile data center, a cockpit domain controller, an on-board gateway, a vehicle controller, a vehicle domain controller or a body domain controller.

7. The method according to any one of claims 1 to 6, characterized in that The source data includes at least one of the following data: On-vehicle communication message data, electronic control unit ECU process data, ECU operation log, and key event statistics.

8. The method according to claim 7, characterized in that When the source data includes the vehicle-mounted communication message data, the method further includes: The vehicle-mounted controller collects key vehicle-mounted communication messages based on message identifiers, where the message identifiers correspond to the key vehicle-mounted communication messages, and the key vehicle-mounted communication messages are included in the vehicle-mounted communication message data.

9. The method according to claim 8, characterized in that The method further comprises: The on-vehicle controller obtains key byte data in the key on-vehicle message.

10. The method according to any one of claims 1 to 9, characterized in that The data analysis category in the data analysis instruction includes at least one of the following: Privacy leakage judgment, security attack judgment, ECU process monitoring, data frame tracking, abnormal log statistics, and hardware security analysis.

11. A data management method, characterized in that: The method comprises: The terminal device sends a data analysis instruction to the vehicle controller, wherein the data analysis instruction includes a data analysis category; The terminal device receives a data analysis result sent by the vehicle-mounted controller, where the data analysis result is associated with a data analysis category in the data analysis instruction and source data of a vehicle, wherein the vehicle includes the vehicle-mounted controller.

12. The method according to claim 11, characterized in that The method further comprises: The terminal device sends a data export instruction to the vehicle controller; The terminal device requests the vehicle-mounted controller to perform identity authentication on the terminal device; When the identity authentication is passed, the terminal device receives the source data of the vehicle sent by the on-board controller.

13. The method according to claim 11 or 12, characterized in that The method further comprises: The terminal device sends a data deletion or modification instruction to the vehicle controller; The terminal device determines the credibility of the onboard controller based on whether the onboard controller responds to the data deletion or modification instruction.

14. The method according to claim 13, characterized in that The terminal device determines the credibility of the vehicle-mounted controller based on whether the vehicle-mounted controller responds to the data deletion or modification instruction, including: When the terminal device receives a response from the onboard controller confirming data deletion or confirming data modification, the terminal device determines that the onboard controller is untrustworthy.

15. The method according to any one of claims 11 to 14, characterized in that The on-board controller is an on-board communication module, an on-board mobile data center, a cockpit domain controller, an on-board gateway, a vehicle controller, a vehicle domain controller or a body domain controller.

16. The method according to any one of claims 11 to 15, characterized in that The source data includes at least one of the following data: On-vehicle communication message data, electronic control unit ECU process data, ECU operation log, and key event statistics.

17. The method according to claim 16, characterized in that When the source data includes the in-vehicle communication message data, the in-vehicle communication message data includes a key in-vehicle communication message, and the key in-vehicle communication message corresponds to the message identifier.

18. The method according to any one of claims 11 to 17, characterized in that The data analysis category in the data analysis instruction includes at least one of the following: Privacy leakage judgment, security attack judgment, ECU process monitoring, data frame tracking, abnormal log statistics, and hardware security analysis.

19. A data management device, characterized in that: The device comprises: a receiving unit, configured to receive a data analysis instruction sent by the first device, wherein the data analysis instruction includes a data analysis category; a processing unit, configured to analyze the source data of the vehicle based on the data analysis category in the data analysis instruction to obtain a data analysis result; A sending unit is used to send the data analysis result to the first device.

20. The device according to claim 19, characterized in that The receiving unit is further configured to receive a data export instruction sent by the second device; The apparatus further includes: an authentication unit, configured to perform identity authentication on the second device; The sending unit is further configured to send the source data of the vehicle to the second device according to the data export instruction when the identity authentication is passed.

21. The device according to claim 20, characterized in that The source data of the vehicle is divided into multiple levels, and different levels correspond to different permissions; The authentication unit is configured to determine, based on the data export instruction, an authority level of the source data to be exported by the second device; The identity of the second device is authenticated based on the permission level of the source data to be exported by the second device.

22. The device according to any one of claims 19 to 21, characterized in that The receiving unit is further configured to receive a data deletion or modification instruction sent by a third device; The processing unit is further configured to discard the data deletion or modification instruction.

23. The device according to any one of claims 19 to 22, characterized in that The processing unit is further configured to delete data in the source data whose storage time exceeds a threshold; or to delete the derived data in the source data.

24. The device according to any one of claims 19 to 23, characterized in that The device is integrated into an on-board communication module, an on-board mobile data center, a cockpit domain controller, an on-board gateway, a whole vehicle controller, a whole vehicle domain controller or a body domain controller.

25. The device according to any one of claims 19 to 24, characterized in that The source data includes at least one of the following data: On-vehicle communication message data, electronic control unit ECU process data, ECU operation log, and key event statistics.

26. The device according to claim 25, characterized in that When the source data includes the vehicle communication message data, the device further includes: a collection unit for collecting key vehicle communication messages based on message identifiers, the message identifiers corresponding to the key vehicle communication messages, and the key vehicle communication messages included in the vehicle communication message data.

27. The device according to claim 26, characterized in that The processing unit is further used to obtain key byte data in the key vehicle-borne message.

28. The device according to any one of claims 19 to 27, characterized in that The data analysis category in the data analysis instruction includes at least one of the following: Privacy leakage judgment, security attack judgment, ECU process monitoring, data frame tracking, abnormal log statistics, and hardware security analysis.

29. A data management device, characterized in that: The device comprises: a sending unit, configured to send a data analysis instruction to the vehicle controller, wherein the data analysis instruction includes a data analysis category; A receiving unit is used to receive a data analysis result sent by the vehicle-mounted controller, where the data analysis result is associated with a data analysis category in the data analysis instruction and source data of a vehicle, and the vehicle includes the vehicle-mounted controller.

30. The device according to claim 29, characterized in that The sending unit is further configured to send a data export instruction to the vehicle-mounted controller; The apparatus further comprises: an authentication unit, configured to request the vehicle-mounted controller to perform identity authentication on the terminal device; The receiving unit is further configured to receive the source data of the vehicle sent by the onboard controller when the identity authentication is passed.

31. The device according to claim 29 or 30, characterized in that The sending unit is further used to send a data deletion or modification instruction to the vehicle controller; The apparatus further includes a processing unit configured to determine the credibility of the onboard controller based on whether the onboard controller responds to the data deletion or modification instruction.

32. The device according to claim 31, characterized in that The processing unit is configured to determine that the onboard controller is untrustworthy when receiving a response confirming data deletion or data modification from the onboard controller.

33. The device according to any one of claims 29 to 32, characterized in that The on-board controller is an on-board communication module, an on-board mobile data center, a cockpit domain controller, an on-board gateway, a vehicle controller, a vehicle domain controller or a body domain controller.

34. The device according to any one of claims 29 to 33, characterized in that The source data includes at least one of the following data: On-vehicle communication message data, electronic control unit ECU process data, ECU operation log, and key event statistics.

35. The device according to claim 34, characterized in that When the source data includes the in-vehicle communication message data, the in-vehicle communication message data includes a key in-vehicle communication message, and the key in-vehicle communication message corresponds to the message identifier.

36. The device according to any one of claims 29 to 35, characterized in that The data analysis category in the data analysis instruction includes at least one of the following: Privacy leakage judgment, security attack judgment, ECU process monitoring, data frame tracking, abnormal log statistics, and hardware security analysis.

37. A vehicle-mounted device, characterized in that: The in-vehicle device includes a processor and a memory, the memory is used to store software programs, and the processor runs or executes the software programs stored in the memory, so that the in-vehicle device implements the method according to any one of claims 1 to 10.

38. A terminal device, characterized in that: The terminal device includes a processor and a memory, the memory is used to store a software program, and the processor runs or executes the software program stored in the memory so that the terminal device implements the method according to any one of claims 11 to 18.

39. A computer-readable storage medium, characterized in that The computer-readable storage medium is used to store program codes executed by a processor, wherein the program codes include instructions for implementing the method according to any one of claims 1 to 10, or instructions for implementing the method according to any one of claims 11 to 18.

Images