Data processing method and related device

Abstract

The present invention discloses a data processing method for use in the field of intelligent vehicle technology. The method is applied to a vehicle comprising a controller and a number of electronic control units ECUs. The method includes: The controller receives a data request message from a first ECU, the first ECU being any one of the plurality of ECUs, and the data request message is used to request to obtain sensor data. The controller sends a response message to the first ECU, which indicates to the first ECU to obtain the sensor data. The controller generates mark information based on the data request message, and the mark information records the request information for the sensor data. When a vehicle triggers deletion of the sensor data in the first ECU, the controller sends a first data deletion command to the first ECU based on the mark information, where the first data deletion command indicates the first ECU to delete the sensor data. Based on this method, fine-grained management of data can be implemented for components within a vehicle, so that specific data within the vehicle can be suitably deleted, and leakage of private data within the vehicle can be avoided.

Description

[Technical Field]

[0001] This application claims priority to Chinese Patent Application No. 202110983634.34, entitled "DATA PROCESSING METHOD AND RELATED APPARATUS," filed with the State Intellectual Property Office of China on August 25, 2021, which is incorporated herein by reference in its entirety.

[0002] [Technical field] This application relates to the field of intelligent vehicle technology, and more particularly to data processing methods and related devices. [Background technology]

[0003] With the development of modern information technology, the amount of electronic products in vehicles is increasing, and the complexity of vehicles is also increasing. In order to meet the development trend in the vehicle field, vehicles need to implement more functions, and the number of electronic control elements in systems for implementing electronic control functions in vehicles, especially electronic control units (ECUs) located in vehicle components, is also increasing.

[0004] Generally, one or more ECUs are arranged in a vehicle for each vehicle component having an electronic control function, and each ECU has functions such as a control function and a calculation function. In the normal driving process of a vehicle, the ECU in the vehicle usually needs to obtain various types of data of the vehicle in the driving process, such as data on the driving speed and driving position of the vehicle.

[0005] After a vehicle has been running for a certain period of time, the ECU in the vehicle typically stores various types of data generated during the vehicle's operation, and the data stored in the ECU in the vehicle is private data of the vehicle owner. In some cases, the vehicle owner typically wants to delete some of the private data stored in the vehicle to avoid privacy leaks. However, current vehicles do not support the vehicle owner's ability to delete data from each ECU in the vehicle at a granular level. The vehicle owner can only delete data from all vehicle components by formatting the vehicle, and deleting data from all vehicle components would affect the vehicle owner's normal operation of the vehicle.

[0006] Therefore, there is currently an urgent need for a method that can effectively manage in-vehicle data. Summary of the Invention

[0007] The present invention provides a data processing method, which can implement fine-grained management of data for components in a vehicle, and thus can suitably delete specific data in the vehicle, thereby avoiding the leakage of private data in the vehicle.

[0008] A first aspect of the present invention provides a data processing method. The present invention is applied to a vehicle including a controller and a plurality of ECUs. The vehicle may be, for example, an intelligent vehicle. The method includes: the controller receives a data request message from a first ECU, the first ECU being any one of the plurality of ECUs, and the data request message is used to request acquisition of sensor data. The controller sends a response message to the first ECU, and the response message indicates to the first ECU to acquire the sensor data. Based on the response message, the first ECU can acquire the corresponding sensor data.

[0009] The controller generates mark information based on the data request message, and the mark information records request information for the sensor data. For example, the request information for the sensor data includes a requester of the sensor data, a request time for the sensor data, and content of the sensor data. For example, the request information for the sensor data may be as follows: The first ECU requests camera data at xx:xx on xx / xx (month / day).

[0010] When the vehicle triggers the deletion of the sensor data in the first ECU, the controller sends a first data deletion command to the first ECU based on the mark information, and the first data deletion command indicates to the first ECU to delete the sensor data.

[0011] In this solution, when multiple ECUs in a vehicle need to acquire sensor data, the multiple ECUs send data requests to a controller, and the controller records information about the ECUs' requests for sensor data. In this way, when deletion of specific sensor data is triggered, the controller can determine an ECU that will acquire the sensor data based on the recorded information and send a data deletion command to that ECU, thereby realizing fine-grained management of in-vehicle data.

[0012] In a possible embodiment, the vehicle triggers the deletion of the sensor data in the first ECU by the following: the controller determines that the sensor data in the first ECU is expired based on the mark information and a preset data retention period. The preset data retention period may be a storage period for in-vehicle data. When the time of the data reaches the storage period (i.e., the data expires), the data needs to be deleted.

[0013] Alternatively, the controller may receive a second data deletion command triggered by a user, the second data deletion command indicating that the sensor data in the first ECU is to be deleted. For example, the user may select data that needs to be deleted on a human-machine interface of the vehicle and trigger the second data deletion command.

[0014] In this solution, when the data in the ECU expires or the user triggers the deletion of the data in the ECU, the controller is triggered to send a data deletion command to the ECU, perform the data deletion, and perform fine-grained management of the data in the vehicle.

[0015] In a possible embodiment, the response message includes information about the sensor, said information about the sensor being used by the first ECU to establish a communication connection with the sensor so that the first ECU obtains sensor data from the sensor.

[0016] In this solution, the connection between the ECU and the sensor is managed and controlled by the controller, so that the controller can manage and control the ECU to acquire sensor data, thereby implementing fine-grained management of in-vehicle data.

[0017] In a possible implementation, when the first ECU acquires sensor data by establishing a communication connection with the sensor, the first data deletion command may indicate to the first ECU to disconnect the communication connection with the sensor.

[0018] For example, if a user changes the application's permissions so that the first ECU no longer has permission to access the sensor data, the controller may send a first data deletion command to the first ECU. The first data deletion instruction instructs the first ECU to delete the sensor data and to disconnect the communication connection with the sensor.

[0019] In this solution, if the permission of the ECU is changed so that the ECU cannot access the sensor data, the first data deletion command instructs the ECU to disconnect the communication connection between the ECU and the sensor, so that the ECU can no longer obtain the sensor data, thereby implementing accurate management and control of in-vehicle data.

[0020] In a possible embodiment, before the controller sends the response message to the first ECU, the method includes: the controller determines that the first ECU has permission to access the sensor data according to a preset permission configuration policy. The permission configuration policy may be set by a user via a human-machine interface in the vehicle or a remote terminal. Alternatively, the permission configuration policy may be set in advance before the vehicle is delivered.

[0021] In a possible implementation, for a controller in a vehicle, the untrusted ECUs in the vehicle, the third-party devices, and the cloud server are all untrusted devices, i.e., devices that are not trusted by the controller. In the process of performing data interaction with the untrusted devices, the controller needs to store evidence of the data interaction to ensure the authenticity of the data interaction.

[0022] The method further includes: the controller receiving address information sent by the untrusted device, the untrusted device including a second ECU or a server, the second ECU being an untrusted ECU among a plurality of ECUs, the address information indicating an address space within the untrusted device used to store data to be transmitted, the address information being determined by the untrusted device based on the size of the data to be transmitted.

[0023] The controller generates a first data certificate based on the address information and the data to be transmitted, the first data certificate uniquely indicating the data to be transmitted. The controller transmits the first data certificate to the untrusted device. The controller receives a first signature result transmitted by the untrusted device, the first signature result being obtained by the untrusted device signing the first data certificate. The controller controls transmission of the data to be transmitted to the untrusted device.

[0024] In this solution, before data is transmitted to an untrusted device, the controller obtains address information returned by the untrusted device and used to store the data to be transmitted, and generates a data certificate based on the address information and the data to be transmitted. The data is transmitted to the untrusted device after the data certificate is signed using the untrusted device. The controller stores the data certificate signed using the untrusted device, thereby providing evidence of data transmission to the untrusted device, thereby eliminating the threat that the untrusted device repudiates (...that the untrusted device does not receive the data) after receiving the data and improving the reliability of data transmission.

[0025] There may be multiple implementations in which the controller may control the transmission of data to be sent to an untrusted device.

[0026] In a possible implementation, if the untrusted device is a second ECU and the second ECU requests to obtain sensor data from the controller, the controller may instruct the second ECU to obtain sensor data from the sensor by returning information about the sensor to the second ECU. That is, the controller controls the transmission of data to be sent to the untrusted device by returning information about the establishment with the sensor to the untrusted device.

[0027] In another possible implementation, if the untrusted device is a second ECU or a server and the data to be transmitted is located in the storage space of the controller, the controller may transmit the data in the storage space of the controller to the second ECU or the server to control the transmission of the data to be transmitted to the untrusted device.

[0028] In yet another possible implementation, if the untrusted device is a server and the data to be transmitted is located on a component other than the controller, the controller may communicate with the component that stores the data to be transmitted and indicate to the component to transmit the data to the server.

[0029] In a possible embodiment, the first data certificate includes address information and one or more of a digest value of the data to be transmitted, a file locator of the data to be transmitted, and a timestamp of the data to be transmitted.

[0030] In a possible implementation, the method further includes: the controller generates a second data certificate based on the data to be deleted; the controller sends a third data deletion command to the untrusted device, where the untrusted device includes a third ECU or a server, where the third ECU is an untrusted ECU among the multiple ECUs, where the third data deletion command includes the second data certificate, where the third data deletion command indicates deleting the data to be deleted; the controller obtains a second signature result returned by the untrusted device, where the second signature result is obtained by the server signing the second data certificate, where the second signature result indicates that the untrusted device has deleted the data to be deleted.

[0031] In this solution, before the controller instructs the untrusted device to delete data, the controller generates a data certificate based on the data to be deleted. When instructing the untrusted device to delete data, the controller sends the data certificate to the untrusted device, so that the controller can obtain the result obtained by signing the data certificate by the untrusted device.

[0032] The controller stores the result obtained by signing the data certificate by the untrusted device, thereby providing evidence that the untrusted device confirmed the data deletion, thereby eliminating the threat that the untrusted device repudiates that no data deletion instruction is received and improving the reliability of the data transmission.

[0033] A second aspect of the present invention provides a data processing method. The method is applied to a vehicle including a controller and a plurality of electronic control units (ECUs). The method includes the following steps: a first ECU sends a data request message to the controller, where the first ECU is any one of the plurality of ECUs, and the data request message is used to request acquisition of sensor data; the first ECU receives a response message from the controller, where the response message instructs the first ECU to acquire the sensor data; the first ECU acquires the sensor data based on the response message; and when the vehicle triggers deletion of the sensor data in the first ECU, the first ECU receives a first data deletion command from the controller and deletes the sensor data in the first ECU based on the first data deletion command.

[0034] In a possible implementation, the first ECU acquiring the sensor data based on the response message includes: the first ECU establishing a communication connection with the sensor based on information about the sensor, wherein the response information includes information about the sensor; and the first ECU acquiring the sensor data from the sensor based on the communication connection.

[0035] In a possible embodiment, the first data deletion command instructs the first ECU to disconnect the communication connection with the sensor.

[0036] In a possible implementation, the method further includes: if the first ECU is an untrusted device, the first ECU sends address information to the controller, where the address information indicates an address space within the first ECU used to store the data to be transmitted, and the address information is determined by the first ECU based on the size of the data to be transmitted; the first ECU receives a first data certificate sent by the controller, where the first data certificate is generated based on the address information and the data to be transmitted; the first ECU signs the first data certificate to obtain a first signature result; the first ECU sends the first signature result to the controller; and the first ECU receives the data to be transmitted sent by the controller.

[0037] In a possible embodiment, the first data certificate includes address information and one or more of a digest value of the data to be transmitted, a file locator of the data to be transmitted, and a timestamp of the data to be transmitted.

[0038] In a possible embodiment, the method further includes: if the first ECU is an untrusted device, the first ECU receives a third data deletion command sent by the controller, the third data deletion command including a second data certificate, the second data certificate being generated by the controller based on the data to be deleted; the first ECU signs the second data certificate to obtain a second signature result; the first ECU sends the second signature result to the controller and deletes the data to be deleted, the second signature result indicating that the untrusted device has deleted the data to be deleted.

[0039] A third aspect of the present invention provides a controller, the controller being arranged in a vehicle, the vehicle further comprising a plurality of ECUs, the controller including a transceiver unit and a processing unit.

[0040] The transceiver unit is configured to receive a data request message from a first ECU, where the first ECU is any one of the plurality of ECUs, and the data request message is used to request acquisition of sensor data.

[0041] The transceiver unit is further configured to send a response message to a first ECU, where the response message indicates the first ECU to acquire sensor data.

[0042] The processing unit is configured to generate mark information based on the data request message, where the mark information records the request information for the sensor data.

[0043] When the vehicle triggers the deletion of the sensor data in the first ECU, the transceiver unit is further configured to send a first data deletion command to the first ECU based on the mark information, where the first data deletion command indicates to the first ECU to delete the sensor data.

[0044] In a possible implementation, the request information for the sensor data includes a requester of the sensor data, a time of request for the sensor data, and a content of the sensor data.

[0045] In a possible implementation, the processing unit is further configured to determine that the sensor data in the first ECU is expired based on the mark information and a predetermined data retention period; or the transceiver unit is further configured to obtain a second data deletion command triggered by a user, the second data deletion command instructing the sensor data in the first ECU to be deleted.

[0046] In a possible implementation, the response message includes information about the sensor, which information about the sensor is used by the first ECU to establish a communication connection with the sensor so that the first ECU obtains sensor data from the sensor.

[0047] In a possible implementation, the first data deletion command further instructs the first ECU to disconnect a communication connection with the sensor.

[0048] In a possible implementation, the processing unit is further configured to determine that the first ECU has permission to access the sensor data according to a preset permission configuration policy.

[0049] In a possible implementation, the transceiver unit is further configured to receive address information sent by an untrusted device, the untrusted device including a second ECU or a server, the second ECU being an untrusted ECU among the plurality of ECUs, the address information indicating an address space in the untrusted device used to store data to be transmitted, the address information being determined by the untrusted device based on a size of the data to be transmitted. The processing unit is further configured to generate a first data certificate based on the address information and the data to be transmitted, the first data certificate uniquely indicating the data to be transmitted. The transceiver unit is further configured to transmit the first data certificate to the untrusted device. The transceiver unit is further configured to receive a first signature result sent by the untrusted device, the first signature result being obtained by the untrusted device signing the first data certificate. The transceiver unit is further configured to control transmission of the data to be transmitted to the untrusted device.

[0050] In a possible embodiment, the first data certificate includes address information and one or more of a digest value of the data to be transmitted, a file locator of the data to be transmitted, and a timestamp of the data to be transmitted.

[0051] In a possible implementation, the processing unit is further configured to generate a second data certificate based on the data to be deleted. The transceiver unit is further configured to send a third data deletion command to the untrusted device, where the untrusted device includes a third ECU or a server, where the third ECU is an untrusted ECU among the multiple ECUs, and the third data deletion command includes the second data certificate, and the third data deletion command indicates deleting the data to be deleted. The transceiver unit is further configured to obtain a second signature result returned by the untrusted device, where the second signature result is obtained by the server signing the second data certificate, and the second signature result indicates that the untrusted device has deleted the data to be deleted.

[0052] A fourth aspect of the present invention provides a first ECU. The first ECU is disposed in a vehicle. The vehicle includes a controller and a plurality of ECUs. The first ECU is one of the plurality of ECUs. The first ECU includes a transceiver unit and a processing unit. The transceiver unit is configured to send a data request message to the controller, the data request message being used to request acquisition of sensor data. The transceiver unit is configured to receive a response message from the controller, the response message indicating to the first ECU to acquire the sensor data. The processing unit is configured to acquire the sensor data based on the response message. When the vehicle triggers deletion of the sensor data in the first ECU, the transceiver unit is further configured to receive a first data deletion command from the controller and delete the sensor data in the first ECU based on the first data deletion command.

[0053] In a possible implementation, the transceiver unit is further configured to establish a communication connection with the sensor based on the information about the sensor, and the response information includes the information about the sensor. The transceiver unit is further configured to obtain sensor data from the sensor based on the communication connection.

[0054] In a possible embodiment, the first data deletion command further indicates to the first ECU to disconnect the communication connection with the sensor.

[0055] In a possible embodiment, if the first ECU is an untrusted device, the transceiver unit is further configured to send address information to the controller, the address information indicating an address space in the first ECU used to store the data to be transmitted, the address information being determined by the first ECU based on a size of the data to be transmitted. The transceiver unit is further configured to receive a first data certificate sent by the controller, the first data certificate being generated based on the address information and the data to be transmitted. The processing unit is further configured to sign the first data certificate to obtain a first signature result. The transceiver unit is further configured to send the first signature result to the controller. The transceiver unit is further configured to receive the data to be transmitted sent by the controller.

[0056] In a possible embodiment, the first data certificate includes address information and one or more of a digest value of the data to be transmitted, a file locator of the data to be transmitted, and a timestamp of the data to be transmitted.

[0057] In a possible embodiment, when the first ECU is an untrusted device, the transceiver unit is configured to receive a third data deletion command sent by the controller, where the third data deletion command includes a second data certificate, and the second data certificate is generated by the controller based on the data to be deleted. The processing unit is further configured to sign the second data certificate to obtain a second signature result. The transceiver unit is further configured to: send the second signature result to the controller, deleting the data to be deleted, and the second signature result indicating that the untrusted device has deleted the data to be deleted.

[0058] A fifth aspect of the present invention provides a controller, the controller comprising a memory and a processor, the memory storing code, the processor configured to execute the code, the execution of which causes the controller to perform a method according to any one of the implementation forms of the first aspect.

[0059] A sixth aspect of the present invention provides an ECU, the ECU including a memory and a processor, the memory storing code, the processor being configured to execute the code, the code being executed causing the ECU to perform a method according to any one of the embodiments of the first aspect.

[0060] According to a seventh aspect of the present invention, there is provided a vehicle including a controller and a plurality of ECUs. The controller is individually connected to the plurality of ECUs. The controller is the control device according to the fifth aspect, and any one of the plurality of ECUs is the ECU according to the sixth aspect.

[0061] An eighth aspect of the present invention provides a computer-readable storage medium, the computer-readable storage medium storing a computer program, which, when run on a computer, enables the computer to perform a method according to any one of the implementations of the first or second aspects.

[0062] A ninth aspect of the present invention provides a computer program product which, when run on a computer, enables the computer to perform a method according to any one of the implementations of the first or second aspect.

[0063] A tenth aspect of the present invention provides a chip including one or more processors, some or all of which are configured to read and execute a computer program stored in a memory to perform a method according to any possible implementation of any one of the preceding aspects.

[0064] Optionally, the chip includes a memory, and the memory and the processor are connected to the memory by using circuits or wires. Optionally, the chip further includes a communication interface, and the processor is connected to the communication interface. The communication interface is configured to receive data and / or information that needs to be processed. The processor obtains the data and / or information from the communication interface, processes the data and / or information, and outputs the processing result via the communication interface. The communication interface may be an input / output interface. The method according to the present application may be performed by one chip or may be performed by multiple chips working together. [Brief explanation of the drawings]

[0065] [Figure 1] FIG. 1 is a diagram schematically illustrating the configuration of a vehicle 100 according to an embodiment of the present invention.

[0066] [Figure 2] FIG. 2 is another schematic diagram of the structure of a vehicle according to an embodiment of the present invention.

[0067] [Figure 3] FIG. 3 is a diagram illustrating a schematic structure of a computer system 101 in a vehicle according to an embodiment of the present application.

[0068] [Figure 4] FIG. 4 is a schematic diagram illustrating a flow chart of a data processing method 400 according to an embodiment of the present application.

[0069] [Figure 5] FIG. 5 is a diagram illustrating a schematic diagram of a human-machine interface for a vehicle according to an embodiment of the present invention.

[0070] [Figure 6] FIG. 6 is a schematic diagram illustrating a flow chart of a data processing method 600 according to an embodiment of the present invention.

[0071] [Figure 7] FIG. 7 is a diagram illustrating a system architecture of a vehicle according to an embodiment of the present invention.

[0072] [Figure 8] FIG. 8 is a diagram illustrating a schematic of the interaction between a controller and an ECU, according to an embodiment of the present invention.

[0073] [Figure 9] FIG. 9 is a diagram showing a schematic structure of a data processing center according to an embodiment of the present invention.

[0074] [Figure 10] FIG. 10 is a schematic diagram illustrating a flow chart of a data processing method 1000 according to an embodiment of the present invention.

[0075] [Figure 11] FIG. 11 is a diagram that illustrates a schematic of the interaction between a controller and an untrusted device, according to one embodiment of the present invention.

[0076] [Figure 12] FIG. 12 is a schematic diagram illustrating a flow chart for exchanging data certificate 1 between an ECU and a controller according to an embodiment of the present invention.

[0077] [Figure 13] FIG. 13 is a diagram showing a schematic structure of a data certificate 1 according to an embodiment of the present invention.

[0078] [Figure 14] FIG. 14 is a diagram illustrating the structure of a controller 1400 according to an embodiment of the present invention.

[0079] [Figure 15] FIG. 15 is a diagram schematically showing a configuration of a first ECU 1500 according to the embodiment of the present invention.

[0080] [Figure 16] FIG. 16 is a diagram illustrating a schematic structure of a computer-readable storage medium 1600 according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0081] The following describes the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. It is clear that the described embodiments are only a part of the embodiments of the present invention, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0082] The data processing method provided in the embodiments of the present invention may be applied to various vehicle-related scenarios, such as scenarios in which a vehicle normally plans a driving route for the vehicle, monitors the vehicle status, or remotely controls the vehicle.

[0083] Hereinafter, the embodiments of the present invention will be described with reference to the drawings. Those skilled in the art can know that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application can also be applied to similar technical problems.

[0084] To facilitate understanding of this solution, in an embodiment of the present invention, the structure of a vehicle provided herein will first be described with reference to Fig. 1. Fig. 1 is a diagram schematically illustrating the configuration of a vehicle 100 according to an embodiment of the present invention.

[0085] In one embodiment, vehicle 100 may be configured to be in a fully or partially autonomous driving mode. For example, vehicle 100 in autonomous driving mode controls vehicle 100, determines the current state of the vehicle and the vehicle's surrounding environment through manual operation, determines possible behaviors of at least one other vehicle in the surrounding environment, determines a confidence level corresponding to the likelihood that the other vehicle will perform the possible behavior, and controls vehicle 100 based on the determined information. When vehicle 100 is in autonomous driving mode, vehicle 100 may be configured to operate without human interaction.

[0086] Vehicle 100 may include various subsystems, such as a driving system 102, a sensor system 104, a control system 106, one or more peripheral devices 108, a power source 110, a computer system 112, and a user interface 116. Optionally, vehicle 100 may include more or fewer subsystems, and each subsystem may include multiple elements. For example, each subsystem may include multiple ECUs. Additionally, each subsystem and component of vehicle 100 may be interconnected via wires or wirelessly.

[0087] The traction system 102 may include components that provide power for the vehicle 100 to move. In one embodiment, the traction system 102 may include an engine 118, an energy source 119, a transmission 120, and wheels / tires 121. The engine 118 may be an internal combustion engine, a motor, an air-compression engine, or a combination of other types of engines, such as a hybrid engine including a gasoline engine and a motor, or a hybrid engine including an internal combustion engine and an air-compression engine. The engine 118 converts the energy source 119 into mechanical energy.

[0088] Examples of energy source 119 include gasoline, diesel, other oil-based fuels, propane, other compressed gas-based fuels, dehydrated alcohol, solar panels, batteries, or other power sources. Energy source 119 may also provide energy to other systems of vehicle 100.

[0089] The transmission 120 transmits mechanical power from the engine 118 to the wheels 121. The transmission 120 may include a gearbox, a differential, and a drive shaft. In one embodiment, the transmission 120 may further include other components, such as a clutch. The drive shaft may include one or more shafts that may be coupled to one or more wheels 121.

[0090] The sensor system 104 may include several sensors capable of sensing information about the environment surrounding the vehicle 100. For example, the sensor system 104 may include a positioning system 122 (which may be a GPS system, a BeiDou system, or another positioning system), an inertial measurement unit (IMU) 124, a radar 126, a laser range finder 128, and a camera 130. The sensor system 104 may also include sensors of internal systems of the monitored vehicle 100 (e.g., an interior air quality monitor, a fuel gauge, or an engine oil temperature gauge). Sensor data from one or more of these sensors may be used to detect objects and corresponding characteristics of the objects (e.g., position, shape, orientation, speed, etc.). Such detection and recognition is an important function for the safe operation of the autonomous vehicle 100.

[0091] Positioning system 122 may be configured to estimate the geographic position of vehicle 100. IMU 124 is configured to sense changes in position and orientation of vehicle 100 based on inertial acceleration. In one embodiment, IMU 124 may be a combination of an accelerometer and a gyroscope.

[0092] Radar 126 uses radio signals to sense objects in the environment surrounding vehicle 100. In some embodiments, in addition to sensing objects, radar 126 may be further configured to sense the speed and / or direction of movement of the objects.

[0093] Laser range finder 128 can use lasers to sense objects in the environment in which vehicle 100 is located. In some embodiments, laser range finder 128 can include one or more laser sources, a laser scanner, one or more detectors, and other system components.

[0094] Camera 130 may be configured to capture multiple images of the environment surrounding vehicle 100. Camera 130 may be a static camera or a video camera.

[0095] The control system 106 controls the operation of the vehicle 100 and the components of the vehicle 100. The control system 106 may include various components, including a steering system 132, a throttle 134, a braking unit 136, a sensor fusion algorithm 138, a computer vision system 140, a route control system 142, and an obstacle avoidance system 144.

[0096] The steering system 132 may be actuated to adjust the direction of travel of the vehicle 100. For example, in one embodiment, the steering system 132 may be a steering wheel system.

[0097] The throttle 134 is configured to control the operating speed of the engine 118 , which in turn controls the speed of the vehicle 100 .

[0098] The brake unit 136 is configured to control the deceleration of the vehicle 100. The brake unit 136 can use friction to decelerate the wheels 121. In other embodiments, the brake unit 136 can convert the kinetic energy of the wheels 121 into electric current. The brake unit 136 can alternatively use another form of reducing the rotational speed of the wheels 121 to control the speed of the vehicle 100.

[0099] Computer vision system 140 may operate to process and analyze images captured by camera 130 to identify objects and / or features within the environment surrounding vehicle 100. Objects and / or features may include traffic signals, road boundaries, and obstacles. Computer vision system 140 may use object recognition algorithms, structure from motion (SFM) algorithms, video tracking, and other computer vision techniques. In some embodiments, computer vision system 140 may be configured to draw a map of the environment, track objects, estimate the speed of objects, etc.

[0100] Route control system 142 is configured to determine a route for vehicle 100. In some embodiments, route control system 142 may determine a route for vehicle 100 by referencing data from sensors 138, GPS 122, and one or more predetermined maps.

[0101] Obstacle avoidance system 144 is configured to recognize, evaluate, and otherwise avoid or circumvent potential obstacles in the environment of vehicle 100.

[0102] Of course, in one example, control system 106 may include additional or alternative components other than those shown and described, or control system 106 may omit some of the aforementioned components.

[0103] The vehicle 100 interacts with external sensors, other vehicles, other computer systems, or a user by using peripheral devices 108. The peripheral devices 108 may include a wireless communication system 146, an on-board computer 148, a microphone 150, and / or a speaker 152.

[0104] In some embodiments, peripheral devices 108 provide a means for a user of vehicle 100 to interact with user interface 116. For example, onboard computer 148 may provide information to the user of vehicle 100. User interface 116 may further operate onboard computer 148 to receive user input. Also, onboard computer 148 may operate via a touch panel. In other cases, peripheral devices 108 may provide a means for vehicle 100 to communicate with other devices located within the vehicle. For example, microphone 150 may receive audio (e.g., voice commands or other audio input) from the user of vehicle 100. Similarly, speaker 152 may output audio to the user of vehicle 100.

[0105] The wireless communication system 146 may wirelessly communicate with one or more devices directly or through a communication network. For example, the wireless communication system 146 may communicate via a 3G cellular network such as CDMA, EVD0, or GSM / GPRS, a 4G cellular network such as LTE, or a 5G cellular network. The wireless communication system 146 may communicate with a wireless local area network (WLAN) via Wi-Fi. In some embodiments, the wireless communication system 146 may communicate directly with devices by using an infrared link, Bluetooth, or ZigBee. Other wireless protocols, e.g., various vehicle communication systems such as the wireless communication system 146, may include one or more dedicated short-range communications (DSRC) devices, which may include public and / or private data communications between vehicles and / or roadside stations.

[0106] Power source 110 can provide power to various components of vehicle 100. In one embodiment, power source 110 can be a rechargeable lithium-ion battery or a lead-acid battery. One or more battery packs of such batteries can be configured as a power source for powering the components of vehicle 100. In some embodiments, power source 110 and energy source 119 can be implemented together, for example, in some purely electric vehicles.

[0107] Some or all of the functions of vehicle 100 are controlled by computer system 112. Computer system 112 may include at least one processor 113. Processor 113 executes instructions 115 stored on a non-transitory computer-readable medium, such as a data storage apparatus 114. Computer system 112 may alternatively be multiple computing devices providing distributed control of individual components or subsystems of vehicle 100.

[0108] Processor 113 may be any conventional processor, such as a commercially available CPU. Alternatively, the processor may be a dedicated device, such as an ASIC or another hardware-based processor. While Figure 1 functionally depicts the processor, memory, and other components of computer 110 within the same block, those skilled in the art should understand that the processor, computer, or memory may actually include multiple processors, computers, or memories that may or may not be housed within the same physical enclosure.

[0109] For example, the memory may be a hard disk drive or another storage medium located in a different enclosure than that of computer 110. Thus, reference to a processor or computer is understood to include reference to a set of processors or computers or memories that may or may not operate in parallel. Unlike using a single processor to perform the steps described herein, some components, such as the steering component and the deceleration component, may include respective processors. The processors perform only calculations related to the component's specific function.

[0110] In various aspects described herein, the processor may be located remotely from the vehicle and in wireless communication with the vehicle. In other aspects, some processes described herein are executed on a processor located within the vehicle, while other processes are executed by a remote processor, including performing the steps necessary for a single operation.

[0111] In some embodiments, data storage 114 may include instructions 115 (e.g., program logic) that may be executed by the processor to perform various functions of vehicle 100, including those described above. Data storage 114 may also include additional instructions, such as instructions for transmitting data to, receiving data from, interacting with, and / or controlling one or more of cruise control system 102, sensor system 104, control system 106, and / or peripherals 108.

[0112] In addition to instructions 115, data storage device 114 may further store data such as road maps, route information, vehicle position, direction, speed, and other vehicle data, and other information that may be used by vehicle 100 and computer system 112 when vehicle 100 operates in autonomous, semi-autonomous, and / or manual modes.

[0113] User interface 116 is configured to provide information to or receive information from a user of vehicle 100. Optionally, user interface 116 may include one or more input / output devices in the set of peripheral devices 108, such as a wireless communication system 146, an on-board computer 148, a microphone 150, and a speaker 152.

[0114] Computer system 112 may control functions of vehicle 100 based on inputs received from various subsystems (e.g., cruise control system 102, sensor system 104, and control system 106) and from user interface 116. For example, computer system 112 may access and use inputs from control system 106 to control steering unit 132 to avoid obstacles detected by sensor system 104 and obstacle avoidance system 144. In some embodiments, computer system 112 may operate to provide control over vehicle 100 and its subsystems in many aspects.

[0115] Optionally, one or more of the aforementioned components may be located separately from or associated with vehicle 100. For example, data storage device 114 may be partially or completely separate from vehicle 1100. The aforementioned components may be communicatively coupled together in wired and / or wireless manner.

[0116] Optionally, the above components are only examples. During actual application, components in the above modules can be added or removed based on actual requirements. Figure 1 should not be construed as a limitation on this embodiment of the present invention.

[0117] An autonomous vehicle traveling on a road, such as vehicle 100, may identify an object in the autonomous vehicle's surrounding environment and determine to adjust its current speed. The object may be another vehicle, a traffic control device, or another type of object. In some examples, each identified object may be considered independently and used to determine the speed to be adjusted by the autonomous vehicle based on characteristics of each object, such as the object's current speed, the object's acceleration, and the distance between the object and the vehicle.

[0118] Optionally, autonomous vehicle 100 or a computing device associated with automated vehicle 100 (such as computer system 112, computer vision system 140, and data storage device 114 of FIG. 1 ) may predict the behavior of the identified objects based on the characteristics of the identified objects and the conditions of the surrounding environment (e.g., traffic, rain, or ice on the road). Optionally, all identified objects depend on each other's behavior, and therefore, all identified objects may be considered together to predict the behavior of a single identified object. Vehicle 100 may adjust the speed of vehicle 100 based on the predicted behavior of the identified objects.

[0119] That is, the autonomous vehicle can determine a stable state (e.g., accelerate, decelerate, stop) to which to adjust the vehicle based on the predicted behavior of the object. In this process, other factors may also be considered to determine the speed of vehicle 100, such as the horizontal position of vehicle 100 on the road it is traveling on, the curvature of the road, and the proximity between static and dynamic objects.

[0120] In addition to providing instructions to adjust the speed of the autonomous vehicle, the computing device may further provide instructions to modify the steering angle of the vehicle 100 so that the autonomous vehicle follows a given trajectory and / or safe lateral and longitudinal distances are maintained between the autonomous vehicle and objects near the autonomous vehicle (e.g., cars in adjacent lanes on the road).

[0121] The vehicle 100 may be a sedan, a truck, a motorcycle, a bus, a recreational vehicle, an amusement park vehicle, a construction device, a tram, a golf cart, a train, etc. This is not particularly limited in the embodiments of the present invention.

[0122] 2 is another diagram schematically illustrating a structure of a vehicle according to an embodiment of the present invention. As shown in FIG. 2, the vehicle includes a controller and a plurality of modules. The controller is separately connected to the plurality of modules, and each module includes one or more ECUs. For example, the plurality of modules may include a body control module (BCM), a human-machine interface (HMI) module, an advanced driver-assistance system (ADAS) module, a smart cockpit domain controller (CDC) module, etc.

[0123] It may also be understood that one controller may manage or control one or more ECUs. The ECUs may be ECUs in the system described in FIG. 1. It may also be understood that a vehicle may include multiple control modules. Each module includes or is connected to one or more ECUs, such as, for example, the driving system 102, the sensor system 104, the steering system 132, the throttle 134, and the brake unit 136. Each module includes one or more ECUs configured to control the vehicle's engine, wheels, steering, throttle, brakes, etc.

[0124] 3 is a schematic diagram of the structure of a computer system 101 in a vehicle according to an embodiment of the present application. The computer system 101 includes a processor 103, which is coupled to a system bus 105. The processor 103 may be configured to implement the functions of the controller of FIG. 2. The processor 103 may be one or more processors, and each processor may include one or more processor cores. A video adapter 107 is further included, which can drive a display 109, which is coupled to the system bus 105. The system bus 105 is coupled to an input / output (I / O) bus 113 via a bus bridge 111. An I / O interface 115 is coupled to the I / O bus. I / O interface 115 communicates with multiple I / O devices, such as input devices 117 (e.g., keyboard, mouse, and touch screen), media tray 121 (e.g., CD-ROM and multimedia interface), transceiver 123 (which may transmit and / or receive wireless communication signals), video camera 155 (which may capture dynamic digital video images), and external USB port 125. Optionally, the interface connected to I / O interface 115 may be a USB port.

[0125] Processor 103 may be any conventional processor, including a reduced instruction set computing ("RISC") processor, a complex instruction set computing ("CISC") processor, or a combination thereof. Optionally, the processor may be a special-purpose device such as an application specific integrated circuit ("ASIC"). Optionally, processor 103 may be a neural network processor, or a combination of a neural network processor and the aforementioned conventional processors.

[0126] Optionally, in various embodiments described herein, computer system 101 may be located remotely from the autonomous vehicle and may communicate wirelessly with the autonomous vehicle. In other aspects, some of the processes described herein are executed on a processor located inside the autonomous vehicle, while other processes, including actions required to perform a single operation, are executed by a remote processor.

[0127] The computer system 101 may communicate with the software deployment server 149 via a network interface 129. The network interface 129 is a hardware network interface, e.g., a network interface card. The network 127 may be an external network, such as the Internet, or an internal network, such as Ethernet or a Virtual Private Network (VPN). Optionally, the network 127 is a wireless network, e.g., a Wi-Fi network or a cellular network.

[0128] The hard disk drive interface is coupled to the system bus 105. The hard disk drive interface is connected to the hard disk drive. The system memory 135 is coupled to the system bus 105. Data executing within the system memory 135 may include an operating system 137 and applications 143 of the computer 101.

[0129] The operating system includes a shell 139 and a kernel 141. The shell 139 is the interface between the user and the operating system kernel. The shell is the outermost layer of the operating system. The shell manages the interaction between the user and the operating system, i.e., waiting for user input, interpreting the user input for the operating system, and handling various outputs of the operating system.

[0130] The kernel 141 is within an operating system and includes the parts used to manage memory, files, peripherals, and system resources, and interacts directly with the hardware. An operating system kernel typically runs processes, provides communication between processes, CPU time slice management, interrupt management, memory management, I / O management, etc.

[0131] The application 143 includes a program 147 related to data processing and a program related to automatic driving control of a vehicle. The program 147 related to data processing is configured to individually manage data of multiple ECUs. By executing the program 147 related to data processing, the computer system 101 realizes the functions of the controller described in FIG. 2, manages data of multiple ECUs, and, for example, deletes data stored in the ECUs.

[0132] Programs related to autonomous control of the vehicle may include, for example, programs for managing the interaction of the autonomous vehicle with obstacles on the roadway, programs for controlling the path or speed of the autonomous vehicle, programs for controlling the interaction of the autonomous vehicle with other autonomous vehicles on the roadway, etc. Applications 143 also reside within the deployment server 149 system.

[0133] Sensor 153 is associated with computer system 101. Sensor 153 is configured to detect the surrounding environment of computer system 101. For example, sensor 153 may detect animals, vehicles, obstacles, crosswalks, etc. The sensor may also detect the surrounding environment of the animal, vehicle, obstacle, or crosswalk. For example, the sensor may detect the surrounding environment of animals, such as other animals in the surrounding environment, weather conditions, and the brightness of the surrounding environment.

[0134] Generally, one or more ECUs are arranged in a vehicle for each vehicle component having an electronic control function, and each ECU has functions such as a control function and a calculation function. In the normal driving process of a vehicle, the ECU in the vehicle usually needs to obtain various types of data of the vehicle in the driving process, such as data on the driving speed and driving position of the vehicle.

[0135] After a vehicle has been running for a certain period of time, the ECU in the vehicle typically stores various types of data generated during the vehicle's operation, and the data stored in the ECU in the vehicle is private data of the vehicle owner. In some cases, the vehicle owner typically wants to delete some of the private data stored in the vehicle to avoid privacy leaks. However, current vehicles do not support the vehicle owner's granular deletion of data from each ECU in the vehicle. The vehicle owner can only delete data from components of the entire vehicle by formatting the vehicle, and deleting data from components of the entire vehicle will affect the vehicle owner's normal operation of the vehicle.

[0136] In view of this, an embodiment of the present invention provides a data processing method, which is applied to a vehicle including a controller and multiple ECUs. Based on the data processing method provided in the embodiment of the present invention, when multiple ECUs in the vehicle need to acquire sensor data, the multiple ECUs send data requests to the controller, and the controller records information about the ECUs' requests for sensor data. In this way, when deletion of specific sensor data is triggered, the controller can determine the ECU that will acquire the sensor data based on the recorded information and send a data deletion command to the ECU, thereby realizing fine-grained management of in-vehicle data.

[0137] The data processing method provided in the embodiments of the present invention will be described in detail below. It should be noted that the data processing method provided in the present invention can be applied to a vehicle. The vehicle includes a controller and multiple ECUs, and the controller is communicatively connected to the multiple ECUs. For any one of the multiple ECUs, the controller can manage the data of the ECU based on the data processing method provided in the embodiments of the present application. Generally, there are usually hundreds of ECUs in a vehicle. The controller may manage each data of the hundreds of ECUs based on the data processing method provided in the embodiments of the present application in order to perform detailed management of the ECUs in the vehicle.

[0138] For ease of explanation, the data processing method provided in the embodiment of the present invention will be described below by using a first ECU as an example. The first ECU is one of the multiple ECUs. FIG. 4 is a schematic flowchart of a data processing method 400 according to an embodiment of the present invention. As shown in FIG. 4, the data processing method 400 includes the following steps 401 to 406.

[0139] Step 401: The controller receives a data request message from a first ECU, where the first ECU is any one of the plurality of ECUs, and the data request message is used to request to acquire sensor data.

[0140] In this embodiment, during execution of the first ECU, the first ECU may need to acquire sensor data to provide an associated vehicle service. When the first ECU needs to acquire sensor data, the first ECU sends a data request message to the controller to request that the required sensor data be acquired.

[0141] For example, assume that a first ECU is an ECU in a position measurement system. To provide a position measurement service, the first ECU needs to acquire sensor data acquired by an associated sensor used for position measurement. Therefore, in this case, the first ECU may send a data request message to a controller to request the sensor data acquired by the associated sensor used for position measurement.

[0142] In another example, the first ECU is assumed to be an ECU in an automatic braking system. To provide the automatic braking service, the first ECU needs to acquire sensor data acquired by a sensor used for ranging and determine the distance between the vehicle and an obstacle based on the sensor data, thereby providing the automatic braking service in real time. For example, the first ECU needs to acquire sensor data acquired by a sensor such as a camera, lidar, or ultrasonic radar. In this case, the first ECU may send a data request message to the controller to request the sensor data acquired by the sensor used for ranging.

[0143] Optionally, the data request message sent by the first ECU may indicate the sensor data requested by the first ECU in a direct indication manner, for example, the data request message may carry a camera identifier, a lidar identifier, or an ultrasonic radar identifier, indicating that camera data, lidar data, or ultrasonic radar data is requested.

[0144] The data request message sent by the first ECU may indicate the sensor data requested by the first ECU in an indirect manner. For example, the data request message indicates that the first ECU needs to request sensor data to provide an automatic braking service. When the data request message indicates that the first ECU needs to request sensor data used to provide the automatic braking service, the controller may determine, based on the data request message, that the sensor data requested by the first ECU is camera data, lidar data, or ultrasonic radar data.

[0145] That is, with respect to the controller, the purpose of the data request message sent by the first ECU is to request sensor data, and the data request message may or may not carry the content of the requested sensor data. The content carried in the data request message is not limited in this embodiment.

[0146] Step 402: The controller sends a response message to the first ECU, where the response message indicates the first ECU to acquire sensor data.

[0147] After the controller receives the data request message sent by the first ECU, the controller may determine whether the first ECU has permission to access the sensor data indicated in the data request message. If the controller determines that the first ECU has permission to access the sensor data indicated in the data request message, the controller sends a response message to the first ECU to instruct the first ECU to obtain the sensor data indicated in the data request message.

[0148] In simple terms, when the first ECU has permission to access the sensor data, the controller returns a response message to the first ECU, which can indicate how the first ECU should acquire the sensor data. When the first ECU does not have permission to access the sensor data, the controller may not return a response message to the first ECU, which can result in the first ECU being unable to acquire the necessary sensor data to perform accurate data management.

[0149] Optionally, a permission configuration policy may be preset in the vehicle, and the permission configuration policy may indicate data access permissions for each ECU. The permission configuration policy may be set by a user via a human-machine interface in the vehicle or a remote terminal. Alternatively, the permission configuration policy may be preset before the vehicle is delivered. The controller determines that the first ECU has permission to access the sensor data according to the preset permission configuration policy.

[0150] For example, a user may set a permission configuration policy via a human-machine interface in a vehicle, and the permission configuration policy may indicate that only ECUs in a positioning system and a navigation system may access data from sensors used for positioning. In this case, if a first ECU is an ECU of the positioning system or the navigation system, and the sensor data requested by the first ECU is data from a sensor used for positioning, the controller may determine that the first ECU has permission to access data from a sensor used for positioning. If the first ECU is not an ECU in the positioning system or the navigation system, and the sensor data requested by the first ECU is data from a sensor used for positioning, the controller may determine that the first ECU does not have permission to access data from a sensor used for positioning.

[0151] Optionally, the response message sent by the controller to the first ECU may alternatively indicate how the first ECU should process the acquired sensor data. For example, the response message sent by the controller may instruct the first ECU to store the acquired sensor data, or further, the response message sent by the controller may further indicate a storage space or capacity within the first ECU to be used to store the acquired sensor data. For example, the response message sent by the controller may indicate that the first ECU should store the acquired sensor data and that the first ECU should store the sensor data in a storage space having a capacity of 10 Megabytes (MB).

[0152] For example, the response message sent by the controller may instruct the first ECU to only read the acquired sensor data but not store the acquired sensor data. For example, if the first ECU is an ECU in a reversing image system, the first ECU is configured to acquire camera data, process the camera data, and provide a reversing image service. In this case, the first ECU provides the reversing image service in real time, and the first ECU does not need to store the acquired camera data. Therefore, the response message sent by the controller may instruct the first ECU to only read the acquired camera data but not store the camera data.

[0153] Step 403: The controller generates mark information based on the data request message, and the mark information records the request information for the sensor data.

[0154] After the controller receives the data request message of the first ECU, the controller generates mark information based on the data request message to record that the first ECU is requesting sensor data. By generating the mark information based on the data request message, the controller can record information about the request for sensor data by each ECU, so that the controller can subsequently effectively determine the data stored in each ECU, and thereby quickly delete the sensor data on a specific ECU.

[0155] Specifically, the mark information generated by the control unit records request information for sensor data. The request information for sensor data includes a requester of the sensor data, a time when the sensor data is requested, and the content of the sensor data. For example, the request information for sensor data may be as follows: The first ECU requests camera data at xx:xx on xx / xx (month / day). Alternatively, the first ECU requests camera data, lidar data, and ultrasonic radar data at xx:xx on xx / xx (month / day).

[0156] It should be noted that the execution order between step 402 and step 403 is not limited in this embodiment. The controller may first execute step 402 and then execute step 403. Alternatively, the controller may first execute step 403 and then execute step 402. Alternatively, the controller may execute step 402 and step 403 in parallel.

[0157] Furthermore, the controller may generate mark information after determining that the first ECU has permission to access the requested sensor data. If the first ECU does not have permission to access the requested sensor data, the controller does not return a response message to the first ECU. Therefore, the first ECU does not need to generate mark information.

[0158] Step 404: The first ECU acquires sensor data based on the response message.

[0159] After obtaining the response message returned by the controller, the first ECU may obtain sensor data based on the response message.

[0160] Optionally, if the response message further indicates how the first ECU should process the acquired sensor data, the first ECU may process the acquired response message based on the instruction of the response message. For example, if the response message indicates that the first ECU needs to store the acquired sensor data and the first ECU needs to store the sensor data in a storage space having a capacity of 10 MB, the first ECU allocates 10 MB of storage space in storage hardware corresponding to the first ECU based on the instruction of the response message, and stores the acquired sensor data in the allocated 10 MB of storage space.

[0161] In addition, after the first ECU stores the acquired sensor data, the first ECU may further send a feedback message to the controller, and may feed back to the controller the address of the storage space used to store the sensor data. For example, the first ECU may send a feedback message to the controller, where the feedback message indicates the start address and the end address of the storage space.

[0162] Step 405: If the vehicle triggers the deletion of the sensor data in the first ECU, the controller sends a first data deletion command to the first ECU based on the mark information, where the first data deletion command indicates the first ECU to delete the sensor data.

[0163] In this embodiment, the vehicle can trigger the deletion of sensor data in the first ECU in several ways.

[0164] In a possible embodiment, the controller determines that the sensor data in the first ECU has expired based on the mark information and a preset data retention period, and triggers deletion of the sensor data in the first ECU. The preset data retention period may be a storage period for in-vehicle data. When the storage time of the data reaches the storage period (i.e., the data has expired), the data needs to be deleted. The preset data retention period may be set by a user or specified by the industry. For example, the preset data retention period may be 10 days or 15 days.

[0165] For example, assume that the mark information generated by the controller indicates that the first ECU requests camera data on January 10, and the preset data retention period is 10 days. In this case, the controller may determine that the camera data requested by the first ECU has expired on January 20 based on the mark information and the preset data retention period. Therefore, the controller sends a first data deletion command to the first ECU to instruct the first ECU to delete the camera data.

[0166] In another possible implementation, the controller receives a second data deletion command triggered by a user, the second data deletion command indicating to delete the sensor data in the first ECU, and after the controller receives the second data deletion command, the controller sends a first data deletion command to the first ECU based on the mark information to instruct the first ECU to delete the sensor data.

[0167] Optionally, the user may trigger the second data deletion command in multiple ways. For example, the user may select data that needs to be deleted on the vehicle's human-machine interface to trigger the second data deletion command. For example, the user may select a specific application on the vehicle's human-machine interface, delete data corresponding to the application, and trigger the second data deletion command. The controller may determine an ECU (i.e., a first ECU) corresponding to the application selected by the user based on the second data deletion command, and send the first data deletion command to the ECU corresponding to the application.

[0168] 5 is a schematic diagram of a vehicle human-machine interface according to an embodiment of the present invention. As shown in FIG. 5, applications installed in the vehicle are displayed on the vehicle's human-machine interface, and each application corresponds to different data. A user may select a specific application on the human-machine interface and delete specific data within the application.

[0169] For example, a user may select a navigation application on a vehicle's human-machine interface, where the navigation application includes data such as positioning data, navigation voice data, and user configuration data. The user may further select to delete positioning data in the navigation application to trigger a second data deletion command. After the controller obtains the second data deletion command in this manner, the controller determines, based on the second data deletion command, that positioning data on an ECU in a navigation system corresponding to the navigation application needs to be deleted. The navigation system may be, for example, a Global Positioning System (GPS)-based navigation system in a vehicle. Therefore, the controller may send a first data deletion command to an ECU in the navigation system (e.g., the aforementioned first ECU). The first data deletion command instructs the ECU to delete positioning-related sensor data.

[0170] In addition, the user may select data that needs to be deleted on a terminal (e.g., a smartphone) remotely connected to the vehicle and trigger a second data deletion command. The terminal remotely connected to the vehicle may display applications installed in the vehicle, and it can be understood that each application corresponds to different data. The user can select a specific application from the terminal and delete specific data within the application.

[0171] Alternatively, the user may trigger the second data deletion command by changing the application's permission on the vehicle's human-machine interface or on a terminal remotely connected to the vehicle. Specifically, before the user changes the application's permission, the application has permission to access the sensor data, i.e., the ECU in the system corresponding to the application also has permission to access the sensor data. After the user changes the application's permission, the application no longer has permission to access the sensor data, i.e., the ECU in the system corresponding to the application no longer has permission to access the sensor data. Therefore, the controller needs to send a data deletion command to the ECU to instruct the ECU to delete previously acquired sensor data.

[0172] For example, before a user changes the permissions of a navigation application, the navigation application has permission to access positioning data, i.e., the ECU in the navigation system corresponding to the navigation application has permission to access positioning-related sensor data. Therefore, the ECU in the navigation system can send a data request message to the controller to request positioning-related sensor data and store the acquired sensor data in storage hardware within the ECU. After a user changes the permissions of the navigation application, the navigation application no longer has permission to access positioning data, i.e., the ECU in the navigation system corresponding to the navigation application no longer has permission to access positioning-related sensor data. Therefore, the controller can send a data deletion command to the ECU in the navigation system to instruct the ECU to delete previously acquired positioning-related sensor data.

[0173] In addition, when multiple ECUs have all acquired sensor data, when a user distributes a command to delete the sensor data, the controller may determine the multiple ECUs that acquired the sensor data based on mark information generated when the multiple ECUs request the sensor data, and may send data deletion instructions to the multiple ECUs separately, instructing each of the multiple ECUs to delete the sensor data.

[0174] For example, assume that both ECU1 and ECU2 request data for camera 1 from the controller, and a user delivers data deletion instruction 1 via a human-machine interface. Data deletion instruction 1 indicates that the data for camera 1 should be deleted. The controller sends data deletion instruction 2 to ECU1 and data deletion instruction 3 to ECU2 based on mark information 1 and mark information 2. Mark information 1 indicates that ECU1 requests data for camera 1, mark information 2 indicates that ECU2 requests data for camera 1, data deletion instruction 2 indicates that the data for camera 1 stored in ECU1 should be deleted, and data deletion instruction 3 indicates that the data for camera 1 stored in ECU2 should be deleted.

[0175] In other words, the controller may determine, based on the acquired second data deletion command, that deletion of sensor data by multiple ECUs needs to be triggered, and the first ECU is one of the multiple ECUs whose sensor data needs to be deleted. Then, based on the second data deletion command, the controller may separately send corresponding data deletion commands to the multiple ECUs to instruct each ECU to delete the corresponding sensor data. For example, the controller may send a first data deletion command to the first ECU to instruct the first ECU to delete the sensor data in the first ECU.

[0176] Step 406: The first ECU deletes the sensor data in the first ECU based on the first data deletion command.

[0177] Optionally, when the first ECU feeds back the address of the storage space used to store the sensor data, the controller may add the address of the storage space used to store the sensor data to the first data deletion command, so as to instruct the first ECU to delete the sensor data stored in the storage space based on the address of the storage space. Thus, when the first data deletion command indicates the address of the storage space, the first ECU may delete the sensor data in the storage space based on the address of the storage space indicated by the first data deletion command.

[0178] In this embodiment, when multiple ECUs in a vehicle need to acquire sensor data, the multiple ECUs send data requests to the controller, and the controller records information about the ECUs' requests for sensor data. In this way, when deletion of specific sensor data is triggered, the controller can determine the ECUs that will acquire the sensor data based on the recorded information and send data deletion instructions to the ECUs, thereby achieving fine-grained management of in-vehicle data.

[0179] The above has described the process in which the control unit instructs the first ECU to acquire and delete sensor data. Specific processes in which the first ECU acquires sensor data will be described later. FIG. 6 is a diagram schematically showing a flowchart of a data processing method 600 according to one embodiment of the present invention. As shown in FIG. 6, the data processing method 600 includes the following steps 601 to 606.

[0180] Step 601: The sensor registers a service with the controller.

[0181] In this embodiment, a sensor installed in a vehicle may register a service with the controller to provide data services to other components in the vehicle. After the sensor registers a service, the controller may obtain relevant configuration information of the sensor, such as the sensor's port information and the sensor's identity document (ID) information.

[0182] Step 602: The controller receives a data request message from a first ECU, where the first ECU is any one of the plurality of ECUs, and the data request message is used to request to obtain sensor data.

[0183] In this embodiment, step 602 is similar to step 401. For details, please refer to step 401. The details will not be described again in this specification.

[0184] Step 603: The controller sends a response message to the first ECU, where the response message indicates to the first ECU to acquire sensor data.

[0185] In this embodiment, the response message sent by the controller includes information about the sensor, and the information about the sensor is used by the first ECU to establish a communication connection with the sensor so that the first ECU acquires sensor data from the sensor. For example, the controller determines the sensor to which the sensor data acquired by the first ECU belongs based on the data request message sent by the first ECU, and then includes information about the sensor in the response message based on the service registered by the sensor with the controller. The information about the sensor may include, for example, sensor port information, sensor ID information, etc.

[0186] Step 604: The controller generates mark information based on the data request message, where the mark information records the request information for the sensor data.

[0187] In this embodiment, step 604 is similar to step 403. For details, please refer to step 403. The details will not be described again here.

[0188] Step 605: The first ECU establishes a communication connection with the sensor based on the information about the sensor, and response information includes the information about the sensor.

[0189] After the first ECU receives the response message returned by the controller, the first ECU establishes a communication connection with the sensor based on the information about the sensor in the response message, i.e., the first ECU may establish a communication pipeline between the first ECU and the sensor based on the port information of the sensor to establish the communication connection with the sensor.

[0190] Step 606: The first ECU acquires sensor data from the sensor based on the communication connection.

[0191] After establishing a communication connection with the sensor, the first ECU may acquire sensor data generated by the sensor from the sensor in real time.

[0192] When the vehicle triggers the deletion of the sensor data in the first ECU, the controller sends a first data deletion command to the first ECU, where the first data deletion command indicates to the first ECU to delete the sensor data.

[0193] Optionally, if the first ECU acquires sensor data by establishing a communication connection with the sensor, the first data deletion instruction may indicate to the first ECU to disconnect the communication connection with the sensor. For example, if a user changes the application permissions so that the first ECU no longer has permission to access the sensor data, the controller may send the first data deletion instruction to the first ECU. The first data deletion instruction instructs the first ECU to delete the sensor data and disconnect the communication connection with the sensor. Based on the first data deletion instruction, the first ECU may delete the stored sensor data, remove the communication pipeline between the first ECU and the sensor, and disconnect the communication connection between the first ECU and the sensor.

[0194] For ease of understanding, the data processing method provided in the embodiments of the present application will be described in detail below with reference to specific examples. Figure 7 is a diagram schematically illustrating the system architecture of a vehicle according to an embodiment of the present invention.

[0195] 7, the vehicle includes a vehicle domain controller (VDC), a mobile data center (MDC), a smart cockpit domain controller (CDC), and multiple vehicle interface units (VIU). The VIU in the vehicle is communicatively connected to, for example, a cloud server via a communication module in the vehicle. Each of the VDC, MDC, CDC, and VIU may include one or more ECUs.

[0196] In this embodiment, a complex operating system, such as an Automotive Open System Architecture (AUTOSAR) adaptive platform, can be deployed on components with complex computing capabilities within a vehicle. A simple operating system, such as a Classic Automotive Open System Architecture (Classic AutoSAR) platform, can be deployed on components with weak computing capabilities within a vehicle. For example, in FIG. 7, AutoSAR may be deployed on the VDC, and the MDC, CDC, and Classic AutoSAR may be deployed on the VIU. Based on AUTOSAR deployed on the VDC, software used to manage in-vehicle data may also be deployed on the VDC. This software is the data processing center shown in FIG. 7.

[0197] For the MDC, CDC, and VIU where Classic AutoSAR is deployed, components, i.e., software used to process data at the data execution end shown in Figure 7, may be further deployed on the MDC, CDC, and VIU. In addition, the data execution end may be deployed on a cloud server and configured to perform data processing according to instructions from the VDC.

[0198] Specifically, the VDC may manage data on each ECU in the MDC, CDC, and VIU by using a deployed data processing center, and the MDC, CDC, and VIU may obtain data processing instructions delivered by the VDC to obtain or delete sensor data by using a deployed data execution end.

[0199] Furthermore, in this embodiment, the data processing method provided in the embodiment of the present application is detailed by using the VDC as the controller and any ECU of the MDC, CDC, or VIU as the ECU interacting with the controller.

[0200] 8 is a diagram illustrating the interaction between a controller and an ECU according to an embodiment of the present invention. As shown in FIG. 8, the controller includes a process, a data processing center, a middleware, a storage space, and a communication unit.

[0201] Processes within the controller are used to implement several functions provided by the vehicle. Middleware is a type of software between the application and the system software. It uses basic services provided by the system software to connect various parts of the application or different applications and implement resource sharing and functionality sharing.

[0202] The storage space in the controller is used to store various types of data that need to be used by the process during execution. The communication unit in the controller is configured to communicatively connect to a communication module in the vehicle, thereby allowing the controller to communicate with other components (e.g., ECUs) in the vehicle.

[0203] In the controller, processes and middleware must go through the data processing center before accessing data in the storage space. In other words, the data processing center becomes a new resource manager entity for managing and controlling data access and storage.

[0204] 9 is a schematic diagram of the structure of a data processing center according to an embodiment of the present invention. As shown in FIG. 9, the data processing center includes a data marking module, a policy engine, and a storage service module. The data marking module is configured to generate mark information based on a data request message sent by a data execution end in the ECU to mark sensor data requested by the ECU. The policy engine is configured to determine whether data in the ECU is stale based on a preset data retention period and the mark information. The storage service module is configured to manage and control the behavior of accessing or storing data by a process in the controller.

[0205] Furthermore, the ECU includes a process, a data execution end, a storage space, and a communication unit. The process in the ECU is used to implement the function provided by the ECU, and when accessing the storage space in the ECU, the process in the ECU needs to pass through the data execution end in the ECU. The data execution end in the ECU subscribes to the service of the data processing center in the controller, receives instructions from the data processing center, and controls writing and deleting data. The communication unit in the ECU is configured to be communicatively connected to a communication module in the vehicle, so that the ECU communicates with another component in the vehicle (e.g., a controller or a sensor).

[0206] In practical application, when a process in the ECU needs to acquire sensor data, the data execution end sends a data request message to the data processing center in the controller. The data processing center in the controller receives the data request message, determines whether the ECU has permission to access the sensor data, and if the ECU has permission to access the sensor, returns a response message to the data execution end. After receiving the response message, the data execution end establishes a communication connection with the sensor based on the response message, acquires sensor data from the sensor, and stores the sensor data in the storage space in the ECU.

[0207] Furthermore, after the data processing center receives the data request message sent by the ECU, the data marking module of the data processing center generates marking information to record that the ECU is requesting sensor data at a specific time. After the policy engine in the data processing center determines that the sensor data in the ECU has expired based on the marking information and the preset data retention period, the data processing center sends a data deletion command to the data execution end in the ECU to instruct the data execution end to delete the sensor data in the storage space of the ECU. Finally, the data execution end deletes the sensor data in the storage space of the ECU based on the data deletion command. When the data deletion command sent by the data processing center of the controller further instructs the ECU to disconnect the communication connection with the sensor, the data execution end deletes the communication pipeline between the ECU and the sensor.

[0208] Hereinafter, a procedure in which a controller manages data in an ECU in a vehicle in an embodiment of the present invention will be described. Hereinafter, a procedure in which a controller manages data in an untrusted device will be described.

[0209] It may be understood that in addition to interacting with a trusted ECU in the vehicle, the controller may further interact with another untrusted device. For example, the controller may interact with an untrusted ECU or a third-party device in the vehicle, so that the untrusted ECU or the third-party device can obtain corresponding data. Alternatively, the controller may interact with a cloud server and instruct the server to upload in-vehicle data to the server or delete vehicle-related data. The untrusted ECU may be an ECU manufactured by an unauthorized manufacturer, and the security of the ECU cannot be ensured. The third-party device may be, for example, a device installed by a user in the vehicle, such as an audio device, a navigation device, or a multimedia device.

[0210] With respect to the controller in the vehicle, the untrusted ECU in the vehicle, the third-party device, and the cloud server are untrusted devices, i.e., devices that are not trusted by the controller. In the process of performing data interaction with the untrusted device, the controller needs to store evidence of the data interaction to ensure the authenticity of the data interaction.

[0211] 10 is a diagram schematically showing a flowchart of a data processing method 1000 according to one embodiment of the present invention. As shown in FIG. 10, the data processing method 1000 includes the following steps 1001 to 1006.

[0212] Step 1001: A controller sends a data indication message to an untrusted device, where the data indication message indicates the size of data to be sent.

[0213] When data needs to be sent to an untrusted device, the controller sends a data indication message to the untrusted device based on the size of the data to be sent to the untrusted device, where the data indication message indicates the size of the data to be sent, and the data to be sent is the data to be sent to the untrusted device.

[0214] The untrusted device may include a second ECU or a server, and the second ECU may be an untrusted ECU among the plurality of ECUs. In other words, the untrusted device may be a component in a vehicle or a cloud server.

[0215] During practical applications, there may be multiple scenarios where data needs to be transmitted to untrusted devices.

[0216] In a possible scenario, the untrusted device is a second ECU, which requests to obtain sensor data from the controller, and the second ECU has permission to access the sensor data. In this scenario, the controller needs to control the sensor to send data to the second ECU. Therefore, the controller sends a data instruction message to the second ECU to indicate the size of the sensor data to be sent.

[0217] In another possible scenario, the untrusted device is a second ECU, and the second ECU requests the controller to retrieve data stored in the controller. In this scenario, the controller needs to send data stored in the controller's storage space to the second ECU. Therefore, the controller sends a data instruction message to the second ECU to indicate the size of the data to be sent.

[0218] In yet another possible scenario, the untrusted device is a server, and the server requests to retrieve in-vehicle data from the controller. When the data the server requests to retrieve is located on the controller, the controller may send a data instruction message to the server based on the size of the data to be transmitted. When the data the server requests to retrieve is located on a component external to the controller, the controller may interact with the component, determine the size of the data to be transmitted, and then send a data instruction message to the server.

[0219] Step 1002: The controller receives address information sent by the untrusted device, the address information indicating an address space within the untrusted device used to store data to be transmitted, the address information being determined by the untrusted device based on the size of the data to be transmitted.

[0220] After the untrusted device obtains the data indication message, the untrusted device may allocate storage space for the data to be transmitted based on the size of the data to be transmitted, and send address information of the storage space to the controller, which will be used later to store the data to be transmitted. Simply put, the address information sent by the untrusted device to the controller indicates the address of the storage space reserved by the untrusted device for the data to be transmitted.

[0221] Step 1003: The controller generates a first data certificate based on the address information and the data to be transmitted, where the first data certificate uniquely indicates the data to be transmitted.

[0222] The controller may generate a first data certificate based on the data to be transmitted and the address information returned by the untrusted device, where the first data certificate may uniquely represent the data to be transmitted.

[0223] Optionally, the first data certificate includes address information and one or more of a digest value of the data to be transmitted, a file locator of the data to be transmitted, and a timestamp of the data to be transmitted. Specifically, the digest value of the data to be transmitted may be a hash value of the data to be transmitted, and the controller may calculate the hash value of the data to be transmitted by using a hash algorithm. The file locator of the data to be transmitted may be, for example, a Uniform Resource Locator (URL), and the file locator may indicate the location of the data to be transmitted. The timestamp of the data to be transmitted may be a generation time of the data to be transmitted.

[0224] Step 1004: The controller sends the first data certificate to the untrusted device.

[0225] Step 1005: The controller receives a first signature result sent by the untrusted device, where the first signature result is obtained by signing a first data certificate by the untrusted device.

[0226] In this embodiment, after the controller transmits the first data certificate to the untrusted device, the untrusted device may perform a signature verification on the first data certificate, i.e., perform a digital signature on the first data certificate, to indicate that the untrusted device has obtained the first data certificate and acknowledged the subsequent data transmission.

[0227] Step 1006: The controller controls the transmission of the data to be transmitted to the untrusted device.

[0228] After the controller obtains the first signature result returned by the untrusted device, the controller may determine that the untrusted device has performed signature verification on the first data credential, and thus may control the transmission of data to be sent to the untrusted device.

[0229] There may be multiple implementations in which the controller may control the transmission of data to be sent to an untrusted device.

[0230] In one embodiment, when the untrusted device is a second ECU and the second ECU requests to obtain sensor data from the controller, the controller can instruct the second ECU to obtain the sensor data from the sensor by returning information about the sensor to the second ECU, i.e., the controller controls the transmission of data to be transmitted to the untrusted device by returning information about the establishment with the sensor to the untrusted device.

[0231] In another embodiment, if the untrusted device is a second ECU or a server and the data to be transmitted is located in the storage space of the controller, the controller may transmit the data in the storage space of the controller to the second ECU or the server to control the transmission of the data to be transmitted to the untrusted device.

[0232] In yet another possible implementation, if the untrusted device is a server and the data to be transmitted is located on a component other than the controller, the controller may communicate with the component that stores the data to be transmitted and indicate to the component to transmit the data to the server.

[0233] In this embodiment, before data is transmitted to the untrusted device, the controller obtains address information returned by the untrusted device and used to store the data to be transmitted, and generates a data certificate based on the address information and the data to be transmitted. The data is transmitted to the untrusted device after the data certificate is signed by the untrusted device. The controller stores the data certificate signed by the untrusted device, thereby providing evidence of data transmission to the untrusted device, thereby eliminating the threat that the untrusted device repudiates (that the untrusted device does not receive the data) after receiving the data and improving the reliability of data transmission.

[0234] The above is the procedure for the controller to send data to the untrusted device. The procedure for the controller to instruct the untrusted device to delete data has been described above. Specifically, the method 1000 further includes the following steps 1007 to 1009.

[0235] Step 1007: The controller generates a second data certificate based on the data to be deleted.

[0236] If the controller determines that data in the untrusted device needs to be deleted, the controller generates a second data certificate based on the data to be deleted, and the second data certificate may include one or more of a digest value of the data to be deleted, a file locator of the data to be deleted, and a timestamp of the data to be deleted.

[0237] Optionally, the controller may obtain a data deletion instruction delivered by a user to determine that the data on the untrusted device needs to be deleted. Alternatively, the controller may learn through calculation that the data on the untrusted device will expire to determine that the data on the untrusted device needs to be deleted. Specifically, the manner in which the controller triggers the deletion of data in the untrusted device is similar to the manner described in step 405. For details, please refer to step 405. The details will not be described again in this specification.

[0238] Step 1008: The controller sends a third data deletion command to the untrusted device, where the untrusted device includes a third ECU or a server, the third ECU is an untrusted ECU among the multiple ECUs, the third data deletion command includes the second data certificate, and the third data deletion command indicates to delete the data to be deleted.

[0239] The third ECU and the second ECU may be the same ECU or different ECUs. The controller may include the second data certificate in the third data deletion instruction to indicate to an untrusted device to delete the data indicated in the third data deletion instruction when signing the second data certificate.

[0240] Step 1009: The controller obtains a second signature result returned by the untrusted device, where the second signature result is obtained by the server signing a second data certificate, and the second signature result indicates that the untrusted device has deleted the data to be deleted.

[0241] In this embodiment, after receiving the third data deletion instruction sent by the controller, the untrusted device signs the second data certificate carried in the third data deletion instruction to obtain a second signature result, and then sends the second signature result to the controller to delete the data indicated in the third data deletion instruction.

[0242] After obtaining the second signature result, the controller may store the second signature result, and the second signature result may prove that the untrusted device has obtained an instruction indicating that the untrusted device deletes the data and that the untrusted device has agreed to delete the indicated data.

[0243] In this embodiment, before the controller instructs the untrusted device to delete data, the controller generates a data certificate based on the data to be deleted. When instructing the untrusted device to delete data, the controller sends the data certificate to the untrusted device, so that the controller can obtain the result obtained by the untrusted device signing the data certificate. The controller stores the result obtained by the untrusted device signing the data certificate, so as to provide evidence that the untrusted device has confirmed the data deletion, thereby eliminating the threat that the untrusted device will deny receiving the data deletion command and improving the reliability of data transmission.

[0244] For ease of understanding, the process by which a controller exchanges data with an untrusted device is described in detail below with reference to a specific example.

[0245] 11 is a diagram illustrating a schematic diagram of an interaction between a controller and an untrusted device according to an embodiment of the present invention. As shown in FIG. 11, the procedure of the interaction between the controller and the untrusted device includes the following steps S1 to S5.

[0246] S1: The ECU requests sensor data from the controller.

[0247] When the ECU needs to acquire sensor data, the ECU sends a data request message to the controller to request acquisition of the required sensor data. After determining that the ECU has permission to access the sensor data, the controller feeds back to the ECU the size of the sensor data to be transmitted.

[0248] S2: The ECU exchanges data certificate 1 with the controller.

[0249] Specifically, FIG. 12 is a schematic diagram illustrating a flow chart for exchanging data certificate 1 between an ECU and a controller according to an embodiment of the present invention.

[0250] As shown in FIG. 12, after obtaining the size of the sensor data to be transmitted, the ECU transmits address information to the controller, where the address information indicates an address in the address space reserved by the ECU. The address space reserved by the ECU is used to store the sensor data to be transmitted. The controller generates a hash value, a file locator, and a timestamp corresponding to the sensor data to be transmitted based on the sensor data to be transmitted. Furthermore, the controller generates Data Certificate 1 based on the hash value, the file locator, and the timestamp corresponding to the sensor data to be transmitted and the address information obtained from the ECU. Next, the controller transmits the generated Data Certificate 1 to the ECU. After signing Data Certificate 1, the ECU returns the signature result obtained by signing Data Certificate 1 to the controller, and the controller then stores the signature result obtained by the ECU signing Data Certificate 1.

[0251] 13 is a diagram schematically illustrating the structure of a data certificate 1 according to an embodiment of the present invention. As shown in FIG. 13, for a sensor, the sensor may transmit sensor data in real time. For an untrusted device (e.g., an ECU and a server in this embodiment), the untrusted device receives a data certificate transmitted by the controller, where the data certificate includes a file locator (URI), a timestamp, a hash value (Hash), and address information (Address) corresponding to the sensor data. For the controller, the controller may receive a signature result returned by the untrusted device, where the signature result includes the aforementioned data certificate and a signature (Sign) of the untrusted device.

[0252] S3: The ECU establishes a communication connection with the sensor and receives sensor data from the sensor.

[0253] After the controller receives the signature result returned by the ECU, the controller sends a response message to the ECU, where the response message includes information about the sensor. The information about the sensor may include, for example, port information about the sensor. After receiving the information about the sensor, the ECU establishes a communication connection with the sensor based on the information about the sensor and receives sensor data from the sensor.

[0254] S4: The controller exchanges data certificate 2 with the server.

[0255] When the server sends a data request message to the controller to request sensor data on the ECU, after determining that the server has permission to access the sensor data, the controller feeds back to the server the size of the data to be uploaded. After obtaining the size of the data to be uploaded, the server sends address information to the controller, where the address information indicates an address of an address space reserved by the server. The address space reserved by the server is used to store the data to be uploaded. Based on the data to be uploaded, the controller generates a hash value, a file locator, and a timestamp corresponding to the data to be uploaded.

[0256] Furthermore, the controller generates Data Certificate 2 based on the hash value, file locator, and timestamp corresponding to the data to be uploaded, as well as the address information obtained from the server. Then, the controller sends the generated Data Certificate 2 to the server. After signing Data Certificate 2, the server returns the signature result obtained by signing Data Certificate 2 to the controller, so that the controller stores the signature result obtained by the server signing Data Certificate 1.

[0257] S5: The ECU uploads the sensor data to the server based on instructions from the controller.

[0258] After the controller obtains the signature result returned by the server, the controller sends a data upload command to the ECU to instruct the ECU to upload the sensor data to the server.

[0259] According to the embodiments corresponding to Figures 1 to 13, in order to better implement the aforementioned solutions in the embodiments of the present application, the following further provides related devices configured to implement the aforementioned solutions.

[0260] 14 is a diagram schematically illustrating the structure of a controller 1400 according to an embodiment of the present invention. The controller 1400 is disposed in a vehicle. The vehicle further includes a plurality of ECUs. The controller 1400 includes a transceiver unit 1401 and a processing unit 1402.

[0261] The transceiver unit 1401 is configured to receive a data request message from a first ECU, where the first ECU is any one of the multiple ECUs, and the data request message is used to request to obtain sensor data.

[0262] The transceiver unit 1401 is further configured to send a response message to a first ECU, where the response message indicates the first ECU to acquire sensor data.

[0263] The processing unit 1402 is configured to generate mark information based on the data request message, where the mark information records the request information for the sensor data.

[0264] When the vehicle triggers the deletion of the sensor data in the first ECU, the transceiver unit 1401 is further configured to send a first data deletion command to the first ECU based on the mark information, where the first data deletion command indicates the first ECU to delete the sensor data.

[0265] In a possible implementation, the request information for the sensor data includes a requester of the sensor data, a time of request for the sensor data, and a content of the sensor data.

[0266] In a possible implementation form, the processing unit 1402 is further configured to determine that the sensor data in the first ECU is expired based on the mark information and a predetermined data retention period; or the transceiver unit 1401 is further configured to obtain a second data deletion command triggered by a user, the second data deletion command instructing to delete the sensor data in the first ECU.

[0267] In a possible implementation, the response message includes sensor information, which is used by the first ECU to establish a communication connection with the sensor, so that the first ECU can obtain sensor data from the sensor.

[0268] In a possible embodiment, the first data deletion command further indicates to the first ECU to disconnect the communication connection with the sensor.

[0269] In a possible implementation, the processing unit 1402 is further configured to determine that the first ECU has permission to access the sensor data according to a preset permission configuration policy.

[0270] In a possible implementation, the transceiver unit 1401 is further configured to receive address information sent by an untrusted device, the untrusted device including a second ECU or a server, the second ECU being an untrusted ECU among the plurality of ECUs, the address information indicating an address space in the untrusted device used to store data to be transmitted, the address information being determined by the untrusted device based on a size of the data to be transmitted. The processing unit 1402 is further configured to generate a first data certificate based on the address information and the data to be transmitted, the first data certificate uniquely indicating the data to be transmitted. The transceiver unit 1401 is further configured to transmit the first data certificate to the untrusted device. The transceiver unit 1401 is further configured to receive a first signature result sent by the untrusted device, the first signature result being obtained by the untrusted device signing the first data certificate. The transceiver unit 1401 is further configured to control transmission of the data to be transmitted to the untrusted device.

[0271] In a possible embodiment, the first data certificate includes address information and one or more of a digest value of the data to be transmitted, a file locator of the data to be transmitted, and a timestamp of the data to be transmitted.

[0272] In a possible implementation, the processing unit 1402 is further configured to generate a second data certificate based on the data to be deleted. The transceiver unit 1401 is further configured to send a third data deletion command to the untrusted device, where the untrusted device includes a third ECU or a server, where the third ECU is an untrusted ECU among the multiple ECUs, and the third data deletion command includes the second data certificate, and the third data deletion command indicates deleting the data to be deleted. The transceiver unit 1401 is further configured to obtain a second signature result returned by the untrusted device, where the second signature result is obtained by the server signing the second data certificate, and the second signature result indicates that the untrusted device has deleted the data to be deleted.

[0273] FIG. 15 is a diagram schematically illustrating a configuration of a first ECU 1500 according to an embodiment of the present invention. The first ECU 1500 is disposed in a vehicle. The vehicle includes a controller and multiple ECUs. The first ECU 1500 is one of the multiple ECUs. The first ECU 1500 includes a transceiver unit 1501 and a processing unit 1502. The transceiver unit 1501 is configured to send a data request message to the controller, where the data request message is used to request acquisition of sensor data. The transceiver unit 1501 is configured to receive a response message from the controller, where the response message indicates to the first ECU to acquire the sensor data. The processing unit 1502 is configured to acquire the sensor data based on the response message. When the vehicle triggers deletion of the sensor data in the first ECU, the transceiver unit 1501 is further configured to receive a first data deletion command from the controller and delete the sensor data in the first ECU based on the first data deletion command.

[0274] In a possible implementation, the transceiver unit 1501 is further configured to establish a communication connection with the sensor based on the information about the sensor, and the response information includes the information about the sensor. The transceiver unit 1501 is further configured to acquire sensor data from the sensor based on the communication connection.

[0275] In a possible embodiment, the first data deletion command further indicates to the first ECU to disconnect the communication connection with the sensor.

[0276] In a possible embodiment, if the first ECU is an untrusted device, the transceiver unit 1501 is further configured to send address information to the controller, where the address information indicates an address space in the first ECU used to store the data to be transmitted, and the address information is determined by the first ECU based on the size of the data to be transmitted. The transceiver unit 1501 is further configured to receive a first data certificate sent by the controller, where the first data certificate is generated based on the address information and the data to be transmitted. The processing unit 1502 is further configured to sign the first data certificate to obtain a first signature result. The transceiver unit 1501 is further configured to send the first signature result to the controller. The transceiver unit 1501 is further configured to receive the data to be transmitted sent by the controller.

[0277] In a possible embodiment, the first data certificate includes address information and one or more of a digest value of the data to be transmitted, a file locator of the data to be transmitted, and a timestamp of the data to be transmitted.

[0278] In a possible embodiment, when the first ECU is an untrusted device, the transceiver unit 1501 is further configured to receive a third data deletion command sent by the controller, where the third data deletion command includes a second data certificate, and the second data certificate is generated by the controller based on the data to be deleted. The processing unit 1502 is further configured to sign the second data certificate to obtain a second signature result. The transceiver unit 1501 is further configured to: send the second signature result to the controller, deleting the data to be deleted, and the second signature result indicating that the untrusted device has deleted the data to be deleted.

[0279] The data processing method provided in the embodiments of the present invention may be specifically performed by a chip in an electronic device. The chip includes a processing unit and a communication unit. The processing unit may be, for example, a processor, and the communication unit may be, for example, an input / output interface, a pin, or a circuit. The processing unit may execute computer-executable instructions stored in the storage unit, so that the chip in the server performs the data processing method described in the embodiments shown in FIGS. 1 to 13. Optionally, the storage unit is a storage unit within the chip, such as a register or a cache. Alternatively, the storage unit may be a storage unit at the end of the wireless access device and located outside the chip, such as a read-only memory (ROM), another type of static storage device capable of storing static information and instructions, or a random access memory (RAM).

[0280] 16 is a schematic diagram of the structure of a computer-readable storage medium or computer-readable storage medium 1600 according to an embodiment of the present invention. Embodiments of the present invention further provide a computer-readable storage medium. In some embodiments, the method disclosed in FIG. 4 may be implemented as computer program instructions encoded in a machine-readable format on a computer-readable storage medium or another non-transitory medium or article of manufacture.

[0281] 16 schematically illustrates a conceptual partial view of an exemplary computer-readable storage medium arranged in accordance with at least some embodiments presented herein. The exemplary computer-readable storage medium includes a computer program for executing a computer process on a computing device.

[0282] In one embodiment, computer-readable storage medium 1600 is provided through the use of signal-bearing medium 1601. Signal-bearing medium 1601 can include one or more program instructions 1602, which, when executed by one or more processors, can provide the functionality or several of the functionality described above with respect to Figure 7. Additionally, program instructions 1602 of Figure 16 also describe exemplary instructions.

[0283] In some examples, the signal-bearing medium 1601 may include a computer-readable medium 1603, such as, but not limited to, a hard disk drive, a compact disc (CD), a digital video disc (DVD), digital tape, memory, ROM, or RAM.

[0284] In some implementations, signal bearing medium 1601 may include computer-recordable medium 1604, such as, but not limited to, memory, read / write (R / W) CDs, and R / W DVDs. In some implementations, signal bearing medium 1601 may include communication medium 1605, such as, but not limited to, digital and / or analog communication media (e.g., fiber optic cable, waveguide, wired communication link, or wireless communication link). Thus, for example, signal bearing medium 1601 may be carried by wireless communication medium 1605 (e.g., wireless communication medium conforming to the IEEE 802.9 standard or another transmission protocol).

[0285] The one or more program instructions 1602 may be, for example, computer-executable instructions or logic-implemented instructions. In some examples, the computing device may be configured to provide various operations, functions, or actions in response to program instructions 1602 transmitted to the computing device by using one or more of computer-readable medium 1603, computer-recordable medium 1604, and / or communication medium 1605.

[0286] It should be understood that the configurations described herein are used merely as examples. Thus, it will be understood by those skilled in the art that other arrangements and other elements (e.g., machines, interfaces, functions, sequences, and groupings of functions) may be used instead, and that some elements may be omitted altogether based on the expected results. In addition, many of the described elements are functional entities that may be implemented as separate or distributed components, or in combination with other components, in any suitable location and in any suitable combination.

[0287] Those skilled in the art will clearly understand that for convenience of description, the detailed operation processes of the aforementioned systems, devices and units may be referred to the corresponding processes in the aforementioned method embodiments, and the details will not be described again in this specification.

[0288] In some embodiments provided herein, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the described device embodiments are merely examples. For example, the division into units is merely a division of logical functions, and actual implementation may result in other divisions. For example, multiple units or components may be combined or integrated into another system, or some functions may be ignored or not performed. Furthermore, mutual couplings or direct couplings or communication connections shown or discussed may be implemented via some interfaces. Indirect couplings or communication connections between devices or units may be implemented in electrical, mechanical, or other forms.

[0289] The units described as separate parts may or may not be physically separate, and the parts shown as units may or may not be physical units, and may be located in one location or distributed over multiple network units. Some or all of the units may be selected based on actual requirements to achieve the objectives of the solutions of the embodiments.

[0290] Furthermore, the functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit. The integrated unit may be implemented in the form of hardware or in the form of a software functional unit.

[0291] When an integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, the integrated unit may be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present application, or a portion contributing to the prior art, or all or a portion of the technical solution, may be implemented in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for instructing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or some of the steps of the method described in the embodiments of the present application. The above-mentioned storage medium includes any medium capable of storing program code, such as a USB flash drive, a removable hard disk, a read-only memory, a random access memory, a magnetic disk, or an optical disk.

Claims

1. 1. A method for processing data applied to a vehicle having a controller and a plurality of electronic control units (ECUs), comprising: receiving, by the controller, a data request message from a first ECU, the first ECU being any one of the plurality of ECUs, and the data request message being used to request acquisition of sensor data; sending, by the controller, a response message to the first ECU, the response message indicating to the first ECU to acquire the sensor data; generating, by the controller, mark information based on the data request message, the mark information recording request information for the sensor data; and when the vehicle triggers deletion of the sensor data in the first ECU, sending, by the controller, a first data deletion command to the first ECU based on the mark information, the first data deletion command instructing the first ECU to delete the sensor data; The method further includes, between the step of receiving a data request message from the first ECU and the step of transmitting a response message to the first ECU: receiving, by the controller, address information transmitted by an untrusted device, the untrusted device including a second ECU or a server, the second ECU being an untrusted ECU among the plurality of ECUs, the address information indicating an address space in the untrusted device to be used for storing data to be transmitted, the address information being determined by the untrusted device based on a size of the data to be transmitted; generating, by the controller, a first data certificate based on the address information and the data to be transmitted, the first data certificate uniquely identifying the data to be transmitted; transmitting, by the controller, the first data certificate to the untrusted device; receiving, by the controller, a first signature result sent by the untrusted device, the first signature result being obtained by the untrusted device signing the first data certificate; and controlling, by the controller, the transmission of the data to be transmitted to the untrusted device. method.

2. 1. A method for processing data applied to a vehicle having a controller and a plurality of electronic control units (ECUs), comprising: receiving, by the controller, a data request message from a first ECU, the first ECU being any one of the plurality of ECUs, and the data request message being used to request acquisition of sensor data; sending, by the controller, a response message to the first ECU, the response message indicating to the first ECU to acquire the sensor data; generating, by the controller, mark information based on the data request message, the mark information recording request information for the sensor data; and when the vehicle triggers deletion of the sensor data in the first ECU, sending, by the controller, a first data deletion command to the first ECU based on the mark information, the first data deletion command instructing the first ECU to delete the sensor data; The method further comprises, after the step of transmitting a response message to the first ECU: generating, by the controller, a second data certificate based on the data to be deleted; sending, by the controller, a third data deletion command to an untrusted device, the untrusted device including a third ECU or a server, the third ECU being an untrusted ECU among the plurality of ECUs, the third data deletion command including the second data certificate, and the third data deletion command indicating that the data to be deleted is to be deleted; and obtaining, by the controller, a second signature result returned by the untrusted device, the second signature result being obtained by the server signing the second data certificate, the second signature result indicating that the untrusted device has deleted the data to be deleted. method.

3. The request information for the sensor data includes an ECU requesting the sensor data, a request time for the sensor data, and content of the sensor data.

3. The method according to claim 1 or 2.

4. The intelligent vehicle triggering the deletion of the sensor data in the first ECU comprises: determining, by the controller, that the sensor data in the first ECU is out of date based on the mark information and a preset data retention period; or and acquiring, by the controller, a second data deletion command triggered by a user, the second data deletion command indicating that the sensor data in the first ECU is to be deleted.

3. The method according to claim 1 or 2.

5. the response message includes information about a sensor, the information about the sensor being used by the first ECU to establish a communication connection with the sensor so that the first ECU obtains the sensor data from the sensor.

3. The method according to claim 1 or 2.

6. the first data deletion command further instructs the first ECU to disconnect the communication connection with the sensor. The method of claim 5.

7. Before the step of transmitting a response message to the first ECU by the controller, the method further comprises: determining, by the controller, that the first ECU has permission to access the sensor data according to a preset permission configuration policy; 3. The method according to claim 1 or 2.

8. the first data certificate includes the address information and one or more of a digest value of the data to be transmitted, a file locator of the data to be transmitted, and a timestamp of the data to be transmitted; The method of claim 1.

9. 1. A method for processing data applied to a vehicle having a controller and a plurality of electronic control units (ECUs), comprising: receiving, by the controller, a data request message from a first ECU, the first ECU being any one of the plurality of ECUs, and the data request message being used to request acquisition of sensor data; sending, by the controller, a response message to the first ECU, the response message indicating to the first ECU to acquire the sensor data; acquiring, by the first ECU, the sensor data based on the response message; When the vehicle triggers deletion of the sensor data in the first ECU, the first ECU receives a first data deletion command from the controller, and deletes the sensor data in the first ECU based on the first data deletion command; The method further includes, between the step of receiving a data request message from the first ECU and the step of transmitting a response message to the first ECU: If the first ECU is an untrusted device, transmitting address information to the controller by the first ECU, the address information indicating an address space within the first ECU to be used to store data to be transmitted, the address information being determined by the first ECU based on a size of the data to be transmitted; receiving, by the first ECU, a first data certificate transmitted by the controller, the first data certificate being generated based on the address information and the data to be transmitted; signing, by the first ECU, the first data certificate to obtain a first signature result; transmitting, by the first ECU, the first signature result to the controller; receiving, by the first ECU, the data to be transmitted that is transmitted by the controller; method.

10. 1. A method for processing data applied to a vehicle having a controller and a plurality of electronic control units (ECUs), comprising: receiving, by the controller, a data request message from a first ECU, the first ECU being any one of the plurality of ECUs, and the data request message being used to request acquisition of sensor data; sending, by the controller, a response message to the first ECU, the response message indicating to the first ECU to acquire the sensor data; acquiring, by the first ECU, the sensor data based on the response message; When the vehicle triggers deletion of the sensor data in the first ECU, the first ECU receives a first data deletion command from the controller, and deletes the sensor data in the first ECU based on the first data deletion command; The method further comprises, after the step of transmitting a response message to the first ECU: receiving, by the first ECU if the first ECU is an untrusted device, a third data deletion command sent by the controller, the third data deletion command including a second data certificate, the second data certificate being generated by the controller based on the data to be deleted; signing the second data certificate by the first ECU to obtain a second signature result; and transmitting, by the first ECU, the second signature result to the controller and deleting the data to be deleted, wherein the second signature result indicates that the untrusted device has deleted the data to be deleted. method.

11. The step of acquiring the sensor data based on the response message by the first ECU includes: establishing, by the first ECU, a communication connection with the sensor based on information about the sensor, wherein response information includes the information about the sensor; and acquiring, by the first ECU, the sensor data from the sensor based on the communication connection.

11. The method according to claim 9 or 10.

12. the first data deletion command further instructs the first ECU to disconnect the communication connection with the sensor; The method of claim 11.

13. the first data certificate includes the address information and one or more of a digest value of the data to be transmitted, a file locator of the data to be transmitted, and a timestamp of the data to be transmitted; 10. The method of claim 9.

14. An ECU comprising a memory and a processor, The memory stores code, the processor is configured to execute the code, and when the code is executed, the ECU performs the method of claim 9 or 10. ECU.

15. A vehicle including a controller and a plurality of ECUs, The controller is connected to multiple ECUs separately. Any one of the plurality of ECUs is an ECU according to claim 14. vehicle.

Images