Automatic driving data recording anomaly detection method, device and equipment and automatic driving recorded data label generation method, device and equipment

Abstract

The embodiment of the invention provides an automatic driving data recording anomaly detection method, device and equipment and an automatic driving recorded data label generation method, device and equipment, and relates to the technical field of automatic driving and fault detection, and the method comprises the following steps: executing start detection to verify a ready state required by data recording; executing timing detection according to a preset period so as to verify the running state of hardware on which data recording depends; in response to the data recording instruction, executing instant detection to verify the validity of the recorded data; based on an abnormal event identified by at least one of the starting detection, the timing detection and the instant detection, determining a broadcast priority according to an abnormal type of the abnormal event; adding an audio prompt file of the abnormal event into an audio broadcast queue based on the broadcast priority; and sequentially taking out the audio prompt files from the audio broadcasting queue for broadcasting.

Description

A method, apparatus, and device for anomaly detection and tag generation of autonomous driving recorded data. Technical Field

[0001] This specification relates to the field of autonomous driving and fault detection technology, specifically to a method, apparatus, and device for anomaly detection and tag generation of autonomous driving recorded data. Background Technology

[0002] In the research and development of autonomous driving technology, data collection vehicles continuously record data packets (such as ROSbag) in complex road environments. This data is the foundation for training autonomous driving algorithm models, functional simulation verification, and fault diagnosis of autonomous driving systems. However, the current autonomous driving data recording process suffers from a lag in fault detection, affecting the input quality and generation efficiency of autonomous driving recorded data and corresponding voice tags. Summary of the Invention

[0003] The purpose of the embodiments in this specification is to provide a method, apparatus, and device for anomaly detection and tag generation of autonomous driving data recording, so as to overcome the problem of delayed fault detection in the existing autonomous driving data recording process, thereby improving the input quality and generation efficiency of autonomous driving recording data and corresponding voice tags.

[0004] To address the aforementioned technical problems, the specific technical solutions of this specification embodiment are as follows: On one hand, this specification embodiment provides an anomaly detection method for autonomous driving data recording, applied to a first vehicle-side domain controller; the method includes: performing a startup detection to verify the readiness state required for data recording; performing a timed detection at a preset cycle to verify the operating state of the hardware on which data recording depends; responding to a data recording command and performing an immediate detection to verify the validity of the recorded data; determining a broadcast priority based on the anomaly type of the anomaly event identified by at least one of the startup detection, timed detection, and immediate detection; adding the audio prompt file of the anomaly event to an audio broadcast queue based on the broadcast priority; and sequentially retrieving audio prompt files from the audio broadcast queue for broadcast.

[0005] Furthermore, the recorded data includes autonomous driving data and associated audio tag data; the execution of real-time detection includes: verifying the sound validity of the audio tag data after recording is completed; and verifying the validity of the data output frequency of the preset data source.

[0006] Furthermore, the verification of the sound validity of the audio tag data includes: determining whether the audio signal contains valid audio based on the intensity of the audio signal corresponding to the audio tag data.

[0007] Furthermore, the verification of the validity of the data output frequency of the preset data source includes: determining the output data volume of the preset data source based on the metadata generated during the data recording process; determining the expected data volume of the preset data source according to the expected data output frequency and recording duration configured for the data source; comparing the output data volume with the expected data volume; and determining whether the data output frequency of the preset data source is valid based on the comparison result.

[0008] Furthermore, the real-time detection also includes: in response to a data recording command, verifying the mounting status of the data storage device; if the data storage device is detected to be unmounted, performing mounting; if mounting fails, prohibiting data recording.

[0009] Furthermore, the method also includes: in response to a data recording instruction, recording the triggering method, vehicle configuration information, and data storage path for data recording; and associating the recorded triggering method, vehicle configuration information, and data storage path with the recorded audio tag data.

[0010] Furthermore, the method further includes: acquiring status information of at least one second vehicle-mounted domain controller; performing at least one of startup detection, timed detection, and instant detection based on the status information to identify abnormal events of the second vehicle-mounted domain controller; the step of determining broadcast priority based on the abnormal event identified by at least one of startup detection, timed detection, and instant detection according to the abnormal type of the abnormal event includes: determining broadcast priority based on the abnormal event identified by at least one of startup detection, timed detection, and instant detection and the identified abnormal event of the second vehicle-mounted domain controller according to the abnormal type of the abnormal event.

[0011] Furthermore, the execution of the startup detection includes: verifying the validity of the vehicle configuration information; verifying the mounting status, mounting format, and capacity availability of the data storage device; verifying the connection status of the data interface between the first vehicle-side domain controller and the extended device; verifying the existence and validity of the sensor calibration file; verifying the configuration parameters of the audio input device; and verifying the existence of the preset data source.

[0012] Furthermore, the timed detection performed according to a preset period includes: verifying the connection status of the data interface between the first vehicle-side domain controller and the extended device according to a preset period; and verifying the mounting status, mounting format, and capacity availability of the data storage device according to a preset period.

[0013] Furthermore, embodiments of this specification provide a method for generating tags for autonomous driving recording data, applied to a backend server; the method includes: obtaining audio tag data and its associated data generated during the data recording process from at least one vehicle-side domain controller; the associated data includes the triggering method of data recording, vehicle configuration information, and data storage path; performing speech recognition on the audio tag data to obtain text tag data; and generating structured autonomous driving data tags based on the text tag data and the associated data.

[0014] Furthermore, the step of performing speech recognition on the audio tag data to obtain text tag data includes: performing speech recognition on the audio tag data to obtain first text tag data; and correcting the first text tag data based on a preset autonomous driving vocabulary database to obtain second text tag data.

[0015] Furthermore, the method also includes: constructing an autonomous driving vocabulary library based on industry data statistics, expert experience screening, and scenario feedback iteration; the vocabulary categories of the autonomous driving vocabulary library include at least sensor terms, scenario description terms, and anomaly type terms.

[0016] Furthermore, the step of generating structured autonomous driving data tags based on the text tag data and the associated data includes: extracting keywords from the text tag data; combining the abnormal event information obtained from at least one vehicle-side domain controller, matching and filling the keywords with fields in a preset structured tag template to obtain autonomous driving data tags; the fields of the structured tag template include at least the following: recording date, geographical location, vehicle identification, environmental information, road type, problem description, problem classification, and data storage path.

[0017] Furthermore, the method also includes: obtaining the correction result of the structured autonomous driving data tags; and updating the audio tag data in the vehicle domain controller according to the correction result.

[0018] Furthermore, embodiments of this specification provide an anomaly detection device for autonomous driving data recording, comprising: a startup detection module for performing startup detection to verify the readiness state required for data recording; a timed detection module for performing timed detection at a preset period to verify the operating state of the hardware on which data recording depends; an instant detection module for performing instant detection in response to a data recording command to verify the validity of the recorded data; a determination module for determining a playback priority based on the anomaly type of an anomaly event identified by at least one of the startup detection, timed detection, and instant detection; an addition module for adding audio prompt files of the anomaly event to an audio playback queue based on the playback priority; and a playback module for sequentially retrieving audio prompt files from the audio playback queue for playback.

[0019] In another aspect, embodiments of this specification provide a tag generation device for autonomous driving data recording, comprising: an acquisition module, configured to acquire audio tag data and its associated data generated during the data recording process from at least one vehicle-side domain controller; the associated data includes the data recording triggering method, vehicle configuration information, and data storage path; an identification module, configured to perform speech recognition on the audio tag data to obtain text tag data; and a generation module, configured to generate structured autonomous driving data tags based on the text tag data and the associated data.

[0020] In another aspect, embodiments of this specification provide a first vehicle-side domain controller, including: a memory and a processor, wherein the processor and the memory are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to realize the above-mentioned abnormal detection method for recording autonomous driving data.

[0021] In another aspect, embodiments of this specification provide a backend server, including: a memory and a processor, wherein the processor and the memory are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to implement the above-mentioned method for generating tags for autonomous driving recording data.

[0022] Furthermore, embodiments of this specification provide a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the above-described method for anomaly detection in autonomous driving data recording and the method for generating tags in autonomous driving data recording.

[0023] In another aspect, embodiments of this specification provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the above-described anomaly detection method for autonomous driving data recording and the above-described tag generation method for autonomous driving data recording.

[0024] As can be seen from the technical solutions provided in the embodiments of this specification above, the first vehicle-side domain controller in these embodiments can perform startup detection to verify the readiness state required for data recording; perform timed detection at preset intervals to verify the operating status of the hardware on which data recording depends; and perform real-time detection in response to a data recording command to verify the validity of the recorded data. Based on the abnormal events identified by at least one of the startup detection, timed detection, and real-time detection, the playback priority is determined according to the abnormality type of the abnormal event. Based on the playback priority, the audio prompt file of the abnormal event is added to the audio playback queue; and the audio prompt file is sequentially retrieved from the audio playback queue for playback. Thus, by integrating a three-level collaborative detection mechanism of startup detection, timed detection, and real-time detection, fault detection and quality management of the entire process of autonomous driving data recording are realized. By significantly shifting the node of abnormality discovery and handling from after-the-fact to during and before the event, invalid data caused by abnormal hardware connection, configuration error, or incomplete data stream can be prevented from the source. Meanwhile, by introducing a priority queued broadcasting mechanism based on anomaly type, it is ensured that key alarm information can be delivered to the driver in an orderly and clear manner in complex multi-anomaly scenarios, effectively avoiding the interference of broadcasting conflicts and information overload on driving safety, thereby improving the reliability of data collection quality and ensuring the safety of the vehicle operating environment.

[0025] As can be seen from the technical solutions provided in the embodiments of this specification above, the backend server of these embodiments can obtain audio tag data and its associated data generated during the data recording process from at least one vehicle-side domain controller. The associated data includes the triggering method for data recording, vehicle configuration information, and data storage path. Speech recognition is performed on the audio tag data to obtain text tag data. Based on the text tag data and the associated data, structured autonomous driving data tags are generated. Thus, the combination of voice input and automatic speech recognition replaces the inefficient traditional manual typing method for tag entry, significantly improving the efficiency and convenience of scene information recording. By standardizing and correcting the recognized text using a dedicated autonomous driving vocabulary and associating it with the data recording configuration information uploaded from the vehicle, structured data tags with unified fields and standardized content can be generated. This solves the problem of difficulty in retrieving and managing unstructured voice tags, providing an efficient and accurate index and classification basis for massive amounts of collected data. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the accompanying drawings used in the description of the embodiments or prior art will be briefly introduced below.

[0027] Figure 1 is a schematic diagram of an application scenario of an autonomous driving data acquisition system provided in an embodiment of this specification; Figure 2 is a schematic diagram of the workflow of an autonomous driving data acquisition system provided in an embodiment of this specification; Figure 3 is a flowchart of an anomaly detection method for autonomous driving data recording provided in an embodiment of this specification; Figure 4 is a flowchart of the overall logic of an anomaly detection method for autonomous driving data recording provided in an embodiment of this specification; Figure 5 is a flowchart of a tag generation method for autonomous driving recorded data provided in an embodiment of this specification; Figure 6 is a flowchart of the overall logic of a tag generation method for autonomous driving recorded data provided in an embodiment of this specification; Figure 7 is a schematic diagram of the structural composition of an anomaly detection device for autonomous driving data recording provided in an embodiment of this specification; Figure 8 is a schematic diagram of the structural composition of a tag generation device for autonomous driving recorded data provided in an embodiment of this specification; Figure 9 is a flowchart of an anomaly detection and tag generation method for autonomous driving data recording provided in an embodiment of this specification; Figure 10 is a schematic diagram of the structural composition of a first vehicle-side domain controller provided in an embodiment of this specification; Figure 11 is a schematic diagram of the structural composition of a backend server provided in an embodiment of this specification. Detailed Implementation

[0028] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments in this specification. Other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative effort should fall within the scope of protection of this specification.

[0029] It should be noted that the terms "first," "second," etc., used in this specification, claims, and the foregoing drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0030] This specification provides an embodiment of an autonomous driving data acquisition system. As shown in Figures 1 and 2, the system may include one or more vehicle-mounted domain controllers deployed on a data acquisition vehicle and a back-end server located in a remote facility. The vehicle-mounted domain controller serves as the core of onboard data acquisition and processing, while the back-end server acts as a centralized data processing and tag management center. The two are connected and work together via a network protocol.

[0031] The vehicle-side domain controller can be a hardware module built on a high-performance in-vehicle computing platform, on which data acquisition and anomaly detection programs are deployed. This program is responsible for managing the recording of vehicle sensor data streams, performing full-process status monitoring, providing voice interaction guidance, and anomaly reporting. Specifically, the vehicle-side domain controller is responsible for: 1) performing startup checks to verify the readiness of all prerequisites required for data recording, including vehicle configuration, storage devices, and sensor calibration files; 2) performing timed checks at preset intervals to monitor the operating status of key hardware interfaces and storage devices; 3) responding to data recording commands and performing immediate checks, verifying the storage status and the validity of the recorded data (such as the frequency of key data sources and whether associated voice tags are muted); 4) based on the anomalies identified by the above checks, broadcasting them in an orderly manner through a voice queue according to preset priorities; 5) synchronously collecting and storing the driver's spoken voice scene tags during data recording, ensuring that these tags are accurately associated with the sensor data packets in terms of storage path and metadata; and 6) supporting the acquisition of status information from other sub-domain controllers within the same vehicle via remote protocols, enabling collaborative detection and unified alarms across domain controllers.

[0032] The backend server can be a computing device or cluster deployed in a data center or cloud platform, running data synchronization and intelligent processing programs. The backend server is responsible for: 1) collecting voice tag files and existing text files synchronously from each vehicle domain controller via a secure file transfer protocol; 2) calling a speech recognition model to convert the voice files into text information and standardizing terminology using a high-frequency vocabulary library specifically for the autonomous driving field; 3) combining abnormal event information synchronized from the vehicle with pre-set structured tag templates for matching and automatic filling, generating structured data tags containing multiple dimensions such as date, vehicle, scenario, and problem description; 4) supporting manual review and correction of automatically generated tags, and incrementally synchronizing the corrected tag files back to the vehicle domain controller to form a data closed loop.

[0033] The vehicle-mounted domain controller and the backend server collaborate to form an autonomous driving data acquisition system covering the entire data acquisition chain from "on-site perception to quality control to intelligent post-processing." The vehicle-mounted domain controller ensures controllable quality and real-time intervention in anomalies during the data acquisition process, while the backend server enables efficient and accurate conversion of unstructured voice information into structured data assets. Together, they achieve an automated production loop from raw data recording to high-quality, easily searchable training datasets.

[0034] As shown in Figure 1, in one scenario example, an autonomous driving data collection vehicle is recording road test data on urban roads. The vehicle is equipped with two vehicle-side domain controllers: the primary domain controller is responsible for collecting data from the forward sensors, and the secondary domain controller is responsible for collecting data from the lateral and rearward sensors.

[0035] For example, in a rainy testing mission, tester Mr. Wang drove the data acquisition vehicle into the testing area. After the vehicle was powered on, the main domain controller performed startup checks: verifying the vehicle ID was valid, checking that the external SSD was correctly mounted and formatted, confirming that all sensor calibration files existed and were of normal size, sensing that the Type-C hub connection was secure, and recognizing that the in-vehicle microphone equipment was ready. The system played a voice prompt saying, "System ready, data acquisition can begin."

[0036] Mr. Wang pressed the record button on the steering wheel. The primary domain controller responded to the command and performed an immediate check: confirming that the SSD was mounted normally, it then began recording a ROS data packet containing LiDAR point clouds, camera images, and positioning information, while simultaneously activating the in-vehicle microphone for recording. Upon completion of recording, the system played a "Collection Completed" message and triggered post-recording verification: analysis revealed that the Topic output frequency of the left-side blind spot radar was only 70% of the expected value, and the amplitude of the recorded voice tag WAV file sample was below the silence threshold. Based on preset priorities, the system classified "low left-side radar frequency" as a high-priority anomaly and "silent voice tag" as a medium-priority anomaly, and sequentially broadcast the corresponding voice warnings via a single thread: "Attention, insufficient left-side radar data frequency"; "Attention, no valid voice tags were detected during this recording." Simultaneously, the primary domain controller checked the status of the secondary domain controller via the SSH protocol and found that its hard drive had less than 10% remaining capacity, adding this anomaly to the broadcast queue as well.

[0037] The data acquisition vehicle and backend server can connect to the network, allowing them to download the current and previous recorded voice tag files from the vehicle's main and secondary domain controllers via a synchronization task. For invalid tag files recorded by Mr. Wang in the rain but marked as "mute," the backend server removes them after consistency verification. For other valid voice files, the server uses a speech recognition model for conversion and optimizes the recognition results by incorporating a vocabulary library of high-frequency scenarios such as "rainy day," "traffic jam," and "construction." The backend server can extract keywords from the text and associate them with the "low frequency of left radar" anomaly reported by the vehicle, automatically filling the structured tag template to generate a record containing fields such as "Date: 2026-02-05," "Weather: Rain," "Road Type: Urban Main Road," "Problem Category: Sensor Data Anomaly," and "Problem Description: Left blind spot radar data frequency is below the threshold."

[0038] The data labeler can view this automatically generated label in the backend and correct the problem description to "The left-side blind spot radar experiences data frequency fluctuations under rainy conditions, suspected to be affected by water mist," and add the field "Scenario characteristics: Evening rush hour congestion." The backend server receives this correction, updates the label file, and writes it back to the designated directory on the vehicle-side domain controller via incremental synchronization, establishing a connection with the previous data packets.

[0039] In the above scenario example, the vehicle-side domain controller uses a multi-level detection mechanism to intercept sensor data anomalies and operational errors in real time at the data collection site, preventing the generation and storage of invalid data packets. The backend server, through a domain-optimized intelligent processing flow, transforms scattered voice recordings and abnormal events into standardized, structured, high-quality data tags. The entire system realizes an automated pipeline from data collection and quality control to asset management, providing efficient and reliable data support for the training of autonomous driving algorithms.

[0040] Figure 3 shows a flowchart of an anomaly detection method for autonomous driving data recording in one embodiment of this specification, and Figure 4 shows a schematic flowchart of the overall logic of the anomaly detection method for autonomous driving data recording in one embodiment of this specification. The anomaly detection method for autonomous driving data recording can be applied to a first vehicle-side domain controller. Although this specification provides method operation steps or device structures as shown in the following embodiments or figures, more or fewer operation steps or module units may be included in the method or device based on conventional or non-inventive effort. In steps or structures where there is no logically necessary causal relationship, the execution order of these steps or the module structure of the device is not limited to the execution order or module structure described in the embodiments and figures of this specification. When the method or module structure is applied in actual devices or terminal products, it can be executed sequentially or in parallel according to the method or module structure shown in the embodiments or figures (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed processing environment).

[0041] In some embodiments, the autonomous driving data acquisition system can adopt a distributed in-vehicle computing architecture, which may include a first vehicle-mounted domain controller and one or more second vehicle-mounted domain controllers. The first vehicle-mounted domain controller can be a master domain controller, and the second vehicle-mounted domain controllers can be slave domain controllers. In this distributed in-vehicle computing architecture, the first vehicle-mounted domain controller, which can be configured as a master node, undertakes control functions such as system management, task scheduling, global status monitoring, and unified human-machine interaction. The one or more second vehicle-mounted domain controllers, which can be configured as slave nodes or dedicated processing nodes, are respectively responsible for processing data from specific subsets of sensors, executing regional algorithms, or managing dedicated peripheral hardware. The master domain controller and the slave domain controllers can interact with each other through commands and data, forming a logically unified and physically distributed in-vehicle computing network, thereby achieving balanced distribution of computing load, modular deployment of system functions, and improved overall reliability.

[0042] The first and second vehicle-side domain controllers can be high-performance computing modules integrated into the autonomous driving data acquisition vehicle. These include, but are not limited to: multi-core system-on-a-chip (SoC) based on the ARM architecture and integrating a dedicated AI acceleration processing unit; embedded platforms containing general-purpose processor cores, graphics processing units, and programmable logic units to meet the computing power requirements of multi-sensor data synchronization and complex detection algorithms; and onboard computers with high-bandwidth external interfaces designed specifically for processing high-throughput data streams from cameras, LiDAR, and millimeter-wave radar. These computing modules share common characteristics: sufficient computing performance, rich hardware interfaces, and stable operation in harsh onboard environments to support online detection, voice interaction, and data recording tasks.

[0043] In some embodiments, the first vehicle-mounted domain controller can perform a startup detection, which verifies the readiness state required for data recording. The verification dimensions of the readiness state include vehicle configuration, storage devices, sensor calibration, audio input devices, and a preset data source. The first vehicle-mounted domain controller can perform a timed detection at a preset period, which verifies the operating status of the hardware on which data recording depends. This hardware includes at least a data interface connected to an expansion device and an external data storage device. The first vehicle-mounted domain controller can respond to a data recording command by performing an instant detection, which verifies the validity of the recorded data. Validity verification includes at least determining the validity of the sound associated with the audio tag and the validity of the output frequency of the preset data source. If an abnormal event is identified based on at least one of the startup detection, timed detection, and instant detection, the first vehicle-mounted domain controller can issue an alarm notification through a queued voice broadcast mechanism based on a preset mapping relationship between abnormality types and priorities.

[0044] Specifically, as shown in Figure 3, an anomaly detection method for recording autonomous driving data, which can be applied to a first vehicle-side domain controller, provided by one embodiment of this specification, may include the following steps.

[0045] S301: Perform a startup check to verify the readiness status required for data recording.

[0046] In some embodiments, a startup detection is performed to verify the readiness status required for data recording.

[0047] In the autonomous driving data acquisition process, the startup check can be a series of integrity checks performed after the first vehicle-side domain controller is powered on and initialized, but before it formally responds to the data recording command. Its purpose is to conduct a comprehensive check of the key software configurations, hardware status, and data links supporting the data acquisition task, ensuring that the entire system is in a ready state to begin high-quality data recording at any time. The first vehicle-side domain controller is an onboard computing unit deployed inside the vehicle. Its purpose is to centrally process data from various sensors, execute autonomous driving algorithms, and manage data acquisition tasks. It can consist of high-performance processors (including but not limited to multi-core CPUs), artificial intelligence acceleration units (including but not limited to NPUs or GPUs), memory, storage controllers, and various vehicle bus and network interfaces (including but not limited to CAN FD and in-vehicle Ethernet).

[0048] In some embodiments, step S301 may specifically include: verifying the validity of vehicle configuration information.

[0049] In some embodiments, vehicle configuration information may be a set of parameters pre-installed on the first vehicle-side domain controller. Its purpose is to identify the data collection vehicle and task attributes, ensuring the traceability and manageability of subsequently collected data. This information may include, but is not limited to, a unique vehicle identifier and a task area code.

[0050] In some embodiments, the first vehicle-side domain controller can read the vehicle unique identifier and region code from a specified configuration file (including but not limited to JSON or YAML format files); and compare these read values ​​with a pre-stored list of authorized values ​​or a range of valid values. If the vehicle unique identifier conforms to the specification (e.g., an alphanumeric combination of a specific number of characters) and exists in the list of authorized values, and the region code belongs to a predefined set of valid values, then the vehicle configuration information is deemed valid; otherwise, it is deemed invalid.

[0051] The data collection process ensures the unique identification and compliance of data assets, avoiding data confusion and management chaos caused by incorrect vehicle identity or mission area information, and laying the foundation for accurate data retrieval, attribution, and compliant use in the future.

[0052] In some embodiments, step S301 may further include: verifying the mounting status, mounting format, and capacity availability of the data storage device.

[0053] In some embodiments, verification can be performed on the physical storage basis of the data. The data storage device may be a solid-state drive (SSD) externally connected to the first vehicle-side domain controller via a high-speed interface (including but not limited to USB 3.2 Gen2 or Thunderbolt), intended to provide large-capacity, high-bandwidth storage space for persistently storing large-scale raw sensor data (including but not limited to ROS bag files) and voice tag files generated during recording. It comprises flash memory chips, a main control chip, and external interface circuitry.

[0054] In some embodiments, the first vehicle-mounted domain controller can query the mount status of a specified device node (e.g., / dev / sda1). If the device node is associated with a mount point in the file system directory tree (e.g., / mnt / data_disk), it is determined to be mounted. The first vehicle-mounted domain controller can also obtain the file system format used by the mount point (e.g., ext4 or NTFS) and compare it with a preset list of allowed formats to confirm format compatibility. The first vehicle-mounted domain controller can also query the remaining storage capacity of the mount point.

[0055] By confirming the accessibility, compatibility, and sufficient space of the storage medium before recording begins, recording failures or data loss due to unmounted hard drives, incompatible formats, or insufficient space are prevented, ensuring the continuity and reliability of data acquisition tasks.

[0056] In some embodiments, the above-mentioned verification of the capacity availability of the data storage device may further include: determining the storage space required for a single recording based on the average rate of historical data recording and the maximum recording duration per session; determining the security factor of the data storage device based on the performance fluctuation characteristics of the data storage device; determining the secure storage space for a single recording based on the required storage space for a single recording and the security factor; and determining the capacity availability of the data storage device based on the comparison result between the remaining capacity of the data storage device and the secure storage space for a single recording.

[0057] In some embodiments, the average write rate of data recording under similar sensor configurations can be statistically analyzed based on historical data acquisition logs. Combining this with the preset maximum possible continuous recording duration for each task, the theoretical storage space required for a single recording is estimated through multiplication. Potential performance fluctuations in the storage device during continuous high-speed writing (such as speed reduction due to heat) can be considered, and a safety factor greater than 1 (e.g., 1.2) can be preset. Then, the estimated theoretical storage space is multiplied by the safety factor to obtain the safe storage space reserved for this recording session. The current remaining capacity of the data storage device can be compared with the calculated safe storage space for a single recording session. If the remaining capacity is greater than or equal to the safe storage space, the capacity availability is considered sufficient; otherwise, it is considered insufficient.

[0058] By incorporating historical performance data and security factors, dynamic and accurate predictions of storage requirements are achieved. This enables early warnings of risks that may seem sufficient but are actually inadequate during recording, significantly improving robustness in complex and long-duration acquisition tasks.

[0059] In some embodiments, step S301 may further include: verifying the connection status of the data interface between the first vehicle-side domain controller and the extended device.

[0060] In some embodiments, the expansion device may be a hub or docking station that is directly connected to the first vehicle-mounted domain controller via a wired interface (including but not limited to a USB or Thunderbolt interface in Type-C form). Its purpose is to provide additional physical ports for connecting multiple external data storage devices or specific acquisition cards. The data interface is the collective term for the hardware port and communication protocol that carries this physical connection.

[0061] In some embodiments, the first vehicle-side domain controller can query the device tree or enumeration information of a specific bus in the operating system kernel to check whether an extended device matching preset device description information (such as vendor ID, product ID) has been identified and is in a connected state. This can be achieved by checking whether a corresponding device file exists or by reading the connection status register of the interface.

[0062] This ensures that the critical external hardware links upon which high-speed data is written to the disk are stably established before recording begins, avoiding interruptions in the data transmission channel caused by loose interfaces, hubs not being powered on, or driver malfunctions. This is a crucial step in ensuring that data can flow from the sensor to the domain controller and finally be written to the external hard drive.

[0063] In some embodiments, step S301 may further include: verifying the existence and validity of the sensor calibration file.

[0064] In some embodiments, the sensor calibration file may be a data file (including but not limited to XML, YAML, or JSON format) stored in a specified directory of the first vehicle-side domain controller. Its purpose is to store the internal parameters (including but not limited to focal length, distortion coefficients, rotation and translation matrices) and external parameters (mounting position and attitude relative to the vehicle body) of sensors such as cameras, LiDAR, and inertial measurement units. These parameters are crucial for converting raw sensor data into accurate and usable environmental perception information.

[0065] In some embodiments, it can be checked whether the calibration file corresponding to each preset sensor type (including but not limited to the front main camera and the top LiDAR) exists in a predetermined path. Validity verification can be performed, including verifying whether the file format can be correctly parsed and whether the preset key parameter values ​​are within a reasonable physical range or historical experience range.

[0066] This prevents the collected raw data from being incorrectly interpreted and used by subsequent algorithms due to lost or damaged calibration files or incorrect parameters, ensuring the effective value of the collected data for model training and algorithm verification from the source, and avoiding invalid data from occupying storage and computing resources.

[0067] In some embodiments, verifying the validity of the sensor calibration file may specifically include: reading one or more calibration parameters in the calibration file; calculating the deviation of each calibration parameter based on the physical constraint range or historical valid value range of each calibration parameter; the deviation is used to characterize the degree to which the calibration parameter deviates from the physical constraint range or historical valid value range; if the deviation of at least one calibration parameter exceeds a preset tolerance threshold, the calibration file is determined to be invalid.

[0068] In some embodiments, one or more calibration parameters defined in the calibration file can be read. For each calibration parameter, its physical constraint range or historical valid value range statistically obtained from a large number of historical valid calibration files is obtained. The deviation of the current parameter value from the reference center value of the range (including but not limited to the range median or historical mean) is calculated. The deviation can be characterized by absolute difference, percentage difference, or standardized score. A tolerance threshold is preset for each parameter or each type of parameter. If the deviation calculation result of at least one key calibration parameter exceeds its corresponding tolerance threshold, the calibration file is deemed invalid as a whole.

[0069] By elevating validity judgment from a simple existence / format correctness check to a quantitative level of whether parameters are significantly abnormal, it can automatically identify calibration files that, although existing and in good format, are actually unusable due to sensor physical drift, accidental modification, or calibration process errors. This greatly improves the intelligence and reliability of the detection.

[0070] In some embodiments, step S301 may further include: verifying the configuration parameters of the audio input device.

[0071] In some embodiments, the audio input device may be an internal or external microphone connected to the first vehicle-side domain controller via an audio bus or USB audio class protocol, used to capture scene descriptions uttered by the driver or tester and generate voice tags. Configuration parameters may be hardware attributes that identify and initialize the audio device.

[0072] In some embodiments, the first vehicle-mounted domain controller can obtain detailed information about a preset audio input device. This information may include, but is not limited to, a unique device identifier (ID), the maximum number of supported input channels (including but not limited to Mono or Stereo), and the default sampling rate set by the system. The obtained parameter values ​​are then compared with expected values.

[0073] By confirming that the voice acquisition hardware has been correctly identified and that its working mode (channel, sampling rate) meets the requirements of the subsequent voice processing algorithm before recording begins, problems such as the inability to record voice tags or incompatible recording formats due to microphone driver abnormalities, hardware failures, or configuration errors are avoided, thus ensuring the availability of the voice tag function.

[0074] In some embodiments, step S301 may further include: verifying the existence of a preset data source.

[0075] In some embodiments, the preset data source can be a data publishing node predefined in the autonomous driving software framework and expected to be recorded, specifically manifested as a particular communication topic. Its purpose is to continuously generate and publish various sensor data streams (e.g., the topic / camera / front / image_raw publishes front camera images).

[0076] In some embodiments, after initialization, the first vehicle-side domain controller can obtain the node and topic registry of the autonomous driving software framework and check whether all key data sources (i.e., topic names) specified in the configuration list have corresponding publisher nodes registered and are in an active state.

[0077] This ensures that all critical sensor data streams to be recorded are published correctly at the start of recording, preventing the generation of incomplete and useless packets due to missing core data dimensions caused by a sensor node failure, software crash, or network configuration error. This safeguards the integrity of the dataset from the source of information.

[0078] In some embodiments, the above verification of the existence of a preset data source may further include: after detecting the existence of a data source, parsing the header information of the initial data frame of the data source to verify its protocol version, data length, and checksum field; if the verification fails, the data source is determined to be unusable.

[0079] In some embodiments, after detecting the existence of a preset data source and starting to receive data, the first few data frames (or messages) published by that data source can be read. The protocol header information of these initial data frames is parsed, which may include, but is not limited to,: a protocol version number, the data length of this frame, and a checksum and / or cyclic redundancy check field for error detection. According to the communication protocol specifications defined by the data source, the parsed protocol version is matched and verified, the reasonableness of the data length field is judged, and the checksum of the received data is recalculated and compared with the checksum carried in the frame. If the protocol version does not match, the data length is abnormal, or the checksum is inconsistent, it is determined that although the data source exists, its output is unusable.

[0080] By extending existence verification from addressability to the level of correct communication, zombie data sources (which can respond to queries but whose data is garbled or incorrect) caused by protocol version incompatibility, data serialization / deserialization errors, or minor failures in the underlying communication link can be detected at an early stage, further improving the accuracy and robustness of data source availability assessment.

[0081] S302: Performs timed checks at preset intervals to verify the operating status of the hardware on which data recording depends.

[0082] In some embodiments, timed detection is performed at preset intervals to verify the operating status of the hardware on which data recording depends.

[0083] In some embodiments, the data interface connection status can be the availability of the electrical connection and data link protocol established between the first vehicle-side domain controller and the external extended device through the physical port. Its stability is related to whether the external device can be continuously accessed.

[0084] In some embodiments, timed detection can be a monitoring process that is executed cyclically at fixed time intervals after the data recording system starts up and enters standby or working state. Its purpose is to continuously monitor the health of critical hardware components that are prone to state changes or performance degradation under dynamic environments such as vehicle vibration, temperature changes, and continuous read / write loads, promptly detect and warn of potential faults, and prevent recording interruptions or data quality degradation. This constitutes an important supplement to the one-time static verification of startup detection, realizing full-cycle, dynamic quality control of hardware operation.

[0085] In some embodiments, the connection status verification of the data interface may further include: periodically sending test data packets to the extended device and receiving response data packets; calculating the link communication quality index for each period according to the following formula: Q = (Brespond / Bsend) × (1 - Trespond / Etimeout); where Q is the link communication quality index, Brespond is the number of response data packets, Bsend is the number of test data packets, Trespond is the average response latency, and Etimeout is a preset timeout threshold; if the communication quality index is lower than the preset quality index threshold, the connection status is determined to be abnormal.

[0086] In some embodiments, at the start of each preset detection cycle, the first vehicle-side domain controller can generate a test data packet of a specific format and send it to the connected extended device through the target data interface. The test data packet can be a small data unit containing a specific sequence number and a sending timestamp, used for link probing. Upon receiving it, the extended device should return a response data packet. The total number of test data packets sent and the number of successfully received response data packets in this cycle can be recorded, and the average response latency of all successful response packets, i.e., the time elapsed from sending to receiving, can be calculated.

[0087] By upgrading the connection status check from a static "whether connected" to a dynamic "how the connection is," the packet loss rate and latency of the link can be quantitatively assessed. This allows for the early detection of intermittent connection failures or performance degradation caused by loose interfaces, cable wear, or electromagnetic interference, providing a proactive warning to prevent data writing interruptions during recording.

[0088] In some embodiments, based on the obtained response packet count, total test packet count, and average response latency, a preset timeout threshold can be introduced. This threshold defines the maximum acceptable single response time. The link communication quality index for the current detection period is calculated using the following formula: Q = (Brespond / Bsend) × (1 - Trespond / Etimeout). Where Brespond is the number of response packets, Bsend is the number of test packets, Trespond is the average response latency, and Etimeout is the preset timeout threshold. The first part of the formula (Brespond / Bsend) reflects the link reliability (packet loss rate), and the second part (1 - Trespond / Etimeout) reflects the link real-time performance (latency). The calculated Q value is a value between 0 and 1. This Q value is compared with a preset quality index threshold. If the Q value is lower than the threshold, the current data interface connection status is determined to be abnormal.

[0089] By integrating multi-dimensional link metrics (packet loss, latency) into a comprehensive quality index through a mathematical model, an objective and unified quantification of the degree of connection anomalies is achieved. This avoids the one-sidedness of judgment based on a single threshold, making anomaly detection more scientific and accurate. It is helpful in distinguishing between minor jitter and serious faults and supports setting more reasonable warning levels.

[0090] In some embodiments, step S302 may further include: verifying the mounting status, mounting format, and capacity availability of the data storage device at a preset period.

[0091] In some embodiments, the physical medium carrying the data can be periodically reviewed. The data storage device can be an external solid-state drive, whose mounting status, format, and capacity are fundamental conditions for ensuring continuous and correct data writing.

[0092] In some embodiments, during each detection cycle, the first vehicle-side domain controller can query whether the file system mount point corresponding to the target external storage device still exists and is accessible (mount status review). Simultaneously, it confirms whether the file system format used by the mount point is consistent with expectations (format review). Furthermore, it can query the file system to obtain the current remaining storage capacity (capacity review).

[0093] This can promptly detect and alert when the hard drive physical connection is temporarily disconnected due to severe vibration during vehicle operation (and then reconnected but may not be automatically mounted), or when the storage capacity is rapidly consumed to the warning threshold during recording, ensuring a clear understanding of the storage medium's status at all times and providing continuous assurance for maintaining long-term, uninterrupted data recording.

[0094] In some embodiments, the above-mentioned verification of the capacity availability of the data storage device may further include: obtaining the rate at which data is written to the data storage device in the previous historical detection cycle during the current detection cycle; determining the remaining recordable time of the data storage device under the write load of the current detection cycle based on the rate and the remaining capacity of the data storage device; and triggering a capacity warning if the remaining recordable time is lower than a preset safe time threshold.

[0095] In some embodiments, during each capacity availability check, not only the current remaining capacity C can be obtained, but also the average data write rate V to the target storage device since the previous detection period. This rate V reflects the recent real-time write load. Based on the current remaining capacity C and the current average write rate V, the estimated remaining recording time of the storage device, assuming the recent write load remains constant, is calculated using the formula: Remaining recordable time = C / V. This calculated remaining recordable time is compared to a preset safe time threshold. If the remaining recordable time is lower than this safe threshold, a capacity warning is triggered.

[0096] By transforming capacity alerts from static "insufficient remaining space" to dynamic "insufficient estimated available time," the system takes into account the actual situation where data write rates may fluctuate with changes in the scenario, making the alerts more closely reflect real risks. For example, in dense urban scenarios with large sensor data volumes and high write rates, the system will trigger alerts more quickly, allowing operators sufficient reaction time and preventing storage space from running out midway through recording due to insufficient prediction.

[0097] In some embodiments, step S302 may further include: periodically performing read / write benchmark tests on the data storage device to obtain its read / write performance indicators; comparing the read / write performance indicators with the factory-specified performance indicators or the benchmark performance indicators under historical health conditions to calculate the performance retention rate; if the performance retention rate is lower than a preset degradation threshold for M consecutive detection cycles, determining that the storage device has a performance degradation risk and triggering an early warning; where M is a preset positive integer and is negatively correlated with the detection cycle.

[0098] In some embodiments, a standardized read / write benchmark test can be performed on the data storage device at a longer interval than regular condition checks (e.g., every 24 hours or during idle periods after each vehicle power-on). This test writes and reads data blocks of a specific size and pattern to the device to obtain its current sequential read / write speed, random read / write speed, and other key performance indicators. The current performance indicators obtained from the test are compared with the device's nominal performance indicators at the time of manufacture, or with benchmark performance indicators measured under its known health conditions. The performance retention rate P is calculated using the formula: Performance Retention Rate = (Current Performance Indicator Value / Benchmark Performance Indicator Value) × 100%.

[0099] This allows for the early detection of slow performance degradation in storage devices caused by prolonged use, flash memory chip wear, increased bad blocks, or controller aging. While performance degradation doesn't immediately lead to functional failure, it prolongs data write times, increases the risk of packet timestamp misalignment, or causes cache overflows under extremely high data volumes. Through regular benchmarking and performance retention monitoring, potential performance degradation risks can be identified before the device completely fails or severely impacts data quality, enabling predictive maintenance.

[0100] In some embodiments, a number of consecutive monitoring periods M required to determine performance degradation can be set, where M is a preset positive integer. The value of M can be negatively correlated with the length of the monitoring period; that is, the shorter the monitoring period (the more frequent the monitoring), the more consecutive abnormal periods M required for determination can be increased to avoid frequent false alarms. The performance retention rate P calculated for each monitoring period can be recorded. Only when the performance retention rate P is lower than the preset degradation threshold for M consecutive monitoring periods is the data storage device ultimately determined to have a clear risk of performance degradation, and a corresponding warning is triggered.

[0101] By introducing a rule that determines performance by M consecutive times below a threshold, the system effectively filters out random fluctuations in performance metrics caused by instantaneous system load, accidental interference, or single-test errors, significantly improving the accuracy and reliability of performance degradation warnings. This reduces the frequency of false alarms, allowing the system to focus on addressing hardware with genuine potential problems, thus improving maintenance efficiency and reliability.

[0102] S303: In response to a data recording command, perform an immediate check to verify the validity of the recorded data.

[0103] In some embodiments, in response to a data recording instruction, an immediate detection is performed to verify the validity of the recorded data.

[0104] In some embodiments, real-time detection can be a series of targeted checks driven by a specific event—the triggering of a data recording command. The data recording command can be an electrical signal or software message issued by the driver or tester through a physical interface (including but not limited to a dedicated button on the steering wheel) instructing the system to begin recording sensor data. The purpose of real-time detection is to check and verify the key factors determining the success or quality of the recording at the critical moment of recording and within the first time window after recording is completed, thereby implementing real-time quality interception and feedback at the source of data generation, achieving a shift from passive recording to proactive prevention.

[0105] In some embodiments, step S303 may specifically include: in response to a data recording instruction, verifying the mounting status of the data storage device; if the data storage device is detected to be unmounted, performing mounting; if mounting fails, prohibiting data recording.

[0106] In some embodiments, the mounting state of the data storage device may be the logically writable state of the external solid-state drive in the first vehicle-side domain controller at the time the recording instruction is issued.

[0107] In some embodiments, in response to a data recording command, the system can check whether the file system directory (mount point) corresponding to the target external storage device is effectively mounted and in a read-write state. If the check result indicates that it is correctly mounted, the subsequent data stream writing process is allowed to start. If the check result indicates that it is not mounted, the system automatically attempts to perform a mount operation, which may include activating the device driver, identifying the file system format, and associating it with the specified directory. If the automatic mount operation fails, a control signal is generated to forcibly prohibit data write operations in this data recording process and triggers a voice alarm.

[0108] By constructing a closed-loop control logic of recording triggering, status verification, automatic repair, and failure interception, storage availability checks are extended from the preparation stage to the moment of execution, and an automatic repair mechanism is provided. When automatic repair fails, recording is prohibited, fundamentally eliminating the situation where completely invalid data packets are generated due to last-minute storage failures, significantly saving storage and transmission resources.

[0109] In some embodiments, the recorded data includes autonomous driving data and associated audio tag data. Based on this, step S303 may further include: verifying the sound validity of the audio tag data after recording is completed; and verifying the validity of the data output frequency of a preset data source.

[0110] In some embodiments, audio tag data may be audio files (including but not limited to WAV format) that are synchronously collected and stored by the in-vehicle microphone during the autonomous driving data recording process. Its purpose is to allow the driver or tester to verbally record the current driving scenario, sudden events or subjective feelings of the system, and to provide semantic context for subsequent data retrieval and annotation.

[0111] In some embodiments, after each recording process has officially stopped, the system accesses the audio tag file associated with each recording data packet. The raw digital sample data of this audio file is read. The system calculates the signal strength statistical characteristics of this audio data in the time domain (including but not limited to calculating the average or root mean square value of the absolute amplitude of all sample points) and compares it with a preset silence threshold. If the calculated signal strength characteristic value is lower than the silence threshold, the audio tag data is determined to be silent or invalid, i.e., it does not contain meaningful speech content.

[0112] This implements foolproof verification for voice tag entry, automatically identifying invalid audio files caused by microphone malfunction, accidental button presses (starting recording but not speaking), or extremely noisy environments that mask human voices. By instantly identifying and alerting users when a tag is invalid, it avoids unnecessary subsequent processing of invalid voice data and encourages re-recording or annotation, greatly improving the overall quality and usability of voice tags as data assets.

[0113] In some embodiments, the preset data source may be a specific data stream that is pre-configured and requires recording, including but not limited to point cloud topics from LiDAR or image topics from cameras. Data output frequency validity may refer to whether the actual rate at which the data source publishes data during recording meets the minimum requirements necessary to ensure the algorithm's application.

[0114] In some embodiments, after recording is complete, the metadata of the generated data packet file can be parsed. The metadata can be structured information describing the data packet content, recording the number of messages, timestamp sequence, etc., for each recorded data source (topic) within the packet. The total number of messages from a specified preset data source during this recording is extracted from the metadata as its actual output data volume. Based on the expected output frequency pre-configured for the data source and the actual total recording duration, the expected data volume (expected number of messages) is calculated through multiplication. The actual output data volume is compared with the expected data volume to calculate the achievement ratio. If the achievement ratio is lower than a preset validity threshold (e.g., 98%), the data source is deemed to have failed to meet the frequency requirement in this recording, and the output frequency is invalid.

[0115] By immediately verifying the key signal streams of each recorded output data and providing validity conclusions, the quality baseline of the data entering the database is ensured, providing a reliable data integrity guarantee for downstream algorithm training and testing.

[0116] S304: Based on the abnormal events identified by at least one of the start detection, timed detection and instant detection, determine the broadcast priority according to the abnormal type of the abnormal event.

[0117] In some embodiments, step S304 may specifically include: determining the broadcast priority based on the abnormal event identified by at least one of the start detection, timed detection and instant detection, according to the abnormal type of the abnormal event.

[0118] In some embodiments, the anomaly type can be a standardized label categorizing specific detected problems, such as "disk mount anomaly," "Type-C connection failure," "critical topic missing," or "invalid sensor calibration file." The broadcast priority can be an attribute parameter used to sort the order and urgency of alarm information presentation.

[0119] In some embodiments, a basic priority level can be configured for each predefined anomaly type. This configuration is based on the anomaly's potential impact on the success of the data acquisition task and driving safety. Specifically, anomalies that completely prevent data recording (including but not limited to hard drive mounting failure) can be assigned the highest priority; anomalies that only affect partial data quality but allow recording to continue (including but not limited to a slightly lower frequency from a single camera) can be assigned a medium priority; and suggestive or advisory information (including but not limited to insufficient remaining capacity) can be assigned a lower priority. When an anomaly event is identified, the system directly maps the corresponding broadcast priority according to its anomaly type.

[0120] By pre-setting differentiated response levels for anomalies of different natures, it ensures that limited driving attention resources can be prioritized for the most urgent and serious issues, laying the foundation for subsequent orderly reporting and improving the efficiency and safety of human-computer interaction.

[0121] In some embodiments, the broadcast priority includes at least three levels to distinguish the urgency of abnormal events.

[0122] In some embodiments, the preset broadcast priority may include at least three discrete levels. The highest level corresponds to anomalies that require immediate driver attention and may need immediate action; these anomalies often directly lead to loss of recording function or pose a safety risk. The intermediate level corresponds to anomalies that require driver awareness and appropriate handling; these anomalies affect data quality but the system can still operate at a degraded level. The lowest level corresponds to prompts that only provide status information and do not affect the current task.

[0123] Multi-level classification makes the urgency and severity of alarm information immediately apparent. Drivers do not need to analyze specific anomaly descriptions; they can quickly determine the severity of the problem and the required response speed simply by prioritizing the alarm. This greatly reduces the cost of information comprehension and enables faster and more accurate decision-making in complex driving environments, effectively balancing anomaly notification with driving safety.

[0124] In some embodiments, determining the broadcast priority based on the anomaly type of the abnormal event may further include: calculating at least one correction factor based on the context information when the abnormal event is detected; and determining the broadcast priority of the abnormal event based on the baseline anomaly index of the anomaly type of the abnormal event and the at least one correction factor.

[0125] In some embodiments, the baseline anomaly index may be an initial priority score pre-defined for each anomaly type. Context information may be real-time environmental and status data captured by the system when an anomaly occurs. The correction factor may be a coefficient calculated based on the context information and used to weight and adjust the baseline index.

[0126] In some embodiments, when an abnormal event is detected, a baseline abnormality index B corresponding to its abnormality type can be obtained. One or more correction factors F_i can be calculated based on real-time context information at the time of the abnormality (including but not limited to vehicle speed, recording task status, other concurrent abnormalities, etc.). Each correction factor is assigned a preset weight W_i. An aggregation formula (including but not limited to P = B + Σ(W_i)) is used. F_i) calculates the final broadcast priority score P for the abnormal event. Based on the preset score range in which the P value falls, its final broadcast priority level is determined.

[0127] By shifting from static configuration to dynamic calculation of priorities, the urgency of alarms can be intelligently adjusted based on actual conditions. For example, the urgency of an alarm triggered at the start of a long-distance test versus at the end of the test differs for the same low hard drive capacity; dynamic calculation can reflect this difference. This enhances the alarm system's contextual awareness and intelligence, making broadcast suggestions more reasonable and targeted.

[0128] In some embodiments, the correction factor includes at least a time urgency factor and an impact scope factor. Based on this, the calculation of at least one correction factor according to the context information at the time the abnormal event is detected may further include: determining the time urgency factor based on the cumulative duration since the occurrence of the abnormal event; the time urgency factor is positively correlated with the cumulative duration; determining the impact scope factor based on the type and number of data sources affected by the abnormal event; the impact scope factor is positively correlated with the type and number of data sources affected by the abnormal event.

[0129] In some embodiments, the time urgency factor can be a coefficient that quantifies the escalating risk resulting from the continued unresolved anomaly. The impact scope factor can be a coefficient that quantifies the breadth and depth of the impact of the anomaly on the data acquisition system.

[0130] In some embodiments, for the time urgency factor, the cumulative unprocessed time can be calculated from the moment the anomaly is first identified and added to the processing queue. The value of this factor is designed to be positively correlated with the cumulative time, including but not limited to linear or step function growth. For the impact range factor, the list of data sources directly affected by the anomaly can be analyzed. The more critical the data source type (e.g., main LiDAR vs. ultrasonic radar) and the more data sources affected, the larger the calculated impact range factor value. The broadcast priority of the anomaly can be calculated by taking both factors as input and combining them with a benchmark anomaly index of the anomaly type.

[0131] The time urgency incentive system promptly addresses long-standing anomalies, preventing small issues from escalating into major failures; the impact scope ensures that alerts for systemic and global problems are more impactful than those for localized issues. Together, these factors make the priority calculation model more aligned with real-world operations, guiding resources to prioritize resolving issues that become increasingly troublesome and have a wider impact the longer they are delayed.

[0132] S305: Based on the broadcast priority, add the audio prompt file of the abnormal event to the audio broadcast queue.

[0133] In some embodiments, step S305 may further include: adding the audio prompt file of the abnormal event to the audio broadcast queue based on the broadcast priority.

[0134] In some embodiments, the audio prompt file may be a pre-recorded or generated voice segment file bound to a specific exception type, containing a description and prompt of the exception. The audio playback queue may be a data structure maintained in the first vehicle-side domain controller, arranging the voice files to be played in a specific order.

[0135] In some embodiments, after determining the playback priority of an abnormal event, the corresponding audio prompt file can be indexed according to its abnormality type. The path or identifier of the audio file, along with its playback priority, is added to the audio playback queue as a task item. The queue management logic ensures that task items are organized in priority order.

[0136] Decoupling asynchronously generated exception events from synchronous audio playback allows multiple exceptions to be detected, arranged in order, and then processed sequentially by the playback thread. This avoids the detection thread being blocked by playback operations and provides a data structure foundation for implementing complex broadcast scheduling strategies (including but not limited to queueing and merging).

[0137] In some embodiments, step S305 may further include: before adding the audio prompt file of the abnormal event to the audio broadcast queue, determining whether there is an unbroadcast event in the audio broadcast queue that is the same as the abnormal event to be added and / or associated hardware; if so, merging or replacing the abnormal event to be added with existing events in the queue according to preset rules; the preset rules include replacing lower priority similar events with higher priority abnormal events, or generating an aggregated broadcast message for multiple abnormal events related to the same hardware.

[0138] In some embodiments, before adding an audio prompt file for an abnormal event to the audio playback queue, all unplayed task items in the current queue can be traversed. It is determined whether a task item exists that meets one of the following conditions as the event to be added: has the same abnormal type; or is associated with the same hardware device (including but not limited to the same hard drive or the same Type-C interface). If such a task item exists, it is processed according to preset rules. Rule 1: If the priority of the event to be added is higher than the priority of similar events in the queue, the higher-priority event replaces the lower-priority event. Rule 2: If there are multiple abnormal events to be played for the same hardware device, these events are merged to generate a new aggregated playback message, and an aggregated audio file is created or indexed to replace the original multiple independent task items.

[0139] By deduplicating, repeated broadcasts of the same problem are avoided; by aggregating, multiple related problems are explained at once, reducing the number of broadcasts and the total duration. This allows drivers to obtain a more comprehensive and concise overview of the equipment status in a short time, greatly improving the information reception experience in complex fault situations and reducing distraction or annoyance caused by lengthy and repetitive alarms.

[0140] S306: Take out audio prompt files sequentially from the audio broadcast queue for broadcasting.

[0141] In some embodiments, the broadcast can be a human-machine interaction process that uses an audio output device (including but not limited to in-vehicle speakers) connected to a first vehicle domain controller to clearly and orderly convey abnormal content and handling suggestions in the form of pre-recorded or real-time synthesized voice. The purpose is to ensure that key alarm information can be received in a timely and unambiguous manner, while avoiding information overload that may interfere with driving safety, thus forming a real-time closed loop of detection and feedback.

[0142] In some embodiments, step S306 may further include: sequentially retrieving audio prompt files from the audio broadcast queue for broadcasting.

[0143] In some embodiments, a separate, single-threaded audio playback thread can be maintained. This thread continuously monitors the audio playback queue. When the queue is not empty, the playback thread retrieves the next audio prompt file to be played according to the queue scheduling algorithm. It then calls the underlying audio driver to decode the file's content and output it to the vehicle's speakers for playback. During playback, the playback thread is in an exclusive state until the current voice prompt is completed before processing the next task in the queue.

[0144] Single-threaded playback fundamentally eliminates the confusion and incomprehensibility caused by multiple alarm voices playing simultaneously. Sequential retrieval ensures that alarm information is conveyed according to its importance, so that the most important information is always heard by the driver first. This design provides a reliable and controllable output channel for human-machine voice interaction.

[0145] In some embodiments, the above-mentioned method of sequentially retrieving audio prompt files from the audio broadcast queue for broadcast may further include: obtaining driving status parameters of the data acquisition vehicle; determining whether the data acquisition vehicle is in a preset emergency driving scenario based on the driving status parameters; if so, changing the broadcasting method of audio prompt files with a priority lower than a preset emergency threshold in the audio broadcast queue from voice broadcasting to silent interface prompts; and resuming voice broadcasting after the emergency driving scenario ends.

[0146] In some embodiments, driving state parameters may be acquired information reflecting the dynamics of the data acquisition vehicle, including but not limited to vehicle speed, steering angle, acceleration, and emergency braking signals. Emergency driving scenarios may be vehicle handling states determined by rules or models that require a high degree of driver concentration, including but not limited to high-speed overtaking, emergency obstacle avoidance, and driving on complex curves.

[0147] In some embodiments, vehicle driving status parameters can be acquired and analyzed. Based on preset judgment logic, it is determined whether the current situation falls within a preset emergency driving scenario. If an emergency driving scenario is determined, all tasks in the audio broadcast queue with a priority lower than a certain preset emergency threshold are processed: the broadcast method for these tasks is changed from voice broadcast to silent on-screen prompts. Silent prompts can be displayed on the vehicle screen or dashboard using visual forms such as icons or text, but without sound.

[0148] When drivers need to concentrate most on dealing with complex road conditions, non-emergency voice warnings are automatically suppressed and replaced with visual cues, minimizing the distraction and interference with the driver's attention.

[0149] In some embodiments, the vehicle's driving status can be continuously monitored. When the previously determined emergency driving scenario ends (e.g., the vehicle speed and acceleration return to normal range), a recovery mechanism is triggered. For tasks that were converted to silent interface prompts during the emergency scenario, their playback mode can be re-marked as voice playback. These tasks are re-queued in the audio playback queue according to their priority, waiting to be retrieved and played sequentially by the playback thread.

[0150] Once the intense driving phase has passed, the system can automatically re-report previously delayed alarms, ensuring that the driver can still obtain all system status information while maintaining safety, thus achieving a balance between driving safety and information completeness.

[0151] In some embodiments, the sound validity verification of the audio tag data in step S303 above may specifically include: determining whether the audio signal contains valid audio based on the intensity of the audio signal corresponding to the audio tag data.

[0152] In some embodiments, verifying the sound validity of audio tag data can be performed on the quality of the synchronously acquired speech description files after the data recording process is completed. The purpose is to automatically identify and filter out invalid speech input through signal lightness, including but not limited to silent segments, pure environmental noise, or meaningless speech unrelated to the scene, to ensure that the speech tags associated with the autonomous driving dataset have basic readability and application value.

[0153] In some embodiments, determining whether the audio signal contains valid audio based on the intensity of the audio signal corresponding to the audio tag data may further include: calculating the average amplitude or root mean square value of the audio signal within a preset time period; comparing the average amplitude or root mean square value with a preset silence threshold; and determining that the audio signal does not contain valid audio if it is lower than the silence threshold.

[0154] In some embodiments, the audio signal can be a continuous time-domain discrete sample value sequence obtained by decoding audio tag data. The intensity of the audio signal is a physical quantity that quantifies the loudness of a sound; in digital signals, it can be characterized by calculating the statistical characteristics of the sample values. The average amplitude can be the arithmetic mean of the absolute values ​​of the audio signal's sample points. The root mean square (RMS) value can be the square root of the average of the squares of the audio signal's sample values, better reflecting the signal's energy.

[0155] In some embodiments, the audio tag file to be verified can be read and decoded into a discrete audio signal sequence in pulse code modulation format. A preset complete time period is selected from the audio signal (including but not limited to the period from the beginning to the end of the file, or the effective interval after removing the first and last silent segments). The average amplitude of all audio sampling points within the time period is calculated, or its root mean square value is calculated. The calculated average amplitude or root mean square value is compared with a pre-calibrated silence threshold. The silence threshold represents the minimum intensity limit that a valid human voice signal should have in a typical vehicle noise environment. If the calculated intensity characteristic value is lower than the silence threshold, it is determined that this segment of audio tag data does not contain valid audio.

[0156] This filtering mechanism can immediately detect recording failures caused by the microphone not working, the recording function not being activated, or the operator not speaking at all, thus avoiding sending such obviously invalid data into subsequent more complex processing procedures.

[0157] In some embodiments, determining whether an audio signal contains valid audio based on the intensity of the audio signal corresponding to the audio tag data may further include: performing frame-by-frame processing on the audio signal to extract the temporal and frequency domain features of each frame; calculating the probability that each frame of audio signal belongs to valid human voice based on the temporal and frequency domain features using a preset audio classification model; counting the proportion of frames with a probability exceeding a human voice determination threshold in the entire audio signal; and determining that the audio signal does not contain valid audio if the proportion is lower than the valid speech proportion threshold.

[0158] In some embodiments, frame segmentation can be a preprocessing operation that divides a continuous long audio signal into short signal segments of fixed duration. Time-domain features can be descriptive parameters directly calculated from the waveform of a single-frame audio signal, including but not limited to zero-crossing rate and short-time energy. Frequency-domain features can be parameters calculated after transforming a single-frame audio signal from the time domain to the frequency domain (including but not limited to fast Fourier transform and wavelet transform), including but not limited to spectral centroid and Mel-frequency cepstral coefficients. The audio classification model can be a machine learning or deep learning model pre-trained using audio samples labeled with human and non-human voices, its purpose being to output the probability of belonging to a certain category based on the input feature vector.

[0159] In some embodiments, the complete audio signal can be segmented into frames to obtain a series of consecutive short audio frames. For each frame, a set of time-domain features and a set of frequency-domain features are extracted in parallel or serially to form the feature vector of that frame. This feature vector is input into a preset audio classification model, which outputs a probability value between 0 and 1, representing the likelihood that the audio signal content of that frame belongs to valid human voice. A voice determination threshold is set. All audio frames are traversed, and the number of frames whose model output probability exceeds this voice determination threshold is counted. The proportion of this number to the total number of frames is calculated. A valid speech proportion threshold is set. If the calculated proportion is lower than this threshold, the entire audio signal is determined not to contain valid audio.

[0160] This effectively filters out continuous background noise or non-human audio, ensuring that the retained speech tags do indeed contain human voice components, providing higher quality input for subsequent speech recognition and conversion, and reducing the false recognition rate.

[0161] In some embodiments, determining whether the audio signal contains valid audio based on the intensity of the audio signal corresponding to the audio tag data may further include: using a preset speech recognition engine to recognize the audio signal and obtain a recognition confidence score; if the recognition confidence score is higher than a first threshold, it is determined that the audio signal contains valid audio; if the recognition confidence score is lower than the first threshold but higher than a second threshold, it is analyzed whether the recognized text content contains preset high-frequency scene keywords; if no high-frequency scene keywords are contained, it is determined that the audio signal does not contain valid audio; if the recognition confidence score is lower than the second threshold, it is determined that the audio signal does not contain valid audio.

[0162] In some embodiments, the speech recognition engine can be a software module capable of converting audio signals into corresponding text. Recognition confidence can be a quantitative score assigned by the speech recognition engine to the accuracy or reliability of its output text. High-frequency scene keywords can be a predefined set of words strongly related to autonomous driving test scenarios.

[0163] In some embodiments, a preset speech recognition engine can be invoked to process the entire audio tag data, obtain the output text result, and simultaneously obtain the overall confidence score corresponding to this recognition process. Two confidence thresholds are set: a first threshold (high confidence threshold) and a second threshold (low confidence threshold), with the first threshold being greater than the second threshold. If the recognition confidence is higher than the first threshold, it indicates that the recognition result is highly reliable, and the audio is determined to contain valid audio. If the recognition confidence is lower than the first threshold but higher than the second threshold, it indicates that the recognition result has some uncertainty. In this case, the recognized text content is analyzed to check whether it contains at least one preset high-frequency scene keyword. If the text does not contain any high-frequency scene keywords, the audio is determined not to contain valid audio (it may be meaningless speech or a recognition error). If the recognition confidence is lower than the second threshold, it indicates extremely poor recognition quality, and the audio is determined not to contain valid audio.

[0164] High-quality recognition results are selected by assessing confidence levels, and keyword matching ensures that the content of the voice tags is relevant to the field of autonomous driving. This effectively filters out recordings that, while containing clear human voices, contain content such as casual conversation or singing that is irrelevant to the data context, thus guaranteeing the semantic value of the voice tags and the overall professionalism of the dataset.

[0165] In some embodiments, the verification of the validity of the data output frequency of the preset data source in step S303 above may specifically include: determining the output data volume of the preset data source based on the metadata generated during the data recording process; determining the expected data volume of the preset data source according to the expected data output frequency and recording duration configured for the data source; comparing the output data volume with the expected data volume; and determining whether the data output frequency of the preset data source is valid based on the comparison result.

[0166] In some embodiments, metadata can be an information file automatically generated during data recording that describes the content and structure of the recorded data packets. For ROS bag format, this is a .metadata file that records the number of messages, timestamp sequences, etc., for each recorded data source. The output data volume can be the total number of messages actually published and recorded by a specified preset data source during this recording, extracted from the metadata. The expected data volume can be the theoretically required total number of messages to be recorded, calculated by multiplying the theoretical performance of the data source (expected output frequency) with the actual duration of this recording (recording duration).

[0167] In some embodiments, after recording is complete, the generated metadata file can be parsed. Records from the target preset data source are located in the metadata, and the values ​​of their corresponding fields are extracted as the output data volume. Simultaneously, the preset expected output frequency F for this data source is obtained, and the precise total recording duration T is obtained from the recording control module. The expected data volume is calculated using the formula: Expected Data Volume = F × T. The output data volume is compared with the expected data volume to calculate the actual achievement rate (output data volume / expected data volume). If the achievement rate is lower than a preset validity threshold, the data output frequency of this data source in this recording is deemed invalid; otherwise, it is deemed valid.

[0168] This can reliably identify overall data loss caused by occasional sensor frame drops, brief software node freezes, or system resource bottlenecks, ensuring that the amount of data entering the database meets basic requirements and providing a reliable quality baseline for downstream applications.

[0169] In some embodiments, the above-mentioned determination of the output data volume of the preset data source based on the metadata generated during the data recording process may further include: extracting the number of messages of the preset data source within multiple consecutive time windows from the metadata; calculating the average value and standard deviation of the output frequency within each time window; determining the frequency stability index based on the comparison result of the average value and standard deviation of the output frequency; and determining the output frequency of the data source as invalid if the frequency stability index is lower than a preset stability threshold.

[0170] In some embodiments, a time window can be a continuous time period evenly divided from the entire recording duration. The number of messages can be the number of messages actually published and recorded by a preset data source within each time window. The average value is the arithmetic mean of the output frequencies within each time window, reflecting average performance. The standard deviation is the degree of dispersion of the output frequencies of each time window relative to the average value, reflecting the magnitude of fluctuation.

[0171] In some embodiments, finer-grained time-series information can be extracted from metadata to obtain the number of messages from a preset data source within multiple consecutive and equally long time windows. Based on the number of messages and the window duration for each window, the actual output frequency within that window is calculated. The average μ and standard deviation σ of the output frequencies across all time windows are calculated. A frequency stability index S is calculated based on the average μ and standard deviation σ. One calculation method is: S = μ / (σ + ε), where ε is a very small positive number (e.g., 1e-5) to prevent division by zero errors. The meaning of this index S is: at the same average frequency μ, the smaller the standard deviation σ (the more stable the output), the larger the value of S. A preset stability threshold S_th can be set. If the calculated frequency stability index S is lower than S_th, the output frequency of the data source is deemed invalid, even if its total output data volume may meet the standard.

[0172] This can identify hidden quality issues where the total number of frames meets the target but the data is intermittently severe. For example, if a camera frequently experiences momentary stuttering (drastic frequency fluctuations) during recording, although the total frame rate may be close to the expected value, its unstable output will seriously affect the performance of time-synchronization-based perceptual fusion algorithms. By introducing a stability index, such problems can be effectively detected, improving the evaluation dimensions of data quality.

[0173] In some embodiments, the above method may further include: in response to a data recording instruction, recording the triggering method, vehicle configuration information, and data storage path for data recording; and associating the recorded triggering method, vehicle configuration information, and data storage path with the recorded audio tag data.

[0174] In some embodiments, the triggering method can be an interactive means of initiating data recording, including but not limited to steering wheel button triggering, voice command triggering, or remote command triggering. Vehicle configuration information may include, but is not limited to, a unique vehicle identifier and a mission area code. The data storage path may be the complete storage directory of the recorded sensor data packets on the storage device.

[0175] In some embodiments, a recording event is triggered the moment a data recording instruction is responded to and begins execution. This event captures a timestamp, trigger method, vehicle configuration information, and the data storage path allocated for recording. This information can be encapsulated into an associated record. During recording, when the voice tag recording function is activated, this associated record is bound to the audio file being recorded. When recording ends, this associated information is written to the audio tag file's associated description file or database index.

[0176] This achieves precise spatiotemporal correlation of multimodal data (sensor streams and speech streams) at the source of generation, solving the tedious and error-prone problem of relying on manual matching based on ambiguous information such as filenames and times in traditional methods. By automatically recording key context, it ensures that each speech tag can be unambiguously traced back to the specific data segment it describes.

[0177] In some embodiments, associating the recorded triggering method, vehicle configuration information, and data storage path with the recorded audio tag data may further include: generating a metadata signature, wherein the signature is calculated using a hash function based on the recorded trigger timestamp, vehicle identifier, and data storage path; and simultaneously writing the metadata signature into the header information area of ​​the audio tag data file and the metadata area of ​​the corresponding data recording file.

[0178] In some embodiments, the metadata signature can be a fixed-length unique digital fingerprint calculated from a set of associated information. The hash function can be a one-way function that converts an input of arbitrary length into a fixed-length output, possessing collision resistance. The header information area can be a reserved area in the audio tag file format for storing custom metadata. The metadata area of ​​a data recording file can refer to a specific part of the data packet file used to store recording information.

[0179] In some embodiments, after generating the associated information, this information is concatenated into a string according to a preset format. This string is then input into a selected hash function to calculate its hash value, which serves as the metadata signature for the recording task. After the audio tag file is written, the calculated metadata signature is written to the header information area allowed by that file format. Simultaneously, the same metadata signature is also written to the metadata area of ​​the corresponding sensor data packet (or a specific auxiliary description file).

[0180] Digital fingerprinting technology establishes a strong, non-repudiable chain of evidence across files. Due to the uniqueness of hash values ​​and their sensitivity to input information, any modification to a file or incorrect association information will cause signature verification to fail. This provides a cryptographic-level verification method for data integrity, authenticity, and the correctness of association.

[0181] In some embodiments, the above method further includes: if the audio tag data is found to be missing corresponding association information, extracting timestamps and vehicle identification features from the file name or file attributes; performing fuzzy matching and retrieval in the data recording log based on the extracted features; if a data recording record with a matching degree higher than a preset threshold is retrieved, reconstructing the association relationship and supplementing the association information.

[0182] In some embodiments, missing association information may mean that the audio tag file cannot find its corresponding accompanying description file or index record. Fuzzy matching can be a technique that performs retrieval based on partial feature similarity without relying on precise key values.

[0183] In some embodiments, if a lack of valid association information is detected in an audio file during routine inspection or processing of audio tag data, a repair process is initiated. Attempts can be made to extract potential timestamp information and vehicle identification feature patterns from the audio file's filename and file system creation / modification time attributes. The extracted features (including but not limited to approximate time and suspected vehicle ID) can be used to query the global data recording log database. The query employs fuzzy matching logic, for example, searching for recordings that overlap in time windows and partially match the vehicle identifier. A comprehensive matching score is calculated for each potential match. If a data recording record with a matching score higher than a preset threshold is found, the association relationship for the audio tag file is reconstructed based on the information in that record, and complete association information is added.

[0184] In some embodiments, the above method may further include: acquiring status information of at least one second vehicle-mounted domain controller; and based on the status information, performing at least one of startup detection, timed detection, and instant detection to identify abnormal events of the second vehicle-mounted domain controller. Accordingly, step S304 may further include: determining a broadcast priority based on the abnormal events identified by at least one of the startup detection, timed detection, and instant detection, and the identified abnormal events of the second vehicle-mounted domain controller, according to the abnormality type of the abnormal events.

[0185] In some embodiments, in an autonomous driving data acquisition system equipped with multiple on-board computing nodes, the master control node (first vehicle-side domain controller) can perform coordinated status monitoring and unified alarm management of the subordinate nodes (second vehicle-side domain controller). The aim is to integrate the distributed data acquisition hardware units into a logically unified system health view for centralized management, thereby improving the overall observability and operational efficiency of the complex system and ensuring the global reliability of the data acquisition task.

[0186] In some embodiments, the second vehicle-mounted domain controller may be another on-board computing module within the same vehicle, other than the first vehicle-mounted domain controller which serves as the management entity, responsible for processing different subsets of sensors or performing specific functions. Status information may be data reflecting the health of the second vehicle-mounted domain controller and its associated peripherals, including but not limited to hard disk mount lists, storage space utilization, specific process status, network connection information, etc.

[0187] In some embodiments, the first vehicle-mounted domain controller can periodically or on demand initiate status query requests to one or more second vehicle-mounted domain controllers via a secure remote communication protocol. The second vehicle-mounted domain controller executes the local query command and encapsulates and returns the result. The first vehicle-mounted domain controller receives the returned status information. Based on the received status information, the first vehicle-mounted domain controller applies the same logical rules as the local detection to perform targeted analysis, including but not limited to: using the returned hard disk usage information to perform capacity availability verification equivalent to that in periodic detection; and using the returned process list to perform existence verification of critical services equivalent to that in startup detection. By applying these rules, the first vehicle-mounted domain controller identifies abnormal events on the second vehicle-mounted domain controllers. The first vehicle-mounted domain controller aggregates the abnormal events it identifies with those identified from the second vehicle-mounted domain controllers to form a global abnormal event list. The first vehicle-mounted domain controller sorts and schedules the broadcast of all abnormal events in this global list according to preset priority rules.

[0188] By centralizing and standardizing monitoring of the multi-domain controller architecture, the limitations of a single domain controller managing only local hardware are overcome. This allows the main domain controller to monitor the health status of all critical data acquisition nodes in the vehicle from a unified perspective and with standardized procedures. This greatly simplifies system operation and maintenance. Drivers or testers no longer need to monitor multiple devices separately; they can grasp the overall situation simply through the unified broadcast from the main domain controller, significantly improving the manageability and operational safety of complex systems.

[0189] In some embodiments, the above-mentioned broadcasting based on the identified abnormal events of the second vehicle-mounted domain controller may further include: performing aggregated analysis on abnormal events of the same type from the first vehicle-mounted domain controller and the at least one second vehicle-mounted domain controller; if the abnormal events reported by multiple domain controllers point to the same hardware device or the same root cause, merging the multiple abnormal events to generate an aggregated alarm message, and determining the broadcast priority of the aggregated alarm message according to the highest priority among the abnormal events; the aggregated alarm message includes the identifier of the affected domain controller and a summary of the abnormal type.

[0190] In some embodiments, aggregation analysis can be a process of examining and summarizing the correlations of multiple anomalous events from different domain controllers. The same hardware device can be a component that may be physically shared or relied upon by multiple domain controllers, including but not limited to, the same power supply module powering multiple domain controllers, or the same network switching device accessed by multiple domain controllers through different interfaces. The same root cause can be a common source of failure that can cause similar anomalies in multiple domain controllers.

[0191] In some embodiments, the first domain controller may maintain a global list containing all anomaly events to be broadcast. Each event in the list includes information such as its source domain controller identifier, anomaly type, and associated hardware. This list can be scanned to identify sets of anomaly events that meet the following criteria: these events have the same anomaly type, their associated hardware device identifiers are the same, or they are determined by root cause reasoning rules to point to the same root cause. When such a set of events is identified, these independent events are merged into a single aggregated alarm message. The generation rule for this aggregated alarm message may be: extracting the common anomaly type description of these events as a summary and listing all affected domain controller identifiers. The broadcast priority of this aggregated alarm message is determined by the highest priority of all original events in the event set. The original multiple independent alarm event entries are replaced by this single aggregated alarm message entry.

[0192] In distributed systems, a common hardware failure may trigger similar alarms from multiple computing nodes. Merging these related alarms into a single, more comprehensive, and clearer system-level alarm avoids the same fundamental problem being repeatedly broadcast. This significantly reduces the cognitive load on the driver, enabling them to quickly grasp the essence and scope of the problem.

[0193] As can be seen from the above embodiments of the autonomous driving data recording anomaly detection method provided in this specification, the first vehicle-side domain controller of this embodiment can perform startup detection to verify the readiness state required for data recording; perform timed detection at preset intervals to verify the operating status of the hardware on which data recording depends; and perform real-time detection in response to data recording instructions to verify the validity of the recorded data. Based on the abnormal events identified by at least one of the startup detection, timed detection, and real-time detection, the playback priority is determined according to the anomaly type of the abnormal event. Based on the playback priority, the audio prompt file of the abnormal event is added to the audio playback queue; and the audio prompt files are sequentially retrieved from the audio playback queue for playback. Thus, by integrating the three-level collaborative detection mechanism of startup detection, timed detection, and real-time detection, fault detection and quality management of the entire autonomous driving data recording process are realized. By significantly shifting the node of anomaly discovery and handling from after-the-fact to during and before the event, invalid data caused by hardware connection abnormalities, configuration errors, or incomplete data streams can be prevented from the source. Meanwhile, by introducing a priority queued broadcasting mechanism based on anomaly type, it is ensured that key alarm information can be delivered to the driver in an orderly and clear manner in complex multi-anomaly scenarios, effectively avoiding the interference of broadcasting conflicts and information overload on driving safety, thereby improving the reliability of data collection quality and ensuring the safety of the vehicle operating environment.

[0194] Figure 5 shows a flowchart of a method for generating tags for autonomous driving recorded data according to an embodiment of this specification, and Figure 6 shows a schematic flowchart of the overall logic of the method for generating tags for autonomous driving recorded data according to an embodiment of this specification. The method for generating tags for autonomous driving recorded data can be applied to a backend server. Although this specification provides method operation steps or device structures as shown in the following embodiments or figures, more or fewer operation steps or module units may be included in the method or device based on conventional or non-inventive effort. In steps or structures where there is no logically necessary causal relationship, the execution order of these steps or the module structure of the device is not limited to the execution order or module structure described in the embodiments and figures of this specification. When the method or module structure is applied in actual devices or terminal products, it can be executed sequentially or in parallel according to the method or module structure shown in the embodiments or figures (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed processing environment).

[0195] In some embodiments, the autonomous driving data acquisition system may include a backend server.

[0196] The backend servers can be physical or virtual servers deployed in data centers, or cloud server clusters using a distributed architecture. The construction of the high-frequency vocabulary database can be based on continuous iteration using industry data statistics, expert experience screening, and feedback from real-world scenarios. After the structured data tags are generated, manual correction can be supported, and the correction results can be synchronized to the input device to form a closed loop of data collection and annotation.

[0197] In some embodiments, the backend server can synchronously obtain audio tag files and their associated metadata generated during the data recording process from at least one vehicle-side domain controller. The backend server can perform speech recognition on the audio tag files to obtain initial text information. Based on a pre-defined high-frequency vocabulary database for the autonomous driving field, the backend server can standardize and correct the terminology of the initial text information to improve the standardization and accuracy of the tags. The backend server can combine the standardized text information with associated data such as abnormal events synchronized from the vehicle-side, and automatically fill in and generate data tags according to a pre-defined structured template. The fields of the data tags may include scenario, problem, vehicle, and environmental information.

[0198] Specifically, as shown in Figure 5, a tag generation method for autonomous driving recording data that can be applied to a backend server, provided by one embodiment of this specification, may include the following steps.

[0199] S501: Obtain audio tag data and its associated data generated during the data recording process from at least one vehicle-side domain controller; the associated data includes the data recording triggering method, vehicle configuration information, and data storage path.

[0200] In some embodiments, audio tag data and its associated data generated during the data recording process are obtained from at least one vehicle-side domain controller; the associated data includes the data recording triggering method, vehicle configuration information, and data storage path.

[0201] In some embodiments, unstructured voice tags and their associated context information distributed across various vehicle domain controllers can be reliably, completely, and systematically aggregated to a backend server to prepare raw data materials for subsequent intelligent processing and asset management.

[0202] In some embodiments, step S501 may further include: establishing a connection with the vehicle domain controller; downloading audio tag files and associated metadata files from a directory specified by the vehicle domain controller based on a preset synchronization task strategy; and performing integrity verification on the downloaded files, wherein the verification can be achieved by comparing whether the locally calculated file verification value is consistent with the original verification value obtained synchronously from the vehicle domain controller.

[0203] In some embodiments, the backend server can establish a connection with the target vehicle domain controller. The connection establishment process follows the authentication and encryption procedures of a secure file transfer protocol. After the connection is established, the backend server accesses the specified directory on the vehicle domain controller according to the preset synchronization task policy for each vehicle. The backend server scans the directory, identifies audio tag files and their corresponding metadata files that conform to the naming rules or file types, and downloads them to the server. For each downloaded file, the backend server calculates its file checksum. Simultaneously, the server synchronously obtains the original checksum of the file, which was pre-calculated and stored on the source end, from the vehicle. The locally calculated checksum is compared with the original checksum. If the two checksums match perfectly, the file transfer is considered complete and error-free; if they do not match, the file may have been corrupted during transmission, triggering a re-download or error reporting process.

[0204] S502: Perform speech recognition on the audio tag data to obtain text tag data.

[0205] In some embodiments, speech recognition is performed on the audio tag data to obtain text tag data.

[0206] In some embodiments, unstructured audio tag data can be converted into machine-readable, searchable, and analyzable text information, and domain knowledge can be used to enhance its professionalism and accuracy.

[0207] In some embodiments, step S502 may specifically include: performing speech recognition on the audio tag data to obtain first text tag data; and correcting the first text tag data based on a preset autonomous driving vocabulary database to obtain second text tag data.

[0208] In some embodiments, the first text label data may be the raw text result obtained by a general speech recognition engine from the initial recognition of audio label data, which may contain homophone errors, inaccurate recognition of technical terms, etc. The preset autonomous driving vocabulary can be a set of terms specifically built for autonomous driving data collection scenarios, the purpose of which is to provide standardized technical vocabulary expressions for correcting and standardizing recognition results. The second text label data may be the standardized and normalized final text output obtained after correction by the vocabulary.

[0209] In some embodiments, the synchronously acquired audio tag data file can be processed to output first text tag data. The first text tag data is then compared with entries in a preset autonomous driving vocabulary. The comparison process includes searching for segments in the identified text that sound similar to entries in the vocabulary but use different characters, or for colloquial descriptions that should be replaced with specific technical terms. When such correctable items are found, the corresponding parts in the first text tag data are automatically replaced with standardized terms from the vocabulary, generating corrected second text tag data.

[0210] By introducing a domain-specific vocabulary for post-processing correction, such errors can be automatically corrected, ensuring that the generated text tags use consistent and accurate terminology within the domain, which greatly improves the standardization of the tags and the accuracy of subsequent text-based retrieval.

[0211] In some embodiments, the above method further includes: constructing an autonomous driving vocabulary library based on industry data statistics, expert experience screening, and scenario feedback iteration; the vocabulary categories of the autonomous driving vocabulary library include at least sensor terms, scenario description terms, and anomaly type terms.

[0212] In some embodiments, industry data statistics can be the process of extracting high-frequency terms from publicly available autonomous driving technology literature, standard documents, and historical data reports. Expert experience screening can be a process in which domain experts manually screen and define the terminology set based on their understanding of sensors, scenarios, and faults. Scenario feedback iteration can be a continuous optimization process that supplements, modifies, or adjusts the weights of the vocabulary based on actual speech recognition correction records and manual review feedback.

[0213] In some embodiments, the initial construction of the vocabulary can integrate, but is not limited to, knowledge from three sources. Source one: statistical analysis of large-scale corpora related to autonomous driving technologies to identify high-frequency nouns, verbs, and scene description phrases. Source two: domain experts review, merge, and supplement the statistical results to form an authoritative basic terminology set. Source three: after the system is put into use, new, frequently used scene description terms not covered by the database are continuously collected and added after confirmation. The completed vocabulary is logically divided into at least three distinct categories: sensor terms, including the names, models, and parameters of various sensors; scene description terms, including descriptions of weather, road conditions, traffic participants, and special events; and anomaly type terms, including standardized fault descriptions that may occur in various stages of data acquisition.

[0214] The multi-source construction approach takes into account both objective frequency and subjective authority, the classification management facilitates maintenance and use, and the continuous iteration mechanism ensures that the system can adapt to newly emerging scenarios and terms, maintaining the effectiveness and cutting-edge nature of its correction effects in the long term.

[0215] In some embodiments, the above-mentioned correction of the first text tag data based on a preset autonomous driving vocabulary database may further include: recording the words and their contexts that are replaced or inserted when the first text tag data is corrected during each recognition process; calculating the correction frequency of each word in a specific context and the confirmation rate after correction through manual review; and updating the recommendation weight of each word according to the correction frequency and confirmation rate.

[0216] In some embodiments, the correction record can be an operation log automatically saved each time a word replacement or insertion operation is performed, containing the original word being replaced, the standard word after replacement, and its context text. The correction frequency can be a statistical count of the number of times a word is used to replace other words in a specific context pattern. The manual review confirmation rate can be the percentage of corrections that are recognized as correct when the correction record is subsequently manually sampled or fully reviewed.

[0217] In some embodiments, correction records generated from each batch of speech recognition and correction tasks can be analyzed. For each standard term in the vocabulary, its frequency of occurrence in all correction records is counted, and its contextual features at the time of occurrence are associated. Feedback on the approval or rejection of corrections containing that term is obtained from the human review process. For a given term, its correction frequency in a specific context is denoted as F, and the percentage of terms that pass human review after correction in that context is denoted as R. This can be expressed using the formula W_new = W_old + a. (R F) Update the recommended weight W for this term in this context. Here, W_old is the old weight, and a is the learning rate coefficient. Terms with higher weights are given priority for revision when encountering similar contexts subsequently.

[0218] By using a data-driven approach, it is possible to automatically identify which terms are most effective for correction in which contexts (high frequency and high confirmation rate) and prioritize them. This effectively reduces the likelihood of recommending inappropriate terms to specific contexts, improves the accuracy of automatic correction, and reduces the workload of manual review due to inaccurate automatic correction.

[0219] In some embodiments, step S502 may further include: using a preset recognition model to perform speech recognition on the audio tag data to obtain text tag data; the preset recognition model is coupled with a speech recognition model, a speech endpoint detection model, and a punctuation recovery model.

[0220] In some embodiments, the preset recognition model may be composed of three functionally interconnected sub-models working together. The purpose of the speech recognition model is to map a continuous sequence of digital signals representing sound into a corresponding sequence of text. It may contain an acoustic model and a language model. The acoustic model is responsible for learning the relationship between audio frame features and phonemes or word units; the language model scores and adjusts recognition candidates based on the statistical patterns or deep semantics of the text sequence to improve recognition accuracy. The purpose of the speech endpoint detection model is to intelligently identify which parts of an audio signal contain valid speech content and which parts are silence, background noise, or other non-speech segments. This model locates the start and end points of speech segments by analyzing the short-time energy and spectral characteristics of the audio signal or by using a deep learning model. The purpose of the punctuation recovery model is to automatically add appropriate punctuation marks, such as periods, commas, and question marks, to a continuous text sequence output by the speech recognition model that does not contain any punctuation. This significantly improves the readability and structure of the text, which is crucial for subsequent natural language understanding and information extraction.

[0221] In some embodiments, the preset recognition model may invoke an integrated speech endpoint detection sub-model to process the input audio tag data. This sub-model analyzes the audio stream, identifies and marks the start and end times of all segments containing valid human voices. Based on these marks, the complete audio stream is segmented into one or more clean speech segments, while filtering out silence or pure noise between segments.

[0222] In some embodiments, each obtained clean speech segment can be sequentially input into an integrated speech recognition sub-model. This sub-model independently recognizes each segment and outputs the corresponding text paragraph without punctuation.

[0223] In some embodiments, all output text segments without punctuation can be concatenated chronologically into a complete, long text sequence without punctuation. This long text sequence is then input into an integrated punctuation recovery sub-model. This model analyzes the text's grammatical structure, semantic pauses, and context, predicts and inserts appropriate punctuation marks, and generates the final, readable text tag data.

[0224] By performing endpoint detection beforehand, invalid audio segments can be eliminated, reducing the amount of data that the subsequent speech recognition model needs to process. By performing punctuation recovery afterward, the generated text label data conforms to written language standards, has a clear structure, and clearly defines semantic segments.

[0225] In some embodiments, step S502 may further include: performing speech recognition on the audio tag data to obtain first text tag data and the confidence level of the first text tag data; if the confidence level of the first text tag data is lower than the first text tag confidence threshold, performing a matching search in the preset autonomous driving vocabulary database; replacing the recognition result in the first text tag data with the matched standardized terms; if the confidence level of the replaced first text tag data is lower than the second text tag confidence threshold, marking it as content to be manually reviewed, wherein the second text tag confidence threshold is lower than the first text tag confidence threshold.

[0226] In some embodiments, confidence can be a probability score for each segment of text obtained from speech recognition, representing the degree of certainty regarding the recognition result for that segment. The first text label confidence threshold can be a high confidence threshold used to filter out high-confidence recognition results for direct adoption. The second text label confidence threshold can be a low confidence threshold used to define low-quality results that need to be completely handled manually.

[0227] In some embodiments, after processing the audio tag data, the overall confidence score S corresponding to the first text tag data can be output along with the first text tag data. If the confidence score S is higher than the preset first text tag confidence threshold, the recognition result is determined to be highly reliable, and the first text tag data can be used as the final second text tag data without vocabulary correction. If the confidence score S is lower than the first text tag confidence threshold, a vocabulary-based correction process is initiated. The recognition result is matched with the vocabulary, and the candidate fields are replaced with the matched standardized terms to generate a corrected text. A corrected confidence score S' is then re-evaluated based on a certain rule. If the corrected confidence score S' is still lower than the preset second text tag confidence threshold, it indicates that the automatic processing has failed to meet the reliability standard. The audio tag and its text data are marked as awaiting manual review and placed in a special queue for manual intervention.

[0228] By grading confidence levels, resources are allocated rationally: high-confidence results are processed quickly to ensure efficiency; medium-confidence results trigger automatic correction to improve quality; and low-confidence results are subject to manual review to ensure a minimum level of reliability. This strategy effectively controls the quality risks of the output text while maintaining overall processing throughput.

[0229] S503: Generate structured autonomous driving data tags based on the text tag data and the associated data.

[0230] In some embodiments, structured autonomous driving data tags are generated based on the text tag data and the associated data.

[0231] In some embodiments, identified text tag data, associated data synchronized from the vehicle, and abnormal event information can be integrated, organized, and enriched according to a standardized framework to automatically generate high-quality structured data tags.

[0232] In some embodiments, step S503 may specifically include: extracting keywords from the text tag data; combining the abnormal event information obtained from at least one vehicle domain controller, matching and filling the keywords with fields in a preset structured tag template to obtain autonomous driving data tags; the fields of the structured tag template include at least the following: recording date, geographical location, vehicle identification, environmental information, road type, problem description, problem classification, and data storage path.

[0233] In some embodiments, keywords can be core words or phrases automatically identified from text tag data that summarize the scenario or problem. Abnormal event information can be abnormal records synchronized from the vehicle-side domain controller and identified by a three-level detection mechanism during data acquisition. The structured tag template can be a predefined data schema that specifies which fields the final generated tags should contain and the data type of each field. Its field design aims to comprehensively describe a data acquisition task.

[0234] In some embodiments, natural language processing can be performed on the corrected text tag data (second text tag data) to extract the keyword set using techniques such as part-of-speech tagging and named entity recognition. A list of abnormal event information corresponding to the current recording, synchronized from the vehicle, is read. Based on a preset structured tag template, the extracted keywords and abnormal event descriptions are intelligently matched and mapped with various fields in the template. This template contains a series of fields, including but not limited to: recording date, geographical location, vehicle identification, environmental information, road type, problem description, problem category, and data storage path. For example, heavy rain is filled into the environmental information field, the abnormal event description of sparse LiDAR point clouds is filled into the problem description field, and information such as the recording date and vehicle identification are directly obtained from associated data for filling. Finally, a complete and uniformly formatted autonomous driving data tag record is generated.

[0235] By using preset templates, labels with uniform format and clear fields are forced to be output, which changes the problem of inconsistent format and standards caused by relying on manual interpretation of text or free input in the past.

[0236] In some embodiments, step S503 may further include: if the information extracted from the text tag data and associated data is insufficient to fill a specific field in the structured tag template, the missing field is deduced and filled based on a preset domain knowledge graph or reasoning rules; the deduction includes: deducing the potential risk level of the road type based on the filled environmental information field, or deducing the vehicle type correlation of the problem based on the problem description field and the vehicle identification field.

[0237] In some embodiments, the domain knowledge graph can be a semantic network stored in a graph structure that describes entities in the autonomous driving domain and the relationships between them. The inference rules can be pre-defined rules based on logic or statistics, used to derive unknown conclusions from known facts.

[0238] In some embodiments, during the template population process, the backend server detects that one or more fields cannot be directly populated from the currently available text tag data, associated data, and abnormal events. Inference can be derived by calling a domain knowledge graph or preset inference rules. For example, if the environment information field is populated as "heavy rain," but the road type field is "urban arterial road," and the potential risk level field is missing, the knowledge graph may contain the rule: (Environment: Heavy Rain) & (Road Type: Urban Arterial Road) -> (Potential Risk Level: High), which can be used to deduce and populate the potential risk level as "high." As another example, if the problem description field includes "front-view camera shake," and the vehicle identification field is known, the content of the vehicle model association field can be deduced based on the inference rule that a specific vehicle model segment has a known camera bracket resonance problem, indicating that the problem may be related to a specific vehicle model.

[0239] By proactively leveraging domain knowledge, implicit and deep-seated correlations are uncovered. This allows the generated tags to not only record what happened, but also, to some extent, suggest why it happened or what it might lead to, providing richer context and clues for data analysis and problem-solving, and greatly enhancing the added value of data tags.

[0240] In some embodiments, step S503 may further include: if a keyword has a semantic association with the descriptions of multiple candidate fields, calculating the semantic similarity between the keyword and the standard descriptions of each candidate field; obtaining the historical frequency of the keyword matching each candidate field; determining the matching degree between the keyword and each candidate field based on the semantic similarity and historical frequency; and selecting the candidate field with the highest matching degree for filling.

[0241] In some embodiments, semantic similarity can be a quantitative metric that measures how close two words or phrases are in meaning. Historical frequency can refer to statistical information about the number of times a keyword has been successfully matched and populated into a specific template field in past tag generation records.

[0242] In some embodiments, during the matching and filling stage, a keyword may semantically relate to multiple candidate fields in the template. For example, the keyword "congestion" might be related to an environmental information field (describing traffic conditions) or indirectly related to a certain attribute of the road type. The semantic similarity between the keyword and the standard description or example value of each candidate field can be calculated to obtain a set of similarity scores S_semantic. Simultaneously, the historical matching database is queried to obtain the frequency of the keyword being matched to each candidate field in the past, and this frequency is normalized to a historical frequency score S_frequency. According to the formula M = α... S_semantic + β S_frequency calculates the overall matching degree M between the keyword and each candidate field, where α and β are preset weight coefficients. The candidate field with the highest overall matching degree M is selected as the final target for filling the keyword.

[0243] By combining the static semantic associations (similarity) and dynamic historical matching patterns (frequency) of words, it is possible to more reasonably determine the most likely classification of a word in a specific domain scenario. This reduces reliance on simple rules or single-dimensional judgments, effectively reduces the risk of incorrect mapping, and ensures the accuracy of the generated structured labels in terms of field meaning.

[0244] In some embodiments, the method further includes: obtaining the correction result of the structured autonomous driving data tags; and updating the audio tag data in the vehicle domain controller according to the correction result.

[0245] In some embodiments, the final labeling results, which have been manually reviewed and corrected, can be safely and reliably synchronized back to the source—the vehicle-side domain controller—thereby unifying the data description at the data source and forming a complete data governance closed loop of collection-processing-correction-writeback.

[0246] In some embodiments, the corrected result of the structured autonomous driving data label may be the final version of the autonomous driving data label formed after the label is generated, through modification, supplementation, or confirmation of the automatically filled field content by an annotator or algorithm. Audio label data exists in the vehicle-side domain control as audio files, but its associated text description file is the carrier for storing speech recognition text or the final label.

[0247] In some embodiments, the backend server can obtain the submitted and confirmed tag correction results for a specific data recording task. Based on the correction results, it matches the corresponding original audio tag file and its associated text file stored on the vehicle-mounted domain controller. Based on the content of the correction results, it generates or updates the text description file associated with the audio tag file. The updated text description file is then transmitted to the vehicle-mounted domain controller, replacing or overwriting the original version.

[0248] In some embodiments, before updating the audio tag data in the vehicle domain controller based on the correction result, the process may further include: performing a confidence assessment on the correction operation; the confidence assessment is calculated based on at least one of the authorization level of the source of the correction operation, the difference between the corrected content and the original recognized text, and the reliable historical accuracy of the corrected field; if the confidence assessment result is higher than a preset synchronization confidence threshold, an update operation to the vehicle domain controller is performed.

[0249] In some embodiments, confidence assessment can be a quantitative judgment process on whether a correction operation is reliable and suitable for synchronizing the carriage return terminal. Authorization level can be the permission level corresponding to the user or system role performing the correction operation; corrections by higher-level experts have higher reliability than those by junior annotators. The difference between the corrected content and the original recognized text measures the extent of the modification; excessive or anomalous modifications may indicate operational errors or malicious tampering. The reliable historical accuracy rate of the corrected field is a statistical measure of the historical percentage of a specific field that, after being corrected by the same operator or the same type of operation, has been confirmed as correct after a second review.

[0250] In some embodiments, a confidence assessment process is triggered when a correction result to be synchronized exists. Three metrics are calculated: a base confidence score S_auth corresponding to the authorization level of the corrector; the difference D between the corrected text and the original automatically recognized text is calculated using a text similarity algorithm and converted into a difference confidence score S_diff; and the historical database is queried to obtain the corrector's historical accuracy R_history for the modified field. A comprehensive confidence assessment result C is calculated using a preset aggregation function. C is compared with a preset synchronization confidence threshold T. If C > T, an update operation is performed on the vehicle-side domain controller; otherwise, the correction result is marked as pending review, and the administrator is notified for review.

[0251] By automatically identifying potential low-quality corrections or abnormal operations through quantitative models, it effectively prevents inaccurate labeling from contaminating the original vehicle data due to human negligence, misoperation, or even malicious tampering.

[0252] In some embodiments, updating the audio tag data in the vehicle domain controller based on the correction result may further include: converting the corrected structured autonomous driving data tags into a text description file associated with the audio tag file of the vehicle domain controller; and incrementally synchronizing the portions of the text description file that differ from the text description file in a specified directory of the vehicle domain controller to the specified directory.

[0253] In some embodiments, the text description file may be a file stored in the vehicle-side domain control that corresponds one-to-one with the audio tag file and contains tag text content.

[0254] In some embodiments, the corrected structured tags can be converted into a text description file according to a format specification recognizable by the vehicle-side domain controller. The old version of the text description file currently saved in the specified directory of the vehicle-side domain controller and associated with the target audio tag is retrieved. The differences between the old and new text description files are calculated. Difference calculation can employ a line-based comparison algorithm or a more refined content hash comparison. The data representing these differences (including but not limited to patch files with a unified difference format, or directly fragments of difference content) and necessary file metadata are packaged into an incremental update package. This incremental update package is transmitted to the vehicle-side domain controller. Upon receiving the update package, the vehicle-side domain controller applies the differences to the local old version file according to the instructions within, generating a new version of the text description file consistent with the backend.

[0255] As can be seen from the anomaly detection method for autonomous driving data recording provided in the embodiments of this specification, the backend server of this embodiment can obtain audio tag data and its associated data generated during the data recording process from at least one vehicle-side domain controller. The associated data includes the triggering method of data recording, vehicle configuration information, and data storage path. Speech recognition is performed on the audio tag data to obtain text tag data. Based on the text tag data and the associated data, structured autonomous driving data tags are generated. Thus, the combination of voice input and automatic speech recognition replaces the inefficient traditional manual typing method for tag entry, significantly improving the efficiency and convenience of scene information recording. By standardizing and correcting the recognized text using a dedicated autonomous driving vocabulary and associating it with the data recording configuration information uploaded from the vehicle, structured data tags with unified fields and standardized content can be generated. This solves the problem of difficulty in retrieving and managing unstructured voice tags, providing an efficient and accurate index and classification basis for massive amounts of collected data.

[0256] Referring to Figure 7, this embodiment of the specification also provides an anomaly detection device 700 for autonomous driving data recording. This device may specifically include the following structural modules: a startup detection module 701, used to perform startup detection to verify the readiness state required for data recording; a timing detection module 702, used to perform timing detection at a preset period to verify the operating state of the hardware on which data recording depends; an instant detection module 703, used to perform instant detection in response to a data recording command to verify the validity of the recorded data; a determination module 704, used to determine a playback priority based on the anomaly type of the anomaly event identified by at least one of the startup detection, timing detection, and instant detection; an addition module 705, used to add the audio prompt file of the anomaly event to the audio playback queue based on the playback priority; and a playback module 706, used to sequentially retrieve the audio prompt file from the audio playback queue for playback.

[0257] In some embodiments, the recorded data includes autonomous driving data and associated audio tag data.

[0258] Based on this, the aforementioned real-time detection module 703 can be specifically used to: verify the sound validity of the audio tag data after recording is completed; and verify the validity of the data output frequency of the preset data source.

[0259] In some embodiments, the instant detection module 703 described above can also be used to: determine whether the audio signal contains valid audio based on the intensity of the audio signal corresponding to the audio tag data.

[0260] In some embodiments, the real-time detection module 703 described above can also be used to: determine the output data volume of the preset data source based on the metadata generated during the data recording process; determine the expected data volume of the preset data source according to the expected data output frequency and recording duration configured for the data source; compare the output data volume with the expected data volume; and determine whether the data output frequency of the preset data source is valid based on the comparison result.

[0261] In some embodiments, the real-time detection module 703 described above can also be used to: verify the mounting status of the data storage device in response to a data recording command; if the data storage device is detected to be unmounted, perform mounting; if mounting fails, prohibit data recording.

[0262] In some embodiments, the above-described anomaly detection device 700 for autonomous driving data recording can also be used to: in response to a data recording instruction, record the triggering method, vehicle configuration information, and data storage path for data recording; and associate the recorded triggering method, vehicle configuration information, and data storage path with the recorded audio tag data.

[0263] In some embodiments, the above-described anomaly detection device 700 for recording autonomous driving data can also be used to: acquire status information of at least one second vehicle-side domain controller; perform at least one of startup detection, timed detection, and real-time detection based on the status information to identify abnormal events of the second vehicle-side domain controller; and determine a broadcast priority based on the abnormal events identified by at least one of startup detection, timed detection, and real-time detection and the identified abnormal events of the second vehicle-side domain controller, according to the anomaly type of the abnormal events.

[0264] In some embodiments, the startup detection module 701 described above can be used to: verify the validity of vehicle configuration information; verify the mounting status, mounting format, and capacity availability of data storage devices; verify the connection status of the data interface between the first vehicle-side domain controller and the extended device; verify the existence and validity of sensor calibration files; verify the configuration parameters of audio input devices; and verify the existence of preset data sources.

[0265] In some embodiments, the aforementioned timing detection module 702 may be used to: verify the connection status of the data interface between the first vehicle-side domain controller and the extended device at a preset period; and verify the mounting status, mounting format, and capacity availability of the data storage device at a preset period.

[0266] As can be seen from the above, the anomaly detection device 700 for autonomous driving data recording provided in the embodiments of this specification can perform startup detection to verify the readiness state required for data recording; perform timed detection at preset intervals to verify the operating status of the hardware on which data recording depends; perform real-time detection in response to data recording instructions to verify the validity of the recorded data; determine the broadcast priority based on the anomaly type of the anomaly event identified by at least one of the startup detection, timed detection, and real-time detection; add the audio prompt file of the anomaly event to the audio broadcast queue based on the broadcast priority; and sequentially retrieve the audio prompt file from the audio broadcast queue for broadcasting. Thus, by integrating a three-level collaborative detection mechanism of startup detection, timed detection, and real-time detection, fault detection and quality management of the entire autonomous driving data recording process are realized. By significantly shifting the node of anomaly discovery and handling from after-the-fact to during and before the event, invalid data caused by hardware connection abnormalities, configuration errors, or incomplete data streams can be prevented from the source. Meanwhile, by introducing a priority queued broadcasting mechanism based on anomaly type, it is ensured that key alarm information can be delivered to the driver in an orderly and clear manner in complex multi-anomaly scenarios, effectively avoiding the interference of broadcasting conflicts and information overload on driving safety, thereby improving the reliability of data collection quality and ensuring the safety of the vehicle operating environment.

[0267] Referring to Figure 8, this embodiment of the specification also provides a tag generation device 800 for autonomous driving recording data. This device may specifically include the following structural modules: an acquisition module 801, used to acquire audio tag data and its associated data generated during the data recording process from at least one vehicle-side domain controller; the associated data includes the data recording triggering method, vehicle configuration information, and data storage path; an identification module 802, used to perform speech recognition on the audio tag data to obtain text tag data; and a generation module 803, used to generate structured autonomous driving data tags based on the text tag data and the associated data.

[0268] In some embodiments, the recognition module 802 may be specifically used to: perform speech recognition on the audio tag data to obtain first text tag data; and correct the first text tag data based on a preset autonomous driving vocabulary database to obtain second text tag data.

[0269] In some embodiments, the label generation device 800 for the autonomous driving recorded data can also be used to: construct an autonomous driving vocabulary library based on industry data statistics, expert experience screening, and scene feedback iteration; the vocabulary categories of the autonomous driving vocabulary library include at least sensor terms, scene description terms, and anomaly type terms.

[0270] In some embodiments, the generation module 803 can be specifically used to: extract keywords from the text tag data; combine the abnormal event information obtained from at least one vehicle domain controller, match and fill the keywords with fields in a preset structured tag template to obtain autonomous driving data tags; the fields of the structured tag template include at least the following: recording date, geographical location, vehicle identification, environmental information, road type, problem description, problem classification and data storage path.

[0271] In some embodiments, the above-mentioned label generation device 800 for autonomous driving recording data can also be used to: obtain the correction result of the structured autonomous driving data labels; and update the audio label data in the vehicle domain controller according to the correction result.

[0272] As can be seen from the above, the tag generation device 800 for autonomous driving recording data provided in the embodiments of this specification can obtain audio tag data and its associated data generated during the data recording process from at least one vehicle-side domain controller. The associated data includes the triggering method of data recording, vehicle configuration information, and data storage path. Speech recognition is performed on the audio tag data to obtain text tag data. Based on the text tag data and the associated data, structured autonomous driving data tags are generated. Thus, by combining voice input with automatic speech recognition, the inefficient traditional manual typing method for tag entry is replaced, significantly improving the efficiency and convenience of scene information recording. By standardizing and correcting the recognized text using a dedicated autonomous driving vocabulary and associating it with the data recording configuration information uploaded from the vehicle, structured data tags with unified fields and standardized content can be generated. This solves the problem of difficulty in retrieving and managing unstructured voice tags, providing an efficient and accurate index and classification basis for massive amounts of collected data.

[0273] It should be noted that the units, devices, or modules described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. For ease of description, the above devices are described by dividing them into various modules according to their functions. Of course, in implementing this specification, the functions of each module can be implemented in one or more software and / or hardware, or a module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are illustrative. For example, the division of units is a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or communication connection shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical, or other forms.

[0274] Referring to Figure 9, this embodiment of the specification also provides a method for anomaly detection and tag generation of autonomous driving data recording, applied to an autonomous driving data acquisition system. The autonomous driving data acquisition system may include a first vehicle-side domain controller A and a backend server B. The method may include: S901: performing a startup detection to verify the readiness state required for data recording; S902: performing a timed detection at a preset period to verify the operating status of the hardware on which data recording depends; S903: responding to a data recording command, performing an immediate detection to verify the validity of the recorded data; S904: based on at least one of the startup detection, timed detection, and immediate detection... S905: For any abnormal event that occurs, determine the broadcast priority based on the type of abnormal event; S906: Based on the broadcast priority, add the audio prompt file of the abnormal event to the audio broadcast queue; S907: Sequentially retrieve the audio prompt files from the audio broadcast queue for broadcasting; S908: Obtain audio tag data and its associated data generated during the data recording process from at least one vehicle-side domain controller; the associated data includes the triggering method of data recording, vehicle configuration information, and data storage path; S909: Perform speech recognition on the audio tag data to obtain text tag data; S9000: Generate structured autonomous driving data tags based on the text tag data and the associated data.

[0275] It is understood that the descriptions and specific implementation methods of the above steps can be understood by referring to the sections on anomaly detection methods and tag generation methods for autonomous driving data recording in Figures 3, 4, 5 and 6, and will not be repeated here.

[0276] Based on the above-described anomaly detection method for autonomous driving data recording, this specification also provides a first vehicle-side domain controller. Referring to Figure 10, the first vehicle-side domain controller 1000 includes a network communication port 1001, a processor 1002, and a memory 1003. These structures are connected by internal cables so that each structure can perform specific data interaction.

[0277] The processor 1002 can specifically be used to perform startup detection to verify the readiness state required for data recording; perform timed detection at preset intervals to verify the operating state of the hardware on which data recording depends; perform real-time detection in response to data recording instructions to verify the validity of the recorded data; determine the playback priority based on the abnormal event identified by at least one of the startup detection, timed detection, and real-time detection, according to the abnormality type of the abnormal event; add the audio prompt file of the abnormal event to the audio playback queue based on the playback priority; and sequentially retrieve the audio prompt file from the audio playback queue for playback.

[0278] The memory 1003 can be used to store the corresponding instruction program, as well as related data such as target data.

[0279] Based on the above method, the relevant structural performance of computer equipment can be effectively utilized to improve the data processing speed of electronic devices and efficiently realize the data processing for anomaly detection in autonomous driving data recording.

[0280] In this embodiment, the network communication port 1001 can be a virtual port bound to different communication protocols, thereby enabling the sending or receiving of different data. For example, the network communication port can be a port responsible for web data communication, a port responsible for FTP data communication, or a port responsible for email data communication. Furthermore, the network communication port can also be a physical communication interface or communication chip. For example, it can be a wireless mobile network communication chip, such as GSM or CDMA; it can also be a Wi-Fi chip; or it can be a Bluetooth chip.

[0281] In this embodiment, the processor 1002 can be implemented in any suitable manner. For example, the processor can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers, etc. This specification is not limiting.

[0282] In this embodiment, the memory 1003 may include multiple layers. In a digital system, anything that can store binary data can be a memory. In an integrated circuit, a circuit with storage function but no physical form is also called a memory, such as RAM, FIFO, etc. In a system, a storage device with a physical form is also called a memory, such as a memory stick, TF card, etc.

[0283] Based on the above-described method for generating tags for autonomous driving recording data, this specification also provides a backend server. Referring to Figure 11, the backend server 1100 includes a network communication port 1101, a processor 1102, and a memory 1103. These structures are connected by internal cables so that each structure can perform specific data interaction.

[0284] The processor 1102 is specifically used to acquire audio tag data and its associated data generated during the data recording process from at least one vehicle-side domain controller; the associated data includes the triggering method of data recording, vehicle configuration information and data storage path; perform speech recognition on the audio tag data to obtain text tag data; and generate structured autonomous driving data tags based on the text tag data and the associated data.

[0285] The memory 1103 can be used to store corresponding instruction programs, as well as related data such as target data.

[0286] Based on the above method, the relevant structural performance of computer equipment can be effectively utilized to improve the data processing speed of electronic devices and efficiently realize the data processing for anomaly detection in autonomous driving data recording.

[0287] In this embodiment, the network communication port 1101 can be a virtual port bound to different communication protocols, thereby enabling the sending or receiving of different data. For example, the network communication port can be a port responsible for web data communication, a port responsible for FTP data communication, or a port responsible for email data communication. Furthermore, the network communication port can also be a physical communication interface or communication chip. For example, it can be a wireless mobile network communication chip, such as GSM or CDMA; it can also be a Wi-Fi chip; or it can be a Bluetooth chip.

[0288] In this embodiment, the processor 1102 can be implemented in any suitable manner. For example, the processor can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers, etc. This specification is not limiting.

[0289] In this embodiment, the memory 1103 may include multiple layers. In a digital system, anything that can store binary data can be a memory. In an integrated circuit, a circuit with storage function but no physical form is also called a memory, such as RAM, FIFO, etc. In a system, a storage device with a physical form is also called a memory, such as a memory stick, TF card, etc.

[0290] This specification also provides a computer-readable storage medium based on any of the above-described methods for anomaly detection in autonomous driving data recording and for generating tags for autonomous driving recorded data. The computer-readable storage medium stores computer program instructions that, when executed, can: perform a startup detection to verify the readiness state required for data recording; perform a timed detection at a preset period to verify the operating state of the hardware on which data recording depends; perform an instant detection in response to a data recording instruction to verify the validity of the recorded data; determine a playback priority based on the anomaly type of the anomaly event identified by at least one of the startup detection, timed detection, and instant detection; add the audio prompt file of the anomaly event to an audio playback queue based on the playback priority; and sequentially retrieve the audio prompt files from the audio playback queue for playback. The computer-readable storage medium stores computer program instructions that, when executed, enable the following: acquiring audio tag data and its associated data generated during the data recording process from at least one vehicle-side domain controller; the associated data includes the data recording triggering method, vehicle configuration information, and data storage path; performing speech recognition on the audio tag data to obtain text tag data; and generating structured autonomous driving data tags based on the text tag data and the associated data.

[0291] In this embodiment, the storage medium includes, but is not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Cache, Hard Disk Drive (HDD), or Memory Card. The memory can be used to store computer program instructions. The network communication unit can be an interface configured according to standards specified in the communication protocol for network connection communication.

[0292] In this embodiment, the specific functions and effects implemented by the program instructions stored in the computer-readable storage medium can be explained in comparison with other embodiments, and will not be repeated here.

[0293] This specification also provides a computer program product, comprising at least a computer program, which, when executed by a processor, can perform the following method steps: performing a startup detection to verify the readiness state required for data recording; performing a timed detection at a preset period to verify the operating state of the hardware on which data recording depends; performing an instant detection in response to a data recording instruction to verify the validity of the recorded data; determining a broadcast priority based on the anomaly type of an anomaly event identified by at least one of the startup detection, timed detection, and instant detection; adding the audio prompt file of the anomaly event to an audio broadcast queue based on the broadcast priority; and sequentially retrieving audio prompt files from the audio broadcast queue for broadcast. When the computer program is executed by a processor, it can also perform the following method steps: obtaining audio tag data and its associated data generated during the data recording process from at least one vehicle-side domain controller; the associated data includes the data recording triggering method, vehicle configuration information, and data storage path; performing speech recognition on the audio tag data to obtain text tag data; and generating structured autonomous driving data tags based on the text tag data and the associated data.

[0294] While this specification provides the steps of operation for the methods described in the embodiments or flowcharts, more or fewer steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is one possible order of execution among many steps and does not represent the only possible order. In actual device or client product execution, the methods may be executed sequentially or in parallel as shown in the embodiments or drawings (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that includes a list of elements does not include those elements, but also includes other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded. The terms "first," "second," etc., are used to denote names and do not indicate any particular order.

[0295] Those skilled in the art will also know that, besides implementing the controller using purely computer-readable program code, the same functions can be achieved by logically programming the method steps, making the controller function as logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers (PLCs), and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the devices within it used to implement various functions can also be considered structures within that hardware component. Alternatively, the devices used to implement various functions can be considered as both software modules implementing the method and structures within a hardware component.

[0296] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, classes, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer-readable storage media, including storage devices.

[0297] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this specification can be implemented by means of software plus necessary general-purpose hardware servers. Based on this understanding, the technical solutions of this specification can essentially be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, mobile terminal, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments of this specification.

[0298] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. This specification can be used in numerous general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable electronic devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices, etc.

[0299] Although this specification has been described by way of examples, those skilled in the art will recognize that many variations and modifications are possible without departing from the spirit of this specification, and it is intended that the appended claims cover such variations and modifications without departing from the spirit of this specification.

Claims

1. An anomaly detection method for autonomous driving data recording, characterized in that, The method, applied to a first vehicle-side domain controller, includes: performing a startup detection to verify the readiness state required for data recording; performing a timed detection at a preset period to verify the operating state of the hardware on which data recording depends; performing an instant detection in response to a data recording command to verify the validity of the recorded data; determining a playback priority based on the abnormal event identified by at least one of the startup detection, timed detection, and instant detection, according to the abnormal type of the abnormal event; adding the audio prompt file of the abnormal event to an audio playback queue based on the playback priority; and sequentially retrieving the audio prompt files from the audio playback queue for playback.

2. The method according to claim 1, characterized in that, The recorded data includes autonomous driving data and associated audio tag data; The real-time detection includes: verifying the sound validity of the audio tag data after recording is completed; and verifying the validity of the data output frequency of the preset data source.

3. The method according to claim 2, characterized in that, The verification of the sound validity of the audio tag data includes: determining whether the audio signal contains valid audio based on the intensity of the audio signal corresponding to the audio tag data.

4. The method according to claim 2, characterized in that, The verification of the validity of the data output frequency of the preset data source includes: determining the output data volume of the preset data source based on the metadata generated during the data recording process; determining the expected data volume of the preset data source according to the expected data output frequency and recording duration configured for the data source; comparing the output data volume with the expected data volume; and determining whether the data output frequency of the preset data source is valid based on the comparison result.

5. The method according to claim 1, characterized in that, The real-time detection process further includes: in response to a data recording command, verifying the mounting status of the data storage device; if the data storage device is detected to be unmounted, performing mounting; if mounting fails, prohibiting data recording.

6. The method according to claim 1, characterized in that, The method further includes: in response to a data recording instruction, recording the triggering method, vehicle configuration information, and data storage path for data recording; and associating the recorded triggering method, vehicle configuration information, and data storage path with the recorded audio tag data.

7. The method according to claim 1, characterized in that, The method further includes: acquiring status information of at least one second vehicle-mounted domain controller; performing at least one of startup detection, timed detection, and instant detection based on the status information to identify abnormal events of the second vehicle-mounted domain controller; determining broadcast priority based on the abnormal event identified by at least one of startup detection, timed detection, and instant detection according to the abnormal type of the abnormal event includes: determining broadcast priority based on the abnormal event identified by at least one of startup detection, timed detection, and instant detection and the identified abnormal event of the second vehicle-mounted domain controller according to the abnormal type of the abnormal event.

8. The method according to claim 1, characterized in that, The execution startup detection includes: verifying the validity of vehicle configuration information; verifying the mounting status, mounting format, and capacity availability of data storage devices; verifying the connection status of the data interface between the first vehicle-side domain controller and the extended device; verifying the existence and validity of sensor calibration files; verifying the configuration parameters of audio input devices; and verifying the existence of preset data sources.

9. The method according to claim 1, characterized in that, The timed detection performed according to a preset period includes: verifying the connection status of the data interface between the first vehicle-side domain controller and the extended device according to a preset period; and verifying the mounting status, mounting format, and capacity availability of the data storage device according to a preset period.

10. A method for generating tags for autonomous driving recording data, characterized in that, The method, applied to a backend server, includes: acquiring audio tag data and its associated data generated during the data recording process from at least one vehicle-side domain controller; the associated data includes the triggering method of data recording, vehicle configuration information, and data storage path; performing speech recognition on the audio tag data to obtain text tag data; and generating structured autonomous driving data tags based on the text tag data and the associated data.

11. The method according to claim 10, characterized in that, The step of performing speech recognition on the audio tag data to obtain text tag data includes: performing speech recognition on the audio tag data to obtain first text tag data; and correcting the first text tag data based on a preset autonomous driving vocabulary library to obtain second text tag data.

12. The method according to claim 11, characterized in that, The method further includes: constructing an autonomous driving vocabulary database based on industry data statistics, expert experience screening, and scenario feedback iteration; the vocabulary categories of the autonomous driving vocabulary database include at least sensor terms, scenario description terms, and anomaly type terms.

13. The method according to claim 10, characterized in that, The step of generating structured autonomous driving data tags based on the text tag data and the associated data includes: extracting keywords from the text tag data; combining the abnormal event information obtained from at least one vehicle-side domain controller, matching and filling the keywords with fields in a preset structured tag template to obtain autonomous driving data tags; the fields of the structured tag template include at least the following: recording date, geographical location, vehicle identification, environmental information, road type, problem description, problem classification, and data storage path.

14. The method according to claim 11, characterized in that, The method further includes: obtaining the correction result of the structured autonomous driving data tags; and updating the audio tag data in the vehicle domain controller according to the correction result.

15. An anomaly detection device for autonomous driving data recording, characterized in that, include: The startup detection module is used to perform startup detection to verify the readiness status required for data recording; The timed detection module is used to perform timed detection at preset intervals to verify the operating status of the hardware on which data recording depends. The real-time detection module is used to perform real-time detection in response to data recording commands to verify the validity of the recorded data; The determination module is used to determine the broadcast priority based on the abnormal event identified by at least one of the start detection, timed detection and instant detection, according to the abnormality type of the abnormal event. The module is used to add audio prompt files for abnormal events to the audio playback queue based on the playback priority. The broadcast module is used to sequentially retrieve audio prompt files from the audio broadcast queue for broadcasting.

16. A tag generation device for autonomous driving recording data, characterized in that, include: The acquisition module is used to acquire audio tag data and its associated data generated during the data recording process from at least one vehicle-side domain controller; the associated data includes the data recording triggering method, vehicle configuration information, and data storage path; The recognition module is used to perform speech recognition on the audio tag data to obtain text tag data; the generation module is used to generate structured autonomous driving data tags based on the text tag data and the associated data.

17. A first vehicle-side domain controller, characterized in that, include: The system includes a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes the computer instructions to implement the anomaly detection method for recording autonomous driving data as described in any one of claims 1 to 9.

18. A backend server, characterized in that, include: The system includes a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to implement the tag generation method for autonomous driving recording data according to any one of claims 10 to 14.

19. A computer-readable storage medium storing computer instructions thereon, characterized in that, When the instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 14.

20. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 14.

Images