Vehicle multi-source data acquisition method, device and equipment and readable storage medium

Abstract

The invention relates to the technical field of data processing, and discloses a vehicle multi-source data acquisition method, device and equipment and a readable storage medium, and the vehicle multi-source data acquisition method comprises the steps: receiving a visual perception result from a vehicle control processing unit, carrying out the analysis of the visual perception result according to a communication protocol, and carrying out the analysis of the visual perception result; obtaining a target visual perception result; packaging the target visual perception result and the key state variable to generate a message; and controlling the communication interface to periodically send the message to the vehicle-mounted communication bus. According to the method, the perceptual accuracy and the traceability of decision logic in the algorithm debugging process are remarkably improved; accurate reproduction and multi-source data linkage analysis of problem scenes are effectively supported, and the fault positioning efficiency is improved; meanwhile, a basis is provided for data recharge simulation, the reliability and consistency of simulation results are enhanced, then the algorithm iteration period is greatly shortened, and the development efficiency and stability of the intelligent driving system are improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, device and readable storage medium for acquiring multi-source data from vehicles. Background Technology

[0002] In the field of autonomous driving and advanced driver assistance systems (ADAS), intelligent driving domain controllers typically adopt a heterogeneous "SoC + MCU" architecture. The SoC processes raw data from sensors such as cameras and runs visual perception algorithms to output structured perception results such as obstacles, lane lines, and traffic signs. The MCU, based on the perceived input, executes path planning, behavior decision-making, and motion control algorithms to generate vehicle control commands. To support algorithm development and testing, existing technologies generally employ multi-source sensor data acquisition systems capable of simultaneously recording camera images, millimeter-wave radar point clouds, IMU / GPS positioning information, and vehicle CAN bus data for post-event playback and scenario reproduction. These systems are widely used in real-vehicle testing and have become indispensable data support tools in the autonomous driving R&D process.

[0003] However, current data acquisition solutions primarily focus on recording external sensors and vehicle status signals, lacking the ability to acquire key intermediate data within the domain controller, especially the visual perception results output by the SoC and internal variables (such as state machine states, risk scores, and control gains) during the operation of the MCU-side regulatory control algorithm. Since this data typically circulates only within the system and is not exposed externally, developers struggle to accurately determine whether abnormal behavior (such as false braking or lane change failure) stems from false detections or deficiencies in the regulatory control logic. Troubleshooting often relies on empirical inference or repeated trial and error, resulting in low efficiency and severely limiting algorithm iteration speed. Furthermore, during data refeeding simulations, if the actual perception input cannot be reconstructed, relying solely on the original image for re-inference may introduce uncertainties due to model version differences or environmental disturbances, reducing the simulation's realism and repeatability. Summary of the Invention

[0004] In view of this, the embodiments of this application provide a method, apparatus, device and readable storage medium for acquiring multi-source data of vehicles, which can effectively solve the problem in the prior art that it is impossible to obtain key intermediate data inside the intelligent driving domain controller, especially the problem that it is difficult to synchronously acquire visual perception results and internal variables of the control algorithm.

[0005] In a first aspect, embodiments of this application provide a method for collecting multi-source vehicle data, including: The system receives visual perception results from the vehicle control processing unit and parses the visual perception results according to a preset communication protocol to obtain the target visual perception results. The target visual perception result and key state variables are encapsulated according to a preset data format to generate a target message; wherein, the key state variables refer to the state variables generated during the algorithm execution on the processor; The control communication interface sends the target message to the vehicle communication bus according to a preset period.

[0006] In some embodiments, sending the target message to the vehicle communication bus at a preset period includes: The sending status of the target message is detected, and a retransmission operation is performed when an anomaly is detected.

[0007] In some embodiments, receiving visual perception results from a vehicle control processing unit and parsing the visual perception results according to a preset communication protocol to obtain a target visual perception result includes: Data frames containing perception result fields are periodically received from the vehicle control processing unit via a serial peripheral interface. The received data frame is parsed at the field level to extract the original visual perception results corresponding to obstacles, lane lines and traffic signs; Based on the original visual perception results, a set of data objects conforming to the preset communication protocol is generated, and the set of data objects is used as the target visual perception results.

[0008] In some embodiments, the step of encapsulating the target visual perception result and key state variables according to a preset data format to generate a target message includes: Based on the visual perception results of the target, extract the field data corresponding to obstacles, lane lines and traffic signs; Obtain the state variables generated during the algorithm execution on the processor to generate a dataset of running parameters; Based on the preset data format description file, the field data and the running parameter dataset are matched and byte-allocated to form an encapsulation mapping table; Based on the encapsulation mapping table, data reorganization and encoding are performed on each field to generate a target message that conforms to a preset data format.

[0009] In some embodiments, the control communication interface sends the target message to the vehicle communication bus at a preset period, including: Based on the target message, a corresponding sending task queue is generated, and a unique message identifier is assigned to each message to be sent; Write the target message into the transmission buffer of the communication interface in the order of the message identifiers; The sending control unit of the scheduling communication interface reads the target message from the sending buffer at a preset period; The target message is sent to the vehicle communication bus via the communication interface.

[0010] In some embodiments, the control communication interface sends the target message to the vehicle communication bus at a preset period, and further includes: Based on the type of the target message, a corresponding sending period parameter is set, and the communication interface is triggered to perform a sending operation in each sending period by a timed scheduling unit.

[0011] In some embodiments, before the control communication interface sends the target message to the vehicle communication bus at a preset period, it includes: A cycle counting unit is established based on the local clock signal built into the processor; The count value of the periodic counting unit is used as the trigger condition for sending the target message; When the triggering condition is met, the communication interface is controlled to perform a message sending operation.

[0012] Secondly, embodiments of this application provide a vehicle multi-source data acquisition device, comprising: The data processing module is used to receive the visual perception results from the vehicle control processing unit and parse the visual perception results according to a preset communication protocol to obtain the target visual perception results. An encapsulation module is used to encapsulate the target visual perception result and key state variables according to a preset data format to generate a target message; wherein, the key state variables refer to the state variables generated during the algorithm execution on the processor; The data transmission module is used to control the communication interface to send the target message to the vehicle communication bus according to a preset period.

[0013] Thirdly, embodiments of this application provide a terminal device, the terminal device including a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the vehicle multi-source data acquisition method of the first aspect described above.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium, wherein when the computer program is executed on a processor, it implements the vehicle multi-source data acquisition method of the first aspect described above.

[0015] The embodiments of this application have the following beneficial effects: receiving visual perception results from the vehicle control processing unit and parsing them according to a preset communication protocol to obtain target visual perception results; encapsulating the target visual perception results and key state variables according to a preset data format to generate a target message; and controlling the communication interface to send the target message to the vehicle communication bus at a preset period.

[0016] By parsing the received perception results and periodically transmitting them in a unified package with the operating parameters of the local control algorithm, structured acquisition of key intermediate data within the intelligent driving domain control is achieved. This method overcomes the limitations of traditional methods that only record raw sensor data, making perception output and control status observable and significantly improving the efficiency of algorithm problem localization. It also supports high-fidelity data feedback simulation, enhancing test repeatability. Through independent packaging and periodic transmission mechanisms, reliable transmission of debugging data is achieved while ensuring the safety of the main control function, effectively improving the development efficiency and iteration speed of the autonomous driving system. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart of a vehicle multi-source data acquisition method according to an embodiment of this application is shown; Figure 2 Another flowchart of the vehicle multi-source data acquisition method according to an embodiment of this application is shown; Figure 3 This paper illustrates a flowchart of the process of forwarding visual perception results to the vehicle control bus in the vehicle multi-source data acquisition method of this application embodiment; Figure 4 This paper illustrates a flowchart of the process of forwarding key state variables to the vehicle control bus in the vehicle multi-source data acquisition method of this application embodiment; Figure 5 A schematic diagram of a vehicle multi-source data acquisition method according to an embodiment of this application is shown. Detailed Implementation

[0019] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0020] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0022] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0023] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0024] Considering the problem that existing technologies cannot obtain key intermediate data within the intelligent driving domain controller, especially the difficulty in synchronously collecting visual perception results and internal variables of the control algorithm, a multi-source vehicle data acquisition method is proposed. The method involves the vehicle domain controller's processor receiving and parsing the visual perception results from the vehicle control processing unit, encapsulating them and key state variables into a message according to a preset data format, and sending it to the vehicle communication bus at a preset cycle. This achieves synchronous acquisition and structured transmission of perception output and control status, improving algorithm debugging efficiency and the accuracy of data feedback simulation without affecting the safety of the main control function.

[0025] The following describes the multi-source data acquisition method for this vehicle using specific examples.

[0026] Figure 1 A flowchart of a vehicle multi-source data acquisition method according to an embodiment of this application is shown. Exemplarily, this vehicle multi-source data acquisition method is executed by the processor of a vehicle domain controller and includes the following steps: Step S100: Receive the visual perception result from the vehicle control processing unit, and parse the visual perception result according to the preset communication protocol to obtain the target visual perception result.

[0027] The vehicle control processing unit (VCC) refers to the SoC chip in the ADAS domain controller, responsible for running camera visual perception algorithms and outputting structured perception information. The preset communication protocol refers to the proprietary SPI communication protocol agreed upon between the SoC and the MCU (processor), supporting high-speed, low-latency data transmission. The target visual perception result refers to a standard-formatted set of perceived objects that, after parsing and organization, can be used for regulatory decision-making or debugging analysis. By converting the closed perception output from the SoC side into a data format that the MCU (processor) can recognize and process, and then encapsulating it into target messages, the external visibility and collectability of the intermediate perception results are achieved.

[0028] For example, the SoC periodically (e.g., at a frequency of 25Hz) sends perception data frames. The MCU configures its SPI peripheral module to slave mode and receives a complete binary data packet each time communication is triggered. After receiving the data, it parses it according to a predefined message format, reads object fields such as obstacles, lane lines, and traffic signs in sequence, and organizes them into a set of structured objects in memory. Finally, it forms a target visual perception result with a unified access interface.

[0029] For example, in a city road test, the SoC detects a pedestrian crossing the road ahead, and its position, speed, and confidence level are packaged into an SPI data frame; the MCU successfully receives and parses the frame to generate the corresponding target visual perception result.

[0030] In an optional embodiment, step S100 includes the following sub-steps: S101 periodically receives data frames containing perception result fields from the vehicle control processing unit via a serial peripheral interface.

[0031] The Serial Peripheral Interface (SPI) is a full-duplex synchronous serial communication interface. SPI communication uses a master-slave architecture, with the SoC as the master and the MCU as the slave, and data transmission initiated by the SoC. Periodic reception means that the MCU receives data frames from the SoC at fixed time intervals, ensuring continuous acquisition of sensing results. A data frame is a binary message block organized in a specific format, containing information fields from multiple sensed objects. By establishing a physical communication channel between the SoC and the MCU, it is ensured that sensed data can be transmitted to the MCU in real time and completely.

[0032] For example, in a rainy day test, despite significant environmental interference, the SPI link still successfully received the perception data frame sent by the SoC, which included information about the right lane line that was partially visible due to obstruction. This data was completely captured and entered the parsing stage, demonstrating the robustness of the communication link.

[0033] S102, perform field-level parsing on the received data frame to extract the original visual perception results corresponding to obstacles, lane lines and traffic signs.

[0034] Field-level parsing refers to reading the specific values ​​of each sensing object from a specified position in the data frame according to a predefined message structure. The purpose of this step is to restore the binary data stream into intermediate variables with clear semantics, which serve as the basis for constructing higher-level sensing objects.

[0035] As an example, after completing the SPI reception, the MCU parses the data frame according to the predefined message structure, sequentially extracting the number and attribute information of obstacles, including ID, type, location, speed, and confidence level; lane line information, including curvature, offset, and validity status; and traffic sign information, including category, location, and confidence level. All extracted values ​​retain their original precision and are not subjected to unit conversion or filtering, forming a set of original visual perception results.

[0036] S103, based on the original visual perception results, generate a set of data objects that conform to the preset communication protocol, and use the set of data objects as the target visual perception results.

[0037] Among them, the data object set refers to a data container that organizes multiple sensing entities (such as obstacles and lane lines) into a unified memory structure, usually managed in the form of structure arrays or linked lists; the purpose of this step is to normalize and organize the original data so that it has structural consistency, making it easier to participate in planning and control calculations or encapsulate it into CanFD messages.

[0038] For example, in a complex intersection scenario, the original perception results show that there are multiple pedestrians and non-motorized vehicles. The MCU constructs them into independent object instances to form a clearly structured target visual perception result, which is convenient for subsequent encapsulation and transmission.

[0039] Step S200: Encapsulate the target visual perception results and key state variables according to a preset data format to generate a target message.

[0040] The target visual perception result refers to the structured perception object set that has been parsed and organized, including information such as obstacles, lane lines, and traffic signs. Key state variables refer to the critical intermediate signals generated by the planning and control (regulation) algorithm running on the MCU, used to characterize the evolution of its decision-making logic, such as driving mode identification, lateral control gain, collision risk score, and the current stage of the state machine. The preset data format refers to the vehicle communication message structure specification defined based on the DBC file, used to standardize signal layout and encoding methods. The target message is a data frame conforming to the vehicle communication protocol, which can be received and parsed by external acquisition devices. The purpose of this step is to unify the two types of heterogeneous data into a standard format that can be transmitted across systems, forming a bridge from internal intermediate quantities to externally observable signals.

[0041] As an example, the values ​​of each perception field in the target visual perception result are obtained, and the corresponding perception result data format description file is loaded. At the same time, the variable acquisition module is started to periodically read the system status values ​​in the preset variable address list and generate an internal variable dataset. Then, the corresponding internal variable data format description file is loaded, and encapsulation mapping tables are established respectively. Finally, the reassembly and encoding of each message are completed according to the mapping table to generate one or more target messages.

[0042] For example, in a lane change assist function test, the target visual perception result includes the presence of a rapidly approaching vehicle in the adjacent lane on the left, while the risk score of the AGSM module inside the MCU is 0.85. These two types of data are extracted and mapped to target messages with different message identifiers. The final generated target message can synchronously display the correlation between perception judgment and decision logic in the playback system.

[0043] In one alternative embodiment, such as Figure 2 As shown, step S200 includes the following sub-steps: S201, based on the target visual perception results, extract the field data corresponding to obstacles, lane lines and traffic signs.

[0044] The field data includes the obstacle's ID, type, distance, relative speed, and confidence level; the lane line's curvature, offset, and continuity status; and the traffic sign's category, location, and confidence level, among other raw values. This step decomposes high-level object instances into basic data units that can be used to populate vehicular communication signals, serving as input for encapsulation.

[0045] As an example, the MCU iterates through each obstacle object in the perception list, sequentially reading its ID, type, horizontal and vertical coordinates, velocity components, and confidence level, and temporarily storing them in a temporary buffer. All extracted field data retains its original precision, without unit conversion or filtering, ensuring that the encapsulation process faithfully reflects the true state of the perception output.

[0046] For example, if the lateral velocity of an obstacle in the target visual perception result is +2.3m / s (indicating that it is crossing from right to left), this value is accurately extracted and marked as a high-dynamic risk object. Its movement trend is displayed in the message field during subsequent encapsulation, which helps developers analyze the cause of emergency braking.

[0047] In other implementations, a field extraction whitelist mechanism can be configured to extract only the key fields that users are interested in, thereby reducing message load.

[0048] S202: Obtain the state variables generated during the algorithm execution on the processor to generate a dataset of running parameters.

[0049] Among them, state variables refer to important internal variables generated by the MCU during the execution of planning and control (planning and control) algorithms, reflecting the current operating state and decision-making logic of the system; the operating parameter dataset is a key-value set composed of multiple internal variables, usually organized in the form of a structure or hash table.

[0050] As an example, the MCU has a dedicated data acquisition module that periodically scans a pre-configured list of variable addresses. All read values ​​are packaged into a unified data structure, added to the runtime parameter dataset, and timestamped. Since these variables directly affect vehicle behavior, their real-time acquisition is crucial for reproducing abnormal scenarios.

[0051] For example, when a vehicle brakes incorrectly, the system can determine whether the problem is a false detection or a defect in the control logic by examining the sequence of state changes in the operating parameter dataset.

[0052] In other implementations, variable acquisition can support priority-based scheduling, increasing the sampling frequency for critical variables and decreasing the frequency for non-critical variables to save resources.

[0053] S203, based on the preset data format description file, performs field matching and byte allocation on the field data and the running parameter dataset to form an encapsulation mapping table.

[0054] The data format description file refers to the DBC (Database Container) file, which defines the physical attributes of each signal in the CanFD message, including the start bit, bit length, scaling factor, offset, and message ID. Field matching refers to the process of matching the data fields to be encapsulated with the signal names defined in the DBC. Byte allocation refers to determining the bit range occupied by each signal in the CanFD data field. The encapsulation mapping table is a memory lookup structure that records the mapping relationship between the fields to be encapsulated and their positions, lengths, and encoding rules in the target message.

[0055] S204: Based on the encapsulation mapping table, perform data reorganization and encoding on each field to generate a target message that conforms to the preset data format.

[0056] Data reassembly refers to the process of concatenating data from multiple fields into a complete data field according to the bit order indicated by the encapsulation mapping table; encoding includes operations such as numerical transformation, endianness adjustment, and bit stuffing based on scaling factors and offsets; the target message is the final data frame that conforms to the vehicle communication protocol. The purpose of this step is to complete the final transformation from mapping relationship to physical message, enabling the data to be transmissible and universally resolvable.

[0057] For example, initialize a data buffer with an initial value of 0; then iterate through each item in the encapsulation mapping table, retrieve the current value of the corresponding field, and convert it to an integer after performing numerical transformation according to the preset scaling factor and offset; then insert it into the specified bit range of the buffer according to the start bit and bit length; after all fields are filled, set the message identifier and data length, and submit it to the sending queue of the communication interface.

[0058] In step S300, the control communication interface sends the target message to the vehicle communication bus according to a preset period.

[0059] The communication interface is used to realize in-vehicle network communication; the target message is a pre-encapsulated communication data frame; the preset period refers to the different transmission frequencies set according to the data type; the in-vehicle communication bus is a dedicated bus independent of the vehicle's main CAN network, used to transmit debugging-related data. The purpose of this step is to periodically transmit key intermediate data to the external system for reception and recording by the in-vehicle acquisition equipment, without affecting the vehicle's main control communication security, thus forming an output path from the domain controller to the external system.

[0060] As an example, upon receiving a target message to be sent, its type is determined, and it is added to the corresponding timed transmission task queue according to pre-configured periodic parameters. When the system clock reaches the next transmission time, the task scheduler triggers the transmission operation, writes the message into the transmission buffer of the CanFD controller, and starts the controller to execute the transmission process. Finally, the message is output to the extended CanFD bus via the physical transceiver. Because this bus is isolated from the vehicle's CAN bus, it avoids interference from debugging data traffic to critical signals such as braking and steering, ensuring functional safety.

[0061] For example, in a high-speed cruise test, the MCU generates a target message containing the distance to the vehicle in front and the ACC status gain, and accurately sends it to the extended CanFD bus every 30ms. The on-board acquisition device successfully captures this sequence for subsequent analysis of ACC response delay issues.

[0062] In an optional embodiment, step S300 includes the following sub-steps: S301 generates a corresponding sending task queue based on the target message and assigns a unique message identifier to each message to be sent.

[0063] The sending task queue is an in-memory first-in-first-out (FIFO) structure used to buffer CanFD messages to be sent and their scheduling information. The message identifier is a unique number used to distinguish different types or sources of messages, usually mapped to the arbitration ID of the CanFD frame (such as 0x500, 0x600). The purpose of this step is to organize and identify the data to be sent in an orderly manner, ensuring that the subsequent scheduling and sending process is traceable and manageable.

[0064] As an example, after the target message is encapsulated, a corresponding task queue is created or selected based on the message ID: if the message ID is 0x500, it is added to the perception result queue; if it is 0x600, it is added to the internal variable queue. Subsequently, a temporary sequence number is assigned to the message as a local scheduling identifier (not a CanFD protocol field), and this number, along with timestamps, retry counts, and other metadata, is packaged into a sending task node and inserted at the tail of the queue. This mechanism supports asynchronous processing of multiple message types, preventing high-priority tasks from being blocked by low-frequency messages.

[0065] For example, when two sensing messages are generated consecutively, the system assigns them different local scheduling identifiers and queues them in order to ensure the consistency of the sending order.

[0066] In other implementations, a queue priority mechanism can be configured, for example, to elevate emergency-related messages to a high-priority queue for rapid reporting.

[0067] S302, write the target message into the transmit buffer of the communication interface according to the message identifier order.

[0068] The message identifier order refers to the ascending order of the messages in the sending task queue according to their scheduling identifiers, reflecting their expected transmission timing. The transmission buffer of the communication interface refers to a dedicated RAM area inside the CanFD controller used to temporarily store message data to be sent. For example, when the scheduler retrieves a task to be sent from the head of the task queue, it parses the target message content it carries and writes it into the transmission buffer of the communication interface. Once the writing is complete, it enters the waiting-to-send state, awaiting the controller to send it at an opportune time.

[0069] S303 is the transmission control unit of the scheduling communication interface, which reads the target message from the transmission buffer at a preset period.

[0070] The transmission control unit refers to the core logic module within the CanFD controller responsible for arbitration, frame formatting, and physical transmission. The preset cycle is triggered by a timed scheduling task; for example, it triggers every 40ms for sensing messages and every 30ms for internal variable messages. This step initiates the hardware transmission process, causing messages in the buffer to enter the bus contention phase, completing the state transition from "ready" to "transmit".

[0071] As an example, the MCU creates a periodic task through its built-in timer module. When the count reaches a set threshold (e.g., 30ms), the task is awakened to check if there are any new messages to send. If so, it sends a "request to send" command to the CanFD controller. The controller then checks the bus idle state; if idle, it immediately initiates transmission; otherwise, it enters the arbitration process. The scheduling period is set independently for different types of messages. For example, a sensing message with ID 0x500 is bound to a 40ms periodic task, and a variable message with ID 0x600 is bound to a 30ms task, thus achieving asynchronous concurrent transmission.

[0072] For example, when internal variables are updated quickly (30ms) while the perceived results are slow (40ms), the system uses an independent scheduling mechanism to ensure that the two do not block each other, thus improving data real-time performance.

[0073] In other implementations, a dynamic period adjustment strategy can be introduced to adaptively extend or shorten the transmission period based on network load, thereby avoiding bus congestion.

[0074] S304 sends the target message to the vehicle communication bus via the communication interface.

[0075] The output to the vehicle communication bus refers to the process where the target message, after being encoded by the CanFD controller, is converted into a differential electrical signal by the physical transceiver and broadcast on the extended CanFD bus. This step is the final execution stage of the entire transmission link, marking the formal departure of the data from the MCU and entry into the external observable domain, completing the transformation from "internal intermediate quantity" to "externally acquireable signal".

[0076] For example, when the risk score inside the control algorithm suddenly rises, the corresponding message is successfully output to the extended CanFD bus. The acquisition device synchronously captures the event and displays it in conjunction with the camera footage in the playback system, helping developers to confirm whether it was a false trigger.

[0077] In an optional implementation, step S300 further includes the following sub-steps: Based on the type of the target message, the corresponding sending period parameters are set, and the communication interface is triggered to perform the sending operation in each sending period through the timed scheduling unit.

[0078] Here, "type" refers to the category of data content it carries, such as visual perception result messages or internal variable messages of control algorithms; "sending period parameter" refers to the independent sending time interval configured for different types of messages, used to match their data update frequency; "timing scheduling unit" refers to the task scheduling module built inside the MCU based on system tick or hardware timer, responsible for periodically waking up the sending process. Specifically, the pre-configured sending period for perception result messages is 40ms, and the period for internal variable messages is set to 30ms; these parameters are stored in the configuration table; during MCU initialization, a 1ms system tick timer is started, generating an interrupt every 1ms; multiple software counters are maintained in the interrupt service routine, accumulating the elapsed time slices of each type of message; when a counter reaches the corresponding period parameter value, the sending task of that type of message is immediately triggered.

[0079] For example, in a test on a congested urban road, although the MCU main loop had a high computational load due to the complex traffic scenario, the timing scheduling unit still successfully triggered the transmission of internal variables and perception messages at every 30ms and 40ms, ensuring that the vehicle-mounted acquisition device completely captured the entire data chain from "the vehicle in front decelerating" to "this vehicle braking", providing a high-precision time alignment basis for subsequent analysis.

[0080] In other implementations, the timing scheduling unit can combine RTC or PPS signals for external clock synchronization to further improve data time consistency among multiple devices.

[0081] In one optional implementation, the following sub-steps are included before step S300: A periodic counting unit is established based on the processor's built-in local clock signal. The count value of the periodic counting unit is used as the trigger condition for sending the target message. When the trigger condition is met, the communication interface is controlled to perform the message sending operation.

[0082] The MCU's built-in local clock signal is a stable system clock signal generated by the MCU chip's internal crystal oscillator or phase-locked loop (PLL), used to drive timers and task scheduling. The cycle counting unit is a software-implemented counter variable used to accumulate the number of time slices. The trigger condition refers to the logic for determining the state when the counter reaches a preset threshold. Through a precise counting mechanism driven by a hardware clock, accurate control of message transmission timing is achieved, avoiding timing jitter caused by CPU polling or task delays, and improving the time consistency of data acquisition.

[0083] For example, in a high-speed following test, the main loop delay reached 5ms due to the high computational load of the control algorithm. However, thanks to the cycle counting mechanism based on the local clock, the internal variable messages could still be sent accurately every 30±1ms. Based on this, the on-board acquisition equipment successfully reconstructed the complete response curve from the deceleration of the vehicle in front to the acceleration adjustment of the vehicle itself, verifying the timing reliability of the system.

[0084] In other implementations, the periodic counting unit can be periodically calibrated in conjunction with an external GPS pulse (PPS) to eliminate accumulated errors over long-term operation and further improve the data time alignment accuracy between multiple devices.

[0085] In an optional embodiment, step S300 is followed by the following sub-steps: S305 checks the sending status of the target message and performs a retransmission operation when an anomaly is detected.

[0086] Here, "transmission status" refers to the execution result fed back by the CanFD controller after completing a transmission attempt; "abnormality" refers to the failure to receive a response from the receiver or the occurrence of a physical layer communication failure; and "retransmission operation" refers to the behavior of resubmitting the same message to the transmission queue within a limited number of times. This step aims to improve the reliability of data transmission, ensure that critical intermediate data is not lost in scenarios of occasional bus interference or intense contention, and enhance the robustness of the acquisition system.

[0087] Specifically, after submitting the target message, the MCU obtains the transmission status feedback from the communication interface: if the feedback indicates successful transmission, the current process ends; if the feedback indicates failed transmission, the message is reinserted into the transmission queue and retransmitted in the next available cycle, but the maximum number of retries is limited to one.

[0088] For example, in a city tunnel test, electromagnetic interference caused a message containing internal variables of the AGSM risk score to fail to receive an ACK response. After the MCU detected the TERR flag, it triggered a retransmission mechanism and retransmitted the message in the next 30ms cycle. The message was eventually successfully captured by the vehicle-mounted acquisition device, thus avoiding the loss of critical decision information.

[0089] In summary, the vehicle multi-source data acquisition method provided by this embodiment of the invention is executed independently by the MCU in the vehicle domain control. By collecting, encapsulating and periodically sending the visual perception results and internal variables of the control algorithm, it achieves effective monitoring of the intermediate state of the intelligent driving domain control core.

[0090] To facilitate understanding of the deployment and interaction of the above methods in a real system, a specific implementation scenario example is provided below. It should be noted that this example is used to demonstrate the environment in which the method of this invention exists; the core of this invention lies in how the MCU receives, processes, and transmits data.

[0091] Please see Figure 3 This is a schematic diagram illustrating the process of forwarding visual perception results to the vehicle communication bus in a specific embodiment of the present invention. In this scenario: 1) The SoC periodically sends visual perception results via the SPI interface; 2) The MCU receives the SPI data frame and parses out information such as obstacles, lane lines, and traffic signs according to the predefined data definition; 3) The MCU encapsulates the parsed sensing results based on the DBC file required for forwarding; 4) The MCU calls the communication intermediate layer interface to submit the encapsulated message; 5) The communication middleware interface calls the underlying driver to send data to the CanFD bus; 6) Feedback on whether the transmission was successful or failed, and trigger a retransmission mechanism when a transmission failure is detected.

[0092] Please see Figure 4 This is a schematic diagram illustrating the process of forwarding key state variables to the vehicle communication bus: 1) The MCU's internal variable acquisition module periodically reads the key variable values ​​of the control algorithm; 2) The MCU completes data encapsulation based on the corresponding DBC file; 3) The MCU calls the communication intermediate layer interface to send messages; 4) The communication intermediate layer interface outputs its data to the CanFD through the underlying driver; 5) Provide feedback on the sending status; if sending fails, perform a resend operation.

[0093] Figure 5A schematic diagram of a vehicle multi-source data acquisition device according to an embodiment of this application is shown. Exemplarily, the device 100 includes: The data processing module 110 is used to receive the visual perception results from the vehicle control processing unit and parse the visual perception results according to a preset communication protocol to obtain the target visual perception results. The encapsulation module 120 is used to encapsulate the target visual perception result and key state variables according to a preset data format to generate a target message; wherein, the key state variables refer to the state variables generated during the algorithm execution on the processor; The data transmission module 130 is used to control the communication interface to send the target message to the vehicle communication bus according to a preset period.

[0094] It is understood that the apparatus of this embodiment corresponds to the method of the above embodiments, and the options in the above embodiments are also applicable to this embodiment, so they will not be described again here.

[0095] This application also provides a terminal device, exemplary of which includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to enable the terminal device to perform the functions of the various modules in the above-described method or apparatus.

[0096] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0097] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory is used to store computer programs, and the processor can execute the computer programs accordingly after receiving execution instructions.

[0098] This application also provides a computer-readable storage medium for storing the computer program used in the aforementioned terminal device. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0099] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0100] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0101] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0102] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for acquiring multi-source vehicle data, characterized in that, The method is executed by a processor in the vehicle domain control system and includes: The system receives visual perception results from the vehicle control processing unit and parses the visual perception results according to a preset communication protocol to obtain the target visual perception results. The target visual perception result and key state variables are encapsulated according to a preset data format to generate a target message; wherein, the key state variables refer to the state variables generated during the algorithm execution on the processor; The control communication interface sends the target message to the vehicle communication bus according to a preset period.

2. The vehicle multi-source data acquisition method according to claim 1, characterized in that, After sending the target message to the vehicle communication bus according to a preset period, the process includes: The sending status of the target message is detected, and a retransmission operation is performed when an anomaly is detected.

3. The vehicle multi-source data acquisition method according to claim 1, characterized in that, The step of receiving visual perception results from the vehicle control processing unit and parsing the visual perception results according to a preset communication protocol to obtain target visual perception results includes: Data frames containing perception result fields are periodically received from the vehicle control processing unit via a serial peripheral interface. The received data frame is parsed at the field level to extract the original visual perception results corresponding to obstacles, lane lines and traffic signs; Based on the original visual perception results, a set of data objects conforming to the preset communication protocol is generated, and the set of data objects is used as the target visual perception results.

4. The vehicle multi-source data acquisition method according to claim 1, characterized in that, The step of encapsulating the target visual perception result and key state variables according to a preset data format to generate a target message includes: Based on the visual perception results of the target, extract the field data corresponding to obstacles, lane lines and traffic signs; Obtain the state variables generated during the algorithm execution on the processor to generate a dataset of running parameters; Based on the preset data format description file, the field data and the running parameter dataset are matched and byte-allocated to form an encapsulation mapping table; Based on the encapsulation mapping table, data reorganization and encoding are performed on each field to generate a target message that conforms to a preset data format.

5. The vehicle multi-source data acquisition method according to claim 1, characterized in that, The control communication interface sends the target message to the vehicle communication bus at a preset period, including: Based on the target message, a corresponding sending task queue is generated, and a unique message identifier is assigned to each message to be sent; Write the target message into the transmission buffer of the communication interface in the order of the message identifiers; The sending control unit of the scheduling communication interface reads the target message from the sending buffer at a preset period; The target message is sent to the vehicle communication bus via the communication interface.

6. The vehicle multi-source data acquisition method according to claim 1, characterized in that, The control communication interface sends the target message to the vehicle communication bus at a preset period, and also includes: Based on the type of the target message, a corresponding sending period parameter is set, and the communication interface is triggered to perform a sending operation in each sending period by a timed scheduling unit.

7. The vehicle multi-source data acquisition method according to claim 1, characterized in that, Before the control communication interface sends the target message to the vehicle communication bus at a preset period, it includes: A cycle counting unit is established based on the local clock signal built into the processor; The count value of the periodic counting unit is used as the trigger condition for sending the target message; When the triggering condition is met, the communication interface is controlled to perform a message sending operation.

8. A vehicle multi-source data acquisition device, characterized in that, include: The data processing module is used to receive the visual perception results from the vehicle control processing unit and parse the visual perception results according to a preset communication protocol to obtain the target visual perception results. An encapsulation module is used to encapsulate the target visual perception result and key state variables according to a preset data format to generate a target message; wherein, the key state variables refer to the state variables generated during the algorithm execution on the processor; The data transmission module is used to control the communication interface to send the target message to the vehicle communication bus according to a preset period.

9. A terminal device, characterized in that, The terminal device includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the vehicle multi-source data acquisition method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed on a processor, implements the vehicle multi-source data acquisition method according to any one of claims 1-7.

Images