A vehicle-mounted data acquisition method, device and computer equipment

Abstract

The application relates to the technical field of data processing, and discloses a vehicle-mounted data acquisition method and device and computer equipment, the method comprising the following steps: selecting a target data routing mode from preset data routing modes according to a vehicle application scene; under the target data routing mode, transmitting original data collected by each vehicle-mounted sensor to a corresponding target computing node through a corresponding data channel; and adding a time stamp to the original data based on a previously established time reference at the target computing node to generate synchronous data with the time stamp. The application solves the problem that an existing vehicle-mounted data acquisition system cannot flexibly and uniformly adapt different sensors and computing nodes under various road test scenes.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and specifically to a vehicle-mounted data acquisition method, device, and computer equipment. Background Technology

[0002] As autonomous driving technology evolves towards Level 3 and above, the demand for high-quality, comprehensive real-world road scenario data for data-driven algorithms (such as end-to-end perception networks and occupation networks) is surging. During R&D and verification, automakers typically assemble a fleet of road test vehicles with various functional definitions. Typical vehicles include dedicated data acquisition vehicles (equipped with high-specification industrial control computers, directly connecting to various sensors for high-speed data transfer), hybrid data acquisition and testing vehicles (equipped with both near-production domain controllers and industrial control computers, handling both algorithm verification and data recording), and demonstration vehicles (maintaining the original vehicle appearance, limiting equipment size and wiring harnesses). These different vehicles exhibit significant differences in sensor interface types, computing node configurations, and data flow requirements.

[0003] However, existing technologies cannot flexibly adapt data routing paths and computation target nodes to different road test scenarios. Whenever vehicle roles change or sensor configurations are altered, hardware connections and communication protocols must be redesigned, resulting in a rigid architecture that is difficult to reuse. Furthermore, each computation node (industrial control computer, domain controller, etc.) relies on its own independent software clock for timestamp marking, lacking a unified and stable time base. During high-concurrency data injection from multiple sources, CPU scheduling fluctuations can easily cause random timestamp jitter, severely affecting the alignment accuracy of multi-sensor data fusion. These limitations make it difficult for existing acquisition systems to simultaneously meet the flexible deployment requirements across multiple scenarios and the stringent requirements for data time consistency. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a vehicle-mounted data acquisition method, apparatus, and computer equipment to solve the problem that existing vehicle-mounted data acquisition systems cannot flexibly and uniformly adapt to different sensors and computing nodes in various road test scenarios.

[0005] In a first aspect, embodiments of the present invention provide a vehicle-mounted data acquisition method, the method comprising: Based on the vehicle application scenario, select the target data routing mode from the preset data routing modes; In the target data routing mode, the raw data collected by each vehicle sensor is transmitted to the corresponding target computing node through the corresponding data path; At the target computing node, timestamps are added to the original data based on a pre-established time reference to generate timestamped synchronized data.

[0006] Furthermore, before selecting a target data routing mode from preset data routing modes based on the vehicle application scenario, the method further includes: Receive standard positioning messages and physical second pulse signals output by the satellite positioning unit; The key time signal is obtained by decoding the standard positioning message and the physical second pulse signal using a hardware time synchronization box. Based on the key time signal, a time-giving message and a time-synchronization alignment message are constructed, and the hardware time synchronization box is configured as the absolute master clock node of the whole vehicle time synchronization protocol. The time synchronization message and the time synchronization alignment message are sent to each heterogeneous computing node in the vehicle through the vehicle Ethernet switch to align the underlying system clock of each heterogeneous computing node with the key time signal to obtain the time reference.

[0007] Furthermore, the preset data routing mode includes at least one of the following: full-volume high-speed direct connection routing mode, domain controller intelligent agent forwarding routing mode, and edge computing network offloading routing mode; The step of selecting a target data routing mode from preset data routing modes based on the vehicle application scenario includes: When the vehicle application scenario is a dedicated data acquisition scenario, the full-volume high-speed direct connection routing mode is selected as the target data routing mode. The dedicated data acquisition scenario is a data acquisition condition that does not require real-time processing of the raw data collected by the vehicle sensors and only requires raw data to be stored on disk. When the vehicle application scenario is a mixed data acquisition and testing R&D scenario, the domain controller intelligent agent forwarding routing mode is selected as the target data routing mode. The mixed data acquisition and testing R&D scenario is a R&D test condition that requires the domain controller to be connected to the raw data collected by the vehicle sensor to verify the vehicle perception algorithm. When the vehicle application scenario is a covert roadshow demonstration scenario, the edge computing network offloading routing mode is selected as the target data routing mode. The covert roadshow demonstration scenario is a public demonstration condition that requires reducing the exposure of external hardware and ensuring that the core computing power of the domain controller is not interfered with by communication load.

[0008] Furthermore, when the target data routing mode is the full-volume high-speed direct connection routing mode, the step of transmitting the raw data collected by each vehicle sensor to the corresponding target computing node through the corresponding data path includes: The positioning data collected by the satellite positioning unit is transmitted to the industrial control computer through a direct link from serial port to universal serial bus; The image data acquired by the image acquisition unit is transmitted to the industrial control computer via a coaxial cable; The first radar signal collected by the millimeter-wave radar, the second radar signal collected by the ultrasonic radar, and the chassis control signal collected by the vehicle chassis control unit are converged to the controller local area network conversion card via hard wiring, and then integrated by the controller local area network conversion card and connected to the industrial control computer. The third radar signal collected by the lidar is transmitted to the industrial control computer via a direct link of the vehicle Ethernet.

[0009] Furthermore, when the target data routing mode is the domain-controlled intelligent agent forwarding routing mode, the step of transmitting the raw data collected by each vehicle-mounted sensor to the corresponding target computing node through the corresponding data path includes: Configure the domain controller as an intelligent data proxy gateway, and connect the physical wiring harness of the heterogeneous interface devices in the vehicle sensor that are not directly compatible with the industrial control computer to the native wiring terminal of the domain controller. Within the domain controller, the data agent process is bound to a dedicated central processing unit core, and the highest real-time priority escalation mechanism is enabled to respond to hardware interrupts triggered by the heterogeneous interface device using the allocated dedicated computing resources. When the hardware interrupt is responded to, the current timestamp of the time base is extracted and the current timestamp is bound to the corresponding raw data to generate raw data carrying the timestamp; The raw data carrying the timestamp is encapsulated into a standardized message message, and the standardized message message is forwarded to the industrial control computer via the vehicle Ethernet.

[0010] Furthermore, the step of encapsulating the raw data carrying the timestamp into a standardized message packet and forwarding the standardized message packet to the industrial control computer via the vehicle Ethernet includes: The raw data carrying timestamps is encapsulated into standardized message messages for the robot development framework; Configure the standardized message message as a publishing node, and forward the standardized message message to the industrial control computer through the vehicle Ethernet.

[0011] Furthermore, when the target data routing mode is the edge computing network offloading routing mode, the step of transmitting the raw data collected by each vehicle sensor to the corresponding target computing node through the corresponding data path includes: Edge computing nodes are deployed in the concealed compartment of the vehicle, and the time base is sent to the edge computing nodes through the vehicle Ethernet switch to synchronize and calibrate the clock of the edge computing nodes. The edge computing node receives the raw serial byte stream data output by the satellite positioning unit, and performs hard parsing of the raw serial byte stream data using the serial protocol through a dedicated system process within the edge computing node to obtain standardized positioning data. The standardized positioning data is encapsulated into standard Ethernet packets and transmitted to the domain controller in real time via the vehicle Ethernet.

[0012] Furthermore, the method also includes: Through the clock status monitoring mechanism embedded in the domain controller, the heartbeat signal of the main time synchronization link, the status of the hardware time synchronization box, and the satellite positioning signal are monitored in real time. When the satellite positioning signal is lost and / or the hardware time synchronization box is offline and / or the heartbeat signal of the main time synchronization link is interrupted, the clock degradation disaster recovery rollback mechanism is triggered. Through the clock degradation disaster recovery rollback mechanism, the backup satellite positioning chip and temperature-compensated crystal oscillator built into the domain controller motherboard are invoked. Based on the backup satellite positioning chip and the temperature-compensated crystal oscillator, a backup physical second pulse signal is generated to re-anchor the clock source in the vehicle to the backup physical second pulse signal. The domain controller is configured as the proxy master clock node for the vehicle-wide time synchronization protocol. The proxy master clock node sends time synchronization messages and time synchronization alignment messages to each network node in the vehicle in reverse order to maintain the continuity of the time base.

[0013] Secondly, embodiments of the present invention provide a vehicle-mounted data acquisition device, the device comprising: The selection module is used to select a target data routing mode from preset data routing modes based on the vehicle application scenario; The transmission module is used to transmit the raw data collected by each vehicle sensor to the corresponding target computing node through the corresponding data path in the target data routing mode. The generation module is used to add timestamps to the original data at the target computing node based on a pre-established time base, thereby generating timestamped synchronization data.

[0014] Thirdly, embodiments of the present invention provide a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method described in the first aspect or any corresponding embodiment thereof.

[0015] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions that cause a computer to perform the method described in the first aspect or any of its corresponding embodiments.

[0016] The method provided in this application has the following beneficial effects: The method provided in this application selects a target data routing mode from preset data routing modes according to the vehicle application scenario, enabling a single hardware architecture to flexibly adapt to multiple acquisition scenarios and reducing hardware reconfiguration costs during mode switching. By using the corresponding data path in the target data routing mode to transmit the raw data collected by each vehicle sensor to the corresponding target computing node, the method ensures that data is forwarded on demand and reduces invalid bus occupation and signal conversion loss. By adding timestamps to the raw data and generating synchronization data based on a pre-established time reference at the target computing node, the method ensures accurate alignment of heterogeneous sensor data in the time dimension and eliminates timestamp drift caused by the independent clocks of each node. Attached Figure Description

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating the vehicle-mounted data acquisition method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the underlying architecture topology for a dedicated data acquisition scenario according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the underlying architecture topology for a hybrid R&D scenario of acquisition and testing according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the edge computing network offloading architecture topology for covert roadshow demonstration scenarios according to an embodiment of the present invention; Figure 5 This is a flowchart illustrating another vehicle-mounted data acquisition method according to an embodiment of the present invention; Figure 6 This is a flowchart illustrating another vehicle-mounted data acquisition method according to an embodiment of the present invention; Figure 7 This is a structural block diagram of an in-vehicle data acquisition device according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] According to embodiments of the present invention, an in-vehicle data acquisition method, apparatus, and computer device are provided. It should be noted that the steps shown in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0021] This embodiment provides a vehicle-mounted data acquisition method. Figure 1 This is a flowchart of an in-vehicle data acquisition method according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps: Step S101: Select the target data routing mode from the preset data routing modes according to the vehicle application scenario.

[0022] In this embodiment, the preset data routing mode includes at least one of the following: full-volume high-speed direct connection routing mode, domain controller intelligent proxy forwarding routing mode, and edge computing network offloading routing mode; based on the vehicle application scenario, a target data routing mode is selected from the preset data routing modes, including: Step A1: When the vehicle application scenario is a dedicated data acquisition scenario, select the full-volume high-speed direct connection routing mode as the target data routing mode. The dedicated data acquisition scenario is a data acquisition condition that does not require real-time processing of the raw data collected by the vehicle sensors and only requires raw data to be stored on disk.

[0023] Specifically, the dedicated data acquisition scenario refers to a data acquisition situation where the vehicle does not need to process the raw sensor data in real time on the vehicle side, but only needs to completely write all the acquired data to disk for subsequent offline training. The full-volume high-speed direct connection routing mode is a preset data routing scheme specifically designed for this scenario. Its core feature is that all vehicle-mounted sensors do not go through any intermediate computing nodes for protocol conversion or forwarding. Instead, they directly establish a point-to-point connection with the high-performance industrial personal computer (IPC) through physical cables. The data is processed uniformly in the IPC and then directly written to the storage device to achieve bottleneck-free transmission of data streams at the gigabits per second level.

[0024] During the selection process, the scenario is first determined based on the vehicle's current deployment tasks and hardware configuration: if the vehicle does not integrate a domain controller, does not require the running of perception and control algorithms, and does not involve any hidden constraints for external demonstration, it is identified as a dedicated data acquisition scenario. Then, from the preset data routing mode set, the full high-speed direct connection routing mode is activated as the target mode, while the logical paths of the other two routing modes are closed. This selection process is automatically completed by the onboard central management unit reading the preset task configuration file or by physical hardware topology identification (e.g., detecting the presence of domain controllers, edge nodes, etc.). Once the mode is locked, the system's underlying routing table and data distribution strategy immediately switch to the hardwired direct connection topology corresponding to that mode, and proxy forwarding or network offloading of related services is no longer enabled. The entire selection operation does not change the physical wiring of any sensors and computing nodes; it only enables the corresponding data channels through logical configuration, ensuring that all raw data in subsequent steps flows to the industrial control computer along the preset direct connection link.

[0025] Step A2: When the vehicle application scenario is a mixed data acquisition and testing R&D scenario, select the domain controller intelligent agent forwarding routing mode as the target data routing mode. The mixed data acquisition and testing R&D scenario is a R&D test condition that requires the domain controller to access the raw data collected by the vehicle sensor to verify the vehicle perception algorithm.

[0026] Specifically, the hybrid data acquisition and testing R&D scenario refers to a situation where vehicles simultaneously undertake two data acquisition tasks in real traffic flow: on the one hand, they act as a test platform, equipped with a near-production-ready Domain Control Unit (DCU) to run onboard perception algorithms to verify algorithm performance; on the other hand, they act as a data acquisition platform to record high-fidelity sensor data for offline training. Therefore, the vehicle's electrical system contains two computing centers simultaneously: a domain controller and an industrial control computer. The domain controller intelligent proxy forwarding routing mode is a preset data routing scheme designed for this scenario. Its core feature is to downgrade the domain controller to a data forwarding gateway between the industrial control computer and specific onboard sensors. The domain controller receives heterogeneous interface sensor data that the industrial control computer cannot directly incompatible with, completes timestamp binding and protocol encapsulation, and then forwards the data to the industrial control computer for disk storage via the onboard Ethernet.

[0027] During the selection process, the scenario is first determined based on the vehicle's hardware topology and mission objectives: if the vehicle integrates both a domain controller and an industrial control computer, and the current mission requires the domain controller to access raw sensor data to run perception and control algorithms, while also needing to collect raw data and store it on disk for offline training, then it is identified as a mixed data acquisition and testing R&D scenario. Subsequently, from the preset data routing mode set, the domain controller intelligent proxy forwarding routing mode is activated as the target mode, and some data channels in the full direct connection mode are closed (especially those heterogeneous interface channels that the industrial control computer cannot directly physically incompatible with). This selection process is automatically completed by the onboard central management unit reading the task type identifier and hardware list in the current vehicle configuration file. Once the mode is locked, the system's underlying data routing strategy switches to the proxy forwarding topology, enabling the domain controller's data proxy service process, and simultaneously opening the corresponding standardized message subscription port on the industrial control computer side. This ensures that subsequent sensor data flows along the forwarding path of domain controller-Ethernet-industrial control computer, while the sensor channels that could have been directly connected retain their original physical links.

[0028] Step A3: When the vehicle application scenario is a concealed roadshow demonstration scenario, the edge computing network offloading routing mode is selected as the target data routing mode. The concealed roadshow demonstration scenario is a public demonstration condition that requires reducing the exposure of external hardware and ensuring that the core computing power of the domain controller is not interfered with by communication load.

[0029] Specifically, the concealed roadshow demonstration scenario refers to a public demonstration situation aimed at showcasing the vehicle to the public. This requires the vehicle's exterior to closely resemble the original vehicle's condition, prohibiting the installation of bulky mechanical rotating LiDARs or exposed complex wiring harnesses. It necessitates the use of extremely small, concealed positioning antennas. Furthermore, the vehicle's cabin and trunk must not contain high-noise equipment or messy cables, and the demonstration must maintain smoothness and reliability under limited hardware conditions. The edge computing network offloading routing mode is a pre-designed data routing scheme for this scenario. Its core feature is to offload the communication load, such as serial port protocol parsing, which would normally be handled by the domain controller, to a small, independent edge computing node (such as a Mini PC) that can be deployed in a concealed compartment within the vehicle. This node is dedicated to receiving raw serial port data from the Real-Time Kinematic (RTK) satellite positioning unit, performing hard parsing, and then forwarding the standardized positioning data to the domain controller via the vehicle's Ethernet for demonstration purposes. This avoids developing serial port drivers or high-frequency polling logic within the domain controller, protecting its core algorithm computing power from communication interference.

[0030] During the selection process, the scenario is first determined based on the vehicle's current task configuration and hardware topology: if the task list explicitly marks it as a public roadshow for customers, and the hardware deployment plan has removed the large-volume industrial control computer and mechanical LiDAR, retaining only the domain controller, miniaturized RTK antenna, and pre-installed edge computing nodes, it is identified as a covert roadshow demonstration scenario. Subsequently, from the preset data routing mode set, the edge computing network offloading routing mode is activated as the target mode, and the industrial control computer data disk-to-disk channel in the full high-speed direct connection routing mode is simultaneously closed. At the same time, the proxy service involving the domain controller directly receiving raw data from heterogeneous sensors in the domain controller intelligent proxy forwarding routing mode is disabled. The above selection operation is automatically completed by reading the scenario identifier and hardware list in the vehicle configuration file through the vehicle's central management unit. Once the mode is locked, the data routing strategy redirects the target address of the serial port data stream of the satellite positioning unit to the edge computing node, and configures the domain controller to subscribe only to standardized positioning messages forwarded from the edge computing node via Ethernet, ensuring that all subsequent positioning data flows along the path of edge node-Ethernet-domain controller, and the domain controller itself does not need to participate in any underlying serial communication processing.

[0031] Step S102: In the target data routing mode, the raw data collected by each vehicle sensor is transmitted to the corresponding target computing node through the corresponding data path.

[0032] In this embodiment, the target data routing mode refers to the data flow path rule selected from three preset data transmission schemes based on the current application scenario of the vehicle, including the full-volume high-speed direct connection routing mode, the domain control intelligent agent forwarding routing mode, and the edge computing network offloading routing mode. The data path refers to the combination of physical transmission links and logical forwarding channels through which the raw data generated by the vehicle-mounted sensors travels from the acquisition end to the target computing node. Vehicle-mounted sensors include a satellite positioning unit (RTK), an image acquisition unit (ultra-high-definition camera), millimeter-wave radar, ultrasonic radar, lidar, and a vehicle chassis control unit. Raw data refers to the underlying signals or byte streams directly output by the aforementioned sensors without any algorithmic processing. The target computing node is the device that ultimately aggregates the data and performs timestamp binding and storage; depending on the mode, it can be an industrial control computer, a domain controller, or an edge computing node.

[0033] Based on the selected target data routing mode, the raw data collected by each vehicle-mounted sensor is transmitted to the designated target computing node through the data path corresponding to that mode. If the current mode is full-volume high-speed direct connection routing, the positioning data collected by the satellite positioning unit is transmitted to the industrial control computer via a direct link from serial port to universal serial bus (USB); the image data collected by the image acquisition unit is transmitted to the video capture card in the industrial control computer via a coaxial cable, i.e., a Gigabit Multimedia Serial Link (GMSL); the millimeter-wave radar signal, ultrasonic radar signal, and the chassis controller area network (CAN) signal collected by the vehicle chassis control unit are all converged via hard wiring to a Peripheral Component Interconnect Express (PCIe) to Controller Area Network (CAN) converter card, which integrates the data and connects it to the industrial control computer; the signal collected by the lidar is transmitted to the industrial control computer via a vehicle-mounted Ethernet direct link. If the current mode is domain controller intelligent agent forwarding routing, the domain controller is configured as an intelligent data agent gateway. The physical wiring harnesses of heterogeneous interface devices (such as ultrasonic radars using DSI3 interfaces) that are not directly compatible with the industrial control computer are connected to the domain controller's native terminals. Within the domain controller, hardware interrupts are responded to via core binding and real-time priority escalation mechanisms. The timestamp is extracted at the interrupt location and encapsulated into a standardized message (such as a message based on the CyberRT robotics framework), which is then forwarded to the industrial control computer via the vehicle's Ethernet. If the current mode is edge computing network offloading routing, the edge computing node is deployed in the vehicle's concealed compartment. This node receives the local clock via the vehicle's Ethernet switch, calibrates it using a time base, receives the raw serial byte stream data output by the satellite positioning unit, performs hard parsing of the serial protocol to generate standardized positioning data via its dedicated system process, encapsulates it into a standard Ethernet message, and transmits it to the domain controller in real-time via the vehicle's Ethernet.

[0034] Step S103: At the target computing node, timestamps are added to the original data based on a pre-established time base to generate time-stamped synchronized data.

[0035] In this embodiment of the application, when the target data routing mode is the full-data-volume high-speed direct connection routing mode, the raw data collected by each vehicle sensor is transmitted to the corresponding target computing node through the corresponding data path, including: Step B101: The positioning data collected by the satellite positioning unit is transmitted to the industrial control computer through a direct link from serial port to universal serial bus.

[0036] Specifically, the satellite positioning unit refers to the RTK receiver installed on the roof of the vehicle, which is used to receive Global Navigation Satellite System (GNSS) signals and output high-precision positioning data; the positioning data refers to the standard message data output by the RTK receiver, which contains information such as the vehicle's latitude and longitude, heading angle, and speed, specifically the recommended positioning information message in GPRMC format; the direct link refers to the point-to-point physical connection channel between the two devices without any intermediate forwarding nodes.

[0037] In full-volume high-speed direct connection routing mode, the positioning data collected by the satellite positioning unit is transmitted to the industrial control computer via a direct link from serial port to universal serial bus. The satellite positioning unit uses its physical serial port as the data output interface to continuously send GPRMC standard positioning messages. This serial port signal is connected to a serial port to universal serial bus adapter through a serial data transmission cable. The adapter converts the serial port level signal into a universal serial bus protocol signal. The universal serial bus interface of the adapter is directly plugged into the universal serial bus port on the industrial control computer through a universal serial bus cable, forming a physical direct link from the satellite positioning unit to the industrial control computer without any switches or forwarding nodes. The operating system inside the industrial control computer recognizes this universal serial bus port as a virtual serial port device and creates a corresponding character device node in the device file system. The daemon process running on the industrial control computer continuously reads byte stream data from this virtual serial port device node, parses the GPRMC message frame by frame according to the NMEA0183 protocol, extracts positioning information fields such as time, latitude and longitude, speed, and heading, and waits for subsequent steps to bind a unified timestamp to the positioning data based on a global time base before storing it on disk.

[0038] Step B102: The image data acquired by the image acquisition unit is transmitted to the industrial control computer via a coaxial cable.

[0039] Specifically, the image acquisition unit refers to the ultra-high-definition cameras mounted on the vehicle, used to acquire visual image data of the area in front of and around the vehicle. This includes a front-view camera (such as one equipped with an SG8S-AR0820C or SG8-OX08BC sensor) and a panoramic camera (such as an SG3S-ISX031C), totaling 11 channels covering different viewing angles. Image data refers to the raw video frame signals output by these cameras, transmitted in high-speed serial digital form without any compression or algorithm processing. Coaxial cable refers to GMSL coaxial cable, specifically designed for long-distance, high-speed video signal transmission between the vehicle-mounted camera and the receiver, capable of transmitting high-definition image data serially while maintaining signal integrity. The industrial control computer acts as the data acquisition aggregation node, containing a dedicated video capture card to receive multiple GMSL signals.

[0040] In full-volume high-speed direct-connect routing mode, image data acquired by the image acquisition unit is transmitted to the industrial control computer via coaxial cable. Each ultra-high-definition camera establishes a physical connection with the video capture card inside the industrial control computer through an independent GMSL coaxial cable. One end of the cable is plugged into the serializer interface on the camera side, and the other end is plugged into the corresponding deserializer port on the video capture card inside the industrial control computer. After the camera exposes and generates an image frame, it immediately converts the parallel image data into a high-speed serial differential signal through the internal serializer and sends it to the video capture card on the industrial control computer via the coaxial cable. The deserializer on the video capture card reconstructs the received serial signal into a parallel digital image frame and temporarily stores it in the buffer built into the capture card. The device driver in the industrial control computer reads each complete image data frame from the video capture card through continuous polling or interruption via the PCIe bus, and records the time when the frame arrives at the driver layer, preparing for subsequent timestamping based on a global time base. The entire transmission process does not pass through any switches or intermediate forwarding nodes, ensuring that the image data reaches the industrial control computer directly from the acquisition end with minimal latency.

[0041] Step B103: The first radar signal collected by the millimeter-wave radar, the second radar signal collected by the ultrasonic radar, and the chassis control signal collected by the vehicle chassis control unit are converged to the controller LAN conversion card via hard wiring, and then connected to the industrial control computer after being integrated by the controller LAN conversion card.

[0042] Specifically, millimeter-wave radar refers to automotive radar sensors operating in the millimeter-wave frequency band, used to detect the distance, speed, and angle information of obstacles around the vehicle. A typical example is five Valeo millimeter-wave radars, covering the front, rear, and sides of the vehicle. The first radar signal refers to the raw target detection message output by these millimeter-wave radars, containing data such as the target's relative position, relative speed, and reflection intensity. Ultrasonic radar refers to automotive sensors that use ultrasonic echo ranging for short-range obstacle detection. A typical example is twelve F40-16TR7B ultrasonic radars, distributed in the front and rear bumper areas. The second radar signal refers to the raw ranging values ​​output by these ultrasonic radars, typically output in the form of CAN bus messages. The vehicle chassis control unit refers to the Electronic Control Unit (ECU) responsible for the overall chassis status management and control. It outputs chassis control signals, including vehicle speed, wheel speed, steering angle, braking status, and accelerator pedal position, among other dynamic vehicle operating parameters. Hardwired refers to independent physical wires used to directly connect the signal lines of each sensor to the aggregation device point-to-point, without going through any switches, gateways, or wireless repeaters. A Controller Area Network (CAN) converter card is an industrial-grade PCIe-to-multi-channel CAN bus interface conversion device, specifically the ZLG U800 model. This card can simultaneously receive multiple CAN bus signals and integrate them before connecting to an industrial control computer via the PCIe bus.

[0043] In full-speed direct connection routing mode, the first radar signal acquired by the millimeter-wave radar, the second radar signal acquired by the ultrasonic radar, and the chassis control signal acquired by the vehicle chassis control unit are hard-wired to the Controller Area Network (CAN) converter card, and then integrated by the converter card before being connected to the industrial control computer. Each of the five millimeter-wave radars is hard-wired to its corresponding CAN channel port on the CAN converter card via an independent CAN twisted-pair cable. Similarly, the twelve ultrasonic radars are hard-wired to other CAN channel ports on the converter card via their respective CAN bus. The chassis control signal from the vehicle chassis control unit is also hard-wired to the designated CAN channel port on the converter card via the CAN bus. All signal lines use shielded twisted-pair cables to resist vehicle-mounted electromagnetic interference. The CAN converter card is physically inserted into the corresponding expansion slot of the industrial control computer motherboard through its peripheral component quick interconnect interface, establishing a high-speed data channel with the industrial control computer. Multiple CAN controllers within the converter card operate in parallel. The system receives CAN messages from each channel and performs bit timing synchronization, cyclic redundancy check, and identifier filtering on each message frame according to the Controller Area Network Protocol (CAN) standard. After confirming that there are no errors, the multiple messages from different channels are integrated into a unified data stream in chronological order and pushed directly to the memory space of the industrial control computer via the peripheral component fast interconnect bus. The device driver in the industrial control computer reads each CAN message frame in the data stream in the interrupt handling routine, maintains the integrity of its original content, and waits for the subsequent binding of a unified timestamp to each message frame based on the global time base before storing it on disk. The entire aggregation and transmission process does not pass through the vehicle gateway or any intermediate forwarding nodes, ensuring that the signal reaches the industrial control computer with minimal delay and the highest fidelity.

[0044] Step B104: The third radar signal collected by the lidar is transmitted to the industrial control computer via a direct link of the vehicle Ethernet.

[0045] Specifically, LiDAR refers to an active 3D environmental perception sensor based on the principle of laser ranging. It acquires distance and orientation information of surrounding obstacles by emitting laser beams and receiving reflected echoes. The Hesai OT128 model can be used as the main LiDAR, and the Hesai QT128 model can be added as a blind spot radar in Auto Valet Parking (AVP) scenarios. The third radar signal refers to the raw 3D point cloud data output by the LiDAR, containing the 3D spatial coordinates of each reflection point relative to the LiDAR coordinate system and reflection intensity information. This data is output in real time in the form of high-speed Ethernet packets. Automotive Ethernet refers to high-speed in-vehicle network communication technology based on standard Ethernet physical layer and link layer protocols, used to support high-bandwidth, low-latency transmission of sensor data within the vehicle. A direct link refers to a point-to-point communication channel where the data source device and the receiving device are directly connected via a physical network cable, without going through any switches, gateways, or routers. The industrial control computer here acts as a data aggregation node in the full-volume high-speed direct-connection routing mode, responsible for receiving the LiDAR point cloud data and waiting for subsequent steps to bind timestamps to it based on a global time base.

[0046] In full-speed direct connection routing mode, the third radar signal collected by the lidar is transmitted to the industrial control computer through the vehicle Ethernet direct connection link. The specific implementation is as follows: The LiDAR is directly connected to the vehicle-mounted Ethernet physical layer interface on the industrial control computer via a shielded twisted-pair Ethernet cable. Both ends of the cable use automotive-grade connectors to ensure signal reliability under vibration. After completing laser emission, echo reception, and point cloud computing internally, the LiDAR encapsulates each frame of point cloud data into an Ethernet data packet according to the User Datagram Protocol (UDP) / Internet Protocol (IP), and sends it to the directly connected industrial control computer through its Ethernet physical layer interface. After the network card of the industrial control computer receives the data packet at the physical layer, it sequentially passes through the address filtering of the Media Access Control (MAC) layer and the IP / UDP unpacking processing of the network protocol stack, and finally delivers the point cloud payload data to the data receiving daemon process of the application layer. The receiving software on the industrial control computer side continuously listens to the designated UDP port. Whenever a complete frame of point cloud data packet is received, it reads the payload content from the kernel network buffer and records the hardware timestamp when the data packet arrives at the network card driver layer, so as to prepare data for subsequent steps to bind a unified timestamp based on a global time base. The entire transmission link does not pass through any intermediate network nodes, ensuring that point cloud data goes directly from the LiDAR to the industrial control computer with minimal transmission delay.

[0047] Figure 2 This is a schematic diagram of the underlying architecture topology for dedicated data acquisition scenarios, such as... Figure 2As shown, the 570D remote inertial navigation system acts as an RTK receiver, outputting GPRMC standard positioning messages and PPS signals to a hardware time synchronization box via a serial port. After decoding, the synchronization box transmits the time signal to the industrial control computer via PTP through an onboard Ethernet switch. Simultaneously, the synchronization box directly outputs the PPS signal to trigger the camera acquisition card for hardware-level exposure alignment. A total of 11 ultra-high-definition cameras on the vehicle body (including 2 front-view, 1 rear-view, 4 side-view, and 4 surround-view cameras) are connected to two video acquisition cards via GMSL coaxial cables. The acquisition cards are connected to the industrial control computer via a PCIe bus. Five millimeter-wave radars, 12 ultrasonic radars, and chassis wheel pulse signals are hard-wired to an 8-channel PCIe to CAN converter card via a CAN bus. After integration by the converter card, the signals are connected to the industrial control computer. The main LiDAR OT128 and four blind-spot LiDARs QT128 are directly connected to the industrial control computer via onboard Ethernet and undergo clock calibration based on gPTP to ensure that the point cloud data timestamps are aligned with the global reference. In addition, mobile Wi-Fi connects to the industrial control computer via an Ethernet-to-USB module for data upload or remote control. All sensor data is directly fed into the industrial control computer, and after being stamped at the driver layer based on a globally unified time base, it is written to the NVMe solid-state drive array, achieving high-fidelity, zero-frame-loss data persistence. This diagram visually illustrates the complete physical topology and signal flow of the full-volume high-speed direct-connection routing mode in a dedicated data acquisition scenario.

[0048] In this embodiment of the application, when the target data routing mode is the full high-speed direct connection routing mode, at the target computing node, timestamps are added to the original data based on a pre-established time reference to generate time-stamped synchronous data, including: at the industrial control computer, timestamps are added to each sensor data based on the time reference to obtain the original data with timestamps; the original data with timestamps is written to a high-speed solid-state storage array to complete the data disk storage.

[0049] Specifically, the time reference refers to a globally unified rigid clock reference system established through hardware time synchronization (using a built-in Field-Programmable Gate Array (FPGA) to purely hardware decode the standard positioning message (GPRMC) and physical pulse per second (PPS) signals output by the Global Positioning System (GPS) satellite positioning units, and then through full-network time synchronization via the Precision Time Protocol (PTP, i.e., IEEE 1588v2). This reference forces the underlying system clocks of all heterogeneous computing nodes (including industrial control computers, domain controllers, and edge computing nodes) throughout the vehicle to be aligned to the same time, with an alignment error not exceeding 1 microsecond. High-speed solid-state storage arrays refer to non-volatile memory express (NVMe) solid-state drive (SSD) arrays configured inside industrial control computers. Typically, these arrays consist of multiple terabyte-level NVMe SSDs, providing continuous write bandwidth at the gigabits per second level for high-speed disk writing of massive amounts of raw sensor data.

[0050] When timestamp binding and data persistence are performed at the industrial control computer (ICC), the ICC operating system kernel has already aligned its underlying system clock (i.e., the CLOCK_REALTIME type clock source) with the master clock of the hardware time synchronization box at the microsecond level through a precise time protocol handshake process. After all sensor data arrives at the ICC driver layer via their respective physical links, the background daemon running on the ICC continuously monitors the character device nodes or network socket buffers of various sensor devices. Whenever the daemon reads a complete frame of raw data payload from any data source (including the virtual serial port device of the satellite positioning unit, the V4L2 device node of the video capture card, the character device of the controller LAN conversion card, the UDP receiving port of the LiDAR, etc.), it immediately calls the system-level clock acquisition function (such as the clock_gettime function, specifying the CLOCK_REALTIME clock source) to read the number of seconds and nanoseconds of the current moment, and writes the time value as the timestamp field of the data frame into the header of the data buffer, which together with the raw payload constitutes a complete data frame carrying the timestamp. Subsequently, the daemon uses Direct Input / Output (DIO) to... Unbuffered direct write methods, such as asynchronous input / output (AIO) or asynchronous input / output (AIO), continuously append timestamped data frames to the pre-allocated files of the high-speed solid-state storage array. During the write process, the data does not pass through the operating system page cache to avoid additional latency and data loss risks. The data write operations of all sensor channels are executed in parallel. The high-concurrency write capability of the NVMe solid-state drive array ensures that the total data flow of several gigabits per second is completed without bottlenecks and is stored on the disk. Each data frame maintains its timestamp and payload content atomically bound on the storage medium for accurate playback and fusion along the timeline in the subsequent offline training stage.

[0051] In this embodiment of the application, when the target data routing mode is the domain controller intelligent agent forwarding routing mode, the raw data collected by each vehicle sensor is transmitted to the corresponding target computing node through the corresponding data path, including: Step B201: Configure the domain controller as an intelligent data proxy gateway, and connect the physical wiring harness of the heterogeneous interface devices in the vehicle sensors that are not directly compatible with the industrial control computer to the native wiring terminals of the domain controller.

[0052] Specifically, a domain controller refers to an in-vehicle central computing unit that integrates high-performance heterogeneous computing chips (such as the Qualcomm Snapdragon 8775 or 8255 platform), runs a real-time operating system (such as QNX), and is responsible for executing core algorithms for autonomous driving perception, decision-making, and control. An intelligent data proxy gateway refers to configuring a domain controller as a data forwarding intermediary node, transforming it from a pure computing device into a proxy entity with both interface adaptation and data routing functions. It is responsible for receiving raw sensor data that industrial control computers cannot directly support, and forwarding it to the industrial control computer via the in-vehicle Ethernet after binding a timestamp to complete the disk write-to-disk process. Heterogeneous interface devices refer to in-vehicle sensors that use non-standard or closed physical interfaces and communication protocols. These interfaces (such as Distributed System Interface 3, DSI3) are not natively supported by commercial data acquisition cards on industrial control computers and cannot be directly connected to the industrial control computer in a conventional way. Physical wiring harnesses refer to the physical wires connecting the signal output pins of the sensor to the corresponding input pins of the domain controller. Native terminal blocks refer to physical connector pins reserved on the domain controller hardware PCB (Printed Circuit Board) for specific sensor interfaces. They are directly driven by the domain controller chipset and do not require additional protocol conversion bridge chips.

[0053] When implementing this step in the domain controller's intelligent agent forwarding and routing mode, firstly, the output signal harnesses of heterogeneous interface sensors (such as ultrasonic radars using DSI3 interfaces) that are not directly compatible with the industrial control computer are connected to the native terminals on the domain controller according to their pin definitions, ensuring that the signal path does not pass through any third-party adapter cards. Then, at the domain controller's operating system level, the corresponding native device drivers are loaded, enabling the domain controller to recognize and correctly parse the raw data frames from these heterogeneous interfaces. Next, a dedicated agent service process is started within the domain controller, which registers itself as the handler for hardware interrupts of these heterogeneous interface devices via system calls. Finally, the IP forwarding and routing functions in the domain controller's network protocol stack are enabled through software configuration, and data flow forwarding rules are set, specifying which network interface should be forwarded to the industrial control computer after receiving data from the heterogeneous interfaces. This logically completes the configuration of the domain controller as a data agent gateway from the sensor devices to the industrial control computer.

[0054] Step B202: Bind the data agent process to a dedicated central processing unit core within the domain controller and enable the highest real-time priority escalation mechanism to utilize the allocated dedicated computing resources to respond to hardware interrupts triggered by heterogeneous interface devices.

[0055] Specifically, a dedicated CPU core refers to binding a specific process to a designated physical core within a multi-core CPU of a domain controller through CPU affinity. This allows the process to exclusively utilize the core's computing resources, preventing preemption by other tasks and eliminating latency caused by context switching and cache misses. Real-time priority escalation refers to using the operating system's scheduling policy to elevate a designated process to the highest priority level. Specifically, it employs a first-in, first-out (FIFO) real-time scheduling policy (SCHED_FIFO) and assigns the highest priority value (e.g., 99), ensuring that the process always has priority in obtaining CPU execution rights in the ready queue. A hardware interrupt is an electrical signal sent to the CPU by an external hardware device (such as a heterogeneous interface sensor) to notify the processor of new data arrival or a specific event occurrence. Upon receiving this signal, the processor suspends the currently executing task and switches to the interrupt service routine for processing.

[0056] In implementation, the CPU affinity mask of the data agent process is first set to include only a pre-specified physical core (e.g., CPU Core 7) using process binding tools provided by the operating system (such as the `taskset` command in Linux). This ensures that all instructions and threads of the process are executed only on this core, preventing it from being scheduled to run on other cores and also preventing other processes from preempting the core's resources. Subsequently, the scheduling policy of the data agent process is set to a first-in-first-out real-time scheduling policy and given the highest priority value using real-time scheduling commands (such as `chrt -f 99`). This ensures that the data agent process always has priority over all ordinary time-sharing scheduling processes in the ready queue, guaranteeing that it will be scheduled to run immediately after an interrupt is triggered, even when the overall system load is high. After completing the above resource configuration, the data agent process uses the allocated dedicated computing power to wait for and respond to hardware interrupt signals triggered by heterogeneous interface devices with a microsecond-level response delay. Once an interrupt arrives, the process immediately reads the complete original data frame from the driver layer buffer, ensuring that no data loss or response timeout occurs even under the most demanding load conditions.

[0057] Step B203: When responding to a hardware interrupt, extract the current timestamp of the time base and bind the current timestamp to the corresponding raw data to generate raw data carrying the timestamp.

[0058] Specifically, the current timestamp refers to the moment when the data agent process responds to a hardware interrupt triggered by a heterogeneous interface device, read from the underlying system clock of the domain controller, which is aligned with the vehicle's time base. This timestamp is accurate to the microsecond level and is used to identify the exact time when the raw data arrived at the interrupt site. Binding refers to combining the read current timestamp with the corresponding raw data payload in the form of a specific data structure field, making the two an inseparable data unit. The raw data carrying the timestamp refers to the data frame generated after the binding operation, which contains both the raw sensor payload and its precise arrival time information.

[0059] When the data agent process responds to a hardware interrupt, the interrupt handling process is first taken over by the agent process that has obtained dedicated computing resources through core binding and real-time priority elevation. In the interrupt service routine, the process immediately calls the clock reading system interface provided by the operating system (such as the clock_gettime function, specifying a clock source of type CLOCK_REALTIME) to read the current number of seconds and nanoseconds from the domain controller system clock that is aligned with the hardware time synchronization box at the microsecond level, as the current timestamp of the data. Then, the process reads the complete raw data payload reported by the heterogeneous interface device (such as a single frame ranging message of the DSI3 ultrasonic radar) from the hardware register or ring buffer of the driver layer. The process allocates a data structure buffer in memory, fills the read current timestamp into the header timestamp field of the structure, and copies the raw data payload to the payload area after the timestamp field in the original byte order, completing the atomic binding of the timestamp and the raw data, generating raw data carrying the timestamp. This data frame will then be delivered to the network protocol stack for encapsulation and forwarding, ensuring that the timestamp remains associated with the payload in all subsequent processing stages and is not modified or stripped by any intermediate operations.

[0060] Step B204: Encapsulate the raw data carrying the timestamp into a standardized message packet, and forward the standardized message packet to the industrial control computer via the vehicle Ethernet.

[0061] In this embodiment of the application, the raw data carrying timestamps is encapsulated into standardized message packets, and the standardized message packets are forwarded to the industrial control computer via the vehicle Ethernet. This includes: encapsulating the raw data carrying timestamps into standardized message packets of the robot development framework; configuring the standardized message packets as publishing nodes; and forwarding the standardized message packets to the industrial control computer via the vehicle Ethernet.

[0062] Specifically, a standardized message refers to a network transmission data unit encapsulated according to the data serialization format and communication protocol defined by the robot development framework (i.e., the Baidu Apollo CyberRT framework). This format is structurally defined based on Protocol Buffers (Protobuf), containing a fixed message header (carrying metadata such as timestamp, message type, and data length) and a message body (carrying the original sensor payload), ensuring that the sender and receiver can serialize and deserialize according to a unified data contract. The robot development framework refers to the CyberRT communication middleware in the Baidu Apollo autonomous driving open-source platform, which provides a distributed publish / subscribe communication model that supports real-time data exchange across processes and hosts. The publisher node refers to the message publisher role in the CyberRT framework, responsible for sending specific types of messages by topic to subscribers in the network. This publisher node runs inside the domain controller, sending the encapsulated standardized message to the industrial control computer.

[0063] During implementation, after the data broker process completes timestamp binding and generates raw data carrying timestamps, it first calls the message encapsulation interface provided by the CyberRT framework to serialize the data unit according to a predefined message template (a C++ class compiled via Protobuf): the timestamp field is filled into the timestamp member of the message header, the byte stream of the raw payload is filled into the raw_data member of the message body, and the message type identifier and data length verification fields are filled in to form a complete standardized message message; then, a publisher node instance is initialized through the CyberRT framework, and the publisher node is bound to the agreed topic. The name is specified, and the underlying transport protocol is configured as UDP / IP multicast or unicast mode based on vehicle Ethernet. After node initialization, the publishing node calls the publish method to submit the encapsulated standardized message to the network sending queue of the CyberRT framework. The framework sends the message in the form of data packets to the subscriber in the network—the peer receiving process running in advance on the industrial control computer. The industrial control computer receives the message through the subscription node matching the topic name, and deserializes the Protobuf serialized data to restore the original data with timestamp, thereby completing the dual-system aligned data pass-through from the domain controller to the industrial control computer.

[0064] Figure 3 This is a schematic diagram of the underlying architecture topology for a hybrid R&D scenario involving both acquisition and testing, as shown below. Figure 3As shown, the 570D remote inertial navigation system inputs the GPRMC standard positioning message and PPS signal to the hardware time synchronization box via a serial-to-USB converter. After decoding, the synchronization box transmits the time via PTP to the industrial computer and the 8775 domain controller through the vehicle's Ethernet switch, enabling both to share a unified global time reference. Eleven ultra-high-definition cameras on the vehicle body (including two front-view, one rear-view, four side-view, and four surround-view cameras) are connected to the acquisition card via GMSL coaxial cables, and the acquisition card is connected to the industrial computer. Five millimeter-wave radars and chassis wheel pulse signals are connected to the industrial computer via a CAN bus. The main lidar OT128 and four blind-spot lidars QT128 are directly connected to the industrial computer via the vehicle's Ethernet and clock calibration is performed based on gPTP. Twelve ultrasonic radars are directly connected to the native terminals of the 8775 domain controller via physical wiring harnesses with DSI3 interfaces (not directly compatible with the industrial computer). The domain controller forwards the data to the industrial computer via the vehicle's Ethernet, achieving convergence of heterogeneous sensor data at the industrial computer. Mobile Wi-Fi connects to the industrial control computer via an Ethernet-to-USB module for data upload or remote control. This diagram visually illustrates the hardware topology of the domain controller intelligent agent forwarding routing mode in a mixed data acquisition and testing scenario. The key feature distinguishing this mode from the direct connection mode is that ultrasonic radar data is relayed to the industrial control computer via the domain controller.

[0065] In this embodiment of the application, when the target data routing mode is the edge computing network offloading routing mode, the raw data collected by each vehicle sensor is transmitted to the corresponding target computing node through the corresponding data path, including: Step B301 involves deploying edge computing nodes in the concealed compartment of the vehicle and sending a time base to the edge computing nodes via an in-vehicle Ethernet switch to synchronize and calibrate the clocks of the edge computing nodes.

[0066] Specifically, edge computing nodes refer to micro-computing devices that replace industrial control computers in concealed roadshow demonstration scenarios, performing specific communication and protocol parsing tasks. These devices are small in size and low in noise, and can be deployed in concealed spaces such as the trunk partition of a vehicle. They are responsible for receiving time references, parsing serial port data from satellite positioning units, and forwarding standardized positioning information to the domain controller. Concealed vehicle partitions refer to hidden areas inside the vehicle that do not affect the exterior and have sufficient space to accommodate small electronic devices, such as the side wall of the trunk, under the seats, or next to the spare tire compartment, used to house edge computing nodes. In-vehicle Ethernet switches are network switching devices inside the vehicle used to connect multiple in-vehicle Ethernet devices, responsible for forwarding Ethernet data frames between various computing nodes and sensors. The time reference refers to a globally unified rigid clock reference system established by purely hardware decoding of the standard positioning messages and physical second pulse signals output by the GPS satellite positioning unit through a hardware time synchronization box, and then synchronized with the entire network via PTP. Synchronization calibration refers to forcibly aligning the local system clock of the edge computing node with the master clock of the hardware time synchronization box through a precise time protocol handshake process, keeping the time error between the two within the microsecond range.

[0067] During deployment and calibration, the edge computing node is first physically placed inside a concealed compartment of the vehicle, ensuring it does not occupy passenger space or affect the vehicle's appearance. Its network interface is connected to an unused port of the in-vehicle Ethernet switch via a shielded twisted-pair Ethernet cable, enabling it to access the vehicle's Ethernet network. In the edge computing node's operating system configuration file, the Precision Time Protocol (PTP) client service is enabled, and the IP address of the hardware time synchronization box is configured as the target address of the PTP master clock. After power-on, the edge computing node's PTP client process periodically sends synchronization requests to the PTP message stream broadcast by the in-vehicle Ethernet switch, exchanging messages with the hardware time synchronization box in multiple rounds. Hardware timestamps are used to assist in calculating network transmission delay and clock deviation, continuously adjusting the frequency and phase of the local system clock until it is aligned with the global master clock of the hardware time synchronization box within a microsecond-level error range. After calibration, the edge computing node maintains a continuously running PTP daemon process, periodically receiving synchronization messages to compensate for crystal oscillator drift, ensuring that the local clock remains anchored to the global time reference during long-term operation after calibration.

[0068] Step B302: Receive the raw serial byte stream data output by the satellite positioning unit through the edge computing node, and perform hard parsing of the raw serial byte stream data using the serial protocol through a dedicated system process within the edge computing node to obtain standardized positioning data.

[0069] Specifically, the satellite positioning unit refers to the RTK receiver installed on the vehicle roof, used to receive signals from the Global Navigation Satellite System and output high-precision positioning data. In this scenario, the Daoyuan 570D model is specifically used. The raw serial byte stream data refers to the unparsed binary byte sequence continuously output by the satellite positioning unit through the serial communication interface. Its content follows the NMEA 0183 protocol format and includes positioning information fields such as the GPRMC standard positioning message. The dedicated system process refers to the background daemon process created within the edge computing node specifically for receiving and parsing serial port data. This process runs independently, is not interfered with by other applications, and is isolated from other general services within the edge computing node. Serial port protocol hard parsing refers to identifying the frame header, frame trailer, checksum, and data fields from the raw byte stream according to the physical layer timing and data link layer frame format of serial communication, extracting structured information such as latitude and longitude, speed, heading, and UTC (Coordinated Universal Time) time from the positioning message, without the assistance of any intermediate protocol stack or application layer conversion tools. Standardized location data refers to the formatted result of reorganizing the parsed location information according to a unified data structure field, which is then used for subsequent encapsulation into Ethernet packets.

[0070] During implementation, the edge computing node establishes a point-to-point hardware connection with the satellite positioning unit via a physical serial cable (connected to the edge computing node's universal serial bus port via a serial-to-universal-bus adapter). The satellite positioning unit continuously outputs raw byte stream data of the GPRMC standard positioning message via serial port. The edge computing node's operating system recognizes this universal serial bus port as a virtual serial device and creates a character device node. The dedicated system process opens this character device node during initialization, registers asynchronous input / output (Asynchronous I / O) or polling event listeners, and continuously reads the raw byte stream from the device node's receive buffer. After receiving each batch of bytes, the dedicated system process processes the data according to NMEA... The 0183 protocol standard performs a byte-by-byte scan to locate the $GPRMC message start identifier. Then, it extracts key parameters such as UTC time, positioning status, latitude, longitude, ground velocity, and heading angle from subsequent fields, separated by commas. A checksum field is then XORed to verify message integrity. After successful verification, the dedicated system process reorganizes the extracted field values ​​into a standardized positioning data record containing time, longitude, latitude, velocity, and heading fields according to a predefined internal data structure. This record is temporarily stored in a circular buffer maintained within the process, awaiting retrieval in the next step. This dedicated system process exclusively uses the serial port device resources throughout its operation, without sharing them with other processes, ensuring that the parsing process is not interfered with by other tasks on the edge computing node.

[0071] Step B303: Encapsulate the standardized positioning data into a standard Ethernet packet and transmit the standard Ethernet packet to the domain controller in real time via the vehicle Ethernet.

[0072] Specifically, standardized positioning data refers to a formatted positioning record created by the edge computing node's dedicated system process after completing hard parsing of the serial port protocol. This process extracts key fields such as UTC time, latitude and longitude, speed, and heading angle, and reorganizes them according to a predefined internal data structure. Standard Ethernet packets refer to network layer data units encapsulated according to the IEEE 802.3 standard. In this step, it specifically refers to data packets built on the UDP / IP protocol stack, including Ethernet frame headers, IP headers, UDP headers, and the application layer payload (i.e., the serialized byte stream of standardized positioning data). In-vehicle Ethernet refers to high-speed in-vehicle network communication technology based on standard Ethernet physical layer and link layer protocols, used to support high-bandwidth, low-latency transmission of sensor data within the vehicle. The domain controller refers to an in-vehicle central computing unit integrating high-performance heterogeneous computing chips (such as the Qualcomm Snapdragon 8775 or 8255 platform), running a real-time operating system (such as QNX), responsible for executing core algorithms for autonomous driving perception, decision-making, and control. In this scenario, it serves as the final receiver and display end for standardized positioning data.

[0073] During implementation, after the dedicated system process of the edge computing node completes the hard parsing of the serial port protocol and obtains standardized positioning data, it first calls the socket programming interface provided by the operating system. The API creates a User Datagram Protocol (UDP) network socket, sets the destination IP address to the domain controller's IP address in the vehicle Ethernet, and sets the destination port number to a pre-agreed receiving port. Then, it encodes the standardized location data into a byte stream payload using a protocol buffer or similar lightweight serialization method. This payload is then filled into the data area of ​​the UDP packet, and a UDP header (containing the source and destination ports) and an Internet Protocol header (containing the source and destination IPs) are added sequentially. The kernel network protocol stack encapsulates this into an Ethernet frame and sends it through the vehicle Ethernet physical layer interface of the edge computing node. The Ethernet frame is forwarded at Layer 2 by the vehicle Ethernet switch. Based on the destination MAC address table or broadcast domain rules, the frame is sent from the switch port connected to the domain controller. A pre-running receiving daemon on the domain controller continuously listens to this agreed port. Upon receiving the UDP packet, it deserializes and decodes the payload to restore the fields of the standardized location data, which are then directly used for displaying location information on the demo interface. The entire transmission process is completed within sub-millisecond latency, and the domain controller does not need to participate in any underlying serial communication or protocol parsing operations.

[0074] Figure 4 This is a schematic diagram of the edge computing network offloading architecture topology for covert roadshow demonstration scenarios, such as... Figure 4As shown, the Daoyuan 570D (equipped with a concealed small antenna) outputs RTK positioning data to the Mini PC (edge ​​computing node) via a serial-to-USB converter. Simultaneously, it outputs the GPRMC and PPS signals to the hardware time synchronization box via the Ethernet port. After decoding, the time synchronization box sends a global time reference to the Mini PC via PTP through the Ethernet port, aligning the Mini PC's local clock with the time reference. The vehicle's 11 ultra-high-definition cameras (including 2 front-view, 1 rear-view, 4 side-view, and 4 surround-view cameras) are directly connected to the Mini PC via GMSL coaxial cables. Five millimeter-wave radars, twelve ultrasonic radars, and chassis wheel pulse signals are all connected to the 8775 domain controller (vehicle infotainment system) via the CAN bus. The 8775 domain controller receives the parsed standardized positioning data from the Mini PC via the vehicle Ethernet for displaying positioning information on the demonstration interface. This architecture completely eliminates the industrial control computer; the tiny Mini PC independently handles the relay tasks of serial protocol parsing and PTP time synchronization, and the domain controller does not participate in any low-level serial communication processing. This diagram visually illustrates the core topology and signal flow of the edge computing offloading routing mode in a concealed roadshow demonstration scenario.

[0075] In this embodiment of the application, before selecting the target data routing mode from the preset data routing modes according to the vehicle application scenario, such as Figure 5 As shown, the method also includes: Step S201: Receive the standard positioning message and physical second pulse signal output by the satellite positioning unit.

[0076] In this embodiment, the satellite positioning unit refers to a GNSS receiver mounted on the vehicle roof, specifically employing RTK technology, capable of receiving satellite signals and outputting high-precision positioning and timing information. The standard positioning message refers to the recommended positioning information message (i.e., GPRMC message) output by the satellite positioning unit according to the NMEA 0183 protocol format, containing positioning data such as UTC time, latitude and longitude, ground velocity, and heading angle. The physical second pulse signal refers to a nanosecond-level precision square wave pulse signal synchronously output by the satellite positioning unit, generating one rising edge per second. This rising edge is strictly aligned with the integer second of the GPS satellite system, serving as a hardware-level time synchronization reference source.

[0077] During reception, the satellite positioning unit outputs a physical second pulse signal line separately via a coaxial cable, and simultaneously outputs the serial byte stream of the GPRMC standard positioning message via a serial data line. These two signals are each connected to the corresponding input ports of the hardware time synchronization box via independent physical cables—the physical second pulse signal is connected to the dedicated pulse capture input pin of the synchronization box, and the GPRMC serial data is connected to the universal asynchronous receiver / transmitter (UART) receiving pin of the synchronization box. After the satellite positioning unit powers on and completes satellite locking, it continuously outputs GPRMC message frames at a frequency of 1 Hz, and simultaneously outputs a physical second pulse rising edge with a pulse width of tens of microseconds at every whole second. The signal conditioning circuit inside the hardware time synchronization box performs level conversion and shaping filtering on the physical second pulse signal before sending it to the global clock pin of the field-programmable gate array. At the same time, it performs start bit detection and byte sampling on the GPRMC serial bit stream of the UART receiver, establishing a hardware-level association between the received standard positioning message and the physical second pulse signal, providing the raw input for subsequent decoding steps.

[0078] Step S202: Decode the standard positioning message and physical second pulse signal using a hardware time synchronization box to obtain the key time signal.

[0079] In this embodiment, the hardware time synchronization box refers to a dedicated hardware device independently located outside all on-board computing nodes. Its core is an FPGA chip, which does not run any general-purpose operating system; all logical functions are directly implemented by hardware circuitry. Decoding refers to using the pure hardware logic circuitry within the FPGA to parse the input GPRMC serial message and physical second pulse signal, extracting the hour, minute, and second fields of UTC time from the message, and obtaining the precise time of the integer second boundary from the rising edge of the physical second pulse. These two are combined to generate a high-precision time reference signal. The key time signal refers to the unified time reference signal obtained after decoding, containing the current UTC date and time information and the precise integer second trigger edge. This signal exists within the FPGA in the form of hardware logic levels, serving as the sole clock source for subsequent network-wide time synchronization.

[0080] During decoding, the FPGA of the hardware time synchronization box is configured with two parallel processing modules: On the one hand, the UART receiving module continuously samples the GPRMC serial bit stream sent by the satellite positioning unit, parses it byte by byte according to the NMEA 0183 protocol, and after detecting the $GPRMC start identifier, extracts the hour, minute, second and date information of UTC time from the comma-separated fields, and latches these time fields into the registers inside the FPGA; on the other hand, the pulse capture module performs edge detection on the rising edge of the physical second pulse signal. When a valid rising edge is detected, an internal hardware latch signal is triggered, and the UTC time field already latched in the current register is combined with the sub-second phase information at the time of the rising edge into a complete key time signal. Since the entire decoding process is completed by the FPGA hardware logic gate circuits without any software interrupts or operating system scheduling, the delay from the arrival of the physical second pulse rising edge to the completion of the key time signal latching is controlled within a few microseconds and is highly deterministic, completely avoiding the timestamp jitter caused by CPU load fluctuations in traditional software decoding methods.

[0081] Step S203: Construct time synchronization messages and time synchronization alignment messages based on key time signals, and configure the hardware time synchronization box as the absolute master clock node of the whole vehicle time synchronization protocol.

[0082] In this embodiment, the time synchronization message refers to the time synchronization data packet containing the absolute time value of the current master clock, generated by the hardware time synchronization box in PTP format, used to announce the current reference time to the slave clock nodes in the network. The time synchronization alignment message refers to the Sync message and Follow_Up message in the Precision Time Protocol. These messages carry hardware timestamps and are used to perform deviation measurement and delay calculation between the master and slave clocks. The absolute master clock node refers to the master clock device at the highest level in the Precision Time Protocol network. All other clock devices in the entire network are synchronized directly or indirectly with the clock of this node as a reference. Its clock is considered the unique and final time reference source for the entire network, and there is no higher-level clock reference than this node throughout the entire vehicle.

[0083] During construction and configuration, after capturing and latching the edge of the physical second pulse signal and the key time signal, the FPGA starts a precision time protocol hardware protocol stack engine. This engine initializes the internal 1588 reference clock counter based on the latched UTC date and time value. The counter accumulates using the rising edge of the physical second pulse as the trigger source, and is driven by a sub-microsecond frequency division pulse provided by an onboard high-precision temperature-compensated crystal oscillator (TCXO), so that the counter's beat is rigidly bound to the absolute time of the GNSS satellite system. Subsequently, the precision time protocol engine periodically constructs precision time protocol synchronization messages and follow messages according to the IEEE 1588v2 protocol standard, filling the current 1588 reference clock count value into the precise timestamp field of the message. At the same time, the precision time protocol clock level of the hardware time synchronization box is set to 0 (highest priority) through software or hardware configuration registers, and the clock identifier is set to a predefined unique value, completing the role setting of the absolute master clock node, so that the synchronization box declares itself as the only top-level clock source in the entire vehicle in the network.

[0084] Step S204: Time notification messages and time synchronization alignment messages are sent to each heterogeneous computing node in the vehicle through the vehicle Ethernet switch to align the underlying system clock of each heterogeneous computing node with the key time signal to obtain a time reference.

[0085] In this embodiment, the in-vehicle Ethernet switch refers to a network switching device inside a vehicle used to connect multiple in-vehicle Ethernet devices. It possesses a Precision Time Protocol (PTP) transparent clock or boundary clock function, capable of correcting latency caused by packets residing within the switch when forwarding PTP packets. Heterogeneous computing nodes refer to a collection of computing devices running different types of operating systems and different processor architectures within the vehicle, including but not limited to industrial control computers running Ubuntu under x86 architecture, domain controllers running QNX real-time operating systems under ARM architecture, and edge computing nodes based on x86 or ARM architectures. The underlying system clock refers to a CLOCK_REALTIME type system time counter maintained in the kernel of each computing node's operating system. This counter is driven by a local crystal oscillator on the node's hardware platform and can be calibrated by an external PTP timing service. The time reference refers to the fact that, after full network synchronization via the PTP, the underlying system clocks of all heterogeneous computing nodes maintain the same time value within a microsecond-level error range with the absolute master clock of the hardware time synchronization box. This time value exhibits deterministic and monotonically consistent behavior throughout the entire vehicle.

[0086] During transmission and calibration, the hardware time synchronization box's precision time protocol engine sends synchronization and follow-up messages to the precision time protocol multicast MAC address of the vehicle-mounted Ethernet switch at a preset fixed period (usually once or multiple times per second). After the messages undergo dwell time correction via the switch's precision time protocol transparent clock function, they are forwarded to all active ports of the switch. When the network interface cards (NICs) of industrial control computers, domain controllers, and edge computing nodes connected to each port of the switch receive these precision time protocol messages at the physical layer, their NIC chips that support hardware timestamps record a local hardware timestamp the instant the message arrives. When the precision time protocol client daemon of each node receives the synchronization and follow-up messages in user space, it combines the hardware arrival timestamp recorded by the NIC. The local clock's frequency offset and phase deviation relative to the absolute master clock are calculated using the delay calculation and clock skew correction algorithm defined by the precision time protocol (including the exchange of delay request Delay_Req / delay response Delay_Resp messages). Then, the frequency and phase of the local CLOCK_REALTIME system clock are gradually adjusted to be consistent with the absolute master clock through the clock adjustment system call provided by the operating system. After multiple rounds of message exchange and adjustment, the underlying system clocks of each heterogeneous computing node are forced to be leveled to within an error range of no more than 1 microsecond from the reference time of the hardware time synchronization box, thereby establishing a globally rigid time reference for subsequent data stamping throughout the vehicle.

[0087] In this embodiment of the application, the method further includes: independently extracting the physical second pulse signal and connecting it to the hardware trigger interface of the image acquisition unit acquisition card; triggering the image acquisition unit acquisition card to control the exposure acquisition action of the image acquisition unit through the physical second pulse signal, so as to achieve hardware-level time alignment between the exposure acquisition action of the image acquisition unit and the physical second pulse signal.

[0088] Specifically, the physical second pulse signal refers to a square wave pulse signal with nanosecond-level precision output by the satellite positioning unit. It generates one rising edge per second, which is strictly aligned with the integer second of the GNSS signal and can be used as a hardware-level trigger source. The image acquisition unit card is a dedicated video capture card installed inside an industrial control computer to receive image data from multiple ultra-high-definition cameras. This card typically has an external hardware trigger input interface, which can receive external level signals and control the camera's exposure start time accordingly. The hardware trigger interface is a dedicated input pin provided on the acquisition card, used to receive external physical level signals and directly trigger the internal hardware logic of the acquisition card to execute exposure control commands. The image acquisition unit refers to the ultra-high-definition camera mounted on a vehicle, used to acquire visual image data of the vehicle's surrounding environment. The exposure acquisition action refers to the complete process of the camera activating image sensor charge accumulation and completing the readout of one frame of image. The start time of this action directly determines the time phase corresponding to that frame of image. Hardware-level time alignment refers to directly driving the sensor's action through physical electrical signals, so that the exposure start time of image acquisition is strictly synchronized with the external reference time base (the rising edge of the physical second pulse) at the hardware level. The error is only limited by the circuit transmission delay, completely avoiding random jitter caused by software operating system scheduling and central processing unit load fluctuations.

[0089] In implementation, the hardware time synchronization box (with a built-in Field-Programmable Gate Array (FPGA) decodes the physical second pulse signal from the satellite positioning unit. Then, it outputs this signal via a dedicated coaxial cable from its dedicated output pin and directly connects it to the external hardware trigger input interface of the video capture card within the industrial control computer. During initialization, the video capture card is configured to "external trigger mode" via its driver program. This means that the camera's exposure start time is no longer determined by the internal free oscillator or software commands, but by the external rising edge signal detected on the hardware trigger interface. When the hardware time synchronization box emits a physical second pulse rising edge at each full second, this rising edge is transmitted via the coaxial cable to the trigger input pin of the capture card. The edge detection hardware circuit inside the capture card then... Within nanoseconds, a valid rising edge is identified, and an exposure start pulse is generated through onboard logic. This pulse is then sent to the remote image acquisition unit via a GMSL coaxial cable, triggering its image sensor to immediately begin charge accumulation. Since the entire triggering link, from the generation of the physical second pulse to the camera exposure start, is completed entirely by hardware circuitry without any central processing unit interrupts or operating system scheduling, the deviation between the exposure start time of each frame and the rising edge of the physical second pulse is locked within a few microseconds. This deviation is constant and measurable, achieving hardware-level rigid alignment between the image acquisition action and the global time reference. This completely avoids the problem of the video capture card failing to stamp in time due to high load on the industrial control computer, causing it to revert to the default time value.

[0090] In this embodiment of the application, the method further includes: configuring an industrial control computer as a relay timing node for the lidar; and sending a time synchronization and alignment signal to the lidar device through the industrial control computer based on a universal precise time synchronization protocol and time reference, thereby completing the clock calibration of the lidar device.

[0091] Specifically, a relay time synchronization node refers to an industrial control computer (ICC) acting as a slave clock in a PTP network. After receiving the global time reference from the hardware time synchronization box, the ICC uses itself as its clock source to forward time synchronization information to downstream LiDAR devices. In other words, the ICC simultaneously possesses the dual identity of a PTP slave clock and a master clock for the Generalized Precision Time Protocol (gPTP, IEEE 802.1AS standard). gPTP is an Ethernet-based time synchronization protocol defined by the IEEE 802.1AS standard. It is a simplified adaptation of the precision time protocol for automotive networks, specifically designed for Audio Video Bridging (AVB) and Time-Sensitive Networking (TSN) environments, achieving microsecond-level synchronization accuracy through hardware timestamps. Time synchronization refers to the master clock device periodically sending synchronization messages containing the current absolute time value to the slave clock device. Synchronization alignment signals refer to follow-up messages containing precise transmission timestamps and delay request / delay response messages used to measure link latency. These are used to calculate and calibrate the deviation between the local clock and the master clock from the clock device. Clock calibration refers to the process by which the LiDAR adjusts the frequency and phase of its internal clock using the gPTP protocol stack based on the received timing and synchronization alignment signals. This aligns the LiDAR with the global time reference anchored by the industrial control computer, ensuring that each frame of point cloud data output by the LiDAR carries a time stamp consistent with the global reference.

[0092] During implementation, the industrial control computer (ICC) synchronizes its underlying system clock with the absolute master clock of the hardware time synchronization box at the microsecond level through a precision time protocol handshake process (step S204). Subsequently, a Universal Precision Time Synchronization Protocol (gPTP) master clock service process is started within the ICC's operating system. This process configures the ICC's network interface card to support hardware timestamp mode and follows the IEEE standard. The 802.1AS standard periodically sends gPTP synchronization (Sync) and follow-up (Follow_Up) messages to the directly connected LiDAR device via the vehicle Ethernet. These messages carry the precise transmission time value read from the industrial control computer's underlying system clock. The LiDAR device integrates a gPTP slave clock protocol stack. Its network interface card (NIC) automatically records a hardware local arrival timestamp upon receiving the Sync message at the physical layer. Upon receiving the Follow_Up message in user space, it extracts the master clock's transmission timestamp and calculates the clock deviation between itself and the industrial control computer using the local arrival timestamp. Through multiple rounds of Sync / Follow_Up message exchanges and delay request / delay response message exchanges, the LiDAR continuously adjusts the frequency and phase of its internal clock oscillator until the error between its local time and the global time reference anchored by the industrial control computer converges to within the microsecond range. After calibration, the LiDAR uses the calibrated local clock to timestamp the point cloud data frame generated in each subsequent scan, ensuring that the LiDAR point cloud data shares the same rigid time reference with data from other sensors throughout the vehicle.

[0093] In the embodiments of this application, such as Figure 6 As shown, the method also includes: Step S301: Through the clock status monitoring mechanism embedded in the domain controller, the heartbeat signal of the main time synchronization link, the status of the hardware time synchronization box, and the satellite positioning signal are monitored in real time.

[0094] In this embodiment, the clock status monitoring mechanism refers to a dedicated software guardian module deployed in the underlying operating system kernel of the domain controller. This module continuously monitors the status variables of the main timing link and periodically checks the working status of the hardware time synchronization box and the signal quality of the satellite positioning unit. The main timing link refers to the complete communication channel through which the hardware time synchronization box sends PTP timing messages and synchronization alignment messages to various heterogeneous computing nodes via an onboard Ethernet switch. The heartbeat signal refers to the periodic liveness status message sent by the hardware time synchronization box to the domain controller at fixed time intervals (usually once per second or shorter), indicating that it is working normally and the main clock source remains valid. The hardware time synchronization box status refers to operating parameters such as whether the device is online, whether the internal field-programmable gate array is working properly, and whether the number of locked satellites meets the timing accuracy requirements. The satellite positioning signal refers to the navigation, positioning, and timing signals sent by GPS satellites and received by the rooftop RTK receiver, including standard positioning messages (GPRMC) and PPS signals.

[0095] During monitoring, the domain controller's underlying clock status monitoring mechanism runs as a resident kernel thread. This thread executes a check loop every preset short period (e.g., every 100 milliseconds). In each check, the thread obtains the most recent arrival timestamp of the heartbeat signal by reading a shared memory variable continuously updated by the hardware time synchronization box daemon. It subtracts the current system clock time from this timestamp. If the difference exceeds a preset tolerance threshold (e.g., if no heartbeat is received for three consecutive cycles, it is considered an interrupt), a heartbeat loss event is recorded. Simultaneously, the thread reads the status register of the serial port device connected to the satellite positioning unit through system calls, checking the received frame rate of GPRMC messages and whether the rising edge of the physical second pulse signal is continuously present. If no valid GPRMC message is received for several consecutive seconds or the rising edge of the physical second pulse disappears, the satellite positioning signal is considered lost. This monitoring thread writes all monitoring results to a kernel-level status flag area in real time, which is read by the decision logic in an atomic operation manner, ensuring that the delay from the occurrence of an anomaly to its detection does not exceed several hundred milliseconds.

[0096] Step S302: When the satellite positioning signal is lost and / or the hardware time synchronization box is offline and / or the heartbeat signal of the main time synchronization link is interrupted, the clock degradation disaster recovery rollback mechanism is triggered.

[0097] In this embodiment, the clock degradation disaster recovery rollback mechanism refers to a pre-set emergency handling process in which the system automatically switches from a timing mode relying on external satellite positioning signals to a backup timing mode relying on the vehicle's local clock source when an unrecoverable failure occurs in the primary timing link. This process includes three consecutive actions: fault confirmation, clock source switching, and role upgrade. The triggering conditions include three abnormal situations: loss of satellite positioning signals (i.e., continuous missing GPRMC messages or the disappearance of the rising edge of the physical second pulse for more than a preset number of seconds), hardware time synchronization box status failure (i.e., the synchronization box no longer responds to network requests or the FPGA's internal phase-locked loop loses lock), and interruption of the heartbeat signal of the primary timing link (i.e., the domain controller does not receive any liveness status messages from the hardware time synchronization box within a preset tolerance timeout window).

[0098] During triggering, the clock status monitoring mechanism maintains three independent fault counters in each check cycle, corresponding to three anomaly types: satellite positioning signal loss, hardware time synchronization box status failure, and main time synchronization link heartbeat interruption. When any counter continuously accumulates to a preset trigger threshold within consecutive check cycles (e.g., continuous anomaly for 3 seconds), the monitoring mechanism determines it as a valid fault and asserts a global degradation trigger flag. Simultaneously, the monitoring mechanism performs a final status confirmation—reading the physical liveness level of the hardware time synchronization box through an independent hardware watchdog input pin. If this level is also invalid, the main time synchronization link is finally confirmed to be interrupted. After confirmation, the monitoring mechanism immediately sends a software interrupt signal to the interrupt management subsystem of the domain controller kernel, waking up the high-priority kernel thread responsible for clock disaster recovery switching. This thread then takes over control of the subsequent degradation process and begins the clock source re-anchoring operation. The entire time window from anomaly detection to triggering degradation is strictly controlled within 1 second to avoid time base jumps or loss in subsequent data acquisition due to excessive waiting.

[0099] Step S303: Through the clock degradation disaster recovery rollback mechanism, the backup satellite positioning chip and temperature-compensated crystal oscillator built into the domain controller motherboard are called. Based on the backup satellite positioning chip and temperature-compensated crystal oscillator, a backup physical second pulse signal is generated to re-anchor the clock source in the vehicle to the backup physical second pulse signal.

[0100] In this embodiment, the backup satellite positioning chip refers to an independent automotive-grade GNSS receiver chip standardly equipped on the domain controller motherboard. This chip does not rely on an external rooftop RTK antenna but receives satellite signals through an onboard patch antenna on the motherboard. It can still provide basic positioning and timing information when the main RTK receiver fails. Its accuracy is lower than RTK but it can serve as an emergency backup. A temperature-compensated crystal oscillator (TCXO) is a crystal oscillator with a built-in temperature compensation circuit, capable of maintaining high frequency stability over a wide temperature range. It is used to maintain accurate local clock timing within a short window after satellite signal loss. The backup physical second pulse signal refers to the local physical second pulse output generated jointly by the backup satellite positioning chip and the temperature-compensated crystal oscillator. The rising edge of this pulse is aligned with the integer second calculated by the onboard GNSS chip. Although its accuracy is lower than the main RTK physical second pulse, it can meet the basic time anchoring requirements in degraded conditions.

[0101] During the re-anchoring process, the high-priority kernel thread awakened after the degradation is triggered first performs clock source switching preparation operations: It closes the port in the domain controller's network protocol stack that was originally listening to hardware time synchronization and precision time protocol messages, while simultaneously enabling the power and clock outputs of the backup satellite positioning chip and temperature-compensated crystal oscillator on the domain controller's motherboard. After the backup satellite positioning chip powers on, it begins searching for and locking onto visible satellites. Upon successful locking, it outputs a local physical second pulse signal to the general purpose input / output (GPIO) pin of the domain controller's main chip, and simultaneously outputs a signal through the internal integrated circuit (I2C) bus or serial peripheral interface (SPI). The interface bus outputs the current UTC time; a dedicated interrupt handler in the domain controller kernel reads the current UTC time and calculates a new local reference time by combining it with the high-frequency counter value of the temperature-compensated crystal oscillator at each rising edge of the local physical second pulse. The underlying CLOCK_REALTIME system clock of the operating system is gradually adjusted and locked to this time. After latching, the domain controller abandons the time following of the original hardware time synchronization box master clock and re-anchors its own clock source to the guaranteed physical second pulse signal to ensure that even if the master time synchronization link fails completely, the domain controller's local clock can still maintain monotonically increasing and without time jumps.

[0102] Step S304: Configure the domain controller as the proxy master clock node for the vehicle-wide time synchronization protocol. The proxy master clock node sends time synchronization messages and time synchronization alignment messages to each network node in the vehicle in reverse to maintain the continuity of the time base.

[0103] In this embodiment, a proxy master clock node refers to a node in a precision time protocol network that originally received time from an external master clock device. After a failure of the primary time synchronization link, it is configured to assume the role of a temporary master clock, providing time synchronization services to other downstream network nodes. The domain controller assumes this role after a fallback disaster recovery. Reverse time distribution refers to the operation opposite to the normal time synchronization direction—originally, all nodes received time from the hardware time synchronizer and master clock; now, the domain controller, acting as a proxy master clock, sends the locally anchored time signal to other nodes, including industrial control computers and edge computing nodes, through the network, ensuring the entire network maintains a unified time reference even after losing its original clock source.

[0104] During reverse clock transmission, after the domain controller completes clock source anchoring, its internal Precision Time Protocol (PTP) service process switches from slave clock mode to master clock mode. This process starts a PTP master clock engine, using the locally anchored system clock as the reference clock source, and follows the IEEE standard. The 1588v2 protocol standard periodically constructs synchronization and follow-up messages, encapsulates them into UDP / IP packets, and sends them to the vehicle Ethernet switch via the domain controller's vehicle Ethernet interface. The switch then broadcasts the messages to all connected ports. When the precision time protocol client processes on the industrial control computer and edge computing nodes detect the disappearance of the original hardware time synchronization box's master clock, they automatically re-initiate the master clock discovery process. During this process, they identify the proxy master clock identity declared by the domain controller, switch the subscription target, and begin receiving the time messages sent by the domain controller and performing clock calibration. After several rounds of message exchange, the underlying system clocks of the industrial control computer and edge computing nodes are re-aligned with the domain controller's local anchor time. The entire network's time reference is thus continuously maintained even without external satellite signals and the original synchronization box. This ensures that the data collected by vehicles in scenarios where satellite signals are lost, such as long tunnels, still has a unified time scale, avoiding data becoming invalid frames due to clock splitting.

[0105] This embodiment also provides an in-vehicle data acquisition device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0106] This embodiment provides a vehicle-mounted data acquisition device, such as... Figure 7 As shown, it includes: The selection module 701 is used to select a target data routing mode from preset data routing modes according to the vehicle application scenario; The transmission module 702 is used to transmit the raw data collected by each vehicle sensor to the corresponding target computing node through the corresponding data path in the target data routing mode. The generation module 703 is used to add timestamps to the original data at the target computing node based on a pre-established time base, thereby generating time-stamped synchronization data.

[0107] In this embodiment, the device further includes: a receiving module, used to receive standard positioning messages and physical second pulse signals output by a satellite positioning unit; decode the standard positioning messages and physical second pulse signals through a hardware time synchronization box to obtain a key time signal; construct a time synchronization message and a time synchronization alignment message based on the key time signal, and configure the hardware time synchronization box as the absolute master clock node of the vehicle-wide time synchronization protocol; send the time synchronization message and the time synchronization alignment message to each heterogeneous computing node in the vehicle through an in-vehicle Ethernet switch to align the underlying system clock of each heterogeneous computing node with the key time signal to obtain a time reference.

[0108] In this application embodiment, the preset data routing mode includes at least one of the following: full high-speed direct connection routing mode, domain controller intelligent agent forwarding routing mode, and edge computing network offloading routing mode; In this embodiment, module 701 is specifically used to select the full-volume high-speed direct connection routing mode as the target data routing mode when the vehicle application scenario is a dedicated data acquisition scenario, wherein the dedicated data acquisition scenario is a data acquisition condition that does not require real-time processing of the raw data collected by the vehicle sensors and only requires raw data to be stored on disk; when the vehicle application scenario is a mixed acquisition and testing R&D scenario, the domain controller intelligent agent forwarding routing mode is selected as the target data routing mode, wherein the mixed acquisition and testing R&D scenario is a R&D and testing condition that requires the domain controller to connect to the raw data collected by the vehicle sensors to verify the vehicle perception algorithm; when the vehicle application scenario is a covert roadshow demonstration scenario, the edge computing network offloading routing mode is selected as the target data routing mode, wherein the covert roadshow demonstration scenario is a public demonstration condition that requires reducing the exposure of external hardware and ensuring that the core computing power of the domain controller is not interfered with by communication load.

[0109] In this embodiment, the transmission module 702 is specifically used to transmit the positioning data collected by the satellite positioning unit to the industrial control computer via a direct link from a serial port to a universal serial bus when the target data routing mode is a full-volume high-speed direct connection routing mode; transmit the image data collected by the image acquisition unit to the industrial control computer via a coaxial cable; aggregate the first radar signal collected by the millimeter-wave radar, the second radar signal collected by the ultrasonic radar, and the chassis control signal collected by the vehicle chassis control unit to the controller LAN conversion card via a hard wire, and then connect them to the industrial control computer after integration by the controller LAN conversion card; and transmit the third radar signal collected by the lidar to the industrial control computer via a direct link from the vehicle Ethernet.

[0110] In this embodiment, the transmission module 702 is specifically used to configure the domain controller as an intelligent data proxy gateway when the target data routing mode is the domain controller intelligent proxy forwarding routing mode, and to connect the physical wiring harness of the heterogeneous interface devices in the vehicle sensor that are not directly compatible with the industrial control computer to the native wiring terminal of the domain controller; bind the data proxy process to the dedicated central processing unit core within the domain controller, and enable the highest real-time priority escalation mechanism to respond to hardware interrupts triggered by heterogeneous interface devices using the allocated dedicated computing resources; when responding to a hardware interrupt, extract the current timestamp of the time base, bind the current timestamp to the corresponding raw data, and generate raw data carrying the timestamp; encapsulate the raw data carrying the timestamp into a standardized message packet, and forward the standardized message packet to the industrial control computer through the vehicle Ethernet.

[0111] In this embodiment, the transmission module 702 is specifically used to encapsulate the raw data carrying timestamps into standardized message messages of the robot development framework; configure the standardized message messages as publishing nodes; and forward the standardized message messages to the industrial control computer via the vehicle Ethernet.

[0112] In this embodiment, the transmission module 702 is specifically used to deploy edge computing nodes in the concealed partition of the vehicle when the target data routing mode is edge computing network offloading routing mode, and to send the time base to the edge computing nodes through the vehicle Ethernet switch to synchronize and calibrate the clock of the edge computing nodes; to receive the serial port raw byte stream data output by the satellite positioning unit through the edge computing nodes, and to perform serial port protocol hard parsing on the serial port raw byte stream data through the dedicated system process in the edge computing nodes to obtain standardized positioning data; to encapsulate the standardized positioning data into standard Ethernet packets, and to transmit the standard Ethernet packets to the domain controller in real time through the vehicle Ethernet.

[0113] In this embodiment, the device further includes: a monitoring module, used to monitor the heartbeat signal of the main timing link, the status of the hardware time synchronization box, and the satellite positioning signal in real time through a clock status monitoring mechanism embedded in the domain controller; when the satellite positioning signal is lost and / or the hardware time synchronization box is offline and / or the heartbeat signal of the main timing link is interrupted, a clock degradation disaster recovery rollback mechanism is triggered; through the clock degradation disaster recovery rollback mechanism, the backup satellite positioning chip and temperature-compensated crystal oscillator built into the domain controller motherboard are called, and a backup physical second pulse signal is generated based on the backup satellite positioning chip and temperature-compensated crystal oscillator to re-anchor the clock source in the vehicle to the backup physical second pulse signal; the domain controller is configured as the proxy master clock node of the whole vehicle time synchronization protocol, and the proxy master clock node sends time synchronization messages and time synchronization alignment messages back to each network node in the vehicle to maintain the continuity of the time base.

[0114] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 8 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0115] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0116] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.

[0117] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device as shown by a landing page for an app. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0118] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0119] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0120] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0121] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A vehicle-mounted data acquisition method, characterized in that, The method includes: Based on the vehicle application scenario, select the target data routing mode from the preset data routing modes; In the target data routing mode, the raw data collected by each vehicle sensor is transmitted to the corresponding target computing node through the corresponding data path; At the target computing node, timestamps are added to the original data based on a pre-established time reference to generate timestamped synchronized data.

2. The method according to claim 1, characterized in that, Before selecting a target data routing mode from preset data routing modes based on the vehicle application scenario, the method further includes: Receive standard positioning messages and physical second pulse signals output by the satellite positioning unit; The key time signal is obtained by decoding the standard positioning message and the physical second pulse signal using a hardware time synchronization box. Based on the key time signal, a time-giving message and a time-synchronization alignment message are constructed, and the hardware time synchronization box is configured as the absolute master clock node of the whole vehicle time synchronization protocol. The time synchronization message and the time synchronization alignment message are sent to each heterogeneous computing node in the vehicle through the vehicle Ethernet switch to align the underlying system clock of each heterogeneous computing node with the key time signal to obtain the time reference.

3. The method according to claim 1, characterized in that, The preset data routing mode includes at least one of the following: full high-speed direct connection routing mode, domain controller intelligent agent forwarding routing mode, and edge computing network offloading routing mode; The step of selecting a target data routing mode from preset data routing modes based on the vehicle application scenario includes: When the vehicle application scenario is a dedicated data acquisition scenario, the full-volume high-speed direct connection routing mode is selected as the target data routing mode. The dedicated data acquisition scenario is a data acquisition condition that does not require real-time processing of the raw data collected by the vehicle sensors and only requires raw data to be stored on disk. When the vehicle application scenario is a mixed data acquisition and testing R&D scenario, the domain controller intelligent agent forwarding routing mode is selected as the target data routing mode. The mixed data acquisition and testing R&D scenario is a R&D test condition that requires the domain controller to be connected to the raw data collected by the vehicle sensor to verify the vehicle perception algorithm. When the vehicle application scenario is a covert roadshow demonstration scenario, the edge computing network offloading routing mode is selected as the target data routing mode. The covert roadshow demonstration scenario is a public demonstration condition that requires reducing the exposure of external hardware and ensuring that the core computing power of the domain controller is not interfered with by communication load.

4. The method according to claim 3, characterized in that, When the target data routing mode is the full-volume high-speed direct connection routing mode, the step of transmitting the raw data collected by each vehicle sensor to the corresponding target computing node through the corresponding data path includes: The positioning data collected by the satellite positioning unit is transmitted to the industrial control computer through a direct link from serial port to universal serial bus; The image data acquired by the image acquisition unit is transmitted to the industrial control computer via a coaxial cable; The first radar signal collected by the millimeter-wave radar, the second radar signal collected by the ultrasonic radar, and the chassis control signal collected by the vehicle chassis control unit are converged to the controller local area network conversion card via hard wiring, and then integrated by the controller local area network conversion card and connected to the industrial control computer. The third radar signal collected by the lidar is transmitted to the industrial control computer via a direct link of the vehicle Ethernet.

5. The method according to claim 3, characterized in that, When the target data routing mode is the domain controller intelligent agent forwarding routing mode, the step of transmitting the raw data collected by each vehicle sensor to the corresponding target computing node through the corresponding data path includes: Configure the domain controller as an intelligent data proxy gateway, and connect the physical wiring harness of the heterogeneous interface devices in the vehicle sensor that are not directly compatible with the industrial control computer to the native wiring terminal of the domain controller. Within the domain controller, the data agent process is bound to a dedicated central processing unit core, and the highest real-time priority escalation mechanism is enabled to respond to hardware interrupts triggered by the heterogeneous interface device using the allocated dedicated computing resources. When the hardware interrupt is responded to, the current timestamp of the time base is extracted and the current timestamp is bound to the corresponding raw data to generate raw data carrying the timestamp; The raw data carrying the timestamp is encapsulated into a standardized message message, and the standardized message message is forwarded to the industrial control computer via the vehicle Ethernet.

6. The method according to claim 5, characterized in that, The step of encapsulating the original data carrying the timestamp into a standardized message packet and forwarding the standardized message packet to the industrial control computer via the vehicle Ethernet includes: The raw data carrying timestamps is encapsulated into standardized message messages for the robot development framework; Configure the standardized message message as a publishing node, and forward the standardized message message to the industrial control computer through the vehicle Ethernet.

7. The method according to claim 3, characterized in that, When the target data routing mode is the edge computing network offloading routing mode, the step of transmitting the raw data collected by each vehicle sensor to the corresponding target computing node through the corresponding data path includes: Edge computing nodes are deployed in the concealed compartment of the vehicle, and the time base is sent to the edge computing nodes through the vehicle Ethernet switch to synchronize and calibrate the clock of the edge computing nodes. The edge computing node receives the raw serial byte stream data output by the satellite positioning unit, and performs hard parsing of the raw serial byte stream data using the serial protocol through a dedicated system process within the edge computing node to obtain standardized positioning data. The standardized positioning data is encapsulated into standard Ethernet packets and transmitted to the domain controller in real time via the vehicle Ethernet.

8. The method according to claim 1, characterized in that, The method further includes: Through the clock status monitoring mechanism embedded in the domain controller, the heartbeat signal of the main time synchronization link, the status of the hardware time synchronization box, and the satellite positioning signal are monitored in real time. When the satellite positioning signal is lost and / or the hardware time synchronization box is offline and / or the heartbeat signal of the main time synchronization link is interrupted, the clock degradation disaster recovery rollback mechanism is triggered. Through the clock degradation disaster recovery rollback mechanism, the backup satellite positioning chip and temperature-compensated crystal oscillator built into the domain controller motherboard are invoked. Based on the backup satellite positioning chip and the temperature-compensated crystal oscillator, a backup physical second pulse signal is generated to re-anchor the clock source in the vehicle to the backup physical second pulse signal. The domain controller is configured as the proxy master clock node for the vehicle-wide time synchronization protocol. The proxy master clock node sends time synchronization messages and time synchronization alignment messages to each network node in the vehicle in reverse order to maintain the continuity of the time base.

9. A vehicle-mounted data acquisition device, characterized in that, The device includes: The selection module is used to select a target data routing mode from preset data routing modes based on the vehicle application scenario; The transmission module is used to transmit the raw data collected by each vehicle sensor to the corresponding target computing node through the corresponding data path in the target data routing mode. The generation module is used to add timestamps to the original data at the target computing node based on a pre-established time base, thereby generating timestamped synchronization data.

10. A computer device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method of any one of claims 1 to 8.

Images