Vehicle end data acquisition system and method

Abstract

This invention relates to a vehicle-side data acquisition system and method, belonging to the field of vehicle-side data acquisition technology. The vehicle-side data acquisition system includes: a self-test module, used to perform self-tests on the data acquisition task and the vehicle-side local configuration after the vehicle is powered on, and send the self-test results to the cloud; a cloud module, used to update and distribute the data acquisition task and the vehicle-side local configuration based on the consistency verification results of the self-test; a monitoring module, used to detect the execution status of the data acquisition task and the resource information of the vehicle-side local configuration according to a preset period, and report abnormal information; a task management module, used to suspend the execution of the data acquisition task according to a preset priority order when abnormal information is received, and restart the data acquisition task according to the priority order after the abnormality is eliminated; and a data reporting module, used to report the data information in the data acquisition task and the operating status information of the vehicle-side data acquisition system. This invention meets existing requirements for vehicle-side data acquisition.

Description

Technical Field

[0001] This invention relates to the field of vehicle-side data acquisition technology, and in particular to a vehicle-side data acquisition system and method. Background Technology

[0002] With the development of vehicle intelligence, the demand for vehicle-side data collection is increasing.

[0003] Existing vehicle-side data acquisition systems are mostly simple command execution and data feedback modes. There is no automatic self-check mechanism after the vehicle is powered on, and the completeness and validity of local task configuration and threshold rules cannot be verified in a timely manner. This can easily lead to acquisition anomalies caused by missing tasks and inconsistent parameters. The system does not dynamically monitor and schedule vehicle-side resources, and when resources are exhausted, it can easily cause the entire acquisition task to be paralyzed. Furthermore, there is no adaptive strategy for task degradation and restart, resulting in the inability of vehicle-side data acquisition to meet the requirements.

[0004] It is evident that in existing technologies, the collection of vehicle-side data is prone to anomalies caused by missing tasks and inconsistent parameters, which can easily lead to the overall paralysis of the collection task. Furthermore, there is no adaptive strategy for task degradation and restart, resulting in the inability of vehicle-side data collection to meet the requirements. Summary of the Invention

[0005] In view of this, it is necessary to provide a vehicle-side data acquisition system and method to solve the problems in the existing technology that vehicle-side data acquisition is prone to task loss, parameter inconsistency leading to acquisition anomalies, and can easily cause the overall acquisition task to be paralyzed. Furthermore, there is no adaptive strategy for task degradation and restart, which makes it impossible for vehicle-side data acquisition to meet the requirements.

[0006] To address the aforementioned problems, in a first aspect, the present invention provides a vehicle-side data acquisition system, comprising: The self-test module is used to perform self-tests on the data acquisition task and the local configuration on the vehicle after the vehicle is powered on, and to send the self-test results to the cloud. In the cloud, it is used to perform consistency verification on the self-test results, and update and distribute data collection tasks and vehicle-side local configurations based on the consistency verification results; The monitoring module is used to detect the execution status of data collection tasks and the resource information configured locally on the vehicle according to a preset cycle, and to report abnormal information. The task management module is used to pause the execution of data acquisition tasks according to a preset priority order when abnormal information is received, and to restart the data acquisition tasks according to the priority order after the abnormality is eliminated. The data reporting module is used to report data information from the data acquisition task and the operating status information of the vehicle-side data acquisition system.

[0007] In one possible implementation, the self-test module is specifically used for: Verify the integrity of the data acquisition task ID, the running status of the data acquisition task, and the validity of the threshold rules of the vehicle-side local configuration resources. Then, encapsulate the self-check results and corresponding parameters in a structured manner and upload them to the cloud. The self-test module is also used for: After receiving the updated data collection task and vehicle-side local configuration from the cloud based on the consistency verification result, update the data collection task and vehicle-side local configuration, and report the update status to the cloud.

[0008] In one possible implementation, the monitoring module is specifically used for: Obtain the pre-configured local resource thresholds and execution indicator thresholds for data collection tasks on the vehicle side; According to the preset periodic detection data collection task real-time execution indicators and the real-time resources configured locally on the vehicle; When the real-time performance metrics exceed the performance metric threshold and / or the real-time resources configured locally on the vehicle are less than the resource threshold, an error message is generated and reported.

[0009] In one possible implementation, the task management module is specifically used for: Pause each data acquisition task according to its priority and sorting value; After the anomaly is resolved, the data acquisition tasks are restarted according to their priority and sorting values.

[0010] In one possible implementation, the vehicle-side data acquisition system also includes: The task deadline management module is used to determine whether each data acquisition task is within its validity period upon power-on. When a data acquisition task is not within its validity period, the data acquisition task is paused and the cached data of the data acquisition task is reported. It is also used to trigger data acquisition tasks based on the acquisition cycle of the data acquisition task.

[0011] In one possible implementation, the vehicle-side data acquisition system also includes: The task status monitoring module is used to predefine the full lifecycle status type of each data acquisition task, listen for status change events of each data acquisition task in real time, and report the status change events to the cloud.

[0012] In one possible implementation, the vehicle-side data acquisition system also includes: The data acquisition instruction parsing module is used to receive data acquisition instructions sent from the cloud and to perform format and parameter validation on the data acquisition instructions. When the validation fails, it reports an exception and requests a repetition. When the validation passes, it parses the core parameters of the data acquisition instruction and converts the core parameters into executable configurations for the vehicle.

[0013] In one possible implementation, the vehicle-side data acquisition system also includes: The multi-protocol adapter module includes a CAN adapter and a SOME / IP adapter. The CAN adapter is used to capture CAN bus messages and add timestamps, and to perform branch processing on data acquisition tasks. The SOME / IP adapter is used to receive messages and extract valid service data after deserializing the messages.

[0014] In one possible implementation, the data reporting module is specifically used for: The data information in the data acquisition task and the operating status information of the vehicle-side data acquisition system are standardized and packaged, and the packaged data is uploaded to the cloud.

[0015] Secondly, the present invention also provides a vehicle-side data acquisition method, applicable to vehicle-side data acquisition systems of any of the aforementioned implementations, comprising: After the vehicle is powered on, a self-test is performed on the data acquisition task and the vehicle-side local configuration. The consistency of the self-test results is verified, and the data acquisition task and the vehicle-side local configuration are updated based on the consistency verification results. The system checks the execution status of the data acquisition task and the resource information configured locally on the vehicle according to a preset cycle. In case of an anomaly, the system suspends the execution of the data acquisition task according to a preset priority order, and restarts the data acquisition task according to the priority order after the anomaly is eliminated. Report the data information from the data acquisition task and the operational status information of the vehicle-side data acquisition system.

[0016] The beneficial effects of this invention are as follows: The vehicle-side data acquisition system provided by this invention includes a self-test module, a cloud platform, a monitoring module, a task management module, and a data reporting module. The self-test module performs a self-test on the data acquisition task and the vehicle-side local configuration after the vehicle is powered on, and sends the self-test results to the cloud platform. The cloud platform performs consistency verification on the self-test results and updates and distributes the data acquisition task and the vehicle-side local configuration based on the consistency verification results. The power-on self-test mechanism enables advance verification of the local configuration and rapid correction by the cloud platform, avoiding acquisition anomalies caused by missing tasks or inconsistent parameters from the source. The monitoring module detects the execution status of the data acquisition task and the resource information of the vehicle-side local configuration according to a preset period and reports abnormal information. The task management module suspends the execution of the data acquisition task according to a preset priority order when abnormal information is received, and restarts the data acquisition task according to the priority order after the abnormality is eliminated. The resource monitoring and task degradation and restart strategy realizes dynamic resource scheduling, avoids system paralysis caused by resource exhaustion, ensures the continuous and stable operation of high-priority tasks, ensures the stable operation of the vehicle-side data acquisition system, and meets the data acquisition requirements. Attached Figure Description

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

[0018] Figure 1 This is a schematic diagram of the structure of a vehicle-side data acquisition system provided in an embodiment of the present invention; Figure 2 A flowchart illustrating an abnormal information reporting method provided in an embodiment of the present invention; Figure 3 A flowchart illustrating a task management method provided in an embodiment of the present invention; Figure 4 This is a flowchart illustrating a vehicle-side data acquisition method provided in an embodiment of the present invention. Detailed Implementation

[0019] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0020] In the description of the embodiments of the present invention, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0021] The terms "first," "second," etc., used in the embodiments of this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature.

[0022] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0023] A specific embodiment of the present invention, such as Figure 1 As shown, a vehicle-side data acquisition system is disclosed, comprising: The self-test module 101 is used to perform a self-test on the data acquisition task and the local configuration on the vehicle after the vehicle is powered on, and to send the self-test results to the cloud 102. Cloud 102 is used to perform consistency verification on the self-test results, and update and distribute data collection tasks and vehicle-side local configurations based on the consistency verification results; The monitoring module 103 is used to detect the execution status of the data collection task and the resource information configured locally on the vehicle according to a preset period, and to report abnormal information. The task management module 104 is used to pause the execution of the data acquisition task according to a preset priority order when an abnormal information is received, and to restart the data acquisition task according to the priority order after the abnormality is eliminated. The data reporting module 105 is used to report data information in the data acquisition task and the operating status information of the vehicle-side data acquisition system.

[0024] In this embodiment of the invention, after the vehicle is powered on and before any formal data acquisition task is started, the self-test module 101 proactively and comprehensively performs a self-test on the legality, completeness, and consistency of the set of data acquisition tasks to be executed and the various configurations stored locally on the vehicle. Specifically, the self-test module 101 reads the task definition file in the local persistent storage. This file details the unique identifier, triggering conditions, sampling period, data source address, data preprocessing rules, and priority level of each data acquisition task. The self-test module 101 checks one by one whether the description of each task is complete, whether there are circular dependencies, whether the referenced data source is registered in the system's known signal list, and whether the predefined acquisition frequency is within the allowed physical range. If a logical error is found in the task definition, such as a negative sampling period or an invalid data source address, the self-test module 101 immediately marks the task as "invalid" and records the error type in detail in the self-test results. The self-test module 101 is also used to check the vehicle-side local configuration, including but not limited to system-level configurations such as log level, local storage path, upload cycle, network configurations such as the Uniform Resource Locator (URL) of the cloud server 102, the validity period of the Transport Layer Security (TLS) certificate, wireless access point name, hardware resource quotas such as the size of the ring buffer allocated for video capture, the maximum disk space reserved for log files, and specific parameters of each acquisition module such as the baud rate of the controller area network (LAN) interface and the parameters of serial communication. The self-test module 101 verifies whether the data types of these configuration items are correct, whether they are within the legal value range, and whether critical files are intact and not expired.

[0025] In this embodiment of the invention, the cloud platform 102 is not a simple remote server, but rather serves as the core decision-making and coordination unit of the system. It receives self-inspection reports from a massive number of vehicles and, based on a broader perspective and business logic, performs in-depth processing on each vehicle's report. Specifically, after receiving a self-inspection report from a vehicle, the cloud platform 102 compares the report item by item with the expected configuration baseline set for that vehicle or vehicle model batch in its database. This comparison includes not only simple value matching but also logical consistency verification. Based on the consistency verification results, the cloud platform 102 generates personalized correction instructions for that vehicle, forming a new data acquisition task and vehicle-side local configuration, and sends it to the vehicle. The update instructions issued by the cloud platform 102 are encrypted and verified for integrity to ensure they are not tampered with during transmission. After receiving these instructions, the vehicle will perform a self-check by the self-check module 101 in the next cycle or immediately, and report the new self-check results to the cloud 102 again, forming a closed loop of verification, update, and re-verification until the cloud 102 confirms that the vehicle status is completely consistent with the expected status. This closed-loop mechanism fundamentally solves the configuration drift problem.

[0026] In this embodiment of the invention, the monitoring module actively wakes up at a preset, fixed time period, for example, 100 milliseconds, 500 milliseconds, or 1 second, which can be dynamically adjusted by the cloud 102. It comprehensively checks the execution status of all active data acquisition tasks in the current system and the resource information involved in the vehicle's local configuration. It checks whether the thread or process corresponding to each acquisition task is in a runnable or running state, rather than an unresponsive, zombie, or dormant state. The monitoring module 103 also checks the actual usage of various resource quotas defined in the vehicle's local configuration. For example, it obtains the utilization rate of each processor core, paying particular attention to the load of processor cores or control groups allocated to the data acquisition process. The monitoring module 103 can distinguish whether the acquisition task itself consumes processor resources or whether other unrelated processes are competing for resources.

[0027] In this embodiment of the invention, the task management module 104 is specifically responsible for responding to abnormal information from the monitoring module 103 and executing intelligent recovery actions. Its core mechanism is based on a preset priority order, dynamically pausing and restarting data acquisition tasks. Each data acquisition task in the system is assigned a unique, globally valid priority level. The priority level can be an integer, with smaller values ​​indicating higher priority, or it can be divided into several levels such as "critical," "high," "normal," "low," and "background." The initial priority value is defined by the vehicle-side local configuration and can be dynamically adjusted by the cloud 102 through configuration updates. All pause, restart, and crash handling actions of the task management module 104, along with system resource snapshots at the time of each action, are recorded in the local diagnostic log and synchronized to the cloud 102 via the data reporting module 105 for remote auditing and algorithm optimization.

[0028] In this embodiment of the invention, the data reporting module 105 is the only outlet for data exchange between the system and the cloud 102, and is responsible for reliably and efficiently uploading the two types of information to the cloud 102 server.

[0029] The vehicle-side data acquisition system provided by this invention includes a self-test module 101, a cloud platform 102, a monitoring module 103, a task management module 104, and a data reporting module 105. The self-test module 101 performs a self-test on the data acquisition task and the vehicle's local configuration after the vehicle is powered on, and sends the self-test results to the cloud platform 102. The cloud platform 102 performs consistency verification on the self-test results and updates and distributes the data acquisition task and the vehicle's local configuration based on the consistency verification results. This power-on self-test mechanism enables advance verification of the local configuration and rapid correction by the cloud platform 102, preventing task loss and parameter inconsistencies from the outset. The monitoring module 103 is used to detect the execution status of the data acquisition task and the resource information configured locally on the vehicle according to a preset period, and report the abnormal information; the task management module 104 is used to suspend the execution of the data acquisition task according to a preset priority order when receiving abnormal information, and restart the data acquisition task according to the priority order after the abnormality is eliminated; the resource monitoring and task degradation and restart strategy realizes dynamic resource scheduling, avoids system paralysis caused by resource exhaustion, ensures the continuous and stable operation of high-priority tasks, ensures the stable operation of the vehicle data acquisition system, and meets the data acquisition needs.

[0030] In some possible embodiments of the present invention, the self-test module 101 is specifically used for: Verify the integrity of the data acquisition task ID, the running status of the data acquisition task, and the validity of the threshold rules of the vehicle-side local configuration resources. Then, after the self-check results and corresponding parameters are structured and encapsulated, they are uploaded to the cloud 102. The self-test module 101 is also used for: After receiving the updated data collection task and vehicle-side local configuration from the cloud 102 based on the consistency verification result, update the data collection task and vehicle-side local configuration, and report the update status to the cloud 102.

[0031] In this embodiment of the invention, the self-test module 101 first reads the task registry in the vehicle's persistent storage. This registry records globally unique identifiers for all data acquisition tasks that the vehicle should currently execute. Task IDs are generated and distributed by the cloud 102 during task creation, and each ID has a fixed character length and encoding rules. The module checks whether each task ID in the registry has a corresponding complete task description record in the local task definition file. The task description includes at least the task type, data source address, sampling period, priority level, and dependencies. If a task ID cannot be found in the task definition file, it is determined to be an "orphan ID," indicating a lack of integrity. The self-test module 101 pre-stores the fingerprint of the task ID set generated after the last successful synchronization with the cloud 102. The self-test module 101 recalculates the fingerprint of the current task ID set and compares it with the pre-stored fingerprint. If the two are inconsistent, it indicates that the task registry has undergone unauthorized changes since the last synchronization, triggering an integrity alarm. The self-check module 101 performs format checks on the character length and valid character set of each task ID, and verifies its integrity using the built-in check bit or redundant check code of the task ID to rule out ID corruption caused by data transmission or storage errors. After the above verification is completed, the self-check module 101 generates a task ID integrity check list, in which each entry contains at least the task ID, integrity status, and a specific error description.

[0032] In this embodiment of the invention, based on the completion of task ID integrity verification, the self-test module 101 further checks the consistency of the running state corresponding to each valid task ID. The self-test module 101 maintains a persistent task state table, which records the expected state of each task set by the task management module 104 before the system's last normal power-down. The self-test module 101 obtains the current actual running state of each task by querying the operating system process table and checking the task-specific lock file or shared memory flag. For tasks with the expected state of running, the self-test module 101 verifies whether the corresponding operating system process or thread exists and is in a runnable state, and checks whether the task can respond to the health check probe. If the process does not exist, is in a zombie state, or cannot respond to the probe, it is determined to be inconsistent in state, and the actual state is marked as abnormal termination. For tasks with the expected state of paused, the self-test module 101 confirms that its process should still exist but is in a suspended state, and the internal status flag of the task shows paused. If the process has exited or the status flag shows running, it is determined to be inconsistent. For tasks with the expected state of stopped, the self-test module 101 ensures that the relevant process has completely exited and all temporary resources have been released. If residual processes or lock files are found, the self-check module 101 will record the anomaly and attempt to clean it up automatically.

[0033] In this embodiment of the invention, the self-test module 101 reads various resource threshold rules defined in the vehicle's local configuration. These threshold rules are used by the monitoring module 103 to determine whether system resources are within a normal range. Typical threshold rules include, but are not limited to, processor load percentage upper limit, physical memory remaining lower limit, storage write latency upper limit, and task frame drop rate tolerance. After completing the above three checks, the self-test module 101 encapsulates all check results and related system parameters in a structured manner to generate a self-test report in a unified format. After the self-test report is reported to the cloud 102, the cloud 102 generates a personalized configuration update instruction for the vehicle based on the consistency check results, including resending missing tasks, resending inconsistent threshold rules, and adjusting the expected state of tasks. After receiving the update command issued by the cloud 102, the vehicle-side self-inspection module 101 unpacks the configuration update transaction issued by the cloud 102, verifies the digital signature and integrity check code to ensure that the source of the command is legitimate and has not been tampered with during transmission, and executes the update operation in sequence according to the command type. After completing all configuration updates, the self-inspection module 101 generates an update status feedback message, which includes at least the identifier of this update transaction, the execution result of each command, and the updated configuration fingerprint.

[0034] This invention not only enables autonomous health checks and cloud-based 102 reporting after power-on, but also establishes a closed-loop mechanism for reporting, verification, updating, and feedback, ensuring that the vehicle-side configuration always maintains precise consistency with the cloud-based 102 expectations, thus laying a solid foundation for the reliable execution of subsequent data collection tasks.

[0035] In some possible embodiments of the present invention, such as Figure 2 As shown, the monitoring module 103 is specifically used for: S201, obtain the pre-configured local resource thresholds and execution indicator thresholds of the data collection task; S202, according to the preset periodic detection data collection task real-time execution indicators and vehicle-side local configuration real-time resources; S203: When the real-time execution metric exceeds the execution metric threshold and / or the real-time resources configured locally on the vehicle are less than the resource threshold, an abnormal message is generated and reported.

[0036] In this embodiment of the invention, during the system startup initialization phase, the monitoring module 103 reads various pre-configured threshold parameters from the vehicle-side local configuration file and caches them in memory to improve the efficiency of periodic detection. The monitoring module 103 runs independently in a high-priority thread, and its detection cycle is determined by the system configuration parameters, typically 100 milliseconds, 500 milliseconds, or 1 second. This cycle value can also be dynamically adjusted by the cloud 102 through configuration updates to adapt to the real-time requirements of different scenarios. The monitoring module 103 monitors the real-time execution indicators of the data layer task and the real-time resources configured locally on the vehicle side according to this cycle, including but not limited to CPU utilization thresholds, such as not exceeding 85%; available memory capacity thresholds, such as not less than 200MB; remaining disk space thresholds, such as not less than 500MB; available network bandwidth thresholds, such as not less than 100KB / s; maximum allowable latency of the collection task, such as not exceeding 500ms; data packet loss rate thresholds, such as not exceeding 1%; task execution cycle timeout thresholds, such as three consecutive timeouts; and data queue backlog length thresholds, such as not exceeding 1000 entries. When the real-time performance metrics exceed the performance metric threshold and / or the real-time resources configured locally on the vehicle are less than the resource threshold, an error message is generated and reported.

[0037] The embodiments of the present invention can promptly detect problems such as insufficient vehicle-side resources or deterioration in the performance of data collection tasks; avoid data loss or system crashes caused by resource exhaustion or task blocking; provide real-time and quantifiable health status perception capabilities for vehicle-side data collection systems, and support remote operation and maintenance and dynamic scheduling.

[0038] In some possible embodiments of the present invention, such as Figure 3 As shown, the task management module 104 is specifically used for: S301, pause each data acquisition task according to its priority and sorting value; S302, After the anomaly is cleared, restart the data acquisition tasks according to their priority and sorting values.

[0039] In this embodiment of the invention, the task management module 104, as the core scheduling unit of the vehicle-side data acquisition system, maintains a global list of task control blocks to manage all registered data acquisition tasks. Each task control block is a data structure containing complete description information and running status of the task. Priorities are pre-set by system designers or maintenance engineers when a task is registered with the system, and their values ​​reflect the urgency of the task's requirements for driving safety, data criticality, and real-time performance. As an example, and not a limitation, the system can define the following priority levels: highest priority, for example, a priority value of ten, assigned to data acquisition tasks directly related to driving safety, typical tasks include braking system status acquisition, collision detection sensor acquisition, and airbag status monitoring; second-highest priority, for example, a priority value of nine, assigned to tasks that are core to autonomous driving decision-making, typical tasks include LiDAR point cloud acquisition, front camera image acquisition, and millimeter-wave radar target list acquisition; medium-high priority, for example, a priority value of seven or eight, assigned to real-time vehicle dynamic status monitoring tasks, typical tasks include vehicle speed sensor acquisition, steering wheel angle acquisition, and inertial... Data acquisition tasks are categorized into several priority levels: Medium priority (e.g., priority values ​​of five or six) is assigned to environmental perception assistance tasks, such as ultrasonic radar ranging, external temperature and humidity sensor data acquisition, and rain sensor data acquisition; Low-to-medium priority (e.g., priority values ​​of three or four) is assigned to data recording and uploading tasks, such as local log file writing, cloud 102 data synchronization, and video stream encoding and storage; Lowest priority (e.g., priority values ​​of one or two) is assigned to non-critical diagnostic tasks or data acquisition tasks related to the in-vehicle entertainment system, such as in-vehicle audio status acquisition, seat position sensor data acquisition, and interior ambient lighting status acquisition. The ranking value refers to the order of the data acquisition task in the queue; the earlier the task is listed, the lower its ranking value, and the higher its priority when paused.

[0040] Furthermore, the task management module 104 continuously listens for exception information from the monitoring module 103 through an internal message queue or callback interface. Upon receiving exception information, the task management module 104 first parses the key content contained in the information, including the exception type field, used to distinguish whether it is a resource insufficiency exception, an execution indicator exceeding the limit exception, or a mixed exception of both; the affected resource dimension field, used to indicate which specific type of resource has a problem, such as CPU resources, memory resources, disk storage resources, or network bandwidth resources; and the exception severity level field, such as three levels: urgent, severe, and warning, used to guide the task management module 104 to take different levels of aggressive suspension strategies.

[0041] Based on the parsed exception information and the current running status of all data acquisition tasks, the task management module 104 generates a list of tasks to be paused. This list is generated according to the following principles: If the exception type is insufficient resources, only tasks consuming the affected resources are included in the list; for example, when memory resources are insufficient, only tasks with high memory usage are considered, excluding purely CPU-intensive tasks with very low memory usage. If the exception type is exceeding execution limits, all running tasks are included in the list, as execution exceptions often indicate problems with the overall system scheduling. If the exception type is a mixed exception, a stricter strategy is adopted, including all running tasks in the list and using shorter pause cycles. After generating the list, the task management module 104 sorts all tasks in the list based on their priority and ranking value. The specific sorting rules are as follows: First, tasks are sorted from lowest to highest priority, with tasks with lower priority values ​​at the beginning of the list and tasks with higher priority values ​​at the end. This is because when resources are scarce or the system malfunctions, the system should prioritize suspending less important tasks to preserve the continued operation of important tasks as much as possible. When multiple tasks have the same priority, they are further sorted according to their sorting values. The sorting direction is determined by the system configuration; in the default configuration, tasks with lower sorting values ​​are listed first, indicating that these tasks are suspended more frequently among tasks of equal priority.

[0042] This invention implements differentiated task scheduling protection, which can minimize the suspension of high-priority critical tasks when anomalies occur, thereby ensuring driving safety and the continuity of core perception data; while low-priority non-critical tasks are suspended first to free up system resources.

[0043] In some possible embodiments of the present invention, the vehicle-side data acquisition system further includes: The task deadline management module is used to determine whether each data acquisition task is within its validity period upon power-on. When a data acquisition task is not within its validity period, the data acquisition task is paused and the cached data of the data acquisition task is reported. It is also used to trigger data acquisition tasks based on the acquisition cycle of the data acquisition task.

[0044] In this embodiment of the invention, in the practical application of vehicle-side data acquisition systems, many data acquisition tasks are not permanently valid but have a clearly defined validity period. For example, a car manufacturer may conduct a 30-day road test data acquisition activity, and the related data acquisition tasks only need to be executed during the activity period; another example is that an autonomous driving algorithm iteration test task is only valid within the verification cycle of a certain version of the software; yet another example is that, due to data privacy compliance requirements, certain acquisition tasks involving personally identifiable information or geospatial sensitive information must automatically stop after the user's authorization period expires. Furthermore, different data acquisition tasks have different acquisition cycle requirements; some tasks require high-frequency acquisition at the millisecond level, while others only require low-frequency acquisition at the second or minute level. Traditional vehicle-side data acquisition systems typically use unified scheduling or simple time-polling methods, which cannot automatically handle task expiration issues and are difficult to meet diverse cycle triggering requirements.

[0045] In this embodiment of the invention, in the task deadline management module, each data acquisition task can be associated with a validity period information during registration or configuration. This validity period information can be stored in a configuration file on the vehicle's local machine, or it can be downloaded from the cloud configuration center 102 and cached in the vehicle's persistent storage area. The task deadline management module loads this configuration information each time the system powers on and periodically synchronizes it with the cloud 102 during operation to support dynamic updates of the validity period. When the vehicle-side data acquisition system powers on and starts, the task deadline management module is one of the first initialization modules to run. Before the task management module 104 begins scheduling each data acquisition task, the task deadline management module first iterates through all registered data acquisition tasks in the system and performs a validity period judgment for each task. Another core function of the task deadline management module is to trigger task execution based on the data acquisition task's acquisition cycle. Each data acquisition task needs to configure its acquisition cycle parameters during registration. The acquisition cycle can be a fixed time interval, such as ten milliseconds, one hundred milliseconds, one second, one minute, etc.; or it can be a dynamic cycle based on events or conditions, such as using high-frequency acquisition when the vehicle speed exceeds a certain threshold and low-frequency acquisition when it is below that threshold. For simplicity, this embodiment uses a fixed time interval acquisition cycle as an example, but those skilled in the art will understand that dynamic cycles are also within the scope of this invention. The acquisition cycle information, similar to the validity period information, can be stored in a configuration file or obtained from the cloud 102. For acquisition tasks requiring strict real-time performance, the acquisition cycle can also be bound to a vehicle-side hardware timer or hardware interrupt source to achieve microsecond-level precision triggering.

[0046] This invention provides an automated lifecycle management system for data acquisition tasks. After configuring the task validity period, the system can automatically start, maintain, and stop acquisition tasks without manual intervention, making it particularly suitable for large-scale, long-term, and multi-batch acquisition activities.

[0047] In some possible embodiments of the present invention, the vehicle-side data acquisition system further includes: The task status monitoring module 103 is used to predefine the full lifecycle status type of each data acquisition task, listen for status change events of each data acquisition task in real time, and report the status change events to the cloud 102.

[0048] In this embodiment of the invention, the task status monitoring module 103 first predefines a complete set of data acquisition task status types during system initialization to cover the entire lifecycle of a task from creation to destruction. As an example and not a limitation, this set of status types includes the following states: Registered state, indicating that the task has been registered in the system but has not yet been scheduled for execution; Ready state, indicating that the task has the conditions for execution and is waiting for the task management module 104 to allocate resources; Running state, indicating that the task is performing data acquisition work; Paused state, indicating that the task has been temporarily stopped due to insufficient resources, expiration, or other reasons; Abnormal state, indicating that an error occurred during the task's execution, such as hardware read failure or data verification error; Expired state, indicating that the task's validity period has ended and it will no longer be scheduled; Destroyed state, indicating that the task has been completely removed from the system and all resources have been recycled. Through the above status definitions, the system can accurately characterize the stage of any data acquisition task at any given time.

[0049] Furthermore, the task status monitoring module 103 listens for status change events of all data acquisition tasks through a subscription mechanism. Specifically, the task management module 104, the task deadline management module, and other modules that may cause task status changes will broadcast a status change notification to the task status monitoring module 103 when modifying the status field of any task. This notification includes the task identifier, the status before the change, the status after the change, the status change timestamp, and the reason for the change. After receiving the notification, the task status monitoring module 103 records the event in a local circular buffer to avoid event loss due to momentary network failures. The task status monitoring module 103 uses an asynchronous reporting method to report the collected status change events to the cloud 102 through the vehicle-side communication module. The reporting timing can be batched according to preset time intervals or reported individually immediately when a critical status change occurs. The reported data format is a structured message, which includes at least the task identifier, current status, previous status, timestamp, and reason for the change. After receiving this information, the cloud 102 can realize remote full-link monitoring, fault tracing, and operation and maintenance analysis of the vehicle-side data acquisition tasks.

[0050] In some possible embodiments of the present invention, the vehicle-side data acquisition system further includes: The data acquisition instruction parsing module is used to receive data acquisition instructions sent from the cloud 102 and to perform format and parameter verification on the data acquisition instructions. When the verification fails, it reports the exception and requests a repetition. When the verification passes, it parses the core parameters of the data acquisition instruction and converts the core parameters into executable configurations on the vehicle side.

[0051] In this embodiment of the invention, the data acquisition instruction parsing module establishes a bidirectional connection with the cloud 102 through the vehicle-side communication module, continuously listening for data acquisition instructions issued by the cloud 102. Each instruction adopts a predefined protocol format, such as JSON format, which includes fields such as instruction type, task identifier, acquisition parameters, validity period, and priority. Upon receiving an instruction, the module first performs format verification, including checking whether the instruction is a complete and valid message, whether required fields are missing, whether the field data types match the protocol definition, and whether the instruction signature is valid. If the format verification fails, the module immediately generates an exception report, including the reason for the failure and the original instruction fragment, and requests the cloud 102 to resend the instruction through the communication module. After the format verification passes, the data acquisition instruction parsing module further performs parameter verification and business logic verification. This step checks whether the values ​​of each field in the instruction are within a reasonable range, such as whether the acquisition period is less than the minimum period supported by the system, whether the acquisition channel exists, whether the sampling accuracy exceeds the hardware capability, and whether the start and end times of the validity period are logically consistent. If the parameter verification fails, the module also reports an exception and carries specific verification failure information, requesting the cloud 102 to issue a corrected instruction. Once all verifications pass, the data acquisition instruction parsing module extracts core parameters from the original instructions, including but not limited to the data acquisition task type, acquisition frequency, data source address, data packaging method, upload strategy, priority, and validity period. Subsequently, the module converts these core parameters into an executable configuration that the vehicle-side system can directly recognize. The specific conversion methods include: converting the acquisition frequency into a timer period value, mapping the data source address to a specific hardware port or driver name, converting the upload strategy into behavioral parameters for the local cache queue, and converting the validity period into a timestamp format readable by the task expiration management module. The final executable configuration is written to the vehicle-side configuration storage area in a structured format for loading and use by the task management module 104, the task expiration management module, and the monitoring module 103.

[0052] In some possible embodiments of the present invention, the vehicle-side data acquisition system further includes: The multi-protocol adapter module includes a CAN adapter and a SOME / IP adapter. The CAN adapter is used to capture CAN bus messages and add timestamps, and to perform branch processing on data acquisition tasks. The SOME / IP adapter is used to receive messages and extract valid service data after deserializing the messages.

[0053] In this embodiment of the invention, the multi-protocol adapter module includes a CAN adapter and a SOME / IP adapter. The CAN adapter captures CAN bus messages, adds timestamps, and performs branch processing by periodic / event acquisition and full / specified signal acquisition. When acquiring specified signals, it loads a DBC file and parses it into physical values. The SOME / IP adapter receives messages in periodic / event acquisition mode, deserializes them, and extracts valid service data. Both adapters bind the processed data to the task ID and output it.

[0054] In some possible embodiments of the present invention, the data reporting module 105 is specifically used for: The data information in the data acquisition task and the operating status information of the vehicle-side data acquisition system are standardized and packaged, and the packaged data is uploaded to the cloud 102.

[0055] In this embodiment of the invention, the data encapsulation module verifies the required fields of the adapter output data, encapsulates them in a standardized manner according to the cloud 102 preset format, and caches them; the packaging and compression reporting module processes data differently according to real-time / batch reporting modes, real-time reporting is pushed via the MQTT protocol, batch reporting is compressed according to a threshold and uploaded via the HTTP protocol, caches and resends data when it fails, and cleans up local data when it succeeds, while recording the entire process log and synchronizing it to the status reporting module.

[0056] The power-on self-test mechanism of this invention enables advance verification of local configurations and rapid correction by the cloud-based 102, preventing data acquisition anomalies caused by missing tasks or inconsistent parameters from the source. Resource monitoring and task degradation / restart strategies enable dynamic resource scheduling, preventing system paralysis caused by resource exhaustion and ensuring the continuous and stable operation of high-priority tasks. A closed-loop command interaction between the cloud-based 102 and the vehicle enables command scheduling and real-time status monitoring throughout the entire lifecycle of the data acquisition task. Fine-grained validity period and cycle management automatically cleans up invalid tasks to release resources, while simultaneously meeting differentiated and personalized timed data acquisition needs, improving the flexibility of task scheduling. Dedicated adapters are designed for mainstream vehicle protocols such as CAN and SOME / IP, enabling unified acquisition and parsing of multi-protocol data. Standardized data encapsulation formats ensure complete data fields and clear semantics, adapting to the diverse data processing needs of the cloud-based 102. Differentiated reporting strategies based on real-time / batch modes, combined with data compression technology, significantly reduce network bandwidth usage. Local caching, automatic retransmission, and retransmission mechanisms after reporting failures prevent data loss and ensure complete data transmission. Full-process task status monitoring and reporting allows the cloud-based 102 to grasp the overall picture of vehicle-side task operation in real time, providing accurate data support for fault diagnosis and task adjustment; the log recording mechanism of each module facilitates problem tracing and system optimization. From power-on self-test and resource scheduling to task lifecycle management, the entire process is automated without manual intervention, greatly improving the intelligence level of vehicle-side data collection and adapting to unmanned vehicle operation scenarios.

[0057] To better implement the vehicle-side data acquisition system provided in the embodiments of the present invention, such as Figure 4 As shown, this embodiment of the invention also provides a vehicle-side data acquisition method, applicable to the vehicle-side data acquisition system in any of the foregoing embodiments, comprising: S401 performs a self-test on the data acquisition task and the vehicle's local configuration after the vehicle is powered on, performs a consistency check on the self-test results, and updates the data acquisition task and the vehicle's local configuration based on the consistency check results. S402 checks the execution status of the data acquisition task and the resource information configured locally on the vehicle according to a preset cycle, and pauses the execution of the data acquisition task according to a preset priority order when an anomaly occurs, and restarts the data acquisition task according to the priority order after the anomaly is eliminated. S403 reports the data information from the data acquisition task and the operating status information of the vehicle-side data acquisition system.

[0058] The implementation principle of the vehicle-side data acquisition method provided in this embodiment of the invention is the same as that of the vehicle-side data acquisition system in the aforementioned embodiments, and will not be repeated here.

[0059] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A vehicle end data acquisition system, characterized by, include: The self-test module is used to perform a self-test on the data acquisition task and the vehicle-side local configuration after the vehicle is powered on, and to send the self-test results to the cloud. The cloud is used to perform consistency verification on the self-test results, and update and distribute data collection tasks and vehicle-side local configurations based on the consistency verification results; The monitoring module is used to detect the execution status of the data acquisition task and the resource information configured locally on the vehicle according to a preset period, and to report abnormal information. The task management module is used to pause the execution of the data acquisition task according to a preset priority order when abnormal information is received, and to restart the data acquisition task according to the priority order after the abnormality is eliminated. The data reporting module is used to report data information from the data acquisition task and the operating status information of the vehicle-side data acquisition system.

2. The car end data acquisition system of claim 1, wherein, The self-test module is specifically used for: Verify the integrity of the data acquisition task ID, the running status of the data acquisition task, and the validity of the threshold rules of the vehicle-side local configuration resources. Then, encapsulate the self-check results and corresponding parameters in a structured manner and upload them to the cloud. The self-test module is also used for: After receiving the data collection task and vehicle-side local configuration updated and issued by the cloud based on the consistency verification result, the system updates the data collection task and vehicle-side local configuration and reports the update status back to the cloud.

3. The vehicle end data acquisition system of claim 1, wherein, The monitoring module is specifically used for: Obtain the pre-configured local resource thresholds and execution indicator thresholds for data collection tasks on the vehicle side; The real-time execution indicators of the data acquisition task and the real-time resources configured locally on the vehicle are detected according to a preset period. When the real-time execution metric exceeds the execution metric threshold and / or the real-time resources configured locally on the vehicle are less than the resource threshold, an error message is generated and reported.

4. The car end data acquisition system of claim 3, wherein The task management module is specifically used for: Pause each data acquisition task according to its priority and sorting value; After the anomaly is resolved, the data acquisition tasks are restarted according to their priority and sorting values.

5. The car end data acquisition system of claim 1, wherein, The vehicle-side data acquisition system also includes: The task deadline management module is used to determine whether each data acquisition task is within its validity period upon power-on. When a data acquisition task is not within its validity period, the module suspends the data acquisition task and reports the cached data of the data acquisition task. It is also used to trigger the data acquisition task based on its acquisition cycle.

6. The car end data acquisition system of claim 1, wherein The vehicle-side data acquisition system also includes: The task status monitoring module is used to predefine the full lifecycle status type of each data acquisition task, listen for status change events of each data acquisition task in real time, and report the status change events to the cloud.

7. The car end data acquisition system of claim 1, wherein The vehicle-side data acquisition system also includes: The data acquisition instruction parsing module is used to receive data acquisition instructions sent from the cloud and to perform format and parameter verification on the data acquisition instructions. When the verification fails, an exception is reported and a request is made to repeat the process. When the verification passes, the core parameters of the data acquisition instructions are parsed and converted into vehicle-side executable configurations.

8. The car end data acquisition system of claim 1, wherein, The vehicle-side data acquisition system also includes: The multi-protocol adapter module includes a CAN adapter and a SOME / IP adapter. The CAN adapter is used to capture CAN bus messages and add timestamps, and to perform branch processing on data acquisition tasks. The SOME / IP adapter is used to receive messages and extract valid service data after deserializing the messages.

9. The vehicle-side data acquisition system according to claim 1, characterized in that, The data reporting module is specifically used for: The data information in the data acquisition task and the operating status information of the vehicle-side data acquisition system are standardized and packaged, and the packaged data is uploaded to the cloud.

10. A method for collecting data at a vehicle end, which is suitable for the data collection system at a vehicle end according to any one of claims 1 to 9, characterized in that, include: After the vehicle is powered on, a self-test is performed on the data acquisition task and the vehicle-side local configuration. The consistency of the self-test results is verified, and the data acquisition task and the vehicle-side local configuration are updated based on the consistency verification results. The execution status of the data acquisition task and the resource information configured locally on the vehicle are detected according to a preset cycle. In case of an anomaly, the execution of the data acquisition task is paused according to a preset priority order, and the data acquisition task is restarted according to the priority order after the anomaly is eliminated. The data information from the data acquisition task and the operating status information of the vehicle-side data acquisition system are reported.

Images