Domain controller clock synchronization management method, device and system and vehicle

Abstract

The embodiment of the invention provides a domain controller clock synchronization management method, device and system and a vehicle, and relates to the technical field of automatic driving. The method comprises the steps that system timestamp marking is conducted on sensor data based on a system clock source, and meanwhile calendar timestamp marking is conducted on the sensor data based on a calendar clock source; when it is judged that the calendar clock source is in the invalid state, calendar timestamp marking is conducted on the sensor data based on the system clock source; and after the calendar clock source is recovered to be valid, performing calendar timestamp updating processing on the sensor data marked as the abnormal calendar timestamp. According to the embodiment of the invention, the time synchronization in the domain controller is carried out at the same time by configuring the double clock sources, and the calendar timestamp updating processing is carried out on the data in the invalid period of the calendar clock by adopting a post-processing mode, so that the normal operation requirement of the intelligent driving function and the time real-time requirement of a log system / data uploading cloud can be met at the same time.

Description

Technical Field

[0001] The present application relates to the field of autonomous driving technology, and more specifically, to a domain controller clock synchronization management method, device, system, and vehicle. Background Art

[0002] In the field of intelligent driving, implementing various assisted driving functions requires integrating data from multiple sensors, including lidar, cameras, millimeter-wave radar, and inertial navigation systems. To ensure sensor perception, fusion, and decision-making, the intelligent driving domain controller must synchronize the time of its connected sensors to ensure that the entire system operates in the same time domain.

[0003] At present, the intelligent driving domain controller mainly adopts a single-clock time synchronization method to synchronize the UTC (Universal Time Coordinated) time obtained from the gateway within the domain. However, in scenarios with weak network signals such as garages or tunnels and when the entire vehicle system is cold-started, the UTC time information of the gateway will be temporarily invalid. At this time, the intelligent driving system cannot obtain valid time information for time synchronization, resulting in the inability to activate the assisted driving function of the intelligent driving system. If you do not wait for the valid UTC time and directly use the default system local time for time synchronization, although it can ensure the normal activation of the assisted driving function, it still cannot meet the real-time requirements of the logging system, cloud data upload and digital certificate authentication. And when the UTC time information becomes valid again, if you switch directly back to the UTC time synchronization domain, time jumps will occur, causing system abnormalities, which will in turn cause the assisted driving function to exit abnormally.

[0004] In summary, the existing domain controller time synchronization solution cannot simultaneously meet the normal operation requirements of intelligent driving functions and the real-time requirements of the log system / data upload to the cloud. Summary of the Invention

[0005] The purpose of the embodiments of the present application is to provide a domain controller clock synchronization management method, device, system and vehicle, which can simultaneously meet the normal operation requirements of the intelligent driving function and the real-time requirements of the log system / data upload to the cloud.

[0006] In a first aspect, an embodiment of the present application provides a domain controller clock synchronization management method, comprising:

[0007] The sensor data acquired in real time is time-stamped based on a system clock source, and the sensor data is time-stamped based on a calendar clock source. The system clock source is a clock source with monotonically increasing linear time maintained by an external crystal oscillator, and the calendar clock source is a clock source that obtains universal time through a network.

[0008] When it is determined that the calendar clock source is in an invalid state, performing calendar timestamp marking on the sensor data based on the system clock source, and marking the sensor data during the period when the calendar clock source is in the invalid state as calendar timestamp anomaly;

[0009] After determining that the calendar clock source is restored from an invalid state to a valid state, a calendar timestamp update process is performed on the sensor data marked as calendar timestamp anomalies in the log system and the cloud database.

[0010] In an embodiment of the present application, dual clock sources are configured to simultaneously synchronize time within the domain controller. For data during the invalid period of the calendar clock, a post-processing method is used to update the calendar timestamp, thereby simultaneously meeting the normal operation requirements of the intelligent driving function and the real-time requirements of the log system / data upload to the cloud.

[0011] In some possible embodiments, the domain controller clock synchronization management method further includes:

[0012] When receiving the recharge sensor data, obtaining a sensor timestamp of the recharge sensor data and a local system timestamp of the system clock source;

[0013] A system timestamp update process is performed on the recharge sensor data based on the local system timestamp and the sensor timestamp.

[0014] In some possible embodiments, the domain controller clock synchronization management method further includes:

[0015] When receiving the recharge sensor data, obtaining the local calendar timestamp of the calendar clock source, and obtaining the difference between the system timestamp of the recharge sensor data and the local system timestamp;

[0016] Perform calendar time stamp updating processing on the recharge sensor data based on the local calendar time stamp and the phase difference value.

[0017] In some possible embodiments, performing system timestamp updating processing on the recharge sensor data based on the local system timestamp and the sensor timestamp includes:

[0018] Determining whether the millisecond portion of the sensor timestamp is less than the millisecond portion of the local system timestamp;

[0019] If yes, combining the second part of the local system timestamp with the millisecond part of the sensor timestamp as the system timestamp after the reinjection sensor data is updated;

[0020] If not, the second part of the local system timestamp minus one second is combined with the millisecond part of the sensor timestamp to serve as the system timestamp after the recharge sensor data is updated.

[0021] In some possible embodiments, the domain controller includes a microcontroller and a plurality of systems on chips connected to the microcontroller;

[0022] The microcontroller synchronizes the time information of the system clock source to each of the on-chip systems through the gPTP protocol. At the same time, the microcontroller synchronizes the time information of the calendar clock source to each of the on-chip systems through the network time protocol.

[0023] In some possible embodiments, after determining that the calendar clock source is restored from an invalid state to a valid state, performing calendar timestamp updating processing on sensor data marked as calendar timestamp anomalies in the log system and the cloud database includes:

[0024] Obtaining a last timestamp before the calendar clock source is restored to a valid state, and determining a timestamp compensation value based on a timestamp after the calendar clock source is restored to a valid state, the last timestamp, and a preset data update period;

[0025] For target sensor data marked as having abnormal calendar timestamps in the log system and the cloud database, calendar timestamp updating processing is performed on the target sensor data based on the timestamp compensation value.

[0026] In some possible embodiments, determining that the calendar clock source is in an invalid state includes:

[0027] If it is determined that the network signal strength of the vehicle where the domain controller is located is lower than a set threshold, or if it is determined that the vehicle is in a cold start state, then it is determined that the calendar clock source is in an invalid state.

[0028] In a second aspect, an embodiment of the present application provides a domain controller clock synchronization management device, comprising:

[0029] A timestamp module, configured to perform a system timestamp on sensor data acquired in real time based on a system clock source, and to perform a calendar timestamp on the sensor data based on a calendar clock source; wherein the system clock source is a clock source with monotonically increasing linear time maintained by an external crystal oscillator, and the calendar clock source is a clock source that obtains universal time through a network;

[0030] a time invalidation processing module, configured to, when determining that the calendar clock source is in an invalid state, perform calendar timestamp marking on the sensor data based on the system clock source, and mark the sensor data during the period when the calendar clock source is in the invalid state as calendar timestamp anomaly;

[0031] The timestamp post-processing module is used to perform calendar timestamp update processing on sensor data marked as calendar timestamp anomalies in the log system and the cloud database after determining that the calendar clock source is restored from an invalid state to a valid state.

[0032] In a third aspect, an embodiment of the present application provides a domain controller clock synchronization management system, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor can implement the method described in any embodiment of the first aspect when executing the program.

[0033] In a fourth aspect, an embodiment of the present application provides a vehicle, comprising the domain controller clock synchronization management system described in the embodiment of the third aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0035] Figure 1 A flowchart of a domain controller clock synchronization management method provided in an embodiment of the present application;

[0036] Figure 2 A system architecture diagram of the domain controller clock synchronization management solution provided in an embodiment of the present application;

[0037] Figure 3 A schematic diagram of the structure of a domain controller clock synchronization management device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0038] 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.

[0039] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and should not be understood as indicating or implying relative importance.

[0040] It should be noted that in intelligent driving systems at Level 2 and above, implementing advanced assisted driving features such as Traffic Jam Assist (TJA), Lane Centering Assist (LCC), and Navigation Assist (NOA) requires the fusion of data from multiple sensors, including lidar, cameras, millimeter-wave radar, and inertial navigation systems. To ensure the smooth implementation of sensor perception, fusion, and decision-making planning, the intelligent driving domain controller must synchronize time with all connected sensors to ensure the entire system operates in the same time domain.

[0041] At present, since intelligent driving domain controllers mainly use a single-clock time synchronization method, they cannot simultaneously meet the normal operation requirements of intelligent driving functions and the real-time requirements of the log system / data upload to the cloud.

[0042] In view of the problems existing in the above-mentioned prior art, Figure 1 As shown, the embodiment of the present application provides a domain controller clock synchronization management method, which may include the following steps:

[0043] S1. Perform a system timestamp on the sensor data acquired in real time based on the system clock source. At the same time, perform a calendar timestamp on the sensor data based on the calendar clock source. The system clock source is a clock source with monotonically increasing linear time maintained by an external crystal oscillator, and the calendar clock source is a clock source that obtains universal time through the network.

[0044] Furthermore, the domain controller includes a microcontroller and a plurality of systems on chips connected to the microcontroller;

[0045] The microcontroller synchronizes the time information of the system clock source to each on-chip system through the gPTP protocol. At the same time, the microcontroller synchronizes the time information of the calendar clock source to each on-chip system through the Network Time Protocol.

[0046] It should be noted that by simultaneously using the system clock source and the calendar clock source to timestamp the acquired sensor data, the sensor data has both monotonically increasing linear time information and universal time information, thereby simultaneously meeting functions such as data fusion, planning and control, logging, and cloud data upload. Among them, data fusion and planning and control functions are more sensitive to time jumps, so the timestamp information from the system clock source is used as the time basis for data processing. However, functions such as logging and uploading data to cloud storage rely on the real-time information of the data, so the timestamp information from the calendar clock source is used as the time basis for data processing.

[0047] S2. When it is determined that the calendar clock source is in an invalid state, the sensor data is calendar-time-stamped based on the system clock source, and the sensor data during the period when the calendar clock source is in the invalid state is marked as calendar-time-stamp anomaly.

[0048] Furthermore, determining whether the calendar clock source is in an invalid state may include:

[0049] If the network signal strength of the vehicle where the domain controller is located is lower than the set threshold, or if the vehicle is judged to be in a cold start state, the calendar clock source is determined to be in an invalid state.

[0050] It should be noted that when the calendar clock source is in an invalid state, since functions such as data fusion and planning control use the system clock source for timestamps, the invalid period of the calendar clock source has no impact on the normal activation and continued normal operation of functions such as data fusion and planning control. For functions such as logging and uploading cloud storage data, the system clock source can be used for timestamps during the invalid period of the calendar clock source. This does not affect the normal operation of functions such as logging and uploading cloud storage data. In addition, by marking the timestamp information of these sensor data (during the invalid period of the calendar timestamp) as abnormal, the calendar timestamps of these data can be updated through post-processing without affecting the actual data logging performance.

[0051] S3. After determining that the calendar clock source is restored from an invalid state to a valid state, update the calendar timestamps of the sensor data marked as calendar timestamp anomalies in the log system and the cloud database.

[0052] It should be noted that by adopting a dual clock source configuration, on the one hand, the system clock source is used to mark the sensor data with a system timestamp. Since the time of the system clock source is monotonically increasing and there will be no time jumps or rollbacks, the normal activation and continuous normal operation of the assisted driving function are met, and there will be no abnormalities in the assisted driving system due to time jumps; on the other hand, the calendar clock source is used to mark the sensor data with a calendar timestamp, and the logs and cloud data during the period when the calendar clock source is invalid are compensated by post-processing, which does not affect the validity of the log record analysis and uploaded cloud data, and meets the real-time requirements of the log system, cloud uploaded data and digital certificate authentication.

[0053] like Figure 2 As shown, it should be noted that, in the embodiment of the present application, the domain controller may include an MCU (MicroController Unit) and several SOCs (System On Chip) connected to the MCU.

[0054] It should be noted that the domain controller includes a system clock source and a calendar clock source. The system clock source refers to a monotonically increasing linear time based on an external crystal oscillator, starting at 00:00:00 on January 1, 1970. Because the system clock source does not experience time jumps or rollbacks, it can ensure the stability and controllability of the time of each subsystem of the domain controller, thereby ensuring that the assisted driving function can be properly activated and continuously and stably operate normally. The calendar clock source refers to the valid UTC real-time time periodically obtained by the MCU from the backbone CAN network.

[0055] Specifically, the MCU synchronizes the system time (the time of the system clock source) to the SOC through the gPTP (Generalized Precision Time Protocol) protocol, and synchronizes the system time to the private CAN (Controller Area Network) node connected to the MCU through the Can Time Synchronization Protocol (CanTsyn). Similarly, the SOC sends the synchronized system time to the private subsystem nodes (including inertial navigation systems, ultrasonic radars, etc.) connected to the SOC through the gPTP protocol or the Can Time Synchronization Protocol; at the same time, the MCU also synchronizes the calendar time (the time of the calendar clock source) to the SOC through the Network Time Protocol (NTP).

[0056] It should be noted that when the MCU and SOC acquire sensor data (sensor data) from their connected sensors, they can simultaneously stamp this sensor data with a system timestamp and a calendar timestamp to enable functions such as data fusion, planning control, logging, and cloud data upload. It is understandable that due to the monotonically increasing nature of the system clock source, there is no need to reset the time base, ensuring that the time used for perception, fusion, and planning control will not jump or regress, thereby ensuring the stability of the domain controller system and assisted driving functions.

[0057] It is understandable that when the calendar clock source is determined to be in an invalid state (UTC time is invalid), the system time can be used as the calendar time synchronization domain. After the UTC time is valid (after confirming that the calendar clock source has recovered from an invalid state to a valid state), the calendar clock source time can be reset. Therefore, the jump in calendar time will not cause abnormalities or exit of the assisted driving function. Moreover, updating the calendar timestamp during the invalid UTC time period to UTC real time through post-processing will not affect the validity of the log system's record analysis and uploaded cloud data, thereby simultaneously meeting the normal operation requirements of the intelligent driving function and the real-time requirements of the log system / data upload to the cloud.

[0058] In some possible embodiments, the domain controller clock synchronization management method may further include:

[0059] When receiving the recharge sensor data, obtain the sensor timestamp of the recharge sensor data and the local system timestamp of the system clock source;

[0060] The system timestamp of the recharged sensor data is updated based on the local system timestamp and the sensor timestamp.

[0061] Furthermore, performing a system timestamp update process on the recharged sensor data based on the local system timestamp and the sensor timestamp may include:

[0062] Determine whether the millisecond portion of the sensor timestamp is less than the millisecond portion of the local system timestamp;

[0063] If yes, then combine the second part of the local system timestamp with the millisecond part of the sensor timestamp to serve as the system timestamp after the reinjected sensor data is updated;

[0064] If not, the second part of the local system timestamp minus one second is combined with the millisecond part of the sensor timestamp to serve as the system timestamp after the reinjection sensor data is updated.

[0065] It's important to note that in actual production applications, automakers need to use data collection vehicles to collect and test data when launching new models or adding new driving features. Only after the testing meets predetermined standards can the new models be mass-produced or the new driving features be released. Understandably, both data collection vehicles and production vehicles connect real sensors to corresponding domain controller systems and store sensor data on hard drives or upload it to the cloud. Data re-injection involves virtual playback of this sensor data via a host computer, simulating real-world scenarios to verify, test, and optimize intelligent driving functions.

[0066] It is understandable that the re-injected sensor data is not collected in real time by real sensors. The re-injected sensor data is obtained from the hard disk or the cloud and is segmented and labeled. Therefore, the time of the re-injected sensor data is inconsistent with the real-time system time of the domain controller of the re-injection test bench. At this time, the local timestamp is needed for compensation to ensure that the time of the re-injected sensor data and the real-time system time of the domain controller of the re-injection test bench are in the same time domain.

[0067] Specifically, when receiving re-injected sensor data, the domain controller needs to obtain the local system timestamp and sensor timestamp and compare the millisecond portion of the local system timestamp with the millisecond portion of the sensor timestamp. Because the transmission delay of sensor data to the domain controller is less than 1 second, when the millisecond portion of the sensor timestamp is less than the millisecond portion of the local system time, the seconds portion of the local system time can be directly combined with the millisecond portion of the sensor time to serve as the updated system timestamp for the re-injected sensor data. If the millisecond portion of the sensor timestamp is greater than or equal to the millisecond portion of the local system timestamp, it indicates that the local system time is rounded up to the second. Therefore, the seconds portion of the local system time needs to be subtracted by 1 second and then combined with the millisecond portion of the sensor timestamp to serve as the updated system timestamp for the re-injected sensor data.

[0068] Furthermore, the domain controller clock synchronization management method may further include:

[0069] When receiving the recharge sensor data, obtain the local calendar timestamp of the calendar clock source, and obtain the difference between the system timestamp of the recharge sensor data and the local system timestamp;

[0070] The calendar timestamp of the recharge sensor data is updated based on the local calendar timestamp and the phase difference value.

[0071] It should be noted that when the domain controller receives the re-injected sensor data, in addition to updating the system timestamp, it can also obtain the local calendar timestamp and calculate the difference between the local system timestamp and the original system timestamp of the re-injected sensor data. The difference is added as an offset to the original local calendar timestamp of the re-injected sensor data as the updated calendar timestamp of the re-injected sensor data.

[0072] For example, the re-injected sensor data was actually collected and stored in the cloud on January 1, 2020 (in actual applications, system timestamps are usually expressed in seconds and milliseconds. For the convenience of description, this embodiment uses the year-month-day format for explanation). Due to test requirements, the sensor data needs to be re-injected on July 1, 2020. At this time, the original system timestamp of the re-injected sensor data (January 1, 2020) is updated to the latest system timestamp through the above-mentioned time update mechanism (approximately July 1, 2020. Since the millisecond part of the original timestamp of the sensor data is used for update, there is a certain difference from the real-time system timestamp). The calendar timestamp of the re-injected sensor data also needs to be updated. Specifically, since the difference between the updated system timestamp (i.e., the local system timestamp) and the original system timestamp (sensor timestamp) can be considered to be equal to the difference between the updated calendar timestamp and the original calendar timestamp, the difference between the local system timestamp and the original system timestamp of the re-injected sensor data can be superimposed on the local calendar timestamp obtained at the current moment (the moment when the re-injected data is obtained) to obtain the updated calendar timestamp of the re-injected sensor data.

[0073] Based on this, the above-mentioned sensor timestamp update mechanism can simultaneously meet the sensor timestamp update requirements of mass-produced vehicles and recharge test benches, without the need for additional maintenance of special software versions.

[0074] In some possible embodiments, after determining that the calendar clock source has recovered from an invalid state to a valid state, performing calendar timestamp update processing on sensor data marked as calendar timestamp anomalies in the log system and the cloud database includes:

[0075] Obtaining the last timestamp before the calendar clock source is restored to a valid state, and determining a timestamp compensation value based on the timestamp after the calendar clock source is restored to a valid state, the last timestamp, and a preset data update period;

[0076] For target sensor data marked as having abnormal calendar timestamps in the log system and the cloud database, calendar timestamps of the target sensor data are updated based on the timestamp compensation value.

[0077] It should be noted that when the vehicle enters an underground garage or other scenarios with weak network signals, or undergoes a cold start, the UTC time obtained from the gateway is invalid. During this period, the calendar timestamp of the acquired sensor data can be timestamped using the system clock source, without affecting the real-time requirements of the logging system and uploaded cloud data. When the UTC time obtained from the gateway becomes valid, the calendar clock source time is reset. Changes in calendar time will not cause abnormalities or exit the domain controller system or assisted driving functions.

[0078] For calendar timestamps during the period when UTC time is invalid, when the UTC time obtained from the gateway becomes valid, the calendar timestamps in the log system and cloud database are updated to absolute real-time time using a post-processing method. Specifically, the last calendar timestamp before the UTC time becomes valid is first added to the time data update period (the preset data update period), and then the calendar timestamp after the UTC time becomes valid is subtracted from the result of the above sum to obtain the timestamp compensation value; for all calendar timestamps during the period when UTC time is invalid, these calendar timestamps are added to the timestamp compensation value to serve as the updated calendar timestamps of these data.

[0079] For example, suppose the calendar timestamp information of a segment of sensor data stored in the cloud is: "100-101-102-50-51-52-106-107". For the timestamp information of this segment, "50-51-52" is the time marked by the system timestamp during the period when the calendar clock source is invalid. Post-processing is required to compensate and update the timestamps of this period. Specifically, first obtain the last timestamp "52" before the calendar clock source is restored to the valid state, and then determine the timestamp compensation value based on the timestamp "106" after the calendar clock source is restored to the valid state, the last timestamp "52" and the preset data update cycle (the data update cycle is 1 in this example): 106-52-1=53; then, based on the timestamp compensation value "53", each timestamp in "50-51-52" is added to obtain "103-104-105", and the final calendar timestamp after the sensor data segment is updated is "100-101-102-103-104-105-106-107".

[0080] Please refer to Figure 3 , Figure 3 The diagram shows a block diagram of the domain controller clock synchronization management device provided by some embodiments of the present application. It should be understood that the domain controller clock synchronization management device is similar to the above Figure 1 Corresponding to the method embodiment, the various steps involved in the above method embodiment can be executed. The specific functions of the domain controller clock synchronization management device can be found in the description above. To avoid repetition, the detailed description is appropriately omitted here.

[0081] Figure 3 The domain controller clock synchronization management device includes at least one software function module that can be stored in a memory in the form of software or firmware or solidified in the domain controller clock synchronization management device, and the domain controller clock synchronization management device includes:

[0082] The timestamp module 310 is configured to timestamp the sensor data acquired in real time based on a system clock source, and to timestamp the sensor data based on a calendar clock source. The system clock source is a clock source with monotonically increasing linear time maintained by an external crystal oscillator, and the calendar clock source is a clock source that obtains universal time through a network.

[0083] The time invalidation processing module 320 is configured to, when it is determined that the calendar clock source is in an invalid state, perform a calendar timestamp on the sensor data based on the system clock source, and mark the sensor data during the period when the calendar clock source is in the invalid state as a calendar timestamp anomaly;

[0084] The timestamp post-processing module 330 is configured to update the calendar timestamp of the sensor data marked as abnormal in the log system and the cloud database after determining that the calendar clock source is restored from an invalid state to a valid state.

[0085] It can be understood that the above-mentioned device embodiment corresponds to the method embodiment of the present invention. The domain controller clock synchronization management device provided by the embodiment of the present invention can implement the domain controller clock synchronization management method provided by any method embodiment of the present invention.

[0086] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working process of the device described above can refer to the corresponding process in the aforementioned method, and will not be described in detail here.

[0087] An embodiment of the present application also provides a domain controller clock synchronization management system, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the method described in the method embodiment can be implemented when the processor executes the program.

[0088] An embodiment of the present application also provides a vehicle, which includes the domain controller clock synchronization management system of the embodiment of the third aspect.

[0089] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similarities between the various embodiments can be referred to in conjunction with each other. For device embodiments, since they are generally similar to method embodiments, their description is relatively simple, and for relevant details, reference can be made to the description of the method embodiments.

[0090] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions, and operations of the devices, methods, and computer program products according to the multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment, or a portion of code, and the module, program segment, or a portion of code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

[0091] In addition, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0092] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) 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 USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0093] The foregoing is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included within the scope of protection of the present application. It should be noted that similar reference numerals and letters represent similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined or explained in subsequent figures.

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

[0095] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

Claims

1. A domain controller clock synchronization management method, characterized in that: include: The sensor data acquired in real time is time-stamped based on a system clock source, and the sensor data is time-stamped based on a calendar clock source. The system clock source is a clock source with monotonically increasing linear time maintained by an external crystal oscillator, and the calendar clock source is a clock source that obtains universal time through a network. When it is determined that the calendar clock source is in an invalid state, performing calendar timestamp marking on the sensor data based on the system clock source, and marking the sensor data during the period when the calendar clock source is in the invalid state as calendar timestamp anomaly; After determining that the calendar clock source is restored from an invalid state to a valid state, a calendar timestamp update process is performed on the sensor data marked as calendar timestamp anomalies in the log system and the cloud database.

2. The domain controller clock synchronization management method according to claim 1, characterized in that: Also includes: When receiving the recharge sensor data, obtaining a sensor timestamp of the recharge sensor data and a local system timestamp of the system clock source; A system timestamp update process is performed on the recharge sensor data based on the local system timestamp and the sensor timestamp.

3. The domain controller clock synchronization management method according to claim 2, characterized in that: Also includes: When receiving the recharge sensor data, obtaining the local calendar timestamp of the calendar clock source, and obtaining the difference between the system timestamp of the recharge sensor data and the local system timestamp; Perform calendar time stamp updating processing on the recharge sensor data based on the local calendar time stamp and the phase difference value.

4. The domain controller clock synchronization management method according to claim 2, characterized in that: The performing system timestamp updating processing on the recharge sensor data based on the local system timestamp and the sensor timestamp includes: Determining whether the millisecond portion of the sensor timestamp is less than the millisecond portion of the local system timestamp; If yes, combining the second part of the local system timestamp with the millisecond part of the sensor timestamp as the system timestamp after the reinjection sensor data is updated; If not, the second part of the local system timestamp minus one second is combined with the millisecond part of the sensor timestamp to serve as the system timestamp after the recharge sensor data is updated.

5. The domain controller clock synchronization management method according to claim 1, characterized in that: The domain controller includes a microcontroller and a plurality of systems on chips connected to the microcontroller; The microcontroller synchronizes the time information of the system clock source to each of the on-chip systems through the gPTP protocol. At the same time, the microcontroller synchronizes the time information of the calendar clock source to each of the on-chip systems through the network time protocol.

6. The domain controller clock synchronization management method according to claim 1, characterized in that: After determining that the calendar clock source is restored from an invalid state to a valid state, performing calendar timestamp update processing on sensor data marked as calendar timestamp anomalies in the log system and the cloud database includes: Obtaining a last timestamp before the calendar clock source is restored to a valid state, and determining a timestamp compensation value based on a timestamp after the calendar clock source is restored to a valid state, the last timestamp, and a preset data update period; For target sensor data marked as having abnormal calendar timestamps in the log system and the cloud database, calendar timestamp updating processing is performed on the target sensor data based on the timestamp compensation value.

7. The domain controller clock synchronization management method according to claim 1, characterized in that: The determining that the calendar clock source is in an invalid state includes: If it is determined that the network signal strength of the vehicle where the domain controller is located is lower than a set threshold, or if it is determined that the vehicle is in a cold start state, then it is determined that the calendar clock source is in an invalid state.

8. A domain controller clock synchronization management device, characterized in that: include: A timestamp module, configured to perform a system timestamp on sensor data acquired in real time based on a system clock source, and to perform a calendar timestamp on the sensor data based on a calendar clock source; wherein the system clock source is a clock source with monotonically increasing linear time maintained by an external crystal oscillator, and the calendar clock source is a clock source that obtains universal time through a network; a time invalidation processing module, configured to, when determining that the calendar clock source is in an invalid state, perform calendar timestamp marking on the sensor data based on the system clock source, and mark the sensor data during the period when the calendar clock source is in the invalid state as calendar timestamp anomaly; The timestamp post-processing module is used to perform calendar timestamp update processing on sensor data marked as calendar timestamp anomalies in the log system and the cloud database after determining that the calendar clock source is restored from an invalid state to a valid state.

9. A domain controller clock synchronization management system, characterized in that: The system comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the domain controller clock synchronization management method according to any one of claims 1 to 7 can be implemented.

10. A vehicle, characterized in that: The vehicle includes the domain controller clock synchronization management system according to claim 9.

Images