Data backup method and vehicle

Abstract

The present application relates to the technical field of intelligent driving, and provides a data backup method and a vehicle, for use in improving the survivability of data generated during vehicle traveling. In the method, a vehicle at least comprises a first controller and a second controller, wherein the first controller acquires first data on the basis of a first task cycle and sends the first data to the second controller, the first data indicating data related to the first controller and generated during vehicle traveling; the second controller acquires second data on the basis of a second task cycle and sends the second data to the first controller, the second data indicating data related to the second controller and generated during vehicle traveling; and then the first controller associatively stores the second data and the first data on the basis of the first task cycle, and the second controller associatively stores the first data and the second data on the basis of the second task cycle.

Description

Data backup method and vehicle

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on January 24, 2024, with application number 202410108485.X and application name “Data Backup Method and Vehicle”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of intelligent driving technology, and in particular to a data backup method and a vehicle. Background Art

[0003] Currently, vehicles equipped with autonomous driving functions are usually equipped with independent devices such as dashcams, event data recorders (EDRs), and data storage systems for automated driving (DSSADs) to facilitate effective accident analysis and liability determination after an accident. These devices record the control data of the driver and the autonomous driving system during driving. This control data can be used as a basis for vehicle accident analysis and accident liability determination.

[0004] However, while the aforementioned devices can record control data, if they are damaged during a collision or mechanical impact, the control data stored in them will also be destroyed or damaged, and this destroyed or damaged data cannot be recovered. Therefore, the current method of storing control data for autonomous vehicles makes it difficult to preserve control data, which also creates difficulties in tracing back accidents.

[0005] Summary of the Invention

[0006] The present application provides a data backup method and vehicle to make the data generated during the operation of the vehicle more survivable, thereby facilitating cause tracing and accident analysis after a vehicle accident.

[0007] To achieve the above objectives, this application adopts the following technical solutions:

[0008] In a first aspect, a data backup method is provided for use in a vehicle, the vehicle comprising at least a first controller and a second controller. The first controller acquires first data according to a first task cycle and sends the first data to the second controller, where the first data indicates data related to the first controller generated during vehicle operation. The second controller acquires second data according to a second task cycle and sends the second data to the first controller, where the second data indicates data related to the second controller generated during vehicle operation. The first controller then associates and stores the second data with the first data according to the first task cycle, and the second controller associates and stores the first data with the second data according to the second task cycle.

[0009] In the above method, the data generated during the operation of the vehicle can be saved on different controllers respectively to achieve multi-point backup of the data. When a controller fails and the saved data is damaged, the data can also be read from other controllers. This makes the data easier to survive and facilitates cause tracing and accident analysis after a vehicle accident.

[0010] The combination of the first data and the second data can represent the DSSAD data in the vehicle, thereby also improving the survivability of the DSSAD data in the vehicle.

[0011] In one implementation of the first aspect, the first controller corresponds to multiple task cycles, the first task cycle being any one of the multiple task cycles. After acquiring first data within the first task cycle, the first controller sends the first data to the second controller. Thus, the first controller continuously stores the acquired first data and synchronizes it with the second controller.

[0012] It is understood that the first controller can obtain first data from various sensors, the autonomous driving system, actuators, and the like. Different sensors have their own acquisition cycles; that is, a sensor can output data to the first controller once within a corresponding acquisition cycle. The autonomous driving system also has its own task cycle; that is, the autonomous driving system can output data to the first controller once within a corresponding task cycle. The first controller's multiple task cycles include the acquisition cycles of its corresponding sensors and the task cycle of the autonomous driving system.

[0013] In one implementation of the first aspect, the first data includes M data records and a first sequence identifier for each of the M data records, the first sequence identifier including a timestamp and / or cycle count information of a first task cycle, where M is greater than or equal to 1; the second data includes N data records, and the second sequence identifier for each of the N data records includes one or more of a timestamp, a video frame sequence number, and cycle count information of a second task cycle, where N is greater than or equal to 1. The sequence identifiers corresponding to the first data and the second data, respectively, are used to mark the order in which the first data and the second data are acquired.

[0014] In an implementation of the first aspect, the first controller associates and stores the second data with the first data based on all second sequence identifiers of the second data received in the first task period and all first sequence identifiers of the first data acquired in the first task period.

[0015] In the above implementation, based on the method of associating and storing data based on multiple information in the first sequence identifier and the second sequence identifier, for the first controller, the data of other controllers that are synchronized with the first controller can be effectively saved based on the task cycle and / or time of the first controller, so that for the first controller, the saved data is synchronized in task cycle or time, so as to provide more accurate and valuable data for subsequent data analysis, accident analysis, etc.

[0016] In one implementation of the first aspect, the second controller corresponds to multiple task cycles, the second task cycle being any one of the multiple task cycles. After acquiring the second data within the second task cycle, the second controller sends the second data to the first controller. Thus, the second controller continuously stores the acquired second data and synchronizes it with the first controller.

[0017] It is understandable that the second controller can also obtain the second data from different sensors and actuators. Different sensors have their own collection cycles, and the multiple task cycles of the second controller include the collection cycles of the corresponding different sensors.

[0018] In an implementation of the first aspect, the second controller associates and stores the first data with the second data based on all first sequence identifiers of the first data received in the second task period and all second sequence identifiers of the second data acquired in the second task period.

[0019] In the above implementation, based on the method of associating and storing data based on multiple information in the first sequence identifier and the second sequence identifier, for the second controller, the data of other controllers that are synchronized with the second controller can be effectively saved based on the task cycle and / or time of the second controller, so that the data saved by the second controller is synchronized in task cycle or time, so as to provide more accurate and valuable data for subsequent data analysis, accident analysis, etc.

[0020] In one implementation of the first aspect, before the first controller acquires first data according to a first task period, the first controller creates a multicast group and sends information about the multicast group to the second controller via a multicast message. The second controller receives the multicast message sent by the first controller and joins the multicast group. Data synchronization between the first and second controllers is thereby achieved via the multicast group.

[0021] In one implementation of the first aspect, a first controller sends first data to a multicast group, so that a second controller that has joined the multicast group can receive the first data. A second controller sends second data to the multicast group, so that the first controller that has joined the multicast group can receive the second data. In this implementation, data synchronization between the first and second controllers can be achieved based on the multicast group.

[0022] In one implementation of the first aspect, the first controller is a driving domain controller, the second controller is a vehicle domain controller (VDC), and the second data includes one or more of the following: driver control data of the vehicle, environmental data during driving, and vehicle status data. In this implementation, the vehicle's driving domain controller and VDC can jointly implement data backup.

[0023] In one implementation of the first aspect, the first controller is a driving domain controller (DC), the second controller is a cockpit domain controller (CDC), and the second data includes video data recording vehicle operation. In this implementation, the vehicle's driving domain controller and CDC can jointly implement data backup.

[0024] In one implementation of the first aspect, the first controller is a driving domain controller, the second controller is an in-vehicle network unit (VIU), and the second data includes one or more of video data recording vehicle operation, driver control data of the vehicle, environmental data during driving, and vehicle status data. In this implementation, data backup can be jointly implemented by the vehicle's driving domain controller and VIU. The VIU can replace the VDC and / or CDC, or alternatively, the VIU can implement the functions of the VDC and / or CDC.

[0025] In one implementation of the first aspect, when a first controller and a second controller are time-synchronized, the first controller receives a first data extraction instruction, wherein the first data extraction instruction instructs extraction of data corresponding to a target time, where the target time includes a target instant or a target duration. In response to the first data extraction instruction, the first controller retrieves, from the stored data, data records in the first data and data records in the second data corresponding to a target timestamp that matches the target time.

[0026] In the above implementation, since the time between the first controller and the second controller is synchronized, the time of the first controller and the second controller is consistent, and the timestamp of the first data and the timestamp of the second data have the same timing standard. Thus, the first controller can determine the timestamp corresponding to the target time indicated by the first data extraction instruction and the data record corresponding to the timestamp from the saved data. The device that issues the first data extraction instruction (such as a host computer, etc.) can obtain data from different sensors, automatic driving systems ADS, actuators, etc. at the same time from the first controller, which is conducive to analyzing vehicle accidents at a certain time.

[0027] In one implementation of the first aspect, when the first controller and the second controller are time-asynchronous, the first controller receives a second data extraction instruction. In response to the second data extraction instruction, the first controller determines a target first task cycle that matches a target time from at least one first task cycle, and obtains first data and second data corresponding to the target first task cycle.

[0028] In the above implementation, since the time between the first controller and the second controller is not synchronized, the time of the first controller and the second controller may be inconsistent. For example, the timing of the first controller is faster than that of the second controller, or the timing of the first controller is slower than that of the second controller. In this case, the above target time can be positioned on one or more task cycles of the first controller, so as to directly obtain the first data and second data corresponding to one or more task cycles of the first controller. Such data are all in the same task cycle of the first controller, and thus the vehicle accident analysis for the time within the task cycle can also be effective.

[0029] In one implementation of the first aspect, the vehicle further includes a third controller configured to acquire third data according to a third task cycle. When the first controller is a driving domain controller and the second controller is a VDC, the third controller is a CDC, and the third data includes video data recording vehicle operation.

[0030] Alternatively, in another implementation of the first aspect, when the first controller is a driving domain controller, the second controller is a CDC, and the third controller is a VDC, the third data includes one or more of the driver's control data of the vehicle, environmental data during vehicle driving, and vehicle status data.

[0031] In the above implementation, the addition of a third controller allows the DSSAD data on the vehicle to be backed up on more devices, thereby further improving the survivability of the DSSAD data. Furthermore, since no additional independent storage device is required to store the DSSAD data, the cost of storing the data is also reduced.

[0032] In one implementation of the first aspect, the third controller sends third data to the first controller and the second controller. The first controller associates and stores the third data with the first data according to a first task cycle. The second controller associates and stores the second data with the third data according to a second task cycle.

[0033] In another implementation of the first aspect, the first controller sends the first data to the third controller, the second controller sends the second data to the second controller, and the third controller associates and stores the first data, the second data, and the third data according to a third task cycle.

[0034] In the above implementation, the third data may further include Z data records, where the third sequence identifier of each data record in the Z data records includes one or more of a timestamp, a video frame sequence number, and cycle count information of a third task cycle, where Z is greater than or equal to 1. The first controller may further associate the third data with the first data and store it based on all third sequence identifiers of the third data received within the first task cycle and all first sequence identifiers of the first data acquired within the first task cycle.

[0035] The second controller may further associate and store the third data with the second data based on all third sequence identifiers of the third data received in the second task period and all second sequence identifiers of the second data acquired in the second task period.

[0036] The third controller may also associate and save the first data, the second data, and the third data based on all first sequence identifiers of the first data received in the third task period, all second sequence identifiers of the second data, and all third sequence identifiers of the third data obtained in the third task period.

[0037] In a second aspect, a vehicle is provided, comprising at least a first controller and a second controller. The first controller is configured to acquire first data according to a first task cycle and send the first data to the second controller; the first data indicates data related to the first controller generated during the operation of the vehicle. The second controller is configured to acquire second data according to a second task cycle and send the second data to the first controller; the second data indicates data related to the second controller generated during the operation of the vehicle. The first controller is further configured to associate and store the second data with the first data according to the first task cycle. The second controller is further configured to associate and store the first data with the second data according to the second task cycle.

[0038] In an implementation of the second aspect, the first controller corresponds to multiple task cycles, and the first task cycle is any one of the multiple task cycles; the first controller is further used to send the first data to the second controller after obtaining the first data within the first task cycle.

[0039] In an implementation of the second aspect, the first data includes M data records, the first sequence identifier of each data record in the M data records includes a timestamp and / or cycle count information of a first task cycle, and M is greater than or equal to 1; the second data includes N data records, the second sequence identifier of each data record in the N data records includes one or more of a timestamp, a video frame sequence number, and cycle count information of a second task cycle, and N is greater than or equal to 1.

[0040] In an implementation of the second aspect, the first controller is further configured to associate and store the second data with the first data based on all second sequence identifiers of the second data received within the first task period and all first sequence identifiers of the first data acquired within the first task period.

[0041] In an implementation of the second aspect, the second controller corresponds to multiple task cycles, and the second task cycle is any one of the multiple task cycles; the second controller is further used to send the second data to the first controller after obtaining the second data within the second task cycle.

[0042] In an implementation of the second aspect, the second controller is further configured to store the first data and the second data in association with each other based on all first sequence identifiers of the first data received in the second task period and all second sequence identifiers of the second data acquired in the second task period.

[0043] In one implementation of the second aspect, the first controller is further configured to create a multicast group and send information about the multicast group to the second controller via a multicast message. The second controller is further configured to receive the multicast message sent by the first controller and join the multicast group. The multicast group is used to synchronize data between the first and second controllers.

[0044] In an implementation of the second aspect, the first controller is further configured to send the first data to the multicast group. The second controller is further configured to send the second data to the multicast group.

[0045] In an implementation of the second aspect, the first controller is a driving domain controller, the second controller is a vehicle domain controller VDC of the vehicle, and the second data includes one or more of the driver's control data of the vehicle, environmental data during the vehicle's driving process, and vehicle status data.

[0046] In an implementation of the second aspect, the first controller is a driving domain controller, the second controller is a cockpit domain controller CDC, and the second data includes video data recording vehicle operation conditions.

[0047] In an implementation of the second aspect, the first controller is a driving domain controller, the second controller is an in-vehicle network unit VIU, and the second data includes one or more of video data recording vehicle operation conditions, driver's control data of the vehicle, environmental data during vehicle driving, and vehicle status data.

[0048] In one implementation of the second aspect, when the first controller and the second controller are time-synchronized, the first controller is further configured to receive a first data extraction instruction, the first data extraction instruction instructing extraction of data corresponding to a target time, where the target time includes a target instant or a target duration. In response to the first data extraction instruction, the first controller is further configured to obtain, from the stored data, a data record in the first data and a data record in the second data corresponding to a target timestamp that matches the target time.

[0049] In one implementation of the second aspect, when the time between the first controller and the second controller is not synchronized, the first controller is further configured to execute a second data extraction instruction, the second data extraction instruction instructing to extract data corresponding to a target time, where the target time includes a target moment or a target duration. In response to the second data extraction instruction, the first controller is further configured to determine a target first task cycle that matches the target time from at least one first task cycle, and to obtain the first data and the second data corresponding to the target first task cycle.

[0050] In one implementation of the second aspect, the vehicle also includes a third controller; the third controller is used to obtain third data according to a third task cycle; when the first controller is a driving domain controller and the second controller is a vehicle domain controller VDC, the third controller is a cockpit domain controller CDC, and the third data includes video data recording the vehicle operation status.

[0051] In an implementation of the second aspect, when the first controller is a driving domain controller and the second controller is a cockpit domain controller CDC, the third controller is a vehicle domain controller VDC, and the third data includes one or more of the driver's control data of the vehicle, environmental data during vehicle driving, and vehicle status data.

[0052] In one implementation of the second aspect, the third controller is further configured to send third data to the first controller and the second controller. The first controller is further configured to associate and store the third data with the first data according to a first task cycle. The second controller is further configured to associate and store the second data with the third data according to a second task cycle.

[0053] In one implementation of the second aspect, the first controller is further configured to send the first data to the third controller. The second controller is further configured to send the second data to the second controller. The third controller is further configured to associate and store the first data, the second data, and the third data according to a third task cycle.

[0054] In a third aspect, a vehicle is provided, comprising a memory and multiple controllers; the memory is coupled to the multiple controllers; the multiple controllers may represent the first controller and the second controller in the first aspect and any implementation thereof, and may also correspond to the third controller. The memory stores computer program code, which includes computer instructions that, when executed by any controller, cause the controller to perform the method steps performed by the first controller, the second controller, or the third controller in the first aspect and any implementation thereof.

[0055] In a fourth aspect, a computer-readable storage medium is provided, comprising computer instructions. When the computer instructions are executed on a vehicle, the vehicle executes the data backup method as described in the first aspect and any implementation thereof.

[0056] It can be understood that the beneficial effects that can be achieved by the vehicle described in the second aspect, the vehicle described in the third aspect, and the computer-readable storage medium described in the fourth aspect can be referred to the beneficial effects in the first aspect and any possible design method thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] FIG1 is a structural schematic diagram of a vehicle according to an embodiment of the present application;

[0058] FIG2 is a schematic diagram of various task cycles according to an embodiment of the present application;

[0059] FIG3 is a first schematic diagram of communication between an MDC and a VDC according to an embodiment of the present application;

[0060] FIG4 is a first schematic diagram of a storage unit according to an embodiment of the present application;

[0061] FIG5 is a second schematic diagram of communication between an MDC and a VDC according to an embodiment of the present application;

[0062] FIG6 is a third schematic diagram of communication between an MDC and a VDC according to an embodiment of the present application;

[0063] FIG7 is a fourth schematic diagram of communication between an MDC and a VDC according to an embodiment of the present application;

[0064] FIG8 is a first schematic diagram of communication between an MDC and a CDC according to an embodiment of the present application;

[0065] FIG9 is a second schematic diagram of a storage unit according to an embodiment of the present application;

[0066] FIG10 is a second schematic diagram of communication between an MDC and a CDC according to an embodiment of the present application;

[0067] FIG11 is a third schematic diagram of communication between an MDC and a CDC according to an embodiment of the present application;

[0068] FIG12 is a fourth schematic diagram of communication between an MDC and a CDC according to an embodiment of the present application;

[0069] FIG13 is a first schematic diagram of communication between an MDC, a VDC, and a CDC according to an embodiment of the present application;

[0070] FIG14 is a second schematic diagram of communication between the MDC, VDC, and CDC according to an embodiment of the present application;

[0071] FIG15 is a third schematic diagram of communication between an MDC, a VDC, and a CDC according to an embodiment of the present application;

[0072] FIG16 is a second structural diagram of a vehicle according to an embodiment of the present application;

[0073] FIG17 is a third structural diagram of a vehicle according to an embodiment of the present application;

[0074] FIG18 is a flow chart of a data backup method according to an embodiment of the present application;

[0075] FIG19 is a fourth structural diagram of a vehicle shown in an embodiment of the present application. DETAILED DESCRIPTION

[0076] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. Among them, in the description of the present application, unless otherwise specified, " / " indicates that the objects associated before and after are in an "or" relationship, for example, A / B can indicate A or B; "and / or" in the present application is only a description of the association relationship of the associated objects, indicating that there can be three relationships, for example, A and / or B can indicate: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. In addition, in the description of the present application, unless otherwise specified, "multiple" refers to two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can indicate: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple. In addition, in order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit differences. At the same time, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy understanding.

[0077] In addition, the business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0078] Vehicles are typically equipped with devices that record driving data. After an accident or breakdown, the data stored in these devices can be used to effectively analyze the accident and determine responsibility. These devices can include dashcams, EDRs, and other devices.

[0079] A driving recorder is usually a standalone device that is connected to a camera or sensor on a vehicle and installed on the front or rear windshield of the vehicle to record the front and rear view video data of the vehicle.

[0080] EDRs are typically used to record data during a vehicle collision. This data includes data from the 15 seconds before and 5 seconds after the collision. EDRs primarily record vehicle status and basic information at the time of the collision. EDRs are typically deployed as standalone devices within the vehicle's airbag controller.

[0081] As autonomous driving functions become more and more common, L3 vehicles are becoming more and more popular. Currently, vehicles above L3 level need to be equipped with equipment for recording DSSAD data (such as DSSAD recording equipment) to record data on the driver and the autonomous driving system's control of the vehicle during driving, vehicle driving data, vehicle status data, etc. Among them, L3 level vehicles refer to cars with restricted autonomous driving functions. Such cars can automatically complete driving tasks in specific situations, including specific situations such as traffic congestion and highways that do not require continuous driver monitoring.

[0082] The DSSAD recording device is also a standalone device, connected to a bus or major vehicle components (such as the automated driving system (ADS) controller, vehicle controller unit (VCU), or chassis bus) via an external wiring harness. The DSSAD recording device then collects data on the driver and the automated driving system's control of the vehicle during operation, as well as vehicle driving data and vehicle status data (collectively referred to as DSSAD data) and stores it locally. The data stored by the DSSAD recording device can also play a crucial role in accident analysis and liability determination.

[0083] The above-mentioned driving recorders, EDR, DSSAD recording devices, etc., are all independent devices. Therefore, they may have the following problems during use:

[0084] 1. The cost of equipping vehicles with the above equipment is relatively high.

[0085] For example, adding a DSSAD recording device to a vehicle requires adding connectors and wiring harnesses to establish an effective physical connection between the device and the vehicle's existing equipment and systems. These additional connectors and wiring harnesses increase costs.

[0086] Furthermore, DSSAD recorders need to collect DSSAD data, which can come from sensors or various controllers in the vehicle. Consequently, the DSSAD recorder interacts frequently with sensors and controllers, involving a wide variety of data types. The DSSAD recorder must process and store data in various formats and types, requiring its own processor to have strong processing power, at least sufficient to meet the current task requirements. Processors capable of meeting these multiple requirements are typically expensive, leading to high costs for equipping vehicles with DSSAD recorders.

[0087] Furthermore, the installation of the DSSAD recording device will increase the weight of the vehicle and occupy more space in the vehicle. To solve the problems of increased weight and reduced space, other functions or components of the vehicle need to be improved, which will also increase new costs.

[0088] 2. The data stored in the above devices is difficult to survive.

[0089] For example, when a DSSAD recording device is damaged by a collision or mechanical impact, the control data stored in it is also destroyed or damaged. This damaged or corrupted data cannot be recovered, making it difficult to maintain data. This also creates difficulties in accident analysis and liability determination after a vehicle accident.

[0090] In order to avoid equipment damage, the vehicle's anti-collision and anti-impact levels are usually improved, which will undoubtedly lead to increased costs.

[0091] 3. The reliability of the data stored in the above-mentioned devices is difficult to guarantee.

[0092] Among them, still taking the DSSAD recording device as an example, the device cannot effectively protect data from being tampered with, nor can it effectively verify or confirm the stored data, making it difficult to ensure the reliability of the stored data.

[0093] In order to ensure the reliability of data stored on the device, more storage space or data protection functions are usually added, which also brings about the problem of increased costs.

[0094] Based on the above, an embodiment of the present application provides a data backup method. This method can be applied to a vehicle, and the vehicle includes at least a first controller and a second controller. The first controller acquires first data according to a first task cycle and sends the first data to the second controller. The second controller acquires second data according to a second task cycle and sends the second data to the first controller. The first controller then associates and stores the second data with the first data according to the first task cycle, and the second controller associates and stores the first data with the second data according to the second task cycle.

[0095] The first data indicates data related to the first controller generated during the operation of the vehicle, and the second data indicates data related to the second controller generated during the operation of the vehicle.

[0096] In this data backup method, data generated during vehicle operation can be stored on different controllers, achieving multi-point data backup. If a controller fails and the stored data becomes corrupted, the data can be retrieved from other controllers. This ensures data survival and facilitates cause tracing and accident analysis after a vehicle accident. Furthermore, there is no need to set up a separate storage device to store this data, which can also reduce the cost of data storage equipment.

[0097] In addition, the combination of the above-mentioned first data and second data can represent the DSSAD data in the vehicle, thereby also improving the survivability of the DSSAD data in the vehicle.

[0098] When the above data backup method is applied to a vehicle, as shown in FIG1 , the vehicle may include a first controller and a second controller. The first controller is configured to obtain the above first data and may be, for example, a vehicle driver domain controller (DC); the second controller is configured to obtain the above second data and may be, for example, a cockpit domain controller (CDC), a vehicle domain controller (VDC), or a vehicle intranet unit (VIU).

[0099] In some possible implementations, the driving domain controller of the above-mentioned vehicle can also be called the vehicle's mobile data center (MDC), intelligent driving computing platform, etc.

[0100] The above-mentioned first data indicates data related to the first controller generated during the operation of the vehicle, such as operating information of the automated driving system (ADS), collected data from sensors, feedback data from actuators, etc., wherein the operating information of the ADS includes control data of the ADS for vehicle control, status data of the vehicle under the control of the ADS, etc.

[0101] For example, the operation information (or first data) of the ADS may be as shown in Table 1.

[0102] Table 1

[0103] The second data indicates data related to the second controller generated during vehicle operation, and may also include sensor data, actuator feedback data, etc. For example, when the second controller is a CDC, the second data may include video data recording the vehicle's operation. The CDC may be internal or external to the vehicle. When the second controller is a VDC, the second data may include one or more of the following: driver control data, environmental data during vehicle operation, and vehicle status data.

[0104] It can be understood that the above-mentioned first data and second data can represent DSSAD data that needs to be collected for vehicles providing autonomous driving functions.

[0105] In some possible implementations, the above-mentioned first data can be obtained from the sensor by the first controller communicating with different sensors through the on-board Ethernet, or it can be obtained by the first controller from some functional programs for obtaining data (such as mdc_chs, mdc_rndt, etc.) through the controller area network (CAN) bus, or it can be obtained by the first controller from ADS through the CAN bus.

[0106] Similarly, the above-mentioned second data can be obtained from the sensor by the second controller communicating with different sensors through the vehicle Ethernet, or it can be obtained by the second controller from some functional programs for obtaining data (such as vdc_ep_ev, vdc_ep_evr, etc.) through the CAN bus.

[0107] The above-mentioned sensors include but are not limited to lidar, millimeter-wave radar, 4D millimeter-wave radar, etc. Correspondingly, the sensor data may include but are not limited to point cloud data of lidar, millimeter-wave radar data, 4D millimeter-wave radar point cloud data, etc.

[0108] Different sensors, ADSs, and functional programs in a vehicle have different task cycles (or sampling cycles, acquisition cycles, etc.), such as 10ms, 20ms, 50ms, or 100ms. Therefore, when the first controller and the second controller obtain the first data and the second data, they also obtain them according to the task cycles.

[0109] In some possible implementations, the first controller may correspond to multiple task cycles, each of which may correspond to a different sensor, ADS, functional program, etc. For any one of the multiple task cycles, such as the first task cycle, the first controller may acquire the first data according to the first task cycle, that is, continuously acquire the first data within consecutive first task cycles.

[0110] The second controller may also correspond to multiple task cycles, each of which may correspond to a different sensor, functional program, etc. For any task cycle among the multiple task cycles, such as the second task cycle, the second controller may obtain the second data according to the second task cycle, that is, continuously obtain the second data in consecutive second task cycles.

[0111] Exemplarily, FIG2 shows a plurality of task cycles corresponding to different controllers.

[0112] Taking MDC as an example, as shown in Figure 2, the task cycles corresponding to MDC may include cycle 1-1, cycle 1-2, cycle 1-3, cycle 1-4, and so on. Cycle 1-1 lasts 10ms, and the MDC can obtain data once every 10ms. Cycle 1-2 lasts 20ms, and the MDC can obtain data once every 20ms. Cycle 1-3 lasts 50ms, and the MDC can obtain data once every 50ms. Cycle 1-4 lasts 500ms, and the MDC can obtain data once every 500ms (not shown in the figure).

[0113] Taking VDC as an example, as shown in Figure 2, the task cycles corresponding to VDC may include cycle 2-1, cycle 2-2, cycle 2-3, and cycle 2-4. Cycle 2-1 lasts 10 ms, and VDC can obtain data once every 10 ms. Cycle 2-2 lasts 20 ms, and VDC can obtain data once every 20 ms. Cycle 2-3 lasts 50 ms, and VDC can obtain data once every 50 ms. Cycle 2-4 lasts 100 ms, and VDC can obtain data once every 100 ms.

[0114] Taking CDC as an example, as shown in Figure 2, the task cycles corresponding to CDC may include cycle 3-1, cycle 3-2, cycle 3-3, and cycle 3-4. Cycle 3-1 lasts for 10ms, and CDC can obtain data once every 10ms. Cycle 3-2 lasts for 50ms, and CDC can obtain data once every 50ms. Cycle 3-3 lasts for 100ms, and CDC can obtain data once every 100ms. Cycle 3-4 lasts for 1s, and CDC can obtain data once every 1s (not shown in the figure).

[0115] The duration of the task cycle shown in FIG2 is only an example. In other possible implementations, the controller may also acquire data with a task cycle of other durations. For example, a camera sensor may have a task cycle of 33ms, so the task cycle for the CDC to acquire video data may also be 33ms.

[0116] The first controller and the second controller can obtain data according to their respective task cycles shown above. After obtaining the data, the controllers can also share or synchronize the data obtained by each other, so that the first controller saves the data obtained by the first controller and the second controller respectively, and the second controller also saves the data obtained by the first controller and the second controller respectively.

[0117] In some possible implementations, an independent storage unit may be provided in each of the first controller and the second controller to store the first data and the second data (or referred to as DSSAD data). The storage unit may be a dynamic independent storage unit or a fixed storage area, and the data may be stored in a rolling overlay manner within the storage unit.

[0118] For example, the VDC, MDC, etc. can directly use the storage module constructed by its own file system as the independent storage unit to complete data storage.

[0119] In this way, data can be stored using the vehicle's controller's own storage unit without the need for a separate storage device, thereby reducing the number of newly added connectors, wiring harnesses, and the like, and lowering the cost of equipping the vehicle with storage devices. Furthermore, by storing the same DSSAD data (such as the first data and second data described above) in different controllers, once the vehicle collides or is mechanically impacted, as long as any one controller survives, the DSSAD data can be read from that controller. In other words, by storing DSSAD data in this manner, the data is more likely to survive, reducing the risk of data corruption due to damage to the storage device.

[0120] In some possible implementations, the first controller acquires first data according to the first task cycle described above. Each time the first data is acquired, the controller not only saves the corresponding first data according to the first task cycle but also sends the first data to the second controller. In other words, the first controller continuously saves the acquired first data and synchronizes it with the second controller. The second controller acquires second data according to the second task cycle described above. Each time the second data is acquired, the controller not only saves the corresponding second data according to the second task cycle but also sends the second data to the first controller. In other words, the second controller also continuously saves the acquired second data and synchronizes it with the first controller. In this way, data synchronization between the first and second controllers can be achieved.

[0121] In some other possible implementations, the first data may include M data records, each of which includes a first sequence identifier to mark the order in which the data records are obtained, where M is greater than or equal to 1. The first sequence identifier may include a timestamp and / or cycle count information of a task cycle (i.e., a first task cycle), etc. The timestamp is used to mark the specific time when the first controller obtains the data record, and the cycle count information of the task cycle is used to mark the first task cycle in which the first controller obtains the data record.

[0122] Similarly, the second data may include N data records, each of which includes a second sequence identifier to mark the order in which the data records were acquired, where N is greater than or equal to 1. The second sequence identifier includes one or more of a timestamp, a video frame sequence number, and cycle count information of a task cycle (i.e., a second task cycle). The timestamp is used to mark the specific time when the second controller acquired the data record, and the cycle count information of the task cycle is used to mark the second task cycle in which the second controller acquired the data record. The video frame sequence number is used to mark the frame number of the video frame acquired by the second controller in the complete video data collected by the sensor.

[0123] It is understandable that the first data and the second data may also be obtained through sensors. Therefore, the sequence identifiers of the first data and the second data may also be set according to the information of the sensor that collects the data. The sensor information may include the sensor's collection period, the sensor's identifier, etc. The sequence identifier may also include the information of the corresponding sensor (or an association mark between the corresponding sensor).

[0124] When the first controller saves the first data and the second data, for a first task cycle among multiple task cycles, the first data acquired within one first task cycle may be associated and saved with the second data received. Similarly, when the second controller saves the first data and the second data, for a second task cycle among multiple task cycles, the second data acquired within one second task cycle may be associated and saved with the first data received.

[0125] The first controller and the second controller can store corresponding data in a preset storage format according to their respective task cycles. For example, the corresponding storage space can be divided into multiple storage units, each of which can correspond to one or more task cycles and store the cycle count information, cycle identifier, or cycle number of the corresponding task cycle. Furthermore, a storage unit can be specifically divided into multiple data storage areas, each used to store data corresponding to different controllers. When saving data, the corresponding sequence identifier of the data is also saved, thereby achieving the purpose of associating the controller's task cycle with the data's sequence identifier, and also achieving the purpose of associating and storing data corresponding to different controllers.

[0126] This method of storing data in association with each other based on multiple information can effectively save the data of other controllers that are synchronized with a certain controller based on the task cycle and / or time of the controller, so that the saved data for the controller is synchronized in time, thereby providing more accurate and valuable data for subsequent data analysis, accident analysis, etc.

[0127] In addition, each storage unit also includes a verification area for storing the digital signature or encryption information of the data in each storage unit to ensure the security and reliability of the data.

[0128] When other devices (such as a host computer, data acquisition device, etc.) need to obtain data from the first controller, they can locate the specific task cycle of the first controller and obtain the first data and second data corresponding to the task cycle. When other devices need to obtain data from the second controller, they can locate the specific task cycle of the second controller and obtain the first data and second data corresponding to the task cycle.

[0129] In some possible implementations, to synchronize data between the first and second controllers, the first controller may also create a multicast group based on the in-vehicle Ethernet network before acquiring the first data. This multicast group serves as a multicast network for exchanging or synchronizing data between the first and second controllers. The first controller then sends the multicast group information via a multicast message. The second controller obtains the multicast group information based on the received multicast message and joins the multicast group.

[0130] When achieving data synchronization, the first controller can send the acquired first data to the multicast group, so that the second controller in the multicast group can acquire the first data, and the second controller can send the acquired second data to the multicast group, so that the first controller in the multicast group can acquire the second data.

[0131] For example, if the first controller is an MDC and the second controller is a VDC, the communication process between the MDC and VDC is shown in Figure 3. In Figure 3, the MDC and VDC each include a central processing unit (CPU) / microprocessor unit (MPU), a storage unit, a microcontroller unit (MCU), and an Ethernet switch unit.

[0132] On the MDC side, the CPU / MPU first sets up a data storage space or storage unit on a disk or in a storage file system as storage for DSSAD data (such as the first data and the second data). Based on the initial configuration, the CPU / MPU configures permissions and implements anti-manipulation processing for the storage space. The CPU / MPU collects ADS operation information from mdc_chs, mdc_rndt, and other sensors, feedback data from actuators controlled by the autonomous driving function, and feedback data from actuators controlled by driving via the CAN bus. It also collects sensor data from other sensors via the vehicle Ethernet through the Ethernet switching unit. The MDC pre-processes the collected data (such as the first data) through the CPU / MPU, for example, formatting the data based on the storage protocol and adding a sequence identifier (such as the MDC's task cycle sequence number, cycle count information, and timestamp information). The MDC then calculates a digital signature for the data and writes the digital signature to the corresponding area or location in the storage unit, which serves as the basis for subsequent data integrity verification. For the formatted data, the CPU / MPU can also complete the encryption processing of the data based on the encryption protocol. After the encryption is completed, the CPU / MPU writes the data into the corresponding area or location of the storage unit.

[0133] On the MDC side, it is also possible to establish a connection with the VDC using the vehicle Ethernet through the Ethernet switching unit to build a multicast network (such as a multicast group). The CPU / MPU associates and saves the data on the VDC side obtained through the multicast network based on the sequence identifier of the data and the sequence identifier of the local data. When saving, the CPU / MPU will also pre-process the data on the VDC side, such as completing the formatting operation of the data based on the storage protocol, adding the sequence identifier of the data, and then calculating the digital signature of the data, and writing the digital signature to the corresponding area or location of the storage unit as the basis for subsequent data integrity verification. For the formatted data on the VDC side, the CPU / MPU can also complete the encryption processing of the data based on the encryption protocol. After the encryption is completed, the CPU / MPU writes the data to the corresponding area or location of the storage unit.

[0134] On the VDC side, the CPU / MPU first sets up a data storage space or storage unit on disk or in a storage file system as storage for DSSAD data (such as the first data and the second data). Based on the initial configuration, the CPU / MPU configures permissions and implements anti-manipulation measures for the storage space. The CPU / MPU collects vehicle operation data from vdc_ep_ev, vdc_ep_evr, and other sensors, as well as feedback data from actuators controlled by the autonomous driving function and actuators controlled by the driver, via the CAN bus. It also collects sensor data from other sensors via the vehicle Ethernet through the Ethernet switch. For the collected data (such as the second data), the VDC pre-processes the data through the CPU / MPU, for example, formatting it based on the storage protocol and adding a sequence identifier (such as the VDC's task cycle sequence number, cycle count information, and timestamp information). The VDC then calculates a digital signature for the data and writes it to the corresponding area or location in the storage unit, which serves as the basis for subsequent data integrity verification. For the formatted data, the CPU / MPU can also complete the encryption processing of the data based on the encryption protocol. After the encryption is completed, the CPU / MPU writes the data into the corresponding area or location of the storage unit.

[0135] On the VDC side, the VDC establishes a multicast network with the MDC using the vehicle Ethernet through the Ethernet switching unit. The CPU / MPU associates and saves the MDC-side data obtained through the multicast network based on the data's sequence identifier and the local data's sequence identifier. When saving, the CPU / MPU will also pre-process the data on the MDC side, such as completing the data formatting operation based on the storage protocol, adding the data's sequence identifier, and then calculating the digital signature for the data, and writing the digital signature to the corresponding area or location of the storage unit as the basis for subsequent data integrity verification. For the formatted MDC-side data, the CPU / MPU can also complete the data encryption processing based on the encryption protocol. After the encryption is completed, the CPU / MPU writes the data to the corresponding area or location of the storage unit.

[0136] In some possible implementations, the storage units corresponding to the MDC and VDC can be divided into multiple storage units for storing data, as shown in (a) and (b) of Figure 4. Saving DSSAD data in the format of the storage units can serve as the aforementioned data formatting operation. Furthermore, each storage unit can include a frame encoding area, an image frame sequence area, a component data area, and a checksum area.

[0137] For MDC, taking the first task cycle among multiple task cycles as an example, each storage unit corresponds to a first task cycle of MDC, stores the first data (or a data frame) within the first task cycle of MDC, and stores the second data sent by VDC and received by MDC within the first task cycle. The second data can be obtained by VDC in at least one task cycle of VDC.

[0138] For VDC, taking the second task cycle among multiple task cycles as an example, each storage unit corresponds to a second task cycle of VDC, stores the second data (or a data frame) within a second task cycle of VDC, and stores the first data sent by MDC and received by VDC within a second task cycle. The first data can be obtained by MDC in at least one task cycle of MDC.

[0139] MDC and VDC can cyclically write the data to be saved in a fixed storage unit. For example, MDC and VDC generate a frame of data every 10ms and write it to the storage unit in order, thus forming a circular linked list, so that data can be read or traversed from any position in the linked list later.

[0140] As shown in (a) of FIG4 , for MDC, the storage unit mainly includes a storage frame coding area, an image frame sequence area, an MDC data area, an operation data area, and a checksum area. The storage frame coding area is used to store the coding information of the data block, and may include the serial number of an MDC data frame (data block) and the timestamp information for obtaining the data frame. The protection identification area includes a protection identification to indicate that the storage unit cannot be deleted or overwritten, or the protection identification can also be used as a special event mark, an important record mark, etc. The image frame sequence area is used to store the image frame sequence number (or video frame sequence number), the timestamp information of the image frame, the image frame cumulative count information, the frame integrity check code, etc. Alternatively, the storage unit may also include an image data area. If the MDC receives video data or image data in the video data, the video data or the related information corresponding to the image data can be saved in the image frame sequence area, and the video data or the image data can be saved in the image data area. The MDC data area is used to store the message sequence number (such as the MDC task cycle count information, cycle sequence number, cycle identifier, cycle number, etc.) of the MDC-side data (such as the first data), the timestamp information of the MDC-side data, the operation information (such as the first data) of the ADS, and the frame integrity check code. The operation data area is used to store the message sequence number (such as the VDC task cycle count information, cycle sequence number, cycle identifier, cycle number, etc.), the timestamp information of the data (such as the second data), and the frame integrity check code of the data (such as the second data) sent by the VDC.

[0141] It is understood that, since the MDC can receive operational data corresponding to at least one VDC task cycle within a first task cycle, the operational data area may include multiple operational data units, each of which may store the second data within a VDC task cycle. In some possible implementations, the MDC may also receive video data corresponding to at least one CDC task cycle within a first task cycle. Therefore, the image frame sequence area may also include multiple image frame sequence units, each of which may store the second data within a CDC task cycle.

[0142] In other possible implementations, if the amount of image data captured by a camera sensor is large or the image is a panoramic image or surround view image, the camera sensor may divide the data corresponding to the image into multiple sub-blocks and send them to the CDC. The CDC can then send information corresponding to the multiple sub-blocks of the image (such as the corresponding image frame sequence numbers (or video frame sequence numbers), image frame timestamp information, image frame cumulative count information, etc.) to the MDC, which will store the information in the form of an array in the image frame sequence area. The MDC may also store the multiple sub-blocks in the image data area.

[0143] In some possible implementations, the aforementioned storage unit may correspond to multiple MDC (or VDC) task cycles, that is, store the sequence numbers of multiple MDC data frames (data blocks) and the timestamp information of the data frame creation. In this case, to distinguish different task cycles, the timestamp information corresponding to different data frames may also include time offset information of the frame interval.

[0144] When the MDC associates and saves data, it can associate and save the corresponding first data with the data received from the VDC side during a task cycle of the MDC, and save them in a storage unit for one task cycle in the format shown in (a) of FIG. 4 .

[0145] Alternatively, when a storage unit corresponds to multiple task cycles of the MDC, the MDC may further set a mark for indicating the current MDC task cycle for the first data and the second data in a task cycle, thereby associating the first data and the second data in a task cycle.

[0146] The above-mentioned verification area can be used to store the digital signature of the data in each storage unit to ensure the security and reliability of the data.

[0147] As shown in (b) of FIG4 , for the VDC, the storage unit mainly includes a storage frame code area, an image frame sequence area, a VDC data area, a control data area, and a checksum area. The functions of the storage frame code area and the image frame sequence area are similar to those in the above embodiment, except that their functions are respectively related to the VDC. The VDC data area is used to store the message sequence number (such as the count information of the VDC's task cycle, the cycle sequence number, the cycle identifier, the cycle number, etc.) of the VDC-side data (such as the second data), the timestamp information of the VDC-side data, the operation data (such as the second data), and the frame integrity checksum. The control data area is used to store the message sequence number (such as the count information of the MDC's task cycle, the cycle sequence number, the cycle identifier, the cycle number, etc.), the timestamp information of the data (such as the first data), and the frame integrity checksum.

[0148] For other relevant contents of the storage unit corresponding to the VDC, please refer to the contents in the aforementioned embodiment and will not be repeated here.

[0149] When the above-mentioned VDC associates and saves data, it can associate and save the corresponding second data with the data on the MDC side received during a task cycle of the VDC, and save it in a storage unit for one task cycle in the format shown in (b) in the above-mentioned Figure 4.

[0150] Alternatively, when a storage unit corresponds to one or more task cycles of the VDC, the VDC can also set the first data and the second data within a task cycle as marks representing the current VDC task cycle (such as the aforementioned data association mark, etc.), thereby associating the first data and the second data within a task cycle.

[0151] The above-mentioned verification area can be used to store the digital signature of the data in each storage unit to ensure the security and reliability of the data.

[0152] Based on (a) and (b) in FIG4 above, the communication process between the MDC and the VDC in the vehicle can be shown in FIG5.

[0153] It is understandable that after the MDC and VDC on the vehicle are synchronized (or time synchronization is completed), the time of the MDC and VDC is consistent, so the timestamp corresponding to the data can be used as an identifier for extracting data. Subsequently, when other devices (such as a host computer, data acquisition device, etc.) need to obtain data from the MDC or VDC, they can directly obtain the data records in the first data and the data records in the second data corresponding to that time from the MDC or VDC based on the globally synchronized time, where the timestamp of each data record is consistent or the same as that time. Such first data and second data can effectively play a role in vehicle accident analysis at a certain time, etc.

[0154] Alternatively, if the time of the MDC and VDC on the vehicle is not synchronized (or the time synchronization is not completed), then since the time of the MDC and VDC may be inconsistent, the first data (based on the time of the MDC) and the second data (based on the time of the VDC) that appear to be obtained at the same time may not be obtained at the same time. In this case, the timestamp corresponding to the data cannot be used as an identifier for extracting data. Instead, the data to be obtained can be located on a certain task cycle of the MDC or VDC, thereby directly obtaining the storage unit corresponding to this task cycle of the MDC or VDC, and then obtaining the first data and second data in the storage unit. In this way, the first data and the second data are both in the same task cycle of the MDC or the same task cycle of the VDC, and the vehicle accident analysis for the time within the task cycle can also be effective.

[0155] The above-mentioned MDC, VDC, etc. can maintain the independence and continuity of the first data and the second data in terms of time and task cycle for the associated storage of data. Moreover, when reading data subsequently, the data to be read can also be effectively located according to time, task cycle, etc.

[0156] In some possible implementations, as shown in FIG6 , communication between the MDC and the VDC can also be performed via a VIU. The VIU is responsible for collecting data collected by various sensors. The MDC and VDC then obtain the first data and the second data from their respective VIUs. It is understood that the VIU can be a simple controller without any processing capabilities.

[0157] In some possible implementations, the aforementioned multicast group-based communication between the MDC and VDC can also be seen in Figure 7 . In Figure 7 , after the vehicle is powered on or started, the MDC first completes local initialization configuration, applies for storage space or storage units required for data storage, and configures storage space permissions. The MDC then creates a multicast group as a multicast network for data exchange between the MDC and VDC and transmits the multicast group information. The VDC first completes local initialization configuration, applies for storage space or storage units required for data storage, and configures storage space permissions. The VDC then receives the multicast message from the MDC, parses the data, obtains the multicast group information and interface information, and joins the multicast group based on the multicast group information and interface information. After the VDC completes the configuration to join the multicast group, it sends a configuration ACK message to the multicast group. After this, the VDC completes initialization and enters a dormant state. Upon receiving the ACK message via the multicast group, the MDC confirms the completion of MDC initialization and enters a dormant state.

[0158] Figure 7 is merely an example of how messages are sent. Those skilled in the art will recognize that a multicast group is not a single entity, but rather a collection of members identified by a multicast address. After an MDC and a VDC join the same multicast group, they become members of that multicast group. When a message sent by either an MDC or a VDC includes the multicast address, this application refers to the message as being sent to the multicast group.

[0159] When the autonomous driving function is activated, the vehicle starts moving, the ADS starts running, or various sensors start collecting data, the MDC and VDC end their dormant state, enter the working state, and start collecting data according to the task cycle.

[0160] In the above implementation, the vehicle can complete the backup operation of DSSAD data based on MDC and VDC, that is, DSSAD data is stored in MDC and VDC respectively, which can reduce the equipment cost of saving data and make the data easier to survive.

[0161] For example, in a scenario where the first controller is an MDC and the second controller is a CDC, the communication process between the MDC and CDC is shown in Figure 8 . In Figure 8 , the MDC includes a CPU / MPU, a storage unit, an MCU, an Ethernet switch, and the like, while the CDC includes a CPU / MPU, a storage unit, an MCU, and the like. In some possible implementations, the CDC may also include an Ethernet switch, or the CDC may connect to an external storage device (such as a memory card or USB flash drive) via an external interface, thereby storing DSSAD data on the storage device or reading DSSAD data from the storage unit via the storage device.

[0162] The processing process on the MDC side may refer to the content of the aforementioned embodiment.

[0163] On the CDC side, the CPU / MPU first sets up a data storage space or storage unit on a disk or in a storage file system as storage for DSSAD data (such as the first data and the second data). Based on the initial configuration, the CPU / MPU configures permissions and implements anti-manipulation processing for the storage space. The CPU / MPU collects vehicle operation data, sensor data, and other data via the CAN bus. It also uses the Ethernet switch unit to collect vehicle operation video data sent by bicycle recorders and other devices via the vehicle Ethernet. For the collected data (such as the second data), the CDC performs pre-processing on the data through the CPU / MPU. For example, it formats the data based on the storage protocol and adds a sequence identifier (such as the CDC's task cycle sequence number, cycle count information, timestamp information, video frame sequence number, etc.). It then calculates a digital signature for the data and writes it to the corresponding area or location in the storage unit as a basis for subsequent data integrity verification. For the formatted data, the CPU / MPU can also encrypt the data based on the encryption protocol. After encryption is complete, the CPU / MPU writes the data to the corresponding area or location in the storage unit.

[0164] On the CDC side, the CDC uses the vehicle Ethernet to establish a multicast network (such as a multicast group) with the MDC through the Ethernet switching unit. The CPU / MPU associates and saves the MDC-side data obtained through the multicast network based on the sequence identifier of the data and the sequence identifier of the local data. When saving, the CPU / MPU will also complete pre-processing of the data on the MDC side, such as completing the formatting operation of the data based on the storage protocol, adding the sequence identifier of the data, and then calculating the digital signature of the data, and writing the digital signature to the corresponding area or location of the storage unit as the basis for subsequent data integrity verification. For the formatted MDC-side data, the CPU / MPU can also complete the encryption processing of the data based on the encryption protocol. After the encryption is completed, the CPU / MPU writes the data to the corresponding area or location of the storage unit.

[0165] In some possible implementations, the data storage unit corresponding to the CDC may also include a frame coding area, an image frame sequence area, a component data area, a checksum area, and the like. Taking the second task cycle among multiple task cycles as an example, each storage unit corresponds to a second task cycle of the CDC and stores the second data within the second task cycle of the CDC, as well as the first data sent by the MDC and received by the CDC within the second task cycle. The first data may be acquired by the MDC during at least one of the MDC's task cycles. The second data acquired within a second task cycle of the CDC may be a single image frame or multiple image frames.

[0166] As shown in FIG9 , the storage unit corresponding to the CDC mainly includes a storage frame coding area, an image frame sequence area, an image data area, a control data area, and a checksum area. The storage frame coding area is used to store the coding information of the data block corresponding to the current storage unit, and may include the serial number of a CDC data frame (data block), the timestamp information of the data frame, and a protection identification area. The protection identification area includes a protection identification used to indicate that the storage unit cannot be deleted or overwritten, or the protection identification can also be used as a special event mark, an important record mark, etc. The image frame sequence area is used to store the image frame sequence number (or video frame sequence number), the timestamp information of the image frame, the image frame cumulative count information, the frame integrity check code, etc. within a task cycle of the CDC. The image data area is used to store the video data sent by the driving recorder. After the video data is frame-extracted, the frame-extracted video data (such as the second data) is stored in this area in image format. The control data area is used to store the message sequence number (such as the counting information of the MDC task cycle, cycle sequence number, cycle identifier, cycle number, etc.) of the data (such as the first data) sent by the MDC, the timestamp information of the data, the data and frame integrity check code, etc.

[0167] When the CDC associates and stores data, it may associate and store corresponding video data with data received from the MDC side during one task cycle of the CDC, and form a storage unit for one task cycle as shown in FIG. 9 .

[0168] For other relevant contents of the storage unit corresponding to the CDC, please refer to the contents in the aforementioned embodiment and will not be repeated here.

[0169] In some possible implementations, the CDC may also send video frame header data collected according to the CDC task cycle to the MDC based on the multicast group to represent the video data, so that the MDC saves the video frame header data (such as the image frame sequence number, the image frame cumulative count information, the timestamp, etc.) in the image frame sequence area of ​​the storage unit without saving the video data collected by the CDC, thereby saving the corresponding storage space of the MDC.

[0170] The above-mentioned verification area can be used to store the digital signature of the data in each storage unit to ensure the security and reliability of the data.

[0171] Based on FIG. 9 , the communication process between the MDC and CDC in the vehicle can also be seen in FIG. 10 .

[0172] It is understandable that after the MDC and CDC on the vehicle are synchronized (or time synchronization is completed), the time of the MDC and CDC is consistent, so the timestamp corresponding to the data can be used as an identifier for extracting data. Subsequently, when other devices (such as a host computer, data acquisition device, etc.) need to obtain data from the MDC or CDC, they can directly obtain the data records in the first data and the data records in the second data corresponding to the time based on the globally synchronized time from the MDC or CDC, where the timestamp of each data record is consistent or the same as the time. Such first data and second data can effectively play a role in vehicle accident analysis at a certain time.

[0173] Alternatively, if the time of the MDC and CDC on the vehicle is not synchronized (or the time synchronization is not completed), then since the time of the MDC and CDC may be inconsistent, the first data (based on the time of the MDC) and the second data (based on the time of the CDC) that appear to be obtained at the same time may not be obtained at the same time. In this case, the timestamp corresponding to the data is not used as an identifier for extracting data, but the data to be obtained can be located on a certain task cycle of the MDC or CDC, so as to directly obtain the storage unit corresponding to this task cycle of the MDC or CDC, and then obtain the first data and second data in the storage unit. Alternatively, it can be located on a certain image frame (or video frame) of the CDC, so as to directly obtain the storage unit corresponding to a certain task cycle of the MDC and a certain image frame of the CDC, and then obtain the first data and second data. In this way, the first data and the second data are both in the same task cycle of the MDC or the same task cycle of the CDC, and thus the vehicle accident analysis for the time within the task cycle can also be effectively played a role.

[0174] The above-mentioned MDC, CDC, etc. can maintain the independence and continuity of the first data and the second data in terms of time and task cycle for the associated storage of data. Moreover, when reading the data subsequently, the data to be read can also be effectively located according to time, task cycle, etc.

[0175] In some possible implementations, as shown in FIG11 , communication between the MDC and CDC can also be performed via a VIU. The VIU is responsible for collecting data collected by various sensors. The MDC and CDC then obtain the first data and the second data from their respective VIUs. It is understood that the VIU can be a simple controller without any processing capabilities.

[0176] In some possible implementations, the aforementioned multicast group-based communication between the MDC and CDC can also be seen in Figure 12 . In Figure 12 , after the vehicle is powered on or started, the MDC first completes local initialization configuration, applies for storage space or storage units required for data storage, and configures storage space permissions. The MDC then creates a multicast group as a multicast network for data exchange between the MDC and CDC, and transmits the multicast group information via multicast messages. The CDC first completes local initialization configuration, applies for storage space or storage units required for data storage, and configures storage space permissions. The CDC then receives the multicast message from the MDC, parses the data, obtains the multicast group information and interface information, and joins the multicast group based on the multicast group information and interface information. After the CDC completes the configuration to join the multicast group, it sends a configuration ACK message to the multicast group. After this, the CDC completes initialization and enters a dormant state. Upon receiving the ACK message via the multicast group, the MDC confirms that MDC initialization is complete and enters a dormant state.

[0177] When the autonomous driving function is activated, the vehicle starts moving, the ADS starts running, or various sensors start collecting data, the MDC and CDC end their dormant state, enter the working state, and start collecting data according to the task cycle.

[0178] In the above implementation, the vehicle can complete the backup operation of DSSAD data based on MDC and CDC, that is, DSSAD data is stored in MDC and CDC respectively, which can reduce the equipment cost of saving data and make the data easier to survive.

[0179] For example, the first controller is an MDC and the second controller is VIU0. The MDC and VIU0, respectively, include a CPU / MPU, a storage unit, an MCU, an Ethernet switch, and the like. VIU0 can also be a VIU and is a controller with processing capabilities. VIU0 can replace the VDC or CDC in the aforementioned embodiments. For specific functions and data storage formats, refer to the VDC and CDC in the aforementioned embodiments and will not be further elaborated here.

[0180] In some possible implementations, the communication between the MDC and VIU0 can also be performed based on other VIUs, where the other VIUs are responsible for collecting data collected by various sensors, and then the MDC and VIU0 respectively obtain the first data and the second data from the corresponding VIUs.

[0181] Based on Figure 1 above, the vehicle in the embodiment of the present application may also include a third controller. When the second controller is a VDC, the third controller can be a CDC; when the second controller is a CDC, the third controller can be a VDC. This allows full utilization of the three controllers on the vehicle to complete DSSAD data backup.

[0182] For example, in a scenario where the first controller is an MDC, the second controller is a VDC, and the third controller is a CDC, the communication process between the MDC, VDC, and CDC can be seen in Figure 13. In Figure 13, the MDC and VDC each include a CPU / MPU, a storage unit, an MCU, an Ethernet switch, etc. The CDC may also include a CPU / MPU, a storage unit, an MCU, etc. In some possible implementations, the CDC may also include an Ethernet switch, or the CDC may be connected to an external storage device (such as a memory card or USB flash drive), thereby saving DSSAD data to the storage device or reading DSSAD data from the storage unit via the storage device.

[0183] Among them, the processing process on the MDC side can refer to the contents of the aforementioned embodiment. On the MDC side, a multicast network can also be established with the VDC and CDC using the vehicle-mounted Ethernet through the Ethernet switching unit. The CPU / MPU on the MDC side associates and saves the data on the VDC side and the data on the CDC side obtained through the multicast network based on the sequence identifier of the data and the sequence identifier of the local data. When saving, the CPU / MPU will also pre-process the data on the VDC side and the data on the CDC side, such as completing the formatting operation of the data based on the storage protocol, adding the sequence identifier of the data, and then calculating the digital signature of the data and writing it to the corresponding area or location of the storage unit as the basis for subsequent data integrity verification. For the formatted data on the VDC side and the data on the CDC side, the CPU / MPU can also complete the encryption processing of the data based on the encryption protocol. After the encryption is completed, the CPU / MPU writes the data to the corresponding area or location of the storage unit.

[0184] The processing process on the VDC side can refer to the contents of the aforementioned embodiment. On the VDC side, a multicast network can also be established with the MDC and CDC using the vehicle Ethernet through the Ethernet switching unit. The CPU / MPU on the VDC side associates and saves the MDC side data and CDC side data obtained through the multicast network based on the sequence identifier of the data and the sequence identifier of the local data. When saving, the CPU / MPU will also pre-process the data on the MDC side and the data on the CDC side, such as completing the formatting operation of the data based on the storage protocol, adding the sequence identifier of the data, and then calculating the digital signature of the data and writing it to the corresponding area or location of the storage unit as the basis for subsequent data integrity verification. For the formatted MDC side data and VDC side data, the CPU / MPU can also complete the encryption processing of the data based on the encryption protocol. After the encryption is completed, the CPU / MPU writes the data to the corresponding area or location of the storage unit.

[0185] The processing process on the CDC side can refer to the contents of the aforementioned embodiment. On the CDC side, the CDC uses the vehicle Ethernet to establish a multicast network with the MDC and VDC through the Ethernet switching unit. The CPU / MPU on the CDC side associates and saves the MDC side data and VDC side data obtained through the multicast network based on the sequence identifier of the data and the sequence identifier of the local data. When saving, the CPU / MPU will also complete pre-processing of the data on the MDC side and the data on the VDC side, such as completing the formatting operation of the data based on the storage protocol, adding the sequence identifier of the data, and then calculating the digital signature of the data and writing it to the corresponding area or location of the storage unit as the basis for subsequent data integrity verification. For the formatted MDC side data and VDC side data, the CPU / MPU can also complete the encryption processing of the data based on the encryption protocol. After the encryption is completed, the CPU / MPU writes the data to the corresponding area or location of the storage unit.

[0186] In some possible implementations, the storage units for storing data corresponding to the MDC, VDC, and CDC respectively can refer to the contents of the aforementioned embodiments, which will not be repeated here.

[0187] The communication process between the MDC, VDC, and CDC in the vehicle can also be seen in Figure 14.

[0188] After the MDC, VDC, and CDC on a vehicle are synchronized (or time-matched), the times on the MDC, VDC, and CDC are consistent. Therefore, the timestamp corresponding to the data can be used as an identifier for extracting the data. Subsequently, when other devices (such as a host computer or data acquisition device) need to obtain data from the MDC, VDC, or CDC, they can directly obtain the data records in the first data and the data records in the second data corresponding to that time from the MDC, VDC, or CDC based on the globally synchronized time. The timestamp of each data record is consistent or identical with that time. Such first and second data can effectively play a role in analyzing vehicle accidents at a specific time.

[0189] If the MDC, VDC, and CDC times on a vehicle are not synchronized (or not fully synchronized), then the times of the MDC, VDC, and CDC may be inconsistent. Therefore, the first data (based on the MDC or VDC time) and the second data (based on the CDC time) that appear to be acquired at the same time may not be acquired at the same time. In this case, instead of using the corresponding timestamp of the data as an identifier for data extraction, the desired data is located at a specific task cycle of the MDC, VDC, or CDC, thereby directly acquiring the storage unit corresponding to this task cycle of the MDC, VDC, or CDC, and then acquiring the first and second data in this storage unit. Alternatively, the data is located at a specific image frame (or video frame) of the CDC, thereby directly acquiring the storage unit corresponding to a specific task cycle of the MDC (or VDC) and a specific image frame of the CDC, and then acquiring the first and second data. In this way, the first and second data are both within the same task cycle of the MDC (or VDC) or the same task cycle of the CDC, and thus vehicle accident analysis within the time period of this task cycle can also be effective.

[0190] In some possible implementations, the other devices may read data from the MDC, VDC, or CDC using an Ethernet interface, or may read data using other interfaces, such as copying and reading data from the CDC via a USB interface.

[0191] The above-mentioned MDC, VDC, CDC, etc. can maintain the independence and continuity of the first data and the second data in time and task cycle for the associated storage of data. Moreover, when reading data subsequently, the data to be read can also be effectively located according to time, task cycle, etc.

[0192] In addition, due to the large amount of video data, it takes up a lot of storage space when saved. To prevent the storage space of the MDC and VDC from being excessively occupied and affecting the controller performance, in some possible implementations, only the image frame sequence number (or video frame sequence number), image frame timestamp information, image frame cumulative count information, frame integrity check code, etc. corresponding to the video data associated with the task cycle of the MDC and VDC can be saved in the MDC and VDC, and a large amount of image frame data will not be saved locally in the MDC and VDC. Instead, the video data will be saved locally in the CDC. This achieves distributed storage of DSSAD data on the MDC, VDC, and CDC.

[0193] When data needs to be extracted later, the corresponding video data or image frame can be obtained from the CDC based on the image frame sequence number (or video frame sequence number), image frame timestamp information, image frame cumulative count information, etc. associated with the data within the task cycle stored in the MDC or VDC.

[0194] For MDC, if no video data or image frame data is received within a task cycle, a default mark can be added to the corresponding area or position of the storage unit; for VDC, if no video data or image frame data is received within a task cycle, a default mark can be added to the corresponding area or position of the storage unit.

[0195] In some possible implementations, the multicast group-based communication between the MDC, VDC, and CDC can also be seen in Figure 15 . In Figure 15 , after the vehicle is powered on or started, the MDC first completes local initialization configuration, applies for storage space or storage units required for data storage, and configures storage space permissions. The MDC then creates a multicast group, which serves as the multicast network for data exchange among the MDC, VDC, and CDC, and sends the multicast group information via multicast messages.

[0196] The VDC first completes its own initial configuration, applies for the storage space or storage unit required for data storage, and configures storage space permissions. The VDC then receives multicast messages from the MDC, parses the data, obtains the multicast group information and interface information, and joins the multicast group based on these information. After the VDC joins the multicast group, it sends a configuration ACK message to the multicast group. After this, the VDC completes initialization and enters a dormant state.

[0197] The CDC first completes its own initial configuration, then interacts with the dashcam, confirms the data path, applies for the storage space or storage unit required for data storage, and configures storage space permissions. The CDC then receives multicast messages from the MDC, parses the data, obtains the multicast group information and interface information, and joins the multicast group based on these information. After the VDC completes the configuration to join the multicast group, it sends a configuration ACK message to the multicast group. After this, the VDC completes initialization and enters a dormant state.

[0198] After the MDC receives the ACK message sent by the VDC and CDC through the multicast group, it confirms that the MDC initialization is complete and enters the dormant state.

[0199] When the autonomous driving function is activated, the vehicle starts moving, the ADS starts running, or various sensors start collecting data, the MDC, VDC, and CDC end their dormant state, enter the working state, and start collecting data according to the task cycle.

[0200] In the above implementation, the vehicle can complete the backup operation of DSSAD data based on MDC, VDC and CDC, that is, DSSAD data is stored in MDC, VDC and CDC respectively, which can reduce the equipment cost of saving data and make the data easier to survive.

[0201] In some possible implementations, as shown in (a) and (b) of Figure 16 , the third controller may also be VIU0. In this case, the first controller is the MDC, and the second controller may be either the VDC or the CDC. VIU0 may replace the VDC or CDC in the aforementioned embodiments. For specific functions and data storage formats, refer to the relevant content of the VDC and CDC in the aforementioned embodiments and will not be repeated here.

[0202] In some possible implementations, in addition to the above-mentioned distributed storage or multi-device backup method, the first data and the second data can also be stored separately on a controller (or support single device storage). For example, the data can be stored separately in MDC, VDC, CDC, VIU, VIU0 and other devices with data acquisition and storage functions.

[0203] For example, as shown in FIG17 , the vehicle can also implement data backup using only the MDC. In addition to the MDC functions described in the previous embodiments, the MDC shown in FIG17 can also function as a VDC. Alternatively, the MDC can function as both a VDC and a CDC. Specifically, the MDC can directly obtain the first and second data and store them according to the MDC's task cycle.

[0204] In some possible implementations, the cycle count information of the above-mentioned task cycle is the information accumulated by the number of task cycles. For example, if the task of acquiring data is performed once in each task cycle, the cycle count information is accumulated by 1. Usually, the accumulated count starts from 0. In addition, in order to avoid the count information accumulating to the maximum value within a power-on cycle of the vehicle, a 4-byte or larger data type will be set for the controller (such as MDC, VDC, CDC, etc.) to store the accumulated count information or value (sequence counter).

[0205] Some sensors used to acquire videos or images may not have a cumulative counting function. In this case, the video frame sequence number (or image frame sequence number) may be used to replace the video frame cumulative counting information (or image frame cumulative counting information).

[0206] In addition, it can be understood that MDC, VDC, CDC, etc. send the acquired data to the multicast group in the form of data packets. Therefore, each data packet can correspond to the task cycle of MDC, VDC or CDC. When saving data, the serial number of the packet can also be used to replace the cycle count information of the cycle. There is no specific restriction on this in the embodiment of the present application.

[0207] Based on the above, it can be seen that in the data backup method provided in the embodiments of the present application, for a controller storing data, data from different controllers or different sensors can be associated and saved based on various information, such as the timestamp of the data sequence identifier, cycle count information, etc. Furthermore, for a certain controller, data of other controllers that are synchronized with the controller can be effectively saved based on the controller's task cycle and / or time, so that the data saved for the controller is synchronized in time, thereby providing more accurate and valuable data for subsequent data analysis, accident analysis, etc.

[0208] By storing DSSAD data generated during vehicle operation on separate controllers, multi-point data backup is achieved. If a controller fails and the stored data becomes corrupted, the data can be retrieved from other controllers. This ensures data survival and facilitates cause tracing and accident analysis after a vehicle accident. Furthermore, there is no need to set up a separate storage device to store DSSAD data, which reduces the cost of data storage equipment.

[0209] In addition, each storage frame space also includes a check area for storing the digital signature or encryption information of the data in each storage frame space, so as to ensure the security and reliability of the data.

[0210] As shown in FIG. 18 , the data backup method provided in the embodiment of the present application may include the following steps S1801 - S1804 .

[0211] S1801: The first controller obtains first data according to a first task cycle and sends the first data to the second controller.

[0212] The first data refers to data related to the first controller generated during vehicle operation. For example, the first data may be the ADS operation information, sensor data, actuator data, etc., as described in the aforementioned embodiments. The ADS operation information includes ADS control data for vehicle control, vehicle status data, etc.

[0213] The first controller can obtain the first data based on the corresponding program, the corresponding sensor, the ADS, etc., and since the program, the sensor, the ADS, etc. may have their own task cycles or acquisition cycles, the first task cycle of the first controller can be determined according to the task cycle or acquisition cycle of the program, the sensor, etc. The task cycles of different controllers may be inconsistent, or the same controller may have different corresponding task cycles under different circumstances or when obtaining data from different sources, such as shown in Figure 2 in the aforementioned embodiment.

[0214] The first controller can correspond to multiple task cycles, with the first task cycle being any one of the multiple task cycles. During the first task cycle, the first controller cyclically acquires first data according to the first task cycle. After acquiring the first data within a first task cycle, the first controller transmits the first data to the second controller. In other words, the acquisition and transmission of the first data occur in real time. The first controller continuously acquires the first data according to the first task cycle and continuously transmits the first data to the second controller. As a result, the second controller can continuously receive the first data within its own task cycle.

[0215] In some possible implementations, before the first controller begins acquiring the first data, it may also create a multicast group and send information about the multicast group to the second controller via a multicast message. The second controller then receives the multicast message sent by the first controller and joins the multicast group. For details, see the preceding embodiments.

[0216] The multicast group is used to achieve data synchronization between the first controller and the second controller, that is, the first controller sends first data to the multicast group, so that other controllers in the multicast group can also receive the first data.

[0217] S1802: The second controller obtains second data according to a second task cycle and sends the second data to the first controller.

[0218] The second data indicates data related to the second controller generated during the operation of the vehicle. For example, the second data may be one or more of the video data recording the vehicle operation, the driver's control data of the vehicle, the environmental data during the vehicle's driving, and the vehicle's status data, as described in the aforementioned embodiment.

[0219] The second controller can obtain second data based on the corresponding program, corresponding sensor, etc., and since the program, sensor, etc. may have their own task cycle or acquisition cycle, the second task cycle of the second controller can be determined according to the task cycle or acquisition cycle of the program, sensor, etc. The task cycles of different controllers may be inconsistent, or the same controller may have different corresponding task cycles under different circumstances or when obtaining data from different sources, such as shown in Figure 2 in the aforementioned embodiment.

[0220] The second controller can correspond to multiple task cycles, with the second task cycle being any one of the multiple task cycles. During the second task cycle, the second controller cyclically acquires the second data according to the second task cycle. After acquiring the second data within a second task cycle, the second controller transmits the second data to the first controller. In other words, the acquisition and transmission of the second data occur in real time. The second controller continuously acquires the second data according to the second task cycle and continuously transmits the second data to the first controller. Consequently, the first controller can continuously receive the second data within its own task cycle.

[0221] In some possible implementations, after a second controller joins a multicast group created by a first controller, the first controller sends first data to the multicast group, allowing the second controller to obtain the first data. Similarly, the second controller sends second data to the multicast group, allowing the first controller to obtain the second data. This enables data synchronization or data sharing among multiple controllers in the multicast group.

[0222] In some possible implementations, the first controller may be an MDC, and the second controller may be a VDC. When the second controller is a VDC, the second data acquired by the second controller may include one or more of driver control data of the vehicle, environmental data during vehicle driving, and vehicle status data.

[0223] Alternatively, the second controller may also be a CDC. When the second controller is a CDC, the second data acquired by the second controller may include video data recording the running condition of the vehicle.

[0224] Alternatively, the second controller may be a VIU. When the second controller is a VIU (or the aforementioned VIU0), the VIU may independently implement the VDC or CDC functions, or may jointly implement the VDC and CDC functions. Furthermore, the second data acquired by the VIU may include one or more of video data recording vehicle operation conditions, driver control data of the vehicle, environmental data during vehicle driving, and vehicle status data.

[0225] It can be understood that the above-mentioned first data and second data can be regarded as DSSAD data that meets actual needs or requirements.

[0226] S1803: The first controller associates and saves the second data with the first data according to the first task cycle.

[0227] The first data may include M data records, each of which includes a first sequence identifier. The first sequence identifier is used to record the acquisition order of the data record, and the first sequence identifier includes a timestamp and / or cycle count information of the first task cycle. It is understood that within a first task cycle, the first controller can acquire at least one data record.

[0228] The second data may include N data records, each of which includes a second sequence identifier, which is used to record the acquisition order of the data record. The second sequence identifier includes one or more of a timestamp, a video frame sequence number (or an image frame sequence number), and cycle count information of the second task cycle. It is understood that within a second task cycle, the second controller can acquire at least one data record.

[0229] In some possible implementations, for the first task cycle, the first controller may associate and save the second data with the first data based on all second sequence identifiers of the second data received within the first task cycle and all first sequence identifiers of the first data acquired within the first task cycle.

[0230] That is to say, the first controller can save the first data and the second data according to the preset storage format. Specifically, the first data and the first sequence identifier of the first data can be saved in corresponding positions, and the second data and the second sequence identifier of the second data can be saved in corresponding positions. The saving method can be shown in (a) of Figure 4 in the aforementioned embodiment, thereby realizing the associated storage of data.

[0231] S1804: The second controller associates and saves the first data and the second data according to the second task cycle.

[0232] In some possible implementations, for the second task cycle, the second controller may associate and store the first data and the second data based on all first sequence identifiers of the first data received in the second task cycle and all second sequence identifiers of the second data acquired in the second task cycle.

[0233] That is to say, the second controller can save the first data and the second data according to the preset storage format. Specifically, the first data and the first sequence identifier of the first data can be saved in corresponding positions, and the second data and the second sequence identifier of the second data can be saved in corresponding positions. The saving method can be shown in (b) of Figure 4 or Figure 9 in the aforementioned embodiment, thereby realizing the associated storage of data.

[0234] The above method can store the first data acquired by the first controller and the second data acquired by the second controller on the first controller and the second controller, respectively. This allows each controller to store the full amount of DSSAD data. Even if one controller is damaged, the required DSSAD data can be retrieved from the other controller, thus enhancing the survivability of the DSSAD data. Furthermore, there is no need for an additional independent storage device to store the DSSAD data, thus reducing data storage costs.

[0235] In some embodiments, when DSSAD data needs to be read, other devices, such as a host computer, can read from the first controller and the second controller through the first sequence identifier of the first data and / or the second sequence identifier of the second data.

[0236] Exemplarily, the host computer sends a first data extraction instruction to the first controller, wherein the first data extraction instruction is used to instruct to extract data corresponding to a target time, where the target time includes a target moment or a target duration.

[0237] In the case of time synchronization between the first controller and the second controller, the first controller receives a first data extraction instruction and, in response to the first data extraction instruction, obtains data records in the first data and data records in the second data corresponding to a target timestamp matching the target time from the saved data.

[0238] For example, a first data extraction instruction instructs the extraction of DSSAD data at a target time of 3:00 PM on October 3, 2023. If the host computer retrieves data from the first controller, it sends the first data extraction instruction to the first controller. If the first and second controllers are time-synchronized, the first controller identifies the data record with a timestamp of 3:00 PM on October 3, 2023, from the stored DSSAD data.

[0239] For another example, a first data extraction instruction instructs to extract DSSAD data for a target time period. The target time period is January 1, 2024, to January 2, 2024. If the host computer retrieves data from the first controller, the host computer sends the first data extraction instruction to the first controller. If the first and second controllers are time-synchronized, the first controller identifies all data records with timestamps between January 1, 2024, and January 2, 2024, from the stored DSSAD data.

[0240] The first sequence identifier corresponding to the first data includes the timestamp of the first data, and the second sequence identifier corresponding to the second data includes the timestamp of the second data. Since the time between the first controller and the second controller is synchronized, the time of the first controller and the second controller is consistent, and the timestamp of the first data and the timestamp of the second data have the same timing standard. Thus, the first controller can determine the timestamp corresponding to the target time indicated by the first data extraction instruction from the saved DSSAD data. This timestamp can be one or more, and accordingly, the data record of the DSSAD data (first data and / or second data) corresponding to the timestamp can also be one or more. This is equivalent to the host computer being able to obtain data from different sensors, automatic driving systems ADS, actuators, etc. feedback at the same time from the first controller, which is conducive to analyzing vehicle accidents at a certain time.

[0241] As another example, the host computer sends a second data extraction instruction to the first controller, wherein the second data extraction instruction instructs to extract data corresponding to a target time, where the target time includes a target moment or a target duration.

[0242] For the first task cycle, when the time between the first controller and the second controller is not synchronized, the first controller receives a second data extraction instruction, and in response to the second data extraction instruction, determines a target first task cycle that matches the target time from at least one first task cycle, and obtains the first data and the second data corresponding to the target first task cycle.

[0243] For example, the second data extraction instruction instructs to extract DSSAD data at a target time, where the target time is 3:00 PM on October 3, 2023. If the host computer obtains data from the first controller, the host computer sends the second data extraction instruction to the first controller. If the time between the first controller and the second controller is not synchronized, the first controller determines the target first task cycle corresponding to 3:00 PM on October 3, 2023 from at least one corresponding first task cycle (i.e., at least one first task cycle that has been executed) and obtains the saved DSSAD data corresponding to the target first task cycle.

[0244] For another example, the second data extraction instruction instructs to extract DSSAD data for a target duration. The target duration is January 1, 2024, to January 2, 2024. If the host computer retrieves data from the first controller, the host computer sends the second data extraction instruction to the first controller. If the time between the first and second controllers is not synchronized, the first controller determines at least one target first task period corresponding to January 1, 2024, from at least one corresponding first task period, and retrieves the stored DSSAD data corresponding to the at least one target first task period.

[0245] Since the time between the first controller and the second controller is not synchronized, the time of the first controller and the second controller may be inconsistent, for example, the timing of the first controller is faster than that of the second controller, or the timing of the first controller is slower than that of the second controller.

[0246] In this case, the target time can be located on one or more task cycles of the first controller, thereby directly accessing the storage units corresponding to the one or more task cycles of the first controller and, in turn, the DSSAD data in the corresponding storage units. Such DSSAD data is all within the same task cycle of the first controller, and vehicle accident analysis targeting the time within that task cycle can be effectively performed.

[0247] Alternatively, in other embodiments, if the first controller has not determined the data record with the corresponding timestamp from the saved data, the first controller may also locate the target first task cycle according to the target time indicated by the first data extraction instruction, thereby obtaining the DSSAD data corresponding to the target first task cycle.

[0248] The host computer can obtain DSSAD from the second controller. The specific process is the same as the above process and will not be repeated here.

[0249] In some embodiments, the above data backup method may further involve a third controller, that is, data backup may also be performed in the third controller.

[0250] In this case, the third controller is configured to acquire third data according to a third task cycle. When the first controller is an MDC and the second controller is a VDC, the third controller is a CDC. The third data includes video data recording vehicle operation. Alternatively, when the first controller is an MDC, the second controller is a CDC, and the third controller is a VDC, the third data includes one or more of the following: driver control data on the vehicle, environmental data during vehicle operation, and vehicle status data.

[0251] During data backup, the third controller sends third data to the first controller and the second controller. The first controller associates and stores the third data with the first data according to a first task cycle, and the second controller associates and stores the second data with the third data according to a second task cycle.

[0252] In addition, the first controller sends the first data to the third controller, and the second controller sends the second data to the second controller. The third controller associates and stores the first data, the second data, and the third data according to a third task cycle.

[0253] It is understandable that the third data may further include Z data records, and the third sequence identifier of each data record in the Z data records includes one or more of a timestamp, a video frame sequence number, and cycle count information of a third task cycle, where Z is greater than or equal to 1. The first controller may further associate the third data with the first data and store it based on all third sequence identifiers of the third data received within the first task cycle and all first sequence identifiers of the first data acquired within the first task cycle.

[0254] The second controller may further associate and store the third data with the second data based on all third sequence identifiers of the third data received in the second task period and all second sequence identifiers of the second data acquired in the second task period. The third controller may further associate and store the first data, the second data, and the third data based on all first sequence identifiers of the first data received in the third task period, all second sequence identifiers of the second data, and all third sequence identifiers of the third data acquired in the third task period.

[0255] It can be understood that the manner of associating and saving the above data can be found in the content of the aforementioned embodiment and will not be repeated here.

[0256] Furthermore, the addition of a third controller allows the DSSAD data on the vehicle to be backed up on more devices, further improving the survivability of the DSSAD data. Furthermore, since no additional independent storage device is required to store the DSSAD data, data storage costs are also reduced.

[0257] In the aforementioned embodiments, the above-mentioned data backup method is described by taking one of the multiple task cycles corresponding to the controller as an example. It is understandable that in some other embodiments, for each task cycle in the multiple task cycles, the controller can obtain relevant data based on the task cycle and share or synchronize data with other controllers. For each task cycle, the controller can associate and save the data sent by other controllers that it has obtained data from in each task cycle. Among them, the way of sharing data between controllers and the way of saving data by the controller can refer to the methods in the aforementioned embodiments, and the purposes that can be achieved and the effective effects produced, etc. can also refer to the contents in the aforementioned embodiments, which will not be repeated here.

[0258] In some schemes, multiple embodiments of the present application can be combined, and the combined scheme can be implemented. Optionally, some operations in the process of each method embodiment are optionally combined, and / or the order of some operations is optionally changed. In addition, the execution order between the steps of each process is only exemplary and does not constitute a restriction on the execution order between the steps. There can also be other execution orders between the steps. It is not intended to indicate that the execution order is the only order in which these operations can be performed. Those of ordinary skill in the art will think of many ways to reorder the operations described in the embodiments of the present application. In addition, it should be noted that the process details involved in a certain embodiment of the present application are also applicable to other embodiments in a similar manner, or different embodiments can be used in combination.

[0259] Furthermore, some steps in the method embodiments may be equivalently replaced with other possible steps. Alternatively, some steps in the method embodiments may be optional and may be deleted in certain usage scenarios. Alternatively, other possible steps may be added to the method embodiments.

[0260] Furthermore, the various method embodiments may be implemented separately or in combination.

[0261] It is understandable that in order to achieve the above functions, the aforementioned vehicle includes hardware and / or software modules corresponding to the execution of each function. In combination with the algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in combination with the embodiments, but such implementation should not be considered to be beyond the scope of this application.

[0262] In the embodiments of the present application, the functional modules of the vehicle can be divided according to the above-mentioned method examples. For example, each functional module can be divided according to each function, or two or more functions can be integrated into a single processing module. The above-mentioned integrated modules can be implemented in the form of hardware. It should be noted that the module division in the embodiments of the present application is schematic and is only a logical functional division. In actual implementation, other division methods may be used.

[0263] In some embodiments, as shown in FIG19 , the vehicle provided in the embodiment of the present application may further include one or more controllers 1901, a memory 1902, and a communication interface 1903. Among them, the one or more controllers 1901 may respectively correspond to the controllers in the aforementioned embodiments, such as MDC, VDC, CDC, VIU, etc.

[0264] The memory 1902 and the communication interface 1903 are coupled to the controller 1901 . For example, the memory 1902 , the communication interface 1903 and the controller 1901 may be coupled together via a bus 1904 .

[0265] The communication interface 1903 is used to transmit data with other devices. The memory 1902 stores computer program code. The computer program code includes computer instructions. When the computer instructions are executed by the controller 1901, the vehicle executes the data backup method in the embodiment of the present application.

[0266] The controller 1901 may be a processor, such as a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the present disclosure. The controller may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like.

[0267] Bus 1904 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. Bus 1904 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, FIG19 shows only one thick line, but this does not imply that there is only one bus or only one type of bus.

[0268] An embodiment of the present application also provides a computer-readable storage medium, which includes computer instructions. When the computer instructions are executed on a vehicle, the vehicle can execute the relevant method steps in the above method embodiment.

[0269] Among them, the vehicle, computer storage medium, etc. provided in this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0270] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0271] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0272] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0273] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0274] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the contributing part or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0275] The above content is only a specific embodiment of this application, but the scope of protection of this application is not limited to this. Any changes or replacements within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A data backup method, characterized in that, Applied to a vehicle, the vehicle includes at least a first controller and a second controller; The first controller acquires first data according to a first task cycle and sends the first data to the second controller; the first data indicates data related to the first controller generated during the operation of the vehicle; The second controller acquires second data according to a second task cycle and sends the second data to the first controller; the second data indicates data related to the second controller generated during the operation of the vehicle; The first controller associates and stores the second data and the first data according to the first task cycle; The second controller associates and stores the first data and the second data according to the second task cycle.

2. The method according to claim 1, wherein The first controller corresponds to multiple task cycles, and the first task cycle is any one of the multiple task cycles; the first controller acquires first data according to the first task cycle and sends the first data to the second controller, including: After the first controller acquires the first data within the first task cycle, it sends the first data to the second controller.

3. The method according to claim 2, wherein The first data includes M data records, and the first sequence identifier of each data record in the M data records includes a timestamp and / or cycle count information of the first task cycle, where M is greater than or equal to 1; the second data includes N data records, and the second sequence identifier of each data record in the N data records includes one or more of a timestamp, a video frame sequence number, and cycle count information of the second task cycle, where N is greater than or equal to 1.

4. The method according to claim 3, wherein The first controller associates and stores the second data and the first data according to the first task cycle, including: The first controller associates and stores the second data and the first data based on all the second sequence identifiers of the second data received within the first task cycle and all the first sequence identifiers of the first data acquired within the first task cycle.

5. The method according to any one of claims 1-4, characterized in that, Before the first controller acquires first data according to the first task cycle, the method further includes: The first controller creates a multicast group and sends information about the multicast group to the second controller through a multicast message; The second controller receives the multicast message sent by the first controller and joins the multicast group; the multicast group is used to achieve data synchronization between the first controller and the second controller.

6. The method according to claim 5, wherein The first controller sending the first data to the second controller includes: The first controller sends the first data to the multicast group; The second controller sending the second data to the first controller includes: The second controller sends the second data to the multicast group.

7. The method according to any one of claims 1 to 6, characterized in that The first controller is a driving domain controller, the second controller is a vehicle's vehicle domain controller VDC, and the second data includes one or more of the control data of the driver for the vehicle, the environmental data during the vehicle driving process, and the state data of the vehicle.

8. The method according to any one of claims 1-6, characterized in that The first controller is a driving domain controller, the second controller is a cockpit domain controller CDC, and the second data includes video data recording the vehicle operation condition.

9. The method according to any one of claims 1-6, characterized in that, The first controller is a driving domain controller, the second controller is an in-vehicle network unit VIU, and the second data includes one or more of the video data recording the vehicle operation condition, the control data of the driver for the vehicle, the environmental data during the vehicle driving process, and the state data of the vehicle.

10. The method according to any one of claims 3-9, characterized in that The first sequence identifier includes a timestamp, and the second sequence identifier includes a timestamp; After the first controller associates and saves the second data and the first data according to the first task cycle, the method further includes: When time synchronization is achieved between the first controller and the second controller, The first controller receives a first data extraction instruction, and the first data extraction instruction indicates to extract data corresponding to a target time, where the target time includes a target moment or a target duration; The target time includes a target moment or a target duration; In response to the first data extraction instruction, the first controller obtains data records in the first data and data records in the second data corresponding to a target timestamp matching the target time from the saved data.

11. The method according to any one of claims 2-9, characterized in that, After the first controller associates and saves the second data and the first data according to the first task cycle, the method further includes: When time is not synchronized between the first controller and the second controller, The first controller receives a second data extraction instruction, and the second data extraction instruction indicates to extract data corresponding to a target time, where the target time includes a target moment or a target duration; In response to the second data extraction instruction, the first controller determines a target first task cycle matching the target time from at least one of the first task cycles, and obtains the first data and the second data corresponding to the target first task cycle.

12. The method according to claim 7, wherein The vehicle further includes a third controller; the third controller is configured to obtain third data according to a third task cycle; when the first controller is a driving domain controller and the second controller is a vehicle domain controller VDC, the third controller is a cockpit domain controller CDC, and the third data includes video data recording the vehicle operation condition.

13. The method according to claim 8, characterized in that, The vehicle further includes a third controller; the third controller is configured to obtain third data according to a third task cycle; when the first controller is a driving domain controller and the second controller is a cockpit domain controller CDC, the third controller is a vehicle domain controller VDC, and the third data includes one or more of the control data of the driver for the vehicle, the environmental data during the vehicle driving process, and the state data of the vehicle.

14. The method according to claim 12 or 13, characterized in that, The method further includes: The third controller sends the third data to the first controller and the second controller; The first controller associates and stores the third data and the first data according to the first task cycle; The second controller associates and stores the second data and the third data according to the second task cycle.

15. The method according to claim 14, wherein The method further includes: The first controller sends the first data to the third controller; The second controller sends the second data to the second controller; The third controller associates and stores the first data, the second data and the third data according to the third task cycle.

16. A vehicle, characterized in that, The vehicle includes at least a first controller and a second controller; The first controller is configured to obtain first data according to a first task cycle and send the first data to the second controller; the first data indicates data related to the first controller generated during the operation of the vehicle; The second controller is configured to obtain second data according to a second task cycle and send the second data to the first controller; the second data indicates data related to the second controller generated during the operation of the vehicle; The first controller is further configured to associate and store the second data and the first data according to the first task cycle; The second controller is further configured to associate and store the first data and the second data according to the second task cycle.

17. The vehicle according to claim 16, characterized in that, The first controller corresponds to multiple task cycles, and the first task cycle is any one of the multiple task cycles; the first controller is further configured to send the first data to the second controller after obtaining the first data within the first task cycle.

18. The vehicle according to claim 17, characterized in that, The first data includes M data records, and the first sequence identifier of each data record in the M data records includes a time stamp and / or cycle count information of the first task cycle, M≥1; the second data includes N data records, and the second sequence identifier of each data record in the N data records includes one or more of a time stamp, a video frame sequence number, and cycle count information of the second task cycle, N≥1.

19. The vehicle according to claim 18, wherein The first controller is further configured to associate and store the second data and the first data based on all the second sequence identifiers of the second data received within the first task cycle and all the first sequence identifiers of the first data obtained within the first task cycle.

20. The vehicle according to any one of claims 16-19, wherein The first controller is further configured to create a multicast group and send information of the multicast group to the second controller through a multicast message; The second controller is further configured to receive the multicast message sent by the first controller and join the multicast group; the multicast group is used to implement data synchronization between the first controller and the second controller.

21. The vehicle according to claim 20, wherein The first controller is further configured to send the first data to the multicast group; The second controller is further configured to send the second data to the multicast group.

22. The vehicle according to any one of claims 16 - 21, characterized in that, The first controller is a driving domain controller, the second controller is a vehicle's vehicle domain controller VDC, and the second data includes one or more of the driver's control data for the vehicle, the environmental data during the vehicle's driving process, and the status data of the vehicle.

23. The vehicle according to any one of claims 16-21, characterized in that, The first controller is a driving domain controller, the second controller is a cockpit domain controller CDC, and the second data includes video data recording the vehicle's operation.

24. The vehicle according to any one of claims 16-21, characterized in that, The first controller is a driving domain controller, the second controller is an in-vehicle network unit VIU, and the second data includes one or more of the video data recording the vehicle's operation, the driver's control data for the vehicle, the environmental data during the vehicle's driving process, and the status data of the vehicle.

25. The vehicle according to any one of claims 18 - 24, characterized in that, The first sequence identifier includes a timestamp, and the second sequence identifier includes a timestamp; When the first controller and the second controller are time-synchronized, The first controller is further configured to receive a first data extraction instruction, where the first data extraction instruction instructs to extract data corresponding to a target time, and the target time includes a target moment or a target duration; In response to the first data extraction instruction, the first controller is further configured to obtain, from the saved data, the data records in the first data and the data records in the second data corresponding to the target timestamp that matches the target time.

26. The vehicle according to any one of claims 17-24, wherein When the first controller and the second controller are not time-synchronized, The first controller is further configured to receive a second data extraction instruction, where the second data extraction instruction instructs to extract data corresponding to a target time, and the target time includes a target moment or a target duration; In response to the second data extraction instruction, the first controller is further configured to determine, from at least one of the first task cycles, a target first task cycle that matches the target time, and obtain the first data and the second data corresponding to the target first task cycle.

27. The vehicle according to claim 22, wherein, The vehicle further includes a third controller; the third controller is configured to obtain third data according to a third task cycle; when the first controller is a driving domain controller and the second controller is a vehicle domain controller VDC, the third controller is a cockpit domain controller CDC, and the third data includes video data recording the vehicle's operation.

28. The vehicle according to claim 23, wherein The vehicle further includes a third controller; the third controller is configured to obtain third data according to a third task cycle; when the first controller is a driving domain controller and the second controller is a cockpit domain controller CDC, the third controller is a vehicle domain controller VDC, and the third data includes one or more of the driver's control data for the vehicle, the environmental data during the vehicle's driving process, and the status data of the vehicle.

29. The vehicle according to claim 27 or 28, wherein The third controller is further configured to send the third data to the first controller and the second controller; The first controller is further configured to associate and save the third data and the first data according to the first task cycle; The second controller is further configured to associate and save the second data and the third data according to the second task cycle.

30. The vehicle according to claim 29, wherein The first controller is further configured to send the first data to the third controller; The second controller is further configured to send the second data to the second controller; The third controller is further configured to associate and save the first data, the second data, and the third data according to the third task cycle.

31. A computer-readable storage medium, characterized in that, Comprising computer instructions which, when running on a vehicle, cause the vehicle to execute the data backup method according to any one of claims 1-15.

Images