Multi-source cooperative automobile time synchronization method, controller and vehicle

Abstract

According to the multi-source cooperative automobile time synchronization method, the controller and the vehicle, an external clock source is introduced, multi-source cooperative operation is carried out, an accurate timestamp is provided for an intelligent automobile, meanwhile, a high-precision time synchronization method is used in the automobile, and the automobile is safer and more intelligent. The method comprises the steps of receiving time signals from at least two different types of external time sources when it is recognized that a vehicle loses a satellite signal, or the satellite signal strength is lower than a preset threshold value, or the vehicle is in a charging scene; the external time source does not comprise a satellite signal source; dynamically selecting an optimal external time source from a plurality of external time sources according to a preset dynamic selection strategy, and directly determining a time signal of the optimal external time source as an optimal time reference; and generating first global reference time based on the optimal time reference, and distributing the first global reference time to each domain controller and sensor node in the vehicle through a vehicle-mounted network so as to realize time synchronization of the whole vehicle.

Description

Technical Field

[0001] This invention relates to the field of time synchronization for automobiles, and more specifically to a multi-source collaborative automobile time synchronization method, controller, and vehicle. Background Technology

[0002] With the widespread adoption of intelligent technologies in modern automobiles, the electronic architecture of vehicles is exhibiting highly integrated and distributed characteristics. In heterogeneous in-vehicle network systems, the coordinated operation of distributed electronic control units (ECUs), multimodal sensor arrays, and heterogeneous communication modules must be based on strict time consistency.

[0003] Meanwhile, this high-precision time synchronization mechanism has a decisive impact on the reliability of automated driving systems (ADS), and its technical implementation must meet the ASIL-D level requirements of the ISO 26262 functional safety standard. Specifically, in L3-L4 conditional automated driving scenarios, the data fusion of multi-source heterogeneous sensors (including LiDAR, millimeter-wave radar, vision sensors, etc.) faces strict time-domain constraints. Each subsystem needs to achieve millisecond-level timestamp synchronization to ensure that multi-sensor data is fusionable in the time domain. However, in the existing domain controller architecture, because each functional domain (powertrain domain, chassis domain, infotainment domain, intelligent driving domain, etc.) uses an independent clock source and lacks a global synchronization mechanism, the clock sources of each node have inherent frequency deviations and phase offsets, which in turn cause timestamp asynchrony problems.

[0004] Existing technologies for vehicle time synchronization systems suffer from a significant reliance on a single source of information. Specifically, current mainstream solutions over-rely on Global Navigation Satellite Systems (GNSS, such as GPS / BeiDou) and traditional vehicular networks (such as CAN bus) as time reference sources. In complex urban traffic scenarios, GNSS signals are susceptible to the "urban canyon effect," with multipath reflections and obstructions caused by tall buildings resulting in signal loss rates as high as 32% for onboard receivers in complex urban environments. Furthermore, GNSS signals completely fail in enclosed environments such as tunnels and underground parking lots, forcing the system to revert to an internal clock source with insufficient accuracy. Traditional CAN bus timing mechanisms are limited by their physical layer characteristics. Due to the nondeterministic delays and bandwidth limitations caused by the bus arbitration mechanism, even with the improved CANFD protocol, timing accuracy is still limited to ±20ms, failing to meet the ≤2ms time-domain consistency requirement for multi-sensor data fusion in Level 3 and above autonomous driving. In high-speed vehicle scenarios, the Doppler shift effect of GNSS signals and the communication delay of the CAN bus superimpose, potentially amplifying time synchronization errors and directly threatening the decision-making safety boundaries of the autonomous driving system.

[0005] In summary, existing automotive time synchronization methods have the following limitations and problems:

[0006] Internal clock asynchrony problem: Traditional vehicle controllers (such as powertrain, chassis, and infotainment domains) use independent clock sources, resulting in dispersed time bases and accumulated errors of more than 10ms, which cannot meet the real-time data fusion requirements of Level 3 and above autonomous driving.

[0007] External synchronization relies on a single source: Existing solutions mostly rely on GPS or vehicle networks (such as CAN bus) for timing, but GPS signals are easily lost in scenarios such as urban canyons and tunnels, while the timing accuracy of CAN bus can only reach ±20ms.

[0008] Insufficient adaptability to dynamic scenarios: Existing time synchronization protocols have difficulty dynamically compensating for clock drift when vehicles are moving at high speeds or when network topology changes, leading to the failure of V2X collaborative perception. Summary of the Invention

[0009] This application provides a multi-source collaborative vehicle time synchronization method, controller, and vehicle. By introducing an external clock source, multiple sources work together to provide accurate timestamps for intelligent vehicles. At the same time, a high-precision time synchronization method is also used inside the vehicle, making the vehicle safer and smarter.

[0010] The technical solution of this invention is as follows:

[0011] This application provides a multi-source collaborative vehicle time synchronization method, including:

[0012] When it is detected that the vehicle has lost its satellite signal, the satellite signal strength is lower than a preset threshold, or the vehicle is in a charging scenario, time signals are received from at least two different types of external time sources; the external time sources do not include satellite signal sources.

[0013] Based on a preset dynamic selection strategy, an optimal external time source is dynamically selected from the multiple external time sources, and the time signal of the optimal external time source is directly determined as the optimal time reference.

[0014] Based on the optimal time reference, a first global reference time is generated and distributed to the domain controllers and sensor nodes inside the vehicle through the vehicle network to achieve time synchronization of the entire vehicle.

[0015] Preferably, at least two different types of external time sources include at least two of the following: V2X roadside units, smart charging piles, and mobile terminals.

[0016] Preferably, the step of dynamically selecting an optimal external time source from the plurality of external time sources according to a preset dynamic selection strategy includes:

[0017] When the vehicle is in a charging scenario, select a smart charging station as the optimal external time source;

[0018] When a vehicle is in a V2X coverage area, the V2X roadside unit is selected as the optimal external time source.

[0019] When the vehicle currently lacks external infrastructure support, a mobile terminal connected to the vehicle via short-range wireless communication is selected as the optimal external time source.

[0020] Preferably, the step of distributing the first global reference time to various domain controllers and sensor nodes within the vehicle via the in-vehicle network to achieve time synchronization of the entire vehicle includes:

[0021] The system periodically broadcasts synchronization frame messages containing the first global reference time to each domain controller, enabling each domain controller to issue time synchronization commands to its respective sensor nodes based on the time information in the synchronization frame messages, thereby achieving time synchronization of the entire vehicle.

[0022] Preferably, the step of distributing the first global reference time to various domain controllers and sensor nodes within the vehicle via the in-vehicle network to achieve time synchronization of the entire vehicle further includes:

[0023] The system receives time response frame messages sent back by each domain controller after receiving the synchronization frame message. The time response frame message is generated by the domain controller after recording the reception timestamp of the synchronization frame message, and the time response frame message contains the identification information and reception timestamp of the synchronization frame message received by the domain controller.

[0024] Based on the sending timestamp of the synchronization frame message and the receiving timestamp carried in the received time response frame message, calculate the network transmission delay and clock offset of the synchronization frame message to the domain controller.

[0025] Based on the network transmission delay and clock offset, corresponding clock correction parameters are generated and sent to the corresponding domain controllers, so that each domain controller can correct its local clock according to the clock correction parameters in the next transmission cycle and send a time synchronization command to its respective sensor node.

[0026] Preferably, the method further includes:

[0027] When the vehicle is detected to be in a dormant state, the optimal time reference is determined by the time signal of the vehicle's internal time source, a second global reference time is generated, and the second global reference time is distributed to the domain controllers and sensor nodes inside the vehicle through the vehicle network to achieve time synchronization of the whole vehicle.

[0028] Preferably, the method further includes:

[0029] When the central time synchronization controller detects that the difference between time signals from different external time sources exceeds a preset safety threshold, it triggers an arbitration mechanism; the arbitration mechanism performs the following operations:

[0030] Based on preset priority rules related to functional safety, the highest priority time signal is selected from conflicting time sources as the valid input;

[0031] If the conflict continues for more than the preset time, a diagnostic event will be generated and reported to the vehicle diagnostic system.

[0032] Preferably, the method further includes:

[0033] When satellite signal recovery is detected and its strength remains above a preset threshold, the optimal time reference is switched back to the time reference generated by the satellite signal source.

[0034] This application also provides a controller, including:

[0035] The time signal acquisition module is used to receive time signals from at least two different types of external time sources when it is detected that the vehicle has lost satellite signals, the satellite signal strength is lower than a preset threshold, or the vehicle is in a charging scenario; the external time sources do not include satellite signal sources.

[0036] The optimal time reference selection module is used to dynamically select an optimal external time source from the multiple external time sources according to a preset dynamic selection strategy, and directly determine the time signal of the optimal external time source as the optimal time reference.

[0037] The synchronization module is used to generate a first global reference time based on the optimal time reference, and distribute the first global reference time to the domain controllers and sensor nodes inside the vehicle through the vehicle network to achieve time synchronization of the whole vehicle.

[0038] This application also provides a vehicle including the aforementioned controller.

[0039] The beneficial effects of this invention are as follows:

[0040] By intelligently switching and selectively using multiple non-satellite external time sources as a reference in the event of satellite signal failure or specific scenarios, the core pain point of poor time synchronization reliability and sharp drop in accuracy caused by over-reliance on a single satellite signal in complex environments for intelligent vehicles is effectively solved. This provides a continuous, stable and reliable global time reference for high-level autonomous driving functions, fundamentally ensuring the temporal consistency and functional safety of key functions such as multi-sensor data fusion and decision control. Attached Figure Description

[0041] Figure 1This is a flowchart illustrating the multi-source collaborative vehicle time synchronization method in this application embodiment;

[0042] Figure 2 This is a block diagram illustrating the system architecture principle.

[0043] Figure 3 This is a flowchart of the layered time synchronization process;

[0044] Figure 4 This is a schematic diagram of the vehicle structure in an embodiment of this application. Detailed Implementation

[0045] Reference Figure 1 This application provides a multi-source collaborative vehicle time synchronization method, including:

[0046] S1, when it is detected that the vehicle has lost its satellite signal, or the satellite signal strength is lower than a preset threshold, or the vehicle is in a charging scenario, receive time signals from at least two different types of external time sources; the external time sources do not include satellite signal sources;

[0047] S2, based on a preset dynamic selection strategy, dynamically select an optimal external time source from the multiple external time sources, and directly determine the time signal of the optimal external time source as the optimal time reference;

[0048] S3. Based on the optimal time reference, a first global reference time is generated, and the first global reference time is distributed to the domain controllers and sensor nodes inside the vehicle through the vehicle network to achieve time synchronization of the whole vehicle.

[0049] In this embodiment, the method is implemented through coordinated control of the vehicle's central time synchronization controller (CTSC) and various domain controllers. The CTSC continuously monitors the status information and signal quality parameters output by the onboard Global Navigation Satellite System (GNSS) receiver module. Simultaneously, the vehicle gateway or the CTSC itself receives charging status signals from the Battery Management System (BMS) or charging control unit via an onboard network such as Controller Area Network (CAN) or Ethernet.

[0050] Regarding satellite signal status, the central time synchronization controller obtains parameters such as satellite lock status, signal-to-noise ratio, and number of visible satellites in real time by parsing standard NMEA messages or other status interfaces provided by the satellite signal receiver.

[0051] For charging scenarios, the central time synchronization controller confirms the connection by listening to specific messages on the vehicle network (such as charging connection confirmation messages issued by the BMS) or by directly receiving hard-wired signals from the charging communication controller (CCC).

[0052] When satellite signal loss is detected, or key signal quality parameters continue to deteriorate to an unreliable level (i.e., satellite signal strength is below a preset threshold), or when it is confirmed that the vehicle has entered the charging state, the satellite signal source is unreliable, the main time source is at risk of failure, and a more accurate signal source needs to be found from other signal sources.

[0053] Once the conditions for switching to other signal sources are met, the central time synchronization controller obtains time information from at least two preset external time sources through its integrated multiple vehicle communication interfaces.

[0054] Combination Figure 2 In the embodiments of this application, at least two different types of external time sources include at least two of the following: V2X roadside units, smart charging piles, and mobile terminals.

[0055] In this embodiment of the application, the domain controllers of the vehicle include, for example, Figure 3 The system includes domain controllers such as the powertrain domain controller, chassis domain controller, infotainment domain controller, and intelligent driving domain controller. Each domain controller has different sensor nodes. For example, the sensor nodes of the powertrain domain controller include electric drive and electronic control related sensor nodes, the sensor nodes of the chassis domain controller include steering and braking related sensor nodes, the sensor nodes of the infotainment domain controller include instrument and audio related sensor nodes, and the sensor nodes of the intelligent driving domain controller include radar and camera related sensor nodes.

[0056] The central time synchronization controller receives messages periodically broadcast by the V2X roadside unit via a dedicated C-V2X or DSRC communication module.

[0057] In charging scenarios, the central time synchronization controller communicates via a communication line (such as the CC line) inside the charging gun or via wireless communication (such as Wi-Fi / Bluetooth). During this time, the charging pile can send its system time (usually synchronized by the grid frequency or Network Time Protocol NTP) as time information to the vehicle.

[0058] The central time synchronization controller establishes point-to-point communication with paired vehicle owner mobile phones or other smart devices via short-range wireless connectivity technologies such as Bluetooth Low Energy (5.1BLE) or Wi-Fi Direct. The mobile terminal can provide the vehicle with time information obtained from cellular networks (such as 4G / 5G networks) or its own system.

[0059] When it is necessary to find a new time source from other signal sources, any time signals from the satellite signal receiver will be ignored, even if the satellite signal is briefly restored during the process. The central time synchronization controller only processes time information from the aforementioned non-satellite external sources.

[0060] In this embodiment of the application, step S2, which dynamically selects an optimal external time source from the plurality of external time sources according to a preset dynamic selection strategy, specifically includes:

[0061] When the vehicle is in a charging scenario, select a smart charging station as the optimal external time source;

[0062] When a vehicle is in a V2X coverage area, the V2X roadside unit is selected as the optimal external time source.

[0063] When the vehicle currently lacks external infrastructure support, a mobile terminal connected to the vehicle via short-range wireless communication is selected as the optimal external time source.

[0064] The central time synchronization controller performs rapid arbitration based on preset priority rules strongly tied to the vehicle's real-time scenario: in charging scenarios, it prioritizes the time signal provided by smart charging piles; within V2X coverage areas, it prioritizes the time signal broadcast by V2X roadside units; and when there is no external infrastructure support, it prioritizes the time signal from mobile terminals connected via short-range wireless communication. This dynamically and reliably selects the optimal external time source best suited to the current scenario from multiple external time sources. This strategy ensures that the system can automatically select the external time reference with the highest time-domain reliability and optimal security under different operating conditions, avoiding decision conflicts that may arise from multiple signal sources and significantly improving the adaptability and robustness of the time synchronization system in complex real-world environments.

[0065] In this embodiment of the application, step S3, which distributes the first global reference time to various domain controllers and sensor nodes inside the vehicle through the in-vehicle network to achieve time synchronization of the entire vehicle, includes:

[0066] The system periodically broadcasts synchronization frame messages containing the first global reference time to each domain controller, enabling each domain controller to issue time synchronization commands to its respective sensor nodes based on the time information in the synchronization frame messages, thereby achieving time synchronization of the entire vehicle.

[0067] The central time synchronization controller, acting as the vehicle's master clock, periodically broadcasts synchronization frames carrying the first global reference time via a highly deterministic in-vehicle network. Each domain controller, acting as a secondary node, immediately converts the time reference information contained in the message into a local synchronization command upon receiving it, and distributes it to its respective sensor node via the intra-domain bus. This establishes a hierarchical time synchronization system from the central controller to the domains and from the domains to the nodes. This distribution mechanism leverages the high performance of the in-vehicle network to achieve low-latency, high-precision, and reliable transmission of the global reference time to each distributed node. This ensures that all control units and sensors maintain strict time consistency even under complex electromagnetic and load environments, providing a reliable temporal coordination foundation for autonomous driving functions.

[0068] In this embodiment of the application, step S3, which distributes the first global reference time to various domain controllers and sensor nodes inside the vehicle through the in-vehicle network to achieve time synchronization of the entire vehicle, further includes:

[0069] The system receives time response frame messages sent back by each domain controller after receiving the synchronization frame message. The time response frame message is generated by the domain controller after recording the reception timestamp of the synchronization frame message, and the time response frame message contains the identification information and reception timestamp of the synchronization frame message received by the domain controller.

[0070] Based on the sending timestamp of the synchronization frame message and the receiving timestamp carried in the received time response frame message, calculate the network transmission delay and clock offset of the synchronization frame message to the domain controller.

[0071] Based on the network transmission delay and clock offset, corresponding clock correction parameters are generated and sent to the corresponding domain controllers, so that each domain controller can correct its local clock according to the clock correction parameters in the next transmission cycle and send a time synchronization command to its respective sensor node.

[0072] Specifically, the central time synchronization controller acts as the master clock, broadcasting synchronization frames (Sync frames, including CRC32 checksum and digital signature) via the vehicle Ethernet TSN at a fixed period of 100 milliseconds. Each domain controller, acting as a slave clock, automatically records the precise reception timestamp via its internal hardware timestamp unit upon receiving a Sync frame at the physical layer and immediately sends back a time response frame (Follow_Up frame). This frame contains the sequence number and reception timestamp of the received Sync frame. Based on its own recorded precise transmission timestamp of the Sync frame and the reception timestamp carried in the received Follow_Up frames, the central time synchronization controller calculates the network transmission delay and clock offset to each domain controller in real time using a bidirectional delay calculation model, and generates corresponding clock correction parameters. Through bidirectional message exchange with a 100-millisecond period and hardware-level timestamp processing, this mechanism can continuously monitor and compensate for network transmission delay and clock drift of each domain controller while ensuring reasonable network load, ensuring the long-term stability and microsecond-level synchronization accuracy of the global time base, fully meeting the real-time requirements of high-level autonomous driving systems for multi-sensor data fusion.

[0073] In this embodiment of the application, the method further includes:

[0074] S4, when the vehicle is detected to be in a dormant state, determines the optimal time reference based on the time signal of the vehicle's internal time source, generates a second global reference time, and distributes the second global reference time to the domain controllers and sensor nodes inside the vehicle through the vehicle network to achieve time synchronization of the whole vehicle.

[0075] When the vehicle enters sleep mode, the central time synchronization controller automatically switches to a low-power operating mode, ceasing all external time source acquisition and synchronization activities, and instead using its internal high-stability crystal oscillator (such as an OCXO) as the sole time source. At this time, a second global reference time is generated based on the internal clock signal to maintain basic timing functions, and time synchronization information is distributed to each domain controller and sensor node via the vehicle network at a reduced communication frequency. This mechanism, while ensuring the continuous operation of the vehicle's time system, minimizes the overall power consumption of the time synchronization system (e.g., below 10mW) by disabling external interfaces and high-power modules, meeting the energy consumption requirements of the vehicle's sleep state, while maintaining the time consistency of each basic control unit, providing a reliable time reference for rapid system recovery after the vehicle wakes up.

[0076] In this embodiment of the application, the method further includes:

[0077] S5, when the central time synchronization controller detects that the difference between time signals from different external time sources exceeds a preset safety threshold (e.g., 2ms), it triggers an arbitration mechanism; the arbitration mechanism performs the following operations:

[0078] Based on preset priority rules related to functional safety, the highest priority time signal is selected from conflicting time sources as the valid input;

[0079] If the conflict persists for more than a preset time, a diagnostic event will be generated and reported to the vehicle diagnostic system.

[0080] When the central time synchronization controller detects a time deviation between different external time sources exceeding a preset safety threshold, it immediately initiates an arbitration mechanism. First, based on preset functional safety priority rules (e.g., V2X time sources take precedence over mobile terminal time sources), the highest-priority valid time signal is selected as the system input. If the time conflict persists beyond a set time period, diagnostic event information containing the event type, conflict source identifier, and time deviation value is generated and reported to the vehicle diagnostic system via the onboard diagnostic interface. This arbitration mechanism ensures that the time system can make a definite and predictable response according to functional safety requirements when anomalies or conflicts occur at external time sources. This guarantees the continuous and stable operation of the time synchronization system and provides complete event traceability information for system maintenance and fault diagnosis, meeting ASIL-D level functional safety requirements.

[0081] In this embodiment of the application, the method further includes:

[0082] S6. When it is detected that the satellite signal has recovered and its strength is continuously higher than the preset threshold, the optimal time reference is switched back to the time reference generated by the satellite signal source.

[0083] When the detected satellite signal strength remains consistently above a preset threshold and reaches a stable state, the central time synchronization controller initiates a time base switching process. Specifically, a gradual adjustment strategy is employed, fine-tuning the internal clock frequency to progressively approximate the current optimal time base based on the external time source closer to the satellite signal time base. When the deviation between the two falls within an acceptable range, the primary time source is automatically switched to the satellite signal, and frequency fine-tuning continues for a period to ensure a smooth transition. This mechanism enables a smooth recovery of the primary time source from degraded mode to normal mode, avoiding system timing disruptions that may be caused by sudden changes in the time base, ensuring a continuous and stable time synchronization service for the autonomous driving function, and guaranteeing the time continuity of all control units and sensors.

[0084] This application also provides a controller, including:

[0085] The time signal acquisition module is used to receive time signals from at least two different types of external time sources when it is detected that the vehicle has lost satellite signals, or the satellite signal strength is lower than a preset threshold, or the vehicle is in a charging scenario; the external time sources do not include satellite signal sources.

[0086] The optimal time reference selection module is used to dynamically select an optimal external time source from the multiple external time sources according to a preset dynamic selection strategy, and directly determine the time signal of the source as the optimal time reference.

[0087] The synchronization module is used to generate a first global reference time based on the optimal time reference, and distribute the first global reference time to the domain controllers and sensor nodes inside the vehicle through the vehicle network to achieve time synchronization of the whole vehicle.

[0088] This controller is used to execute the execution logic of the aforementioned central time synchronization controller.

[0089] Figure 4 This is a block diagram illustrating a vehicle 200 according to an exemplary embodiment. For example, vehicle 200 may be a hybrid vehicle, a non-hybrid vehicle, an electric vehicle, a fuel cell vehicle, or other types of vehicle. Vehicle 200 may be an autonomous vehicle, a semi-autonomous vehicle, or a non-autonomous vehicle.

[0090] Reference Figure 4The vehicle 200 may include various subsystems, such as an infotainment system 210, a perception system 220, a decision control system 230, a drive system 240, and a computing platform 250. The vehicle 200 may also include more or fewer subsystems, and each subsystem may include multiple components. Furthermore, each subsystem and component of the vehicle 200 can be interconnected via wired or wireless means. In some embodiments, the infotainment system 210 may include a communication system, an entertainment system, and a navigation system, etc.

[0091] The perception system 220 may include several types of sensors for sensing information about the environment surrounding the vehicle 200. For example, the perception system 220 may include a global positioning system (which may be a GPS system, a BeiDou system, or another positioning system), an inertial measurement unit (IMU), lidar, millimeter-wave radar, ultrasonic radar, and a camera device.

[0092] The decision control system 230 may include a computing system, a vehicle controller, a steering system, a throttle, and a braking system. The drive system 240 may include components that provide power to the vehicle 200. In one embodiment, the drive system 240 may include an engine, an energy source, a transmission system, and wheels. The engine may be one or a combination of internal combustion engines, electric motors, and compressed air engines. The engine is capable of converting energy provided by the energy source into mechanical energy.

[0093] Some or all of the functions of vehicle 200 are controlled by computing platform 250. Computing platform 250 may include at least one processor 251 and memory 252, and processor 251 may execute instructions 253 stored in memory 252.

[0094] Processor 251 can be any conventional processor, such as a commercially available CPU. The processor may also include, for example, a Graphics Processing Unit (GPU), a Field Programmable Gate Array (FPGA), a System on Chip (SOC), an Application Specific Integrated Circuit (ASIC), or a combination thereof.

[0095] The memory 252 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0096] In addition to instruction 253, memory 252 can also store data, such as road maps, route information, vehicle position, direction, speed, and other data. The data stored in memory 252 can be used by computing platform 250.

[0097] In this embodiment of the disclosure, processor 251 may execute instruction 253 to complete all or part of the steps of the above-described multi-source collaborative vehicle time synchronization method.

[0098] Furthermore, the term “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as advantageous compared to other aspects or designs. Rather, the use of the term “exemplary” is intended to present the concept in a concrete manner. As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless otherwise specified or clear from the context, “X applies A or B” is intended to mean any of the natural inclusive arrangements. That is, “X applies A or B” satisfies any of the foregoing instances if X applies A; X applies B; or both X applies A and B. Additionally, unless otherwise specified or clear from the context to refer to the singular form, the articles “a” and “an” as used in this application and the appended claims are generally understood to mean “one or more.”

[0099] Similarly, although this disclosure has been shown and described with respect to one or more implementations, equivalent variations and modifications will occur to those skilled in the art upon reading and understanding the specification and drawings. This disclosure includes all such modifications and variations and is limited only by the scope of the claims. In particular, with respect to the various functions performed by the components described above (e.g., elements, resources, etc.), unless otherwise indicated, the terminology used to describe such components is intended to correspond to any component (functionally equivalent) that performs the specific function of the described component, even if structurally not equivalent to the disclosed structure. Furthermore, although specific features of this disclosure may have been disclosed with respect to only one of several implementations, such features may be combined with one or more other features of other implementations, as may be desired and advantageous to any given or particular application. Moreover, with regard to the terms “comprising,” “owning,” “having,” “having,” or variations thereof as used in the detailed description or claims, such terms are intended to be inclusive in a manner similar to the term “including.”

[0100] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0101] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

[0102] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0103] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0104] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of preferred embodiments of this disclosure includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as will be understood by those skilled in the art to which embodiments of this disclosure pertain.

[0105] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processing module, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (control method), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic device, and portable optical disc read-only memory (CDROM). In addition, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning paper or other media, followed by editing, interpreting or otherwise processing as necessary, and then stored in computer memory.

[0106] It should be understood that various parts of the embodiments of this disclosure can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0107] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0108] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into a single processing module, or each unit can exist physically separately, or two or more units can be integrated into a single module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The aforementioned storage medium can be a read-only memory, a hard disk, or an optical disk, etc.

[0109] Although embodiments of the present disclosure have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present disclosure. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present disclosure.

Claims

1. A multi-source collaborative vehicle time synchronization method, characterized in that, include: When it is detected that the vehicle has lost its satellite signal, the satellite signal strength is lower than a preset threshold, or the vehicle is in a charging scenario, time signals are received from at least two different types of external time sources; the external time sources do not include satellite signal sources. Based on a preset dynamic selection strategy, an optimal external time source is dynamically selected from the multiple external time sources, and the time signal of the optimal external time source is directly determined as the optimal time reference. Based on the optimal time reference, a first global reference time is generated and distributed to the domain controllers and sensor nodes inside the vehicle through the vehicle network to achieve time synchronization of the entire vehicle.

2. The method according to claim 1, characterized in that, At least two different types of external time sources include at least two of the following: V2X roadside units, smart charging piles, and mobile terminals.

3. The method according to claim 2, characterized in that, The steps for dynamically selecting an optimal external time source from the plurality of external time sources according to a preset dynamic selection strategy include: When the vehicle is in a charging scenario, select a smart charging station as the optimal external time source; When a vehicle is in a V2X coverage area, the V2X roadside unit is selected as the optimal external time source. When the vehicle currently lacks external infrastructure support, a mobile terminal connected to the vehicle via short-range wireless communication is selected as the optimal external time source.

4. The method according to claim 1, characterized in that, The steps for distributing the first global reference time to various domain controllers and sensor nodes within the vehicle via the in-vehicle network to achieve time synchronization for the entire vehicle include: The system periodically broadcasts synchronization frame messages containing the first global reference time to each domain controller, enabling each domain controller to issue time synchronization commands to its respective sensor nodes based on the time information in the synchronization frame messages, thereby achieving time synchronization of the entire vehicle.

5. The method according to claim 4, characterized in that, The steps of distributing the first global reference time to various domain controllers and sensor nodes within the vehicle via the in-vehicle network to achieve time synchronization for the entire vehicle also include: The system receives time response frame messages sent back by each domain controller after receiving the synchronization frame message. The time response frame message is generated by the domain controller after recording the reception timestamp of the synchronization frame message, and the time response frame message contains the identification information and reception timestamp of the synchronization frame message received by the domain controller. Based on the sending timestamp of the synchronization frame message and the receiving timestamp carried in the received time response frame message, calculate the network transmission delay and clock offset of the synchronization frame message to the domain controller. Based on the network transmission delay and clock offset, corresponding clock correction parameters are generated and sent to the corresponding domain controllers, so that each domain controller can correct its local clock according to the clock correction parameters in the next transmission cycle and send a time synchronization command to its respective sensor node.

6. The method according to claim 1, characterized in that, The method further includes: When the vehicle is detected to be in a dormant state, the optimal time reference is determined by the time signal of the vehicle's internal time source, a second global reference time is generated, and the second global reference time is distributed to the domain controllers and sensor nodes inside the vehicle through the vehicle network to achieve time synchronization of the whole vehicle.

7. The method according to claim 1, characterized in that, The method further includes: When the central time synchronization controller detects that the difference between time signals from different external time sources exceeds a preset safety threshold, it triggers an arbitration mechanism; the arbitration mechanism performs the following operations: Based on preset priority rules related to functional safety, the highest priority time signal is selected from conflicting time sources as the valid input; If the conflict continues for more than the preset time, a diagnostic event will be generated and reported to the vehicle diagnostic system.

8. The method according to claim 1, characterized in that, The method further includes: When satellite signal recovery is detected and its strength remains above a preset threshold, the optimal time reference is switched back to the time reference generated by the satellite signal source.

9. A controller, characterized in that, include: The time signal acquisition module is used to receive time signals from at least two different types of external time sources when it is detected that the vehicle has lost satellite signals, the satellite signal strength is lower than a preset threshold, or the vehicle is in a charging scenario; the external time sources do not include satellite signal sources. The optimal time reference selection module is used to dynamically select an optimal external time source from the multiple external time sources according to a preset dynamic selection strategy, and directly determine the time signal of the optimal external time source as the optimal time reference. The synchronization module is used to generate a first global reference time based on the optimal time reference, and distribute the first global reference time to the domain controllers and sensor nodes inside the vehicle through the vehicle network to achieve time synchronization of the whole vehicle.

10. A vehicle, characterized in that, Includes the controller as described in claim 9.

Images