A multi-domain time synchronization system based on AUTOSAR AP, media and vehicle

Abstract

This application provides a multi-domain time synchronization system, medium, and vehicle based on AUTOSAR AP, relating to the field of automotive electronic and electrical architecture technology. The system achieves remote dynamic configuration and real-time distribution of timing topology through an integrated cloud configuration module. The central computing unit integrates the AUTOSAR AP and CP platform, dynamically constructs a timing tree using the timing management module, and distributes high-precision synchronization signals to different domain controllers as the master clock node. Utilizing a shared memory region with fixed physical addresses and an inter-core interrupt mechanism, it achieves low-latency, high-consistency global time transfer between the AP and CP. Simultaneously, a three-level safety monitoring module covering the hardware, protocol, and application layers monitors and provides feedback on the entire synchronization process, effectively supporting vehicle functional safety mechanisms. The system supports multi-domain collaboration under heterogeneous in-vehicle networks, improving the flexibility, accuracy, and reliability of time synchronization, and meeting the stringent requirements of high-level autonomous driving for cross-domain timing consistency.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic and electrical architecture technology, and more particularly to a multi-domain time synchronization system, medium, and vehicle based on AUTOSAR AP. Background Technology

[0002] In autonomous vehicles, achieving cross-system time coordination among controllers in multiple domains, such as the intelligent driving domain and the cockpit domain, is fundamental to ensuring high-precision synchronous operation of key functions such as perception, decision-making, execution, and human-machine interaction under a unified time reference. This is crucial for guaranteeing system safety, reliability, and overall performance. Although existing technologies employ time synchronization schemes such as GPTP, significant drawbacks remain: First, they rely on static clock configurations, with master / slave roles and synchronization cycles preset in the firmware, making dynamic adjustments at runtime impossible. This necessitates software rewriting when the master clock fails or network topology changes. Second, cross-operating system time transfer is typically achieved through Socket communication, introducing Ethernet switching latency, protocol parsing overhead, and operating system scheduling latency, resulting in large cumulative delay errors that fail to meet high-precision coordination requirements. Third, there is a lack of effective safety monitoring mechanisms. Existing synchronization modules do not provide real-time synchronization status feedback interfaces and cannot automatically trigger degradation strategies when GNSS signals are lost or synchronization anomalies occur, making it difficult to meet ASIL-D level functional safety requirements. Summary of the Invention

[0003] This invention aims to solve the technical problems existing in the above-mentioned related technologies, and proposes a multi-domain time synchronization system, medium and vehicle based on AUTOSAR AP, which can realize dynamic online configuration of clock parameters, sub-microsecond time synchronization across operating systems and multi-level real-time security monitoring, thereby improving the system's time synchronization accuracy, operational reliability and functional safety.

[0004] The solution to the technical problem of this invention is: This invention provides a multi-domain time synchronization system based on AUTOSAR AP, including a central computing unit, a cloud configuration module, and a multi-domain controller group; The cloud configuration module is used to generate and send configuration data containing timing topology information to the central computing unit; The central computing unit integrates the AUTOSAR adaptive platform AP and the classic AUTOSAR platform CP, and includes: The timing management module is configured to receive the configuration data, dynamically construct a timing tree based on the configuration data, and output a time synchronization signal to the multi-domain controller group through the heterogeneous vehicle network as the master clock node. A shared memory region is mapped to a preset fixed physical address and is used to transfer global reference time between the AP and the CP. An inter-core interrupt module, coupled to the shared memory region, is configured to trigger and send an interrupt signal to the CP after the AP writes the global reference time into the shared memory region; The Level 3 safety monitoring module is configured to monitor the status of the time synchronization process at the hardware, protocol and application layers, and provide synchronization status feedback to support vehicle functional safety mechanisms. The multi-domain controller group includes a first domain controller connected via a first vehicle network and a second domain controller connected via a second vehicle network, which respectively receive time synchronization signals from the central computing unit.

[0005] Furthermore, the configuration data is in JSON format and includes the master clock node priority, GPTP synchronization period, and redundant node list; the cloud configuration module sends the configuration data to the central computing unit through a secure OTA channel.

[0006] Furthermore, the timing management module includes a GPTP protocol stack and an optimal master clock algorithm election engine, configured to: run the optimal master clock algorithm to dynamically elect a master clock node based on the master clock node priority and clock quality parameters; and automatically switch to a redundant node when the current master clock node fails, or dynamically reconstruct the timing tree when updated configuration data is received, and the central computing unit does not need to be restarted during the above switching or reconstruction process.

[0007] Furthermore, the shared memory region is implemented as a timestamp register; the time service module on the AP side writes the global reference time into the timestamp register, and the StbM module on the CP side reads the global reference time from the timestamp register to complete local clock calibration.

[0008] Furthermore, the first in-vehicle network is an Ethernet network, and the first domain controller receives synchronization messages based on the GPTP protocol through the Ethernet network and obtains accurate timestamps using hardware stamping at the physical layer; the first domain controller includes a smart driving domain controller or a cockpit domain controller.

[0009] Furthermore, the second vehicle network is a CAN-FD bus, and the second domain controller receives synchronization frames through the CAN-FD bus, wherein timestamp information is embedded in the reserved bits of the CAN-FD data frame; the second domain controller includes a region controller or a body domain controller.

[0010] Furthermore, the three-level security monitoring module includes: The hardware monitoring unit is configured to monitor the update interval of the timestamp register in the Ethernet controller, and generate a hardware error code if the time exceeds a preset time threshold. The protocol state machine unit is configured to maintain a four-state synchronization state machine, the four states including an uninitialized state, a synchronization state, a locked state, and a failed state. The application interface unit is configured to provide the SyncState API interface, which can be called by upper-layer security-related applications to query the current synchronization status.

[0011] Furthermore, the SyncState API interface is configured to provide real-time synchronization status information to the vehicle's critical safety function modules; when the synchronization status is in a failed state, the critical safety function modules trigger a security degradation mechanism, including switching to a backup clock source or enabling local timekeeping mode, to maintain the system's time availability.

[0012] On the other hand, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, enables the processor to implement the functions of the aforementioned AUTOSAR AP-based multi-domain time synchronization system.

[0013] On the other hand, this application provides a vehicle that integrates the aforementioned AUTOSAR AP-based multi-domain time synchronization system.

[0014] The beneficial effects of this invention are as follows: This application provides a multi-domain time synchronization system based on an AUTOSAR AP. By integrating a cloud configuration module, a central computing unit, and a multi-domain controller group, it realizes remote dynamic configuration and real-time distribution of the timing topology. The central computing unit integrates the AUTOSAR AP and the CP platform, dynamically constructs a timing tree using the timing management module, and distributes high-precision synchronization signals to different domain controllers as the master clock node. Utilizing a shared memory region with fixed physical addresses and an inter-core interrupt mechanism, it achieves low-latency, high-consistency global time transfer between the AP and CP. Simultaneously, through a three-level security monitoring module covering the hardware layer, protocol layer, and application layer, it performs full-link status monitoring and feedback on the synchronization process, effectively supporting vehicle functional safety mechanisms. This system supports multi-domain collaboration under heterogeneous in-vehicle networks, significantly improving the flexibility, accuracy, and reliability of time synchronization, meeting the stringent requirements of high-level autonomous driving for cross-domain timing consistency. This application also provides corresponding media and vehicles; the beneficial effects of the media and vehicles are the same as those of the above system, and will not be elaborated upon here.

[0015] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0016] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0017] Figure 1 This is a structural diagram of the multi-domain time synchronization system based on AUTOSAR AP provided in this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] The present application will be further described below with reference to the accompanying drawings and specific embodiments. The described embodiments should not be considered as limitations on the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the present application.

[0020] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] With the development of intelligent connected vehicles, vehicle electronic and electrical architecture is evolving from traditional distributed architecture to centralized, domain-centralized, and even centrally computed architectures. Against this backdrop, key nodes such as the intelligent driving domain controller, cockpit domain controller, area controller, and TBOX need to collaborate efficiently under a unified time reference to ensure that subsystems such as perception, planning, control, and human-machine interaction operate in an orderly manner with microsecond-level timing accuracy. Time synchronization has therefore become a fundamental technology supporting the safety and reliability of high-level autonomous driving.

[0023] Current in-vehicle time synchronization technologies primarily rely on the Generalized Precision Time Protocol (GPP) defined by the IEEE 802.1AS standard, which has been implemented in some classic and adaptive AUTOSAR platforms. For example, patents have proposed in-vehicle time synchronization methods based on the GPP, distributing time information over Ethernet via a master-slave clock architecture; other solutions attempt to use SOMEIP or Socket communication to transmit timestamps between different electronic control units. Furthermore, some commercial toolchains provide synchronization time base management modules that support time base management on classic platforms and, to a certain extent, meet functional safety requirements.

[0024] However, these existing technologies reveal multiple structural flaws when facing complex and dynamic scenarios in high-level autonomous driving. First, existing solutions generally adopt a static configuration strategy, with key parameters such as the master clock role, synchronization period, and priority fixed during the software compilation stage, making dynamic adjustment impossible during vehicle operation. For example, when the TBOX, acting as the master clock source for the Global Navigation Satellite System, loses signal in a tunnel or underground parking garage, the system cannot automatically switch to a backup node such as the intelligent driving domain controller as the new master clock. Furthermore, if the synchronization period needs to be shortened from 100 milliseconds to 50 milliseconds after adding highly time-sensitive sensors such as LiDAR, the vehicle must be stopped and the firmware rewritten, severely impacting development efficiency and user experience.

[0025] Secondly, cross-operating system time synchronization suffers from significant latency and accuracy loss. Current adaptive platform systems are typically based on Linux or QNX, while classic platform systems are based on real-time operating systems. Time transfer between the two often relies on high-level communication protocols such as Socket or SOMEIP. This process introduces multiple delays, including forwarding delays from Ethernet switching chips, protocol stack serialization and deserialization overhead, and scheduling delays caused by context switching between heterogeneous operating systems. The cumulative delay far exceeds the tolerable 20-microsecond clock deviation threshold for autonomous driving systems, easily leading to misalignment between braking commands and perception data on the timeline, causing safety hazards.

[0026] Third, existing time synchronization mechanisms lack comprehensive runtime security monitoring capabilities. Although some solutions achieve basic time synchronization functions, they fail to build a full-stack diagnostic system covering hardware, protocol, and application layers. For example, if the timestamp register of the Ethernet physical layer fails to update in a timely manner due to hardware failure, the system cannot proactively detect and issue an alarm; the internal synchronization state of the protocol stack is usually a black box, without exposing clear status indicators to the outside world, causing upper-layer safety-critical functions such as automatic emergency braking to be unable to make degradation decisions based on the synchronization state; in scenarios where satellite signals are unavailable for extended periods, there is also no strategy to automatically switch to backup clock sources such as local high-stability crystal oscillators, violating the international standard requirement that automotive safety integrity level D systems must maintain safe operation even under single-point failures.

[0027] In summary, existing vehicle time synchronization technologies have significant shortcomings in three dimensions: dynamic adaptability, cross-domain synchronization accuracy, and functional safety monitoring, making it difficult to support the stringent time consistency requirements of future high-level autonomous driving. This application addresses these issues by proposing a multi-domain time synchronization system based on the AUTOSAR adaptive platform, integrating cloud-based dynamic configuration, high-precision time transfer across operating systems, and a multi-layered safety monitoring mechanism.

[0028] The system distributes configuration data containing timing topology information through a cloud-based configuration module, enabling the central computing unit to dynamically build and reconstruct the timing tree at runtime. This allows for master clock role switching and synchronization cycle adjustment without requiring a reboot or firmware re-flash. Within the central computing unit, a shared memory region mapped to a fixed physical address and an inter-core interrupt mechanism are used to achieve sub-microsecond-level global reference time transfer between the adaptive and classic platforms, significantly reducing cross-operating system communication latency. Simultaneously, the system constructs a three-tiered security monitoring system covering the hardware, protocol, and application layers. By monitoring the timestamp register status, maintaining a four-state synchronization machine, and providing a synchronization status query interface, it achieves real-time diagnosis and safety response throughout the time synchronization process, effectively supporting the comprehensive requirements of high-level autonomous driving for time consistency, flexibility, and functional safety.

[0029] First, the multi-domain time synchronization system based on AUTOSAR AP provided in this application will be described in detail below with reference to the accompanying drawings.

[0030] Reference Figure 1 The multi-domain time synchronization system based on AUTOSAR AP provided in this application achieves centralized management and dynamic distribution of time synchronization strategies, flexible reconstruction of timing topology, and high-precision clock alignment between cross-domain controllers through the collaborative work of a central computing unit, a cloud configuration module, and a multi-domain controller group. This architecture not only breaks the limitations of traditional static configuration and improves the system's adaptability in complex operating environments, but also provides a unified and reliable time reference for the safe and reliable collaboration of multiple domain functions such as intelligent driving, cockpit, and vehicle body. It is a key infrastructure supporting the efficient and safe operation of high-level autonomous driving systems.

[0031] In some embodiments of this application, the cloud configuration module is used to generate and distribute configuration data containing timing topology information to the central computing unit. By centrally managing key parameters such as the topology, master-slave relationship, and synchronization cycle required for time synchronization from the cloud and dynamically distributing them to the vehicle, the system is freed from dependence on pre-compiled firmware parameters, enabling remote updates and flexible adjustments to the timing strategy. This allows the system to adapt to different operating scenarios and network topology changes, improving maintainability and deployment efficiency.

[0032] In some embodiments of this application, the central computing unit integrates the AUTOSAR adaptive platform (AP) and the classic AUTOSAR platform (CP), and includes a time synchronization management module, a shared memory region, an inter-core interrupt module, and a three-level security monitoring module. This constructs a unified time synchronization hub integrating heterogeneous operating systems, simultaneously supporting AP and CP environments on the same hardware platform. It provides high-precision, low-latency time base distribution capabilities for cross-domain controllers and provides infrastructure support for the collaborative operation of subsequent functional modules.

[0033] The timing management module is configured to receive configuration data, dynamically construct a timing tree based on the configuration data, and act as the master clock node to output time synchronization signals to the multi-domain controller group through the heterogeneous vehicle network. Specifically, based on the timing topology information distributed from the cloud, the timing tree structure is generated or reconstructed in real time during runtime, the master-slave clock relationship is clarified, and the module actively sends synchronization signals to different domain controllers as the master clock, ensuring that the entire vehicle network works in coordination under a unified time base and meeting the requirements for dynamic switching and high availability.

[0034] The shared memory region is mapped to a preset fixed physical address for transmitting global reference time between the AP and CP. Through a hardware-level fixed address mapping mechanism, a low-overhead, highly deterministic clock transmission channel is established between the adaptive platform and the classic platform, avoiding the transmission, parsing, and scheduling delays introduced by traditional protocol stack-based communication, thereby achieving sub-microsecond cross-operating system time synchronization.

[0035] The inter-core interrupt module is coupled to the shared memory region. It is configured to trigger and send an interrupt signal to the CP after the AP writes the global reference time to the shared memory region. This ensures that the CP can immediately sense the update of the AP's time reference. By breaking the operating system scheduling limitation through the hardware interrupt mechanism, the CP system can respond and read the latest timestamp in the shortest possible time, effectively reducing the response latency of cross-core communication and ensuring the real-time performance and accuracy of time transmission.

[0036] The Level 3 safety monitoring module is configured to monitor the time synchronization process at the hardware, protocol, and application layers, and provide synchronization status feedback to support vehicle functional safety mechanisms. By constructing a runtime monitoring system covering the entire chain, from the underlying hardware register status to the upper-layer application interface, synchronization anomalies are detected layer by layer, and clear status information is output. This provides decision-making basis for functional safety-related modules, ensuring that the system can respond promptly and maintain basic time availability in the event of a clock failure.

[0037] In some embodiments of this application, the multi-domain controller group includes a first domain controller connected via a first in-vehicle network and a second domain controller connected via a second in-vehicle network, each receiving a time synchronization signal from the central computing unit. This extends a unified time base to different types of in-vehicle networks and functional domains, enabling various controllers such as those for intelligent driving, cockpit, and body to obtain synchronization signals from the central computing unit regardless of the communication bus used. This achieves cross-domain time consistency across the entire vehicle, supporting advanced functions such as multi-sensor fusion and collaborative control.

[0038] In some embodiments of this application, the configuration data is in JSON format, including the master clock node priority, GPTP synchronization period, and a list of redundant nodes. The cloud configuration module sends the configuration data to the central computing unit via a secure OTA channel. By using a clearly structured and easily parsed JSON format to standardize and encapsulate key timing parameters, the selection criteria for the master clock, the frequency of time synchronization, and the configuration information of backup nodes can be expressed and transmitted using a unified data model. Simultaneously, the secure OTA channel ensures the integrity and confidentiality of parameters during transmission, preventing tampering or injection attacks. This allows for remote, dynamic, and reliable updates to the vehicle-mounted time synchronization strategy while ensuring system security.

[0039] In some embodiments of this application, the timing management module includes a GPTP protocol stack and a best master clock algorithm election engine, configured to: run the best master clock algorithm to dynamically elect a master clock node based on the master clock node priority and clock quality parameters; and automatically switch to a redundant node when the current master clock node fails, or dynamically reconstruct the timing tree when updated configuration data is received, and the central computing unit does not need to be restarted during the above switching or reconstruction process.

[0040] Specifically, by integrating the best master clock algorithm election engine with the GPTP protocol stack, the system can autonomously determine and select the optimal master clock node based on preset priorities and real-time clock quality indicators during runtime, thereby establishing a reasonable time synchronization hierarchy. When the master clock fails due to faults, signal loss, or other reasons, the system can immediately select a new master clock from redundant nodes to complete a seamless switchover, avoiding time synchronization interruptions. At the same time, after new configuration data is distributed from the cloud, the system can instantly parse and rebuild the time synchronization tree, adjust the master-slave relationship or synchronization strategy, and complete the entire process in runtime without interrupting system services or restarting the central computing unit, significantly improving the availability, robustness, and operational flexibility of the time synchronization system.

[0041] In some embodiments of this application, the timing tree is activated and monitored by the master clock node periodically sending Sync messages containing precise timestamps according to the configured synchronization period; after each slave node receives the Sync message, it combines the FollowUp and Pdelay mechanisms to accurately calculate the link delay and clock deviation, and adjusts the local clock accordingly, ultimately achieving microsecond-level time calibration, ensuring that the entire multi-domain system operates collaboratively under a unified and high-precision time reference.

[0042] In some embodiments of this application, the shared memory region is implemented as a timestamp register. The time service module on the AP side writes the global reference time into the timestamp register, and the StbM module on the CP side reads the global reference time from the timestamp register to complete local clock calibration.

[0043] Specifically, by materializing the shared memory region into a dedicated timestamp register, a highly deterministic clock information transmission channel with extremely low access latency is provided between the adaptive platform and the classic platform. After obtaining the synchronized global reference time, the time service module on the AP side directly writes it into this register, ensuring that the data write location is fixed and can be quickly accessed by hardware. The synchronization time reference management module on the CP side obtains the reference time consistent with the AP side by reading the time value in the same register, and adjusts the local clock accordingly to achieve accurate calibration. The entire process avoids the protocol overhead and scheduling uncertainty brought about by traditional software communication mechanisms, thereby ensuring the accuracy and real-time performance of cross-operating system time synchronization.

[0044] In some embodiments of this application, the sub-microsecond latching technology across operating systems (AP / CP) is implemented through the following process: After the GPTP protocol stack on the AP side obtains the global reference time, it writes the time into the shared memory region with fixed physical addresses 0x80000000 to 0x80000007 and triggers a memory barrier to ensure the consistency of data writing; subsequently, the system establishes a communication channel from the AP core to the CP core by configuring the GIC interrupt controller and writes a specific value to the inter-core interrupt register to actively trigger a cross-core interrupt; the interrupt service routine on the CP side immediately reads the timestamp in the shared memory after receiving the interrupt, compensates for it with the known interrupt response delay, and finally updates the global time reference of the StbM module, thereby completing high-precision, low-latency cross-operating system time synchronization.

[0045] In some embodiments of this application, the first in-vehicle network is Ethernet, and the first domain controller receives synchronization messages based on the GPTP protocol via Ethernet and obtains precise timestamps at the physical layer using hardware stamping. The first domain controller includes an intelligent driving domain controller or a cockpit domain controller. Utilizing the high bandwidth and low latency communication characteristics of Ethernet, combined with the GPTP protocol, high-precision time distribution is achieved, enabling the first domain controller to receive synchronization messages sent by the central computing unit. Simultaneously, the precise arrival or transmission time of messages is directly captured at the physical layer through a hardware stamping mechanism, avoiding the time uncertainty introduced by operating system scheduling and protocol stack processing, thereby obtaining sub-microsecond timestamp accuracy. This mechanism is particularly suitable for intelligent driving domain controllers or cockpit domain controllers with extremely high timing consistency requirements, providing reliable time reference support for their key functions such as perception, decision-making, and human-machine interaction.

[0046] In some embodiments of this application, the second vehicle network is a CAN-FD bus, and the second domain controller receives synchronization frames via the CAN-FD bus, where timestamp information is embedded in reserved bits of the CAN-FD data frame. The second domain controller includes a zone controller or a body domain controller. By extending high-precision time synchronization capabilities to vehicle subsystems using CAN-FD communication, and by utilizing unused reserved bits in the CAN-FD data frame to carry timestamp information, time distribution is achieved without changing the existing bus protocol structure and compatibility. As a receiving end, the second domain controller can parse the embedded timestamp from regular communication frames and calibrate its local clock accordingly, thereby achieving time alignment with the master clock node in resource-constrained or cost-sensitive zone controllers or body domain controllers. This approach effectively solves the problem of the lack of a native time synchronization mechanism in traditional CAN networks, enabling non-Ethernet domains to be incorporated into a unified time system and supporting the needs of multi-domain collaborative control throughout the vehicle.

[0047] In some embodiments of this application, the Level 3 security monitoring module includes the following units.

[0048] The hardware monitoring unit is configured to monitor the update interval of the timestamp register in the Ethernet controller. If the interval exceeds a preset time threshold, a hardware error code is generated. It monitors the health of the time synchronization link in real time at the underlying hardware level, continuously checking whether the timestamp register is updated within a specified time to determine if there are any anomalies in the physical or driver layer. Once the update interval exceeds the set threshold, it indicates that the master clock signal may be interrupted or a hardware failure has occurred. At this point, a clear hardware error code is immediately generated, providing the system with the first line of fault detection and alarm capability, ensuring that problems are identified and handled at the earliest stage.

[0049] Specifically, at the hardware layer, the Ethernet driver periodically checks the valid bits of the timestamp status register. If it detects that the timestamp status has timed out for more than one millisecond, it triggers the hardware error code TS_EC_HW_TIMEOUT and automatically switches to the backup clock source.

[0050] The protocol state machine unit is configured to maintain a four-state synchronization state machine, comprising the uninitialized state (UNINIT), the SYNCING state, the LOCKED state, and the FAIL state. By defining four mutually exclusive states that cover the entire lifecycle, the synchronization progress within the protocol stack presents a clear and discernible logical state to the outside world. The system can determine whether to allow critical functions that depend on the time base to run based on the current state, and trigger corresponding recovery or degradation procedures when entering the failure state, thereby improving the controllability and diagnosability of the synchronization mechanism.

[0051] The application interface unit is configured to provide a SyncState API interface, which upper-layer safety-related applications can call to query the current synchronization status. By opening a standardized status access channel to upper-layer functional software, safety-critical modules such as automatic emergency braking and sensor fusion can proactively obtain the real-time operating status of the time synchronization system. By calling this interface, upper-layer applications can dynamically adjust their behavior based on whether synchronization is effective. For example, when synchronization fails, they can switch to local timekeeping mode or restrict high-risk operations, thereby incorporating the time synchronization status into the vehicle's functional safety decision-making system and meeting the stringent requirements of high-level autonomous driving for time availability and system robustness.

[0052] In some embodiments of this application, the SyncState API interface is configured to provide real-time synchronization status information to the vehicle's critical safety function modules. When the synchronization status fails, the critical safety function modules trigger a security degradation mechanism, including switching to a backup clock source or enabling local timekeeping mode to maintain the system's time availability.

[0053] Specifically, the operating status of the time synchronization system is deeply coupled with the vehicle's functional safety mechanism. Through the SyncState API interface, key safety function modules that are highly sensitive to time accuracy, such as automatic emergency braking and perception fusion, can know in real time whether the current time reference is reliable. Once a synchronization failure is detected, these modules can immediately activate preset safety degradation strategies, such as switching to a highly stable local crystal oscillator as a backup clock source, or relying on a local timekeeping algorithm to maintain basic time estimation for a limited time. This ensures that the system still has a usable and controlled time reference even if the main synchronization link fails, avoiding functional abnormalities or safety risks caused by time inaccuracies, and effectively supporting fault tolerance capabilities that meet ASIL-D level requirements.

[0054] In summary, the system constructs a multi-level time synchronization and cross-domain time synchronization architecture based on the AUTOSAR adaptive platform, including a cloud configuration center, a central computing unit, an intelligent driving domain controller, and a regional controller. The cloud configuration center distributes JSON-formatted configuration information containing master node priority, synchronization cycle, and a list of redundant nodes via a secure OTA channel, enabling remote dynamic management of the vehicle's time synchronization strategy. The central computing unit integrates the AUTOSAR adaptive platform and the classic platform. The adaptive platform's GPTP protocol stack and time service module write the global reference time to a shared memory area in the form of a 64-bit timestamp register with physical address 0x80000000, while the classic platform's StbM module reads the timestamp from this shared memory to complete local clock calibration. The central computing unit is also equipped with a protocol stack hot-update module, supporting dynamic loading of JSON configurations at runtime and activation of the optimal master clock algorithm election engine to flexibly respond to network topology changes. Time synchronization is distributed through two paths: First, GPTP synchronization messages are transmitted via Ethernet to deliver high-precision time to the intelligent driving domain controller. Sensors connected to this controller, such as cameras and LiDAR, rely on physical layer hardware stamping mechanisms to obtain sub-microsecond timestamps. Second, the timestamp is embedded in reserved bits of the data frame via the CAN-FD bus, extending synchronization capabilities to the area controller for time alignment of various sensors in the vehicle domain. The entire system thus achieves a unified time synchronization system that covers multiple domains, supports heterogeneous networks, possesses dynamic configuration capabilities, and meets high-precision requirements.

[0055] Secondly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it enables the processor to implement the functions of the aforementioned multi-domain time synchronization system based on AUTOSAR AP.

[0056] Furthermore, embodiments of this application provide a vehicle that integrates the aforementioned multi-domain time synchronization system based on AUTOSAR AP.

[0057] In summary, the AUTOSAR AP-based multi-domain time synchronization system, medium, and vehicle provided in this application have the following technical effects.

[0058] This solution dynamically distributes JSON-formatted time synchronization topology configurations from the cloud, enabling runtime updates of key parameters such as master clock priority, synchronization period, and redundant nodes. This overcomes the limitations of traditional static firmware configurations in terms of functional iteration and scenario adaptation. The time synchronization management module integrated within the central computing unit, combined with the GPTP protocol stack and the optimal master clock algorithm election engine, can complete role switching or time synchronization tree reconstruction within milliseconds when the master clock fails or its configuration changes, without requiring a system restart, significantly improving the availability and continuity of time synchronization. By implementing the shared memory region as a timestamp register with a fixed physical address and cooperating with the inter-core interrupt mechanism, the time transmission delay between the AP side and the CP side is compressed to the sub-microsecond level, effectively solving the timing discontinuity problem in heterogeneous operating system collaboration. For Ethernet and CAN-FD, two mainstream vehicle networks, hardware stamping and reserved bit embedded timestamps are used respectively, enabling different types of domain controllers, such as the intelligent driving domain, cockpit domain, area controller, and body domain, to be included in a unified high-precision time system. At the same time, the three-level safety monitoring module monitors the timestamp register update status at the hardware layer, maintains the four-state synchronization state machine at the protocol layer, and opens SyncState at the application layer. The API interface establishes real-time diagnostic and feedback capabilities covering the entire timeline. When synchronization fails, it can trigger safety degradation mechanisms such as switching to a backup clock source or enabling local timekeeping, ensuring system time availability even under fault conditions and meeting ISO 26262 ASIL-D level functional safety requirements. Overall, this solution improves time synchronization accuracy and cross-domain consistency while enhancing the system's dynamic adaptability, safety redundancy, and resource efficiency, providing reliable time infrastructure support for high-level autonomous driving.

[0059] It should be noted that in all specific embodiments of this application, all data processing activities related to user identity or personal characteristics, such as user information, user behavior data, historical data, and location information, will be conducted in accordance with the principles of legality, legitimacy, and necessity. All data collection, use, storage, and processing will be subject to compliance with applicable national and regional laws, regulations, and industry standards, and informed consent from users will be obtained in a clear and explicit manner before processing. For the processing of sensitive personal information, separate consent from users will be obtained through prominent means such as pop-up prompts and independent confirmation pages. If any processing conflicts with laws and regulations, the laws and regulations will prevail, and necessary data processing will only be carried out within the scope permitted by laws and regulations, ensuring that all data-based applications, analyses, and technical implementations are conducted within the scope permitted by laws and regulations.

[0060] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0061] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of ordinary skill of an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary skill. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0062] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several programs to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0063] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequential list of executable programs for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, a program execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can retrieve and execute a program from or in conjunction with such a program execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit a program for use by or in conjunction with a program execution system, apparatus, or device.

[0064] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Additionally, computer-readable media can even be paper or other suitable media on which programs can be printed, for example, by optically scanning the paper or other media, then editing, interpreting, or, if necessary, processing it in a suitable manner to obtain the program electronically, and then storing it in computer memory.

[0065] It should be understood that various parts of the present invention 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 program 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.

[0066] In the foregoing description of this specification, the reference to terms such as "one embodiment / implementation," "another embodiment / implementation," or "certain embodiments / implementations," etc., indicates that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in an embodiment or example of the present invention. 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.

[0067] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0068] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

Claims

1. An AUTOSAR AP based multi-domain time synchronization system, characterized in that, This includes a central computing unit, a cloud configuration module, and a multi-domain controller group; The cloud configuration module is used to generate and send configuration data containing timing topology information to the central computing unit; The central computing unit integrates the AUTOSAR adaptive platform AP and the classic AUTOSAR platform CP, and includes: The timing management module is configured to receive the configuration data, dynamically construct a timing tree based on the configuration data, and output a time synchronization signal to the multi-domain controller group through the heterogeneous vehicle network as the master clock node. A shared memory region is mapped to a preset fixed physical address and is used to transfer global reference time between the AP and the CP. The inter-core interrupt module is configured to trigger and send an interrupt signal to the CP after the AP writes the global reference time into the shared memory region; The Level 3 safety monitoring module is configured to monitor the status of the time synchronization process at the hardware, protocol and application layers, and provide synchronization status feedback to support vehicle functional safety mechanisms. The multi-domain controller group includes a first domain controller connected via a first vehicle network and a second domain controller connected via a second vehicle network, which respectively receive time synchronization signals from the central computing unit.

2. The AUTOSAR AP based multi-domain time synchronization system according to claim 1, characterized in that, The configuration data is in JSON format and includes the master clock node priority, GPTP synchronization period, and redundant node list; the cloud configuration module sends the configuration data to the central computing unit through a secure OTA channel.

3. The AUTOSAR AP based multi-domain time synchronization system according to claim 1, characterized in that, The timing management module includes a GPTP protocol stack and a best master clock algorithm election engine, configured to: run the best master clock algorithm and dynamically elect a master clock node based on the master clock node priority and clock quality parameters; It automatically switches to a redundant node when the current master clock node fails, or dynamically reconstructs the timing tree when updated configuration data is received, and the central computing unit does not need to be restarted during the switching or reconstruction process.

4. The AUTOSAR AP based multi-domain time synchronization system according to claim 1, characterized in that, The shared memory region is implemented as a timestamp register; the time service module on the AP side writes the global reference time into the timestamp register, and the StbM module on the CP side reads the global reference time from the timestamp register to complete local clock calibration.

5. The AUTOSAR AP based multi-domain time synchronization system according to claim 1, characterized in that, The first vehicle network is an Ethernet network. The first domain controller receives synchronization messages based on the GPTP protocol through the Ethernet network and obtains accurate timestamps using hardware stamping at the physical layer. The first domain controller includes a smart driving domain controller or a cockpit domain controller.

6. The AUTOSAR AP based multi-domain time synchronization system according to claim 1, characterized in that, The second vehicle network is a CAN-FD bus. The second domain controller receives synchronization frames through the CAN-FD bus, wherein timestamp information is embedded in the reserved bits of the CAN-FD data frame. The second domain controller includes a zone controller or a body domain controller.

7. The AUTOSAR AP based multi-domain time synchronization system according to claim 1, characterized in that, The three-level security monitoring module includes: The hardware monitoring unit is configured to monitor the update interval of the timestamp register in the Ethernet controller, and generate a hardware error code if the time exceeds a preset time threshold. The protocol state machine unit is configured to maintain a four-state synchronization state machine, the four states including an uninitialized state, a synchronization state, a locked state, and a failed state. The application interface unit is configured to provide the SyncState API interface, which can be called by upper-layer security-related applications to query the current synchronization status.

8. The AUTOSAR AP based multi-domain time synchronization system according to claim 7, characterized in that, The SyncState API interface is configured to provide real-time synchronization status information to the vehicle's critical safety function modules. When the synchronization status is in a failed state, the critical safety function modules trigger a security degradation mechanism, including switching to a backup clock source or enabling local timekeeping mode, to maintain the system's time availability.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that When the computer program is executed by the processor, it enables the processor to implement the functions of the AUTOSAR AP-based multi-domain time synchronization system as described in any one of claims 1 to 8.

10. A vehicle characterized by comprising: Integrate a multi-domain time synchronization system based on AUTOSAR AP as described in any one of claims 1 to 8.

Images