Domain controller time synchronization method and device based on time division multiplexing

Abstract

This invention provides a time synchronization method and device for a domain controller based on time-division multiplexing. The invention includes a system-on-a-chip (SoC) and a microcontroller unit (MCU). The SoC acts as a slave node, performing high-precision time synchronization with the MCU within the domain and the vehicle-to-cloud (V2X) ECU outside the domain. The MCU and V2X ECU act as clock sources, acquiring UTC timestamps and local time. The V2X ECU and MCU each construct a gPTP time domain and output uninterrupted time data frames. The SoC receives time synchronization messages from both clock sources in a time-division manner, multiplexing its own PTP clock, thus achieving high-precision time synchronization of the SoC for the two clock sources and ensuring the SoC's high-precision time requirements for autonomous driving.

Description

Technical Field

[0001] This invention relates to a time synchronization method and device for a domain controller based on time division multiplexing. Background Technology

[0002] With the rapid development of autonomous driving technology, automotive electronic and electrical architecture has evolved from traditional distributed Electronic Control Units (ECUs) to centralized central controllers or domain controllers. Autonomous driving domain controllers can perform tasks such as perception, localization, and planning for assisted or autonomous driving, and interact with the vehicle control domain to achieve real-time control of the autonomous vehicle. This often requires the autonomous driving domain controller system-on-a-chip (SoC) to provide sufficient computing power. The microcontroller unit (MCU) is responsible for the system control of the domain controller and communicates with the vehicle control domain via a fieldbus to complete vehicle control.

[0003] To achieve real-time vehicle control via the vehicle control domain, the system-on-a-chip (SoC) of the domain controller must achieve high-precision time synchronization with the microcontroller unit (MCU). All communication delays between the SoC and the MCU need to be controlled within the microsecond level. Simultaneously, with the iterative upgrades of autonomous driving functions, the demand for Over-the-Air (OTA) upgrades and high-precision navigation in autonomous vehicles is increasing. The SoC needs to simultaneously ensure high-precision time synchronization with the Coordinated Universal Time (UTC) provided by the GNSS signals received by the vehicle-to-cloud ECU. Current high-precision time synchronization for in-vehicle ECUs is generally based on the General Precise Time Protocol (gPTP). gPTP time synchronization involves sending synchronization data frames between master and slave nodes, recording the transmission and reception times of the data frames. Slave nodes obtain time information and calculate the time deviation between their local clocks and the master clock, as well as the node transmission delay. Based on this, they correct their local clocks to ensure that the slave and master nodes maintain the same frequency and phase.

[0004] The gPTP protocol relies on a peer-to-peer (P2P) latency strategy for latency measurement, and only one master clock can exist in the time domain. Furthermore, a system-on-a-chip (SoC) typically only has one PTP clock available for synchronization. Therefore, existing solutions struggle to address the challenge of SoCs needing to synchronize with two or more clock sources. Summary of the Invention

[0005] To address the problems existing in the prior art, the present invention provides a method and device for time synchronization of domain controllers based on time division multiplexing.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] This invention provides a time synchronization method for domain controllers based on time-division multiplexing, comprising:

[0008] The vehicle cloud ECU obtains its local UTC time; the microcontroller unit (MCU) obtains its local MCU time.

[0009] The vehicle cloud ECU and microcontroller MCU respectively construct gPTP time domains to select the vehicle cloud ECU and microcontroller MCU as master nodes respectively; the vehicle cloud ECU and microcontroller MCU respectively output uninterrupted time data frames, the time data frames include UTC time and MCU local time;

[0010] The system-on-a-chip (SOC) receives synchronization messages from the vehicle cloud ECU clock source and MCU clock source in a time-division manner, and uses the slave node to complete high-precision time synchronization, synchronizing the UTC time and the MCU local time to the SOC system clock respectively.

[0011] Furthermore, in the above method, the system-on-a-chip (SOC) receives synchronization messages from the vehicle cloud ECU clock source and the MCU clock source in a time-division multiplexing manner, and performs high-precision time synchronization by multiplexing the slave node, synchronizing the UTC time and the MCU local time to the SOC system clock respectively, including:

[0012] The system-on-a-chip (SoC) sends a PDelay_Req message to the vehicle cloud ECU for peer-to-peer delay measurement. When the PDelay_Req message leaves the device's physical layer, the SoC uses its local clock to obtain the timestamp T11.

[0013] When the PDelay_Req message arrives at the physical layer of the vehicle cloud ECU, the vehicle cloud ECU clock source obtains the timestamp T12 using the local clock; the vehicle cloud ECU clock source generates a PDelay_Resp message and sends it to the system-on-a-chip (SOC); the vehicle cloud ECU clock source records the message sending timestamp T13.

[0014] After receiving the PDelay_Resp message, the system-on-a-chip (SOC) records the message arrival timestamp T14.

[0015] The vehicle cloud ECU clock source sends a PDelay_Resp_Follow_Up message to the system-on-a-chip (SOC), and the message carries a timestamp T13.

[0016] Based on the received T11, T12, T13, and T14, the System-on-a-Chip (SOC) calculates the transmission delay Delay1 and clock offset Offset1 between the SOC and the vehicle-to-cloud ECU. The SOC then obtains an accurate UTC timestamp based on the calculated transmission delay Delay1 and clock offset Offset1, thus completing time synchronization.

[0017] Furthermore, in the above method, after the system-on-a-chip (SoC) obtains the accurate UTC timestamp based on the calculated transmission delay Delay1 and clock offset Offset1, and completes time synchronization, it also includes:

[0018] The system-on-a-chip (SoC) sends a PDelay_Req message to the microcontroller unit (MCU) for peer-to-peer delay measurement. The domain number field in the PDelay_Req message identifies the MCU clock source. When the message leaves the device physical layer, the SoC obtains the current timestamp T21 based on the local clock.

[0019] When the PDelay_Req message arrives at the microcontroller unit (MCU), the MCU obtains the timestamp T22 using its local clock; the MCU clock source generates a PDelay_Resp message and sends it to the system-on-a-chip (SOC); the MCU records the message sending timestamp T23.

[0020] After receiving the PDelay_Resp message, the system-on-a-chip (SOC) records the message arrival timestamp T24.

[0021] The microcontroller unit (MCU) sends a PDelay_Resp_Follow_Up message to the system-on-a-chip (SOC), and the PDelay_Resp_Follow_Up message is saved with timestamp T23.

[0022] Based on the received T21, T22, T23, and T24, the System-on-a-Chip (SOC) calculates the transmission delay Delay2 and clock offset Offset2 between the SOC and the MCU. The SOC then uses the calculated transmission delay Delay2 and clock offset Offset1 to obtain the accurate MCU timestamp, thus completing time synchronization.

[0023] Furthermore, in the above method, the PDelay_Req message includes: Header 3 and originTimestamp 2, wherein the Header 3 carries a time domain Number field, which is used to identify the vehicle cloud ECU clock source; the originTimestamp 2 represents the source timestamp, which is used to characterize the system-on-a-chip (SOC) estimate of the PDelay_Req message transmission time.

[0024] Furthermore, in the above method, the PDelay_Resp message includes a header 4 and a requestReceipt Timestamp 1 field, wherein the request Receipt Timestamp 1 represents the request receiving timestamp, and the receiving timestamp is the timestamp T12;

[0025] The PDelay_Resp_Follow_Up message includes: Header 5 and response OriginTimestamp 2, the response OriginTimestamp 2 field carrying the timestamp T13.

[0026] Furthermore, in the above method, the transmission delay Delay1 is calculated as follows:

[0027] ,

[0028] The clock offset Offset1 is calculated as follows:

[0029] .

[0030] Furthermore, in the above method, the transmission delay Delay2 is calculated as follows:

[0031] ,

[0032] The clock offset Offset2 is calculated as follows:

[0033] .

[0034] Furthermore, in the above method, the time data frame is: Sync messages and Follow_Up messages sent sequentially by the vehicle cloud ECU and the microcontroller unit MCU, respectively, using the clock information obtained as clock sources.

[0035] The Sync message consists of a first header (Header 1) and an origin Timestamp 1 field. The first header (Header 1) carries a domain number field, where 0 and 1 are used to identify the vehicle-to-cloud ECU clock source or the MCU clock source, respectively. The origin Timestamp 1 field represents the estimated time of the Sync message transmission by the clock source.

[0036] The Follow_Up message consists of a second header (Header 2) and a precise Origin Timestamp field. The second header (Header 2) carries a domain number field, where 0 and 1 are used to identify the vehicle-to-cloud ECU clock source or the MCU clock source, respectively. The precise Origin Timestamp represents the precise time source tag and is used to store the Sync message transmission time (t). m11 .

[0037] According to another aspect of the present invention, a computing-based device is also provided, comprising:

[0038] Processor; and

[0039] A memory configured to store computer-executable instructions, which, when executed, cause the processor to:

[0040] The vehicle cloud ECU obtains its local UTC time; the microcontroller unit (MCU) obtains its local MCU time.

[0041] The vehicle cloud ECU and microcontroller MCU respectively construct gPTP time domains to select the vehicle cloud ECU and microcontroller MCU as master nodes respectively; the vehicle cloud ECU and microcontroller MCU respectively output uninterrupted time data frames, the time data frames include UTC time and MCU local time;

[0042] The system-on-a-chip (SOC) receives synchronization messages from the vehicle cloud ECU clock source and MCU clock source in a time-division manner, and uses the slave node to complete high-precision time synchronization, synchronizing the UTC time and the MCU local time to the SOC system clock respectively.

[0043] According to another aspect of the present invention, a computer-readable storage medium is also provided, having stored thereon computer-executable instructions, wherein when executed by a processor, the computer-executable instructions cause the processor to:

[0044] The vehicle cloud ECU obtains its local UTC time; the microcontroller unit (MCU) obtains its local MCU time.

[0045] The vehicle cloud ECU and microcontroller MCU respectively construct gPTP time domains to select the vehicle cloud ECU and microcontroller MCU as master nodes respectively; the vehicle cloud ECU and microcontroller MCU respectively output uninterrupted time data frames, the time data frames include UTC time and MCU local time;

[0046] The system-on-a-chip (SOC) receives synchronization messages from the vehicle cloud ECU clock source and MCU clock source in a time-division manner, and uses the slave node to complete high-precision time synchronization, synchronizing the UTC time and the MCU local time to the SOC system clock respectively.

[0047] In summary, this invention includes a system-on-a-chip (SoC) and a microcontroller unit (MCU). The SoC acts as a slave node, performing high-precision time synchronization with the MCU within the domain and the vehicle-to-cloud ECU outside the domain. The MCU and MCU act as clock sources, acquiring UTC timestamps and local time. The MCU and MCU each construct a gPTP time domain and output uninterrupted time data frames. The SoC receives time synchronization messages from both clock sources in a time-division manner, multiplexing its own PTP clock, thus achieving high-precision time synchronization between the SoC and the two clock sources, ensuring the SoC's high-precision time requirements for autonomous driving.

[0048] This invention addresses the shortcomings of the traditional gPTP time synchronization protocol, which can only synchronize with a single clock source. By introducing a dual-master-slave time domain synchronization architecture and using a time-division multiplexed system-on-a-chip (SoC) slave node message receiving module, it achieves high-precision time synchronization between two clock sources for the SoC, effectively meeting the high-precision time synchronization requirements of autonomous driving domain controllers for completing autonomous driving tasks.

[0049] This invention addresses the need for System-on-a-Chip (SoC) to synchronize with multiple clock sources. It designs a time synchronization architecture for a single slave node in a multi-master node configuration. By introducing time-division multiplexing, the PTP clock carried by the SoC is reused. Different clock sources are isolated using domain numbers. By configuring the domain messages received by the SoC at different times, high-precision time synchronization between two clock sources is achieved, ensuring the SoC meets the high-precision time requirements of autonomous driving. Attached Figure Description

[0050] Figure 1 This is a schematic diagram of the domain controller time synchronization architecture of a domain controller time synchronization method based on time division multiplexing according to an embodiment of the present invention;

[0051] Figure 2 This is a flowchart of a domain controller time synchronization method based on time division multiplexing according to an embodiment of the present invention;

[0052] Figure 3 This is a schematic diagram of the interaction of time synchronization messages between domain controllers according to an embodiment of the present invention. Detailed Implementation

[0053] The present invention will now be described in further detail with reference to the accompanying drawings.

[0054] In a typical configuration of this application, the terminal, the device of the service network, and the trusted party all include one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0055] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0056] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0057] Traditional domain controller time synchronization schemes can only support high-precision time synchronization from a single clock source using a system-on-a-chip (SoC). This application provides a time-division multiplexing-based domain controller time synchronization method to achieve high-precision time synchronization between two clock sources within the domain controller.

[0058] Please refer to Figure 1 , Figure 1 This application proposes a time-division multiplexing-based domain controller time synchronization architecture, which can be applied to various autonomous driving devices, including but not limited to driverless cars, drones, unmanned ships, and wheeled robots. Figure 2 A flowchart of a domain controller time synchronization method based on time division multiplexing provided in this application embodiment, the method specifically includes the following steps S1 to S3:

[0059] Step S1: The vehicle cloud ECU module obtains the local UTC time; the microcontroller unit (MCU) obtains the local MCU time.

[0060] Here, the vehicle cloud ECU module receives GPS messages published by the satellite positioning system based on the satellite positioning module, and receives Coordinated Universal Time (UTC) as the local time.

[0061] Optionally, the satellite positioning system (GNSS) includes navigation satellite systems such as GPS, BDS, GLONASS, and GALILEO, which can provide users with high-precision position and time information on the Earth's surface or in near-Earth space. The GPS messages include, but are not limited to, positioning messages such as GPGGA and GPRMC.

[0062] Optionally, the Coordinated Universal Time (UTC local time) is obtained by the satellite positioning module from the atomic time obtained from the GPS message and converted based on leap second information.

[0063] Optionally, the local time obtained by the microcontroller unit (MCU) is based on the clock control unit (CCU). The clock control unit records the cumulative time after the MCU starts up and automatically resets after power failure.

[0064] Step S2: The vehicle cloud ECU and the microcontroller unit (MCU) respectively construct gPTP time domains to select the vehicle cloud ECU and the microcontroller unit (MCU) as master nodes respectively; the vehicle cloud ECU and the microcontroller unit (MCU) respectively output uninterrupted time data frames, the time data frames including UTC time and MCU local time.

[0065] Specifically, gPTP stands for Generalized Precision Time Protocol, a derivative and refinement of the PTP protocol, employing a peer-to-peer latency strategy. Generally, the gPTP protocol uses the Optimal Master Clock Algorithm (BMCA) to select the master node in the time domain.

[0066] In this embodiment of the application, the vehicle cloud ECU and the microcontroller unit (MCU) are selected as the master nodes, respectively.

[0067] In this embodiment, the time data frame is a Sync message and a Follow_Up message sent sequentially by the vehicle cloud ECU and the microcontroller unit MCU, respectively, using the clock information obtained by the ECU and MCU as clock sources. Each message carries a UTC timestamp and a relative timestamp.

[0068] Preferably, the Sync message consists of a first header (Header 1) and an origin Timestamp 1 field. The first header (Header 1) carries a domain number field, where 0 and 1 are used to identify the vehicle-to-cloud ECU clock source or the MCU clock source, respectively. The origin Timestamp 1 field represents the estimated time of the Sync message transmission by the clock source.

[0069] In this embodiment, the Follow_Up message consists of a second header (Header 2) and a precise OriginTimestamp field. The second header (Header 2) carries a domain number field, where 0 and 1 are used to identify the vehicle-to-cloud ECU clock source or the MCU clock source, respectively. The precise Origin Timestamp represents the precise time source tag and is used to store the Sync message transmission time (t). m11 .

[0070] In step S3, the system-on-a-chip (SOC) receives synchronization messages from the vehicle cloud ECU clock source and MCU clock source in a time-division manner, and uses the slave node to complete high-precision time synchronization, synchronizing the UTC time and the MCU local time to the SOC system clock respectively.

[0071] Specifically, the system-on-a-chip (SOC) includes a PTP hardware clock / dev / ptp0, which can be used to achieve high-precision gPTP time synchronization.

[0072] like Figure 3 As shown, step S3 further includes steps S3.1 to S3.10, the specific steps of which are as follows:

[0073] Step S3.1: The system-on-a-chip (SOC) sends a PDelay_Req message to the vehicle cloud ECU for peer-to-peer delay measurement. When the PDelay_Req message leaves the device physical layer, the SOC uses its local clock to obtain the timestamp T11.

[0074] In this embodiment of the application, the PDelay_Req message consists of a header 3, an origin timestamp 2, and a reserved field. The header 3 carries a domain number field to identify the clock source of the vehicle cloud ECU. The origin timestamp 2 represents the source timestamp and is used to characterize the system-on-a-chip (SOC) estimate of the PDelay_Req message transmission time.

[0075] Step S3.2: When the PDelay_Req message arrives at the physical layer of the vehicle cloud ECU, the vehicle cloud ECU clock source obtains the timestamp T12 using the local clock; the vehicle cloud ECU clock source generates a PDelay_Resp message and sends it to the system-on-a-chip (SOC); the vehicle cloud ECU clock source records the message sending timestamp T13.

[0076] In this embodiment of the application, the PDelay_Resp message consists of a header 4, a request ReceiptTimestamp 1, and a requesting Port Identity 1 field, wherein the request ReceiptTimestamp 1 represents the request receiving timestamp, and the receiving timestamp is the timestamp T12.

[0077] Step S3.3: After receiving the Pdelay_Resp message, the system-on-a-chip (SOC) records the message arrival timestamp T14.

[0078] In step S3.4, the vehicle cloud ECU clock source sends a PDelay_Resp_Follow_Up message to the system-on-a-chip (SOC), and the message carries a timestamp T13.

[0079] In this embodiment, the PDelay_Resp_Follow_Up message consists of a header (Header 5), a responseOriginTimestamp 2 field, and a requesting Port Identity 2 field. The responseOriginTimestamp 2 field carries the timestamp T13.

[0080] In step S3.5, the system-on-a-chip (SOC) calculates the transmission delay Delay1 and clock offset Offset1 between the SOC and the vehicle cloud ECU based on the received T11, T12, T13, and T14. The SOC then obtains the accurate UTC timestamp based on the calculated transmission delay Delay1 and clock offset Offset1, thus completing time synchronization.

[0081] The transmission delay Delay1 is calculated as follows:

[0082] ,

[0083] The clock offset Offset1 is calculated as follows:

[0084] .

[0085] Step S3.6: The system-on-a-chip (SOC) sends a PDelay_Req message to the microcontroller unit (MCU) for peer-to-peer delay measurement. The domain number field in the PDelay_Req message identifies the MCU clock source. When the message leaves the device physical layer, the SOC obtains the current timestamp T21 based on the local clock.

[0086] Step S3.7: When the PDelay_Req message arrives at the microcontroller unit (MCU), the MCU obtains the timestamp T22 using its local clock; the MCU clock source generates a PDelay_Resp message and sends it to the system-on-a-chip (SOC); the MCU records the message sending timestamp T23.

[0087] In step S3.8, after the system-on-a-chip (SOC) receives the PDelay_Resp message, it records the message arrival timestamp T24.

[0088] Step S3.9: The microcontroller unit (MCU) sends a PDelay_Resp_Follow_Up message to the system-on-a-chip (SOC), and the PDelay_Resp_Follow_Up message is saved with timestamp T23.

[0089] In step S3.10, the system-on-a-chip (SOC) calculates the transmission delay Delay2 and clock offset Offset2 between the SOC and the MCU based on the received T21, T22, T23, and T24. The SOC then obtains the accurate MCU timestamp based on the calculated transmission delay Delay2 and clock offset Offset2, thus completing time synchronization.

[0090] The transmission delay Delay2 is calculated as follows:

[0091] ,

[0092] The clock offset Offset2 is calculated as follows:

[0093] .

[0094] In summary, this invention includes a system-on-a-chip (SoC) and a microcontroller unit (MCU). The SoC acts as a slave node, performing high-precision time synchronization with the MCU within the domain and the vehicle-to-cloud ECU outside the domain. The MCU and MCU act as clock sources, acquiring UTC timestamps and local time. The MCU and MCU each construct a gPTP time domain and output uninterrupted time data frames. The SoC receives time synchronization messages from both clock sources in a time-division manner, multiplexing its own PTP clock, thus achieving high-precision time synchronization between the SoC and the two clock sources, ensuring the SoC's high-precision time requirements for autonomous driving.

[0095] This invention addresses the shortcomings of the traditional gPTP time synchronization protocol, which can only synchronize with a single clock source. By introducing a dual-master-slave time domain synchronization architecture and using a time-division multiplexed system-on-a-chip (SoC) slave node message receiving module, it achieves high-precision time synchronization between two clock sources for the SoC, effectively meeting the high-precision time synchronization requirements of autonomous driving domain controllers for completing autonomous driving tasks.

[0096] This invention addresses the need for System-on-a-Chip (SoC) to synchronize with multiple clock sources. It designs a time synchronization architecture for a single slave node in a multi-master node configuration. By introducing time-division multiplexing, the PTP clock carried by the SoC is reused. Different clock sources are isolated using domain numbers. By configuring the domain messages received by the SoC at different times, high-precision time synchronization between two clock sources is achieved, ensuring the SoC meets the high-precision time requirements of autonomous driving.

[0097] The method of the present invention can be integrated into a specific control device.

[0098] The control device of the present invention can be a computer program product, wherein when the computer program product is run on a computer, the computer performs some or all of the steps of the methods in the above method embodiments.

[0099] The control device of the present invention can be an application publishing platform, wherein the application publishing platform is used to publish computer program products, wherein when the computer program products are run on a computer, the computer performs some or all of the steps of the methods in the above method embodiments.

[0100] In various embodiments of the present invention, it should be understood that the sequence number of each process does not necessarily imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0101] When the various systems and units of this invention are implemented as software functional units, they can be stored in a computer-accessible memory. Based on this understanding, part or all of the technical solutions of this invention can be embodied in the form of a software product. This computer software product is stored in a memory and includes several requests to cause one or more computer devices (such as personal computers, servers, or network devices, specifically processors in computer devices) to execute part or all of the steps of the methods described in the various embodiments of this invention.

[0102] Those skilled in the art will understand that all or part of the steps of the various embodiments listed in this invention can be implemented by a computer program instructing related hardware. These computer programs can be stored centrally or distributedly in one or more computer devices, such as in a readable storage medium. The aforementioned computer devices include read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, magnetic disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0103] Those skilled in the art should recognize that the above embodiments are merely illustrative of the present invention and are not intended to limit the present invention. Any variations or modifications to the above embodiments that are within the spirit and essence of the present invention will fall within the scope of the claims of the present invention.

[0104] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

[0105] It should be noted that the present invention can be implemented in software and / or a combination of software and hardware, for example, using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In one embodiment, the software program of the present invention can be executed by a processor to implement the steps or functions described above. Similarly, the software program of the present invention (including associated data structures) can be stored in a computer-readable recording medium, such as RAM memory, a magnetic or optical drive, a floppy disk, or similar devices. Furthermore, some steps or functions of the present invention can be implemented in hardware, for example, as circuitry that works with a processor to perform the various steps or functions.

[0106] Furthermore, a portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. The program instructions invoking the methods of the invention may be stored in a fixed or removable recording medium, and / or transmitted via a data stream in a broadcast or other signal-carrying medium, and / or stored in the working memory of a computer device operating according to the program instructions. Here, an embodiment of the invention includes an apparatus comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein, when the computer program instructions are executed by the processor, the apparatus is triggered to operate the methods and / or technical solutions based on the foregoing embodiments of the invention.

[0107] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the invention. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in the apparatus claims may also be implemented by a single unit or device in software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any particular order.

Claims

1. A method and device for time synchronization of a domain controller based on time-division multiplexing, characterized in that, include: CarCloud ECU obtains local UTC time; The microcontroller unit (MCU) obtains its local time. The vehicle cloud ECU and microcontroller MCU respectively construct gPTP time domains to select the vehicle cloud ECU and microcontroller MCU as master nodes respectively; the vehicle cloud ECU and microcontroller MCU respectively output uninterrupted time data frames, the time data frames include UTC time and MCU local time; The system-on-a-chip (SOC) acts as a time-division multiplexing slave node to receive synchronization messages from the vehicle cloud ECU clock source and MCU clock source. It uses domain numbers to isolate different clock sources. By configuring the domain messages received by the SOC at different times, the slave node can achieve high-precision time synchronization, synchronizing the UTC time and the MCU local time to the SOC system clock respectively.

2. The domain controller time synchronization method and device based on time-division multiplexing as described in claim 1, characterized in that, The System-on-Chip (SOC) acts as a time-division multiplexing slave node, receiving synchronization messages from the vehicle cloud ECU clock source and MCU clock source. It uses domain numbers to isolate different clock sources. By configuring the domain messages received by the SOC at different times, the slave node achieves high-precision time synchronization, synchronizing both UTC time and MCU local time to the SOC system clock, including: The system-on-a-chip (SoC) sends a PDelay_Req message to the vehicle cloud ECU for peer-to-peer delay measurement. When the PDelay_Req message leaves the device's physical layer, the SoC uses its local clock to obtain the timestamp T11. When the PDelay_Req message arrives at the physical layer of the vehicle cloud ECU, the vehicle cloud ECU clock source obtains the timestamp T12 using the local clock; the vehicle cloud ECU clock source generates a PDelay_Resp message and sends it to the system-on-a-chip (SOC); the vehicle cloud ECU clock source records the message sending timestamp T13. After receiving the PDelay_Resp message, the system-on-a-chip (SOC) records the message arrival timestamp T14. The vehicle cloud ECU clock source sends a PDelay_Resp_Follow_Up message to the system-on-a-chip (SOC), and the message carries a timestamp T13. Based on the received T11, T12, T13, and T14, the System-on-a-Chip (SOC) calculates the transmission delay Delay1 and clock offset Offset1 between the SOC and the vehicle-to-cloud ECU. The SOC then obtains an accurate UTC timestamp based on the calculated transmission delay Delay1 and clock offset Offset1, thus completing time synchronization.

3. The domain controller time synchronization method and device based on time-division multiplexing as described in claim 2, characterized in that, The transmission delay Delay1 is calculated as follows: ， The clock offset Offset1 is calculated as follows: 。 4. The domain controller time synchronization method and device based on time-division multiplexing as described in claim 2, characterized in that, The system-on-a-chip (SoC) obtains an accurate UTC timestamp based on the calculated transmission delay Delay1 and clock offset Offset1. After completing time synchronization, it also includes: The system-on-a-chip (SoC) sends a PDelay_Req message to the microcontroller unit (MCU) for peer-to-peer delay measurement. The domain number field in the PDelay_Req message identifies the MCU clock source. When the message leaves the device physical layer, the SoC obtains the current timestamp T21 based on the local clock. When the PDelay_Req message arrives at the microcontroller unit (MCU), the MCU obtains the timestamp T22 using its local clock; the MCU clock source generates a PDelay_Resp message and sends it to the system-on-a-chip (SOC); the MCU records the message sending timestamp T23. After receiving the PDelay_Resp message, the system-on-a-chip (SOC) records the message arrival timestamp T24. The microcontroller unit (MCU) sends a PDelay_Resp_Follow_Up message to the system-on-a-chip (SOC), and the PDelay_Resp_Follow_Up message is saved with timestamp T23. Based on the received T21, T22, T23, and T24, the System-on-a-Chip (SOC) calculates the transmission delay Delay2 and clock offset Offset2 between the SOC and the Microcontroller Unit (MCU). The SOC then obtains the accurate MCU timestamp based on the calculated transmission delay Delay2 and clock offset Offset2, thus completing time synchronization.

5. The domain controller time synchronization method and device based on time-division multiplexing as described in claim 4, characterized in that, The transmission delay Delay2 is calculated as follows: ， The clock offset Offset2 is calculated as follows: 。 6. The domain controller time synchronization method and device based on time-division multiplexing as described in claim 2, characterized in that, The PDelay_Req message includes a header 3 and an origin timestamp 2. The header 3 carries a domain number field to identify the clock source of the vehicle cloud ECU. The origin timestamp 2 represents the source timestamp and is used to characterize the system-on-a-chip (SOC)'s estimate of the PDelay_Req message transmission time.

7. The domain controller time synchronization method and device based on time-division multiplexing as described in claim 2, characterized in that, The PDelay_Resp message includes: Header 4 and request Receipt Timestamp 1 field, wherein the request Receipt Timestamp 1 represents the request receiving timestamp, and the receiving timestamp is the timestamp T12; The PDelay_Resp_Follow_Up message includes: Header 5 and responseOrigin Timestamp 2, the responseOrigin Timestamp 2 field carrying the timestamp T13.

8. The domain controller time synchronization method and device based on time-division multiplexing as described in claim 1, characterized in that, The time data frame consists of Sync and Follow_Up messages sent sequentially by the vehicle cloud ECU and the microcontroller unit MCU, respectively, using the clock information obtained as clock sources. The Sync message includes a first header Header 1 and an origin Timestamp 1 field. The first header Header 1 carries a time field domain Number field, in which 0 and 1 are used to identify the vehicle cloud ECU clock source or MCU clock source, respectively. The origin Timestamp 1 field represents the estimated time of the Sync message transmission by the clock source. The Follow_Up packet includes: a second header Header 2 and a precise Origin Timestamp field, wherein the second header Header 2 field carries a time domain domain Number field, and 0 and 1 in the domain Number field are used to identify a vehicle cloud ECU clock source or an MCU clock source, and the precise Origin Timestamp represents an accurate time source label, used to save the sending time t of the Sync packet m11 .

9. A computing-based device, wherein, include: processor; as well as A memory configured to store computer-executable instructions, which, when executed, cause the processor to: CarCloud ECU obtains local UTC time; The microcontroller unit (MCU) obtains its local time. The vehicle cloud ECU and microcontroller MCU respectively construct gPTP time domains to select the vehicle cloud ECU and microcontroller MCU as master nodes respectively; the vehicle cloud ECU and microcontroller MCU respectively output uninterrupted time data frames, the time data frames include UTC time and MCU local time; The system-on-a-chip (SOC) acts as a time-division multiplexing slave node to receive synchronization messages from the vehicle cloud ECU clock source and MCU clock source. It uses domain numbers to isolate different clock sources. By configuring the domain messages received by the SOC at different times, the slave node can achieve high-precision time synchronization, synchronizing the UTC time and the MCU local time to the SOC system clock respectively.

10. A computer-readable storage medium having stored thereon computer-executable instructions, wherein, When the computer-executable instruction is executed by the processor, it causes the processor to: The vehicle cloud ECU obtains its local UTC time; the microcontroller unit (MCU) obtains its local MCU time. The vehicle cloud ECU and microcontroller MCU respectively construct gPTP time domains to select the vehicle cloud ECU and microcontroller MCU as master nodes respectively; the vehicle cloud ECU and microcontroller MCU respectively output uninterrupted time data frames, the time data frames include UTC time and MCU local time; The system-on-a-chip (SOC) acts as a time-division multiplexing slave node to receive synchronization messages from the vehicle cloud ECU clock source and MCU clock source. It uses domain numbers to isolate different clock sources. By configuring the domain messages received by the SOC at different times, the slave node can achieve high-precision time synchronization, synchronizing the UTC time and the MCU local time to the SOC system clock respectively.

Images