A car-grade multi-source sensor data unified diagnosis method and system

Abstract

This invention relates to the field of automotive sensor data processing technology, and discloses a unified diagnostic method and system for automotive-grade multi-source sensor data. The method includes: parsing multi-source sensor configuration files to generate a plug-in instance table; reading multi-type interface data to form a raw data packet sequence; generating a standardized frame message sequence based on plug-in templates and a circular buffer; recording the release status; and combining heartbeat detection, anomaly confidence, and a finite state machine to output operational diagnostic results. Compared to existing technologies where different types of sensors typically rely on independent drivers, especially under conditions of mixed operation with multiple communication interfaces, this invention addresses the technical problem of failing to achieve unified correlation diagnosis of interface reading anomalies, plug-in parsing anomalies, and release link anomalies. Because this application constructs a unified release record using a plug-in instance table, raw data packet sequence, standardized frame message sequence, and unified release record, it improves the accuracy and stability of anomaly localization in automotive-grade multi-source sensor systems.

Description

Technical Field

[0001] This invention relates to the field of vehicle sensor data processing technology, and in particular to a unified diagnostic method and system for automotive-grade multi-source sensor data. Background Technology

[0002] With the rapid development of intelligent driving and autonomous driving technologies, vehicles are integrating an increasing number and variety of sensors, such as cameras, LiDAR, millimeter-wave radar, ultrasonic radar, inertial measurement units (IMUs), and global positioning systems (GPS). These sensors typically have different physical interfaces (such as Ethernet, CAN, serial ports, SPI, etc.), communication protocols, and data formats, forming a complex multi-source heterogeneous sensor system. Ensuring the stable and reliable operation of these sensors in the complex in-vehicle environment, and performing real-time and accurate diagnostics of their operating status, is a crucial prerequisite for guaranteeing the safety and reliability of advanced driver assistance systems (ADAS) and autonomous driving functions.

[0003] Currently, state diagnosis for multi-source sensors suffers from the following shortcomings. For example, existing solutions are mostly designed for a single type or a few types of sensors, with diagnostic logic deeply coupled to specific sensor hardware or protocols, lacking versatility. When adding or changing sensor types, it often requires modifying a large amount of low-level code and diagnostic logic, resulting in poor system scalability and maintainability. Furthermore, traditional methods often only focus on simple states such as whether a sensor is online or whether data has arrived, lacking a comprehensive evaluation of multiple dimensions such as data flow continuity, interface read latency, end-to-end data processing latency, and frame rate stability. Especially in automotive-grade applications with heterogeneous sensor interfaces, diverse data protocols, and extremely high real-time requirements, existing technologies cannot fully meet the need for unified, accurate, and real-time diagnosis of the overall operational health of sensors. Therefore, there is an urgent need for a diagnostic method and system that can still achieve a unified, flexible, scalable, and comprehensive assessment of the overall operational status of sensors, even in the face of dynamic sensor changes, heterogeneous interfaces, and diverse protocols, to improve the reliability and safety of intelligent driving systems. Summary of the Invention

[0004] To address the aforementioned technical shortcomings, the purpose of this invention is to propose a unified diagnostic method for automotive-grade multi-source sensor data. This method aims to solve the technical problem that in the prior art, different types of sensors typically rely on independent drivers, especially under conditions of mixed operation of multiple communication interfaces, making it impossible to achieve unified correlation diagnosis of interface reading anomalies, plug-in parsing anomalies, and release link anomalies.

[0005] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: The present invention provides a unified diagnostic method for automotive-grade multi-source sensor data.

[0006] The automotive-grade multi-source sensor data unified diagnostic method includes: Step S10: Obtain the multi-source sensor configuration file, and based on the multi-source sensor configuration file, execute the sensor plugin instantiation task using dynamic library loading and factory mode, and output the sensor plugin instance table; Step S20: Based on the sensor plug-in instance table, execute the multi-type sensor interface reading task using the adapter mode and output the raw data packet sequence; Step S30: Based on the original data packet sequence, perform frame data preprocessing tasks using a template method and a circular buffer to output a standardized frame message sequence; Step S40: Based on the standardized frame message sequence, perform the sensor data publishing record generation task using publish-subscribe mode or request-response mode, and output a unified publishing record; Step S50: Based on the unified release record, heartbeat detection and finite state machine are used to diagnose the operating status of multi-source sensors, and the operating diagnosis results are output.

[0007] Preferably, step S10, which involves obtaining a multi-source sensor configuration file and constructing a sensor plugin instance table based on the multi-source sensor configuration file using dynamic library loading and factory mode, specifically includes: Step S101: Parse the multi-source sensor configuration file, extract the sensor name, plug-in class name, plug-in dynamic library path, data interface type, diagnostic code set, diagnostic threshold parameter and communication adapter name, and generate a sensor configuration description table; Step S102: Based on the plug-in dynamic library path and plug-in class name in the sensor configuration description table, instantiate the corresponding sensor plug-in object by calling the dynamic library loading method to obtain the sensor plug-in object table; Step S103: Bind each sensor plug-in object in the sensor plug-in object table with its corresponding sensor name, data interface type, diagnostic code set, diagnostic threshold parameter, and communication adapter name to form the sensor plug-in instance table.

[0008] Preferably, step S20, which involves executing a multi-type sensor interface reading task using the adapter mode based on the sensor plug-in instance table and outputting the original data packet sequence, specifically includes: Step S201: Based on the data interface type corresponding to each sensor plug-in instance in the sensor plug-in instance table, create at least one interface instance among Ethernet interface instance, CAN interface instance, serial port interface instance, SPI interface instance and video acquisition interface instance; Step S202: Based on the interface configuration parameters corresponding to each sensor plug-in instance in the sensor plug-in instance table, configure the read trigger mode, read timeout, number of data buffers, data filtering conditions and device identifier for the interface instance to obtain the diagnostic interface instance table; Step S203: Read the raw data of the corresponding sensor through the diagnostic interface instance table, and encapsulate the read raw data into a raw data packet sequence with interface source identifier, device identifier, reading timestamp and reading status identifier.

[0009] Preferably, step S202, configuring the read trigger mode, read timeout, data buffer size, data filtering conditions, and device identifier for the interface instance, includes: Configure a packet ring buffer for each interface instance, the packet ring buffer including write nodes, ready nodes and read nodes; When the read trigger mode is the polling trigger mode, the corresponding interface instance is controlled to continuously read the original data within a preset number of polling times, and the number of empty reads is recorded when no valid data is read. When the read trigger mode is a condition trigger mode, the corresponding interface instance is controlled to wait for data to arrive, and a read timeout flag is recorded when the waiting time exceeds the read timeout time. Based on the number of empty reads, the read timeout flag, and the node update status of the data packet circular buffer, an interface read stability parameter is generated, and the interface read stability parameter is written into the read status flag of the original data packet sequence.

[0010] Preferably, step S30, which involves performing frame data preprocessing based on the original data packet sequence using a template method and a circular buffer to output a standardized frame message sequence, specifically includes: Step S301: Distribute the original data packet sequence to the corresponding sensor plug-in instance according to the interface source identifier and device identifier in the original data packet sequence; Step S302: The sensor plugin instance calls the template method in the corresponding sensor base class to perform protocol parsing, data integrity verification, and frame structure encapsulation on the original data packet sequence to obtain the sensor frame data sequence; Step S303: Write the sensor frame data sequence into the frame data circular buffer, and generate a standardized frame message sequence for each frame data, which includes a frame timestamp, frame cache index, frame validity status, and sensor type identifier.

[0011] Preferably, step S40, which involves executing the sensor data publishing record generation task based on the standardized frame message sequence using a publish-subscribe mode or a request-response mode, and outputting a unified publishing record, specifically includes: Step S401: Query the corresponding communication adapter instance based on the communication adapter name in the standardized frame message sequence; Step S402: Determine whether the current standardized frame message adopts a publish-subscribe mode or a request-response mode based on the communication configuration parameters of the communication adapter instance; Step S403: When using the publish-subscribe mode, record the topic name, publication timestamp, and publication status of the corresponding standardized frame message; when using the request-response mode, record the request timestamp, response timestamp, and response status of the corresponding standardized frame message, and output a unified publication record.

[0012] Preferably, step S50, which involves using heartbeat detection and a finite state machine to diagnose the operating status of multiple sensors based on the unified release record and outputting the operating diagnosis results, specifically includes: Step S501: Based on the release timestamp, release status, and response status in the unified release record, and combined with the heartbeat information of the corresponding sensor plugin instance, generate the operation observation vector of each sensor; Step S502: Calculate the anomaly confidence level of each sensor based on the observed vector, where the anomaly confidence level of the i-th sensor at time t is... satisfy:

[0013] in, This represents the interface readout delay of the i-th sensor at time t. This indicates the preset maximum interface read latency. This represents the end-to-end delay from plugin parsing to deployment completion for the i-th sensor at time t. This indicates the preset maximum end-to-end delay. This represents the actual frame rate of the i-th sensor within the current statistical window. This represents the reference frame rate of the i-th sensor. This represents the discrete anomaly flag of the i-th sensor at time t. , γ These represent the weighting coefficients corresponding to interface read latency, end-to-end latency, frame rate deviation, and discrete anomaly flag, respectively. Step S503: Based on the anomaly confidence level, a finite state machine is used to determine the operational diagnostic results of each sensor, wherein the operational state of the i-th sensor at time t is... satisfy:

[0014] in, This represents the anomaly confidence threshold. This represents the consecutive anomaly count of the i-th sensor. This represents the continuous normal count of the i-th sensor. Indicates the number of times the anomaly has been confirmed to be stable. This indicates the number of times the system has been confirmed to be stable.

[0015] This invention also provides an automotive-grade multi-source sensor data unified diagnostic system, comprising: The plugin instance building module is used to obtain the multi-source sensor configuration file and build a sensor plugin instance table based on the multi-source sensor configuration file using dynamic library loading and factory pattern. The interface data reading module is used to perform multi-type sensor interface reading tasks based on the sensor plug-in instance table and in adapter mode, and output the raw data packet sequence. The frame data preprocessing module is used to perform frame data preprocessing tasks based on the original data packet sequence, using a template method pattern and a circular buffer, and output a standardized frame message sequence. The release record generation module is used to perform sensor data release record generation tasks based on the standardized frame message sequence, using a publish-subscribe mode or a request-response mode, and output a unified release record. The unified diagnostic module is used to perform multi-source sensor operation status diagnosis based on the unified release record using heartbeat detection and finite state machine, and output the operation diagnosis results.

[0016] The present invention also provides an automotive-grade multi-source sensor data unified diagnostic device, the automotive-grade multi-source sensor data unified diagnostic device comprising: a memory, a processor, and an automotive-grade multi-source sensor data unified diagnostic program stored in the memory and executable on the processor, wherein the automotive-grade multi-source sensor data unified diagnostic program implements the above method when executed by the processor.

[0017] The present invention also provides a computer program product, the computer program product including an automotive-grade multi-source sensor data unified diagnostic program, which implements the above method when executed by a processor.

[0018] The beneficial effects of this invention are as follows: 1. This invention constructs a highly modular, loosely coupled, and easily extensible unified diagnostic framework for automotive-grade multi-source sensor data by employing a combination of software design patterns, including dynamic library loading, factory pattern, adapter pattern, template method pattern, publish-subscribe / request-response pattern, and heartbeat detection with finite state machines. This framework can flexibly adapt to different types of sensors and their heterogeneous interfaces, achieving standardized processing throughout the entire process from data acquisition, preprocessing, and publishing to state diagnosis. It effectively solves the technical challenges of scattered diagnostic logic, system rigidity, and difficulty in maintenance and expansion found in traditional solutions.

[0019] 2. The method proposed in this invention, based on unified release records and combined with multi-dimensional indicators (such as interface read latency, end-to-end processing latency, frame rate deviation, etc.) to calculate anomaly confidence, and utilizing a finite state machine for state determination, enables a more comprehensive and accurate evaluation of sensor operating status. Compared to simple methods that only detect online status, this invention can detect potential sensor performance degradation or intermittent faults earlier and more accurately, providing more reliable sensor health status information for upper-layer applications, thereby improving the robustness and safety of the entire intelligent driving system. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the automotive-grade multi-source sensor data unified diagnostic method of the present invention. Detailed Implementation

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

[0022] Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0023] Example 1: As Figure 1 The diagram shown is a flowchart of the first embodiment of the unified diagnostic method for automotive-grade multi-source sensor data of the present invention, which presents the first embodiment of the unified diagnostic method for automotive-grade multi-source sensor data of the present invention.

[0024] In the first embodiment, the automotive-grade multi-source sensor data unified diagnostic method includes: Step S10: Obtain the multi-source sensor configuration file, and based on the multi-source sensor configuration file, execute the sensor plugin instantiation task using dynamic library loading and factory mode, and output the sensor plugin instance table; The "Multi-Source Sensor Configuration File" in this step is a structured data file used to describe the metadata of all sensors in the system to be diagnosed. Specifically, this file defines a unique identifier (name) for each sensor, the plugin class name that implements its specific function, the path to the dynamic library file storing the plugin implementation code, the data interface type used by the sensor (such as Ethernet, CAN, serial port, etc.), the sensor-specific set of diagnostic status codes, diagnostic threshold parameters used to determine anomalies (such as maximum allowable delay, reference frame rate, etc.), and the name of the communication adapter used for data distribution. The "Dynamic Library Loading" mechanism allows sensor-specific processing code (dynamic library) to be dynamically loaded at system runtime, while the "Factory Pattern" provides a unified interface to create sensor plugin objects corresponding to these loaded codes. The final output "Sensor Plugin Instance Table" is a data structure that binds the instantiated sensor plugin objects to their complete configuration information (name, interface type, diagnostic parameters, etc.), providing an operable set of sensor processing units with complete context for subsequent steps.

[0025] This step plays a crucial role in system initialization and plugin management in this invention. By parsing external configuration files, it abstracts the sensor's hardware characteristics and diagnostic logic into configurable metadata and utilizes dynamic libraries and factory patterns to achieve "hot-swappable" sensor processing plugins. This means that when adding or changing sensor types, only new configuration items, plugin dynamic libraries, and updated configuration files are required, without modifying the core system framework code, greatly improving flexibility and scalability. The generated sensor plugin instance table serves as the foundation and starting point for all subsequent data processing and diagnostic tasks.

[0026] Compared to traditional technologies where sensor types and diagnostic logic are typically hard-coded into the main system program or handled through complex conditional statements and branching logic, the technical solution presented in this paper offers significant advantages. Traditional methods result in high coupling; any change to a sensor requires recompiling and re-deploying the entire system, leading to high maintenance costs and a high risk of errors. This invention, through configurable and plug-in design, isolates changes in configuration files and independent dynamic libraries, decoupling business logic from specific sensor implementations. This allows for rapid adaptation to the fast-paced iteration and diverse needs of the automotive sensor ecosystem, meeting the high reliability and maintainability requirements of automotive-grade software.

[0027] For example, in a Level 3 autonomous vehicle, the initial configuration includes a forward-facing camera, a forward-facing millimeter-wave radar, and an ultrasonic radar. Its configuration file defines the corresponding information for these three sensors. When the vehicle is upgraded and a lidar needs to be added to the roof, the technician does not need to modify the existing diagnostic system's main program code. They only need to write a specific data parsing plugin for the lidar and compile it into a dynamic library. Then, they add a configuration description for the lidar to the configuration file, including its plugin class name "LidarPlugin," the dynamic library path " / plugins / lidar.so," the interface type "Ethernet," and specific diagnostic codes. After restarting or dynamically loading the configuration, step S10 automatically reads the new configuration file, loads the "lidar.so" dynamic library, creates a "LidarPlugin" instance through the factory, binds it to the configuration information, and adds it to the sensor plugin instance table.

[0028] Step S20: Based on the sensor plug-in instance table, execute the multi-type sensor interface reading task using the adapter mode and output the raw data packet sequence; The "Adapter Pattern" in this step is a software design pattern used to convert the interface of a class into another interface expected by the client, enabling classes that would otherwise be unable to work together due to interface incompatibility to collaborate. Here, it is used to unify data reading operations across different physical interfaces (such as Ethernet, CAN, serial port, SPI, video acquisition interfaces, etc.). Based on the "data interface type" and "interface configuration parameters" bound to each instance in the sensor plug-in instance table output in step S10, this step creates corresponding, specific interface instances (e.g., an Ethernet Socket instance or a CAN channel instance). After unified configuration (such as trigger mode, timeout time, etc.), these interface instances form a "diagnostic interface instance table." Each interface instance is responsible for reading raw byte stream data from the corresponding physical sensor device and encapsulating the read data into a structured "raw data packet." This data packet not only contains the raw data body, but also includes an "interface source identifier" (indicating which interface instance it comes from), a "device identifier" (corresponding to the specific sensor), a "read timestamp" (recording the data arrival time), and a "read status identifier" (such as whether it timed out, whether it was an empty read, etc.). This additional information provides crucial basis for subsequent data tracing, latency calculation, and preliminary interface health assessment. The final output "raw data packet sequence" is a raw data set with rich metadata.

[0029] This step plays a crucial role in unifying and abstracting the data acquisition layer in this invention. It uses an adapter pattern to shield the significant differences in communication protocols, data formats, and access methods among various underlying sensor interfaces, providing a consistent and transparent data reading interface to the upper layers. This allows the processing logic in step S30 and beyond to disregard whether the data originates from the CAN bus or Ethernet; it only needs to process the unified raw data packet sequence, greatly simplifying the system architecture and reducing coupling between modules. Simultaneously, by attaching source, timestamp, and status information to the raw data packets, a solid foundation is laid for the observability of the entire data stream and subsequent accurate diagnostics.

[0030] Compared to traditional technologies that require writing entirely different data acquisition threads or modules for different interfaces, resulting in high code duplication and a mix of interface and business logic, the technical solution in this step demonstrates significant engineering advantages. Traditionally, adding a new interface type (such as FlexRay) requires developing a complete set of acquisition code from scratch and carefully integrating it into the system, which is prone to introducing errors. This invention, however, uses the adapter pattern to encapsulate interface differences in a separate adapter class. When adding a new interface, only a new adapter class conforming to the unified interface specification needs to be implemented and specified in the configuration; no other parts of the system need to be modified. This design significantly improves code reusability, elegantly supports future new automotive interface standards, and enhances future compatibility.

[0031] For example, a camera transmits data via Ethernet (GigE Vision protocol), and a millimeter-wave radar sends data via a CAN bus. In step S20, two adapter instances are created according to the configuration: an Ethernet interface adapter instance and a CAN interface adapter instance. The Ethernet adapter instance may be configured in "condition-triggered mode," listening on a specific UDP port; the CAN adapter instance may be configured in "polling-triggered mode," periodically reading the CAN channel. When a frame of image data arrives from the camera, the Ethernet adapter is triggered, reads the data, encapsulates it into a raw data packet, and marks the interface source as "ETH". A "dapter1", the device identifier is "Front" C The system displays "amera" and records the precise arrival timestamp. Simultaneously, the CAN adapter polls and packages radar data at its own pace. Although the underlying communication mechanisms are completely different, the upper layers receive the same raw data packet sequence in a uniform format, allowing subsequent processing to proceed equally.

[0032] Step S30: Based on the original data packet sequence, perform frame data preprocessing tasks using a template method and a circular buffer to output a standardized frame message sequence; The "Template Method Pattern" in this step is a behavioral design pattern that defines an algorithm skeleton (i.e., a template method) for an operation in the parent class (base class), while deferring the specific implementation of some steps to subclasses. In this invention, the sensor base class defines a general algorithm skeleton for frame data preprocessing, such as general buffer management and timestamp recording, while the specific logic of "protocol parsing," "data integrity verification" (such as CRC check), and "frame structure encapsulation" is implemented by the specific sensor plugins (subclasses) instantiated in step S10. A "circular buffer" is an efficient data structure used to buffer data between producers (data writers) and consumers (data readers), particularly suitable for processing real-time data streams. This step first distributes the raw data packet sequence to the corresponding sensor plugin instance based on the metadata (interface source identifier, device identifier) ​​in the sequence. Then, the plugin instance calls the template method inherited from the base class to parse, verify, and encapsulate the raw byte stream, forming "sensor frame data" with clear semantics (e.g., a radar frame containing a list of targets, or a frame of image data). Subsequently, this frame data is written into a "frame data circular buffer" for buffering. Finally, a "normalized frame message" is generated for each valid frame of data in the buffer. This message contains a "frame timestamp" (usually using or refining the read timestamp), a "frame buffer index" (pointing to its position in the circular buffer), a "frame validity status" (verification result), and a "sensor type identifier", thus outputting a uniform "normalized frame message sequence" that is easy to distribute later.

[0033] This step in this invention realizes the conversion and standardization of data from raw byte streams to standard messages understandable at the application layer, serving as a crucial link between the preceding and following steps. The template method pattern ensures the consistency of the data processing workflow framework across different sensors, while allowing for flexible variations in their unique parsing logic. The introduction of a circular buffer effectively solves the problem of data loss that may occur due to short-term fluctuations in data processing speed or untimely processing by the consumer (publishing module), ensuring the continuity and integrity of the data stream. The output standardized frame message sequence strips away the sensor-specific raw format, providing a clean and structured data source for subsequent unified publishing and diagnostics.

[0034] Compared to traditional technologies where data parsing code for each sensor is scattered across various acquisition or application modules, resulting in strong coupling between parsing logic and acquisition and business logic, and a lack of unified data buffer management, the technical solution in this step provides a clearer and more robust architecture. In traditional methods, modifications to the parsing logic can affect acquisition or business modules, and frame loss is easily caused by untimely data processing. This invention uses the template method pattern to converge the parsing logic into specific plugin classes, ensuring clear responsibilities. By introducing an independent circular buffer layer, data production (parsing) and consumption (publishing) are decoupled, allowing them to run at different rates, smoothing the data flow, and enhancing the ability to handle instantaneous load pressure. This is crucial for ensuring the real-time performance and reliability of automotive-grade systems under complex road conditions.

[0035] For example, a raw data packet is received from step S20. Step S30 distributes it to the millimeter-wave radar plugin instance based on the device identifier. The plugin instance calls the template method of the base class. Within the template method framework, it performs specific radar protocol parsing (e.g., parsing out multiple target information such as range, azimuth, velocity, and RCS value), and then performs a CRC check to ensure that the data is error-free during transmission. After the check passes, it encapsulates this set of target information into a structured radar frame object. Next, this radar frame object is written to the millimeter-wave radar's dedicated frame data circular buffer. Simultaneously, a standardized frame message is generated, which may contain: {frame timestamp: 1234567890.123, frame buffer index: 5, frame valid status: true, sensor type identifier: RADAR}. The messages in this sequence no longer contain specific target data, but rather "references" or "notifications" to specific data frames in the buffer, greatly reducing the amount of data transmitted internally and improving efficiency.

[0036] Step S40: Based on the standardized frame message sequence, perform the sensor data publishing record generation task using publish-subscribe mode or request-response mode, and output a unified publishing record; The "publish-subscribe mode" and "request-response mode" in this step are two common inter-process or inter-module communication modes. The "publish-subscribe mode" is an asynchronous communication mode where the publisher publishes messages to a specific topic without needing to know which subscribers exist; subscribers subscribe to topics of interest and receive all messages published to that topic. The "request-response mode" is a synchronous or asynchronous communication mode where the client sends a request and waits for or asynchronously receives a response from the server. In this step, based on the "communication adapter name" implicitly or associated in the standardized frame message sequence (this information originates from the configuration file binding in step S10), the corresponding communication adapter instance (e.g., a ROS2 publisher adapter, a DDS adapter, or an internal IPC adapter) is queried. Then, based on the adapter instance's own configuration parameters, it is determined which mode should be used to publish the data carried by the current standardized frame message. If a publish-subscribe model is used, the "topic name," "publishing timestamp" (the actual time the message was sent), and "publishing status" (e.g., success, failure) of this publishing action will be recorded. If a request-response model is used (for example, some sensor data requires a response confirmation), the "request timestamp," "response timestamp" (the time the response was received), and "response status" will be recorded. All these records are aggregated to form a "unified publishing record." This record does not contain the specific sensor data content, but focuses on the "behavior" and "timing" information of data distribution, and is one of the core inputs for state diagnosis in step S50.

[0037] This step in this invention serves as a unified management system for data output and a mechanism for generating activity logs. By supporting multiple communication modes, it allows the processed, standardized sensor data to flexibly adapt to the needs of different downstream systems or applications. For example, real-time sensing algorithms may require a subscription model, while diagnostic services may use a request-response model to obtain snapshots at specific moments. More importantly, by recording key metadata for each data release or request-response event, it creates an observable layer regarding whether the data was delivered in a timely and successful manner. This unified release record acts as a bridge connecting the sensor data processing pipeline with the final health status diagnosis, transforming the internal processing status of the data stream into an event log that can be used for quantitative analysis.

[0038] Compared to traditional technologies where sensor data is processed and directly sent to fixed consumers, lacking effective monitoring and recording of the sending process itself, or where monitoring logs are scattered across different modules and inconsistent in format, this technical solution provides a more systematic and standardized observation method. In traditional approaches, when downstream applications fail to receive data, it's difficult to quickly pinpoint the source of the problem—whether it's a sensor-related issue, a data processing problem, or a network communication problem. This invention, by mandating the generation of standardized records for every data export operation and managing all records uniformly, can clearly track the entire link status of each data frame from reading to publishing. This enables advanced diagnostics such as end-to-end latency analysis and publishing success rate statistics, significantly improving the efficiency of fault diagnosis and performance analysis.

[0039] Step S50: Based on the unified release record, heartbeat detection and finite state machine are used to diagnose the operating status of multi-source sensors, and the operating diagnosis results are output.

[0040] Based on the "unified release record" generated in step S40, and combined with the "heartbeat information" (a periodic signal indicating that the plugin's own logic is operating normally) periodically emitted by each sensor plugin instance, the operating status of the sensors is comprehensively judged. First, it uses the timestamps (release timestamp, request / response timestamp) and status (release status, response status) in the release record, as well as the heartbeat information, to construct an "operational observation vector" for each sensor. This vector contains multiple dimensions of information reflecting the health of the sensor, such as the timeliness and continuity of data release, and whether the heartbeat is normal. Then, an "anomaly confidence level" for each sensor is calculated through a predefined mathematical model (formula). This formula integrates multiple factors such as "interface read latency" (reflecting the latency of the data acquisition process), "end-to-end latency from plugin parsing to release completion" (reflecting the total latency of data processing and distribution), "frame rate deviation" (the deviation between the actual frame rate and the reference frame rate, reflecting the continuity of the data flow), and "discrete anomaly indicators" (such as heartbeat loss, verification failure, and other hard errors), and adjusts the importance of each factor through weighting coefficients (α, β, γ, δ). Finally, a finite state machine (FSM) model is used for state decision-making. The FSM determines whether the sensor should be in an "abnormal state," "recovery state," or "maintain its original state" based on whether the calculated anomaly confidence level exceeds a threshold, and whether the continuous anomaly count or continuous normal count has reached a stable number of iterations. This mechanism introduces a "hysteresis" effect in state transitions, effectively avoiding frequent state fluctuations caused by transient interference, resulting in more stable and reliable diagnostic results. The final output "operational diagnostic result" is a clear and stable state identifier.

[0041] This step in the invention enables intelligent reasoning and decision-making from raw observation data to a higher level of health status. It is no longer a simple Boolean judgment (online / offline), but rather calculates a comprehensive anomaly confidence level through the fusion of multi-dimensional, quantitative indicators, thus enabling a more nuanced perception of sensor performance degradation. The introduction of a finite state machine endows the diagnostic logic with "memory" and "anti-jitter" capabilities. The diagnostic results are no longer a simple mapping of instantaneous observations, but a stable conclusion after a period of behavioral pattern analysis. This significantly improves the reliability and practicality of the diagnostic results, providing a reliable basis for higher-level fault handling, system degradation, or early warning.

[0042] Compared to traditional technologies, sensor diagnostics typically rely on simple timeout checks or heartbeat detection, providing only a binary "good" or "bad" conclusion. These methods are also susceptible to false alarms due to environmental interference such as network congestion and CPU scheduling fluctuations. The technical solution presented in this invention represents a more advanced and robust diagnostic approach. Traditional binary diagnostics cannot predict performance degradation trends, and frequent state transitions can trigger unnecessary restarts or switches at higher levels. This invention quantifies the "sub-health" level of sensors through confidence calculation using multi-indicator fusion, enabling early warning. The hysteresis design of a finite state machine ensures the rigor of state transitions, avoiding the "ping-pong effect" and resulting in smoother and more reliable diagnostic outputs. This diagnostic approach better meets the actual needs of complex systems (such as autonomous driving systems) for sensor reliability management and supports more refined fault-tolerant control strategies.

[0043] Example 2: Furthermore, the present invention provides an automotive-grade multi-source sensor data unified diagnostic system, which employs an automotive-grade multi-source sensor data unified diagnostic method from the above embodiments, and can solve the technical problem of unified diagnostics for automotive-grade multi-source sensor data. The beneficial effects of the automotive-grade multi-source sensor data unified diagnostic system provided by the present invention are the same as those of the automotive-grade multi-source sensor data unified diagnostic method provided in the above embodiments, and other technical features of the automotive-grade multi-source sensor data unified diagnostic system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0044] Example 3: This invention provides an automotive-grade multi-source sensor data unified diagnostic device. The device includes: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor, which are then executed to enable the at least one processor to perform the automotive-grade multi-source sensor data unified diagnostic method described in Example 1. The automotive-grade multi-source sensor data unified diagnostic device in this invention can include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. This automotive-grade multi-source sensor data unified diagnostic device is merely an example and should not limit the functionality or scope of the invention. An automotive-grade multi-source sensor data unified diagnostic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes based on a program stored in read-only memory or a program loaded from a storage device into random access memory. The random access memory also stores various programs and data required for the operation of the automotive-grade multi-source sensor data unified diagnostic device. The processing unit, read-only memory, and random access memory are interconnected via a bus. I / O interfaces are also connected to the bus. Typically, the following systems can be connected to the I / O interface: input devices including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices including, for example, magnetic tapes, hard disks, etc.; and communication devices. The communication device allows the automotive-grade multi-source sensor data unified diagnostic device to communicate wirelessly or wiredly with other devices to exchange data. Although the figures show an automotive-grade multi-source sensor data unified diagnostic device with various systems, it should be understood that implementation or possession of all the systems shown is not required. It can be implemented alternatively or with more or fewer systems.

[0045] Example 4: This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described unified diagnostic method for automotive-grade multi-source sensor data. The computer program product provided by this invention can solve the technical problem of unified diagnostics for automotive-grade multi-source sensor data. Compared with the prior art, the beneficial effects of the computer program product provided by this invention are the same as those of the unified diagnostic method for automotive-grade multi-source sensor data provided in the above embodiments, and will not be repeated here.

[0046] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device, or installed from a read-only memory. When the computer program is executed by a processing device, it performs the functions defined in the methods of the embodiments disclosed in this invention.

[0047] It should be understood that the various parts disclosed in this invention can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics may be combined in any suitable manner in one or more embodiments or examples.

[0048] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the present invention and its equivalents, the present invention also intends to include these modifications and variations.

Claims

1. A unified diagnostic method for automotive-grade multi-source sensor data, characterized in that, The methods include: Step S10: Obtain the multi-source sensor configuration file, and based on the multi-source sensor configuration file, execute the sensor plugin instantiation task using dynamic library loading and factory mode, and output the sensor plugin instance table; Step S20: Based on the sensor plug-in instance table, execute the multi-type sensor interface reading task using the adapter mode and output the raw data packet sequence; Step S30: Based on the original data packet sequence, perform frame data preprocessing tasks using a template method and a circular buffer to output a standardized frame message sequence; Step S40: Based on the standardized frame message sequence, perform the sensor data publishing record generation task using publish-subscribe mode or request-response mode, and output a unified publishing record; Step S50: Based on the unified release record, heartbeat detection and finite state machine are used to diagnose the operating status of multi-source sensors, and the operating diagnosis results are output.

2. The automotive-grade multi-source sensor data unified diagnostic method as described in claim 1, characterized in that, Step S10, which involves obtaining the multi-source sensor configuration file and constructing a sensor plugin instance table based on the configuration file using dynamic library loading and factory pattern, specifically includes: Step S101: Parse the multi-source sensor configuration file, extract the sensor name, plug-in class name, plug-in dynamic library path, data interface type, diagnostic code set, diagnostic threshold parameter and communication adapter name, and generate a sensor configuration description table; Step S102: Based on the plug-in dynamic library path and plug-in class name in the sensor configuration description table, instantiate the corresponding sensor plug-in object by calling the dynamic library loading method to obtain the sensor plug-in object table; Step S103: Bind each sensor plug-in object in the sensor plug-in object table with its corresponding sensor name, data interface type, diagnostic code set, diagnostic threshold parameter, and communication adapter name to form the sensor plug-in instance table.

3. The automotive-grade multi-source sensor data unified diagnostic method as described in claim 1, characterized in that, Step S20, based on the sensor plug-in instance table, involves executing a multi-type sensor interface reading task using the adapter mode and outputting the raw data packet sequence. This step specifically includes: Step S201: Based on the data interface type corresponding to each sensor plug-in instance in the sensor plug-in instance table, create at least one interface instance among Ethernet interface instance, CAN interface instance, serial port interface instance, SPI interface instance and video acquisition interface instance; Step S202: Based on the interface configuration parameters corresponding to each sensor plug-in instance in the sensor plug-in instance table, configure the read trigger mode, read timeout, number of data buffers, data filtering conditions and device identifier for the interface instance to obtain the diagnostic interface instance table; Step S203: Read the raw data of the corresponding sensor through the diagnostic interface instance table, and encapsulate the read raw data into a raw data packet sequence with interface source identifier, device identifier, reading timestamp and reading status identifier.

4. The automotive-grade multi-source sensor data unified diagnostic method as described in claim 3, characterized in that, Step S202, configuring the read trigger mode, read timeout, data buffer size, data filtering conditions, and device identifier for the interface instance, includes: Configure a packet ring buffer for each interface instance, the packet ring buffer including write nodes, ready nodes and read nodes; When the read trigger mode is the polling trigger mode, the corresponding interface instance is controlled to continuously read the original data within a preset number of polling times, and the number of empty reads is recorded when no valid data is read. When the read trigger mode is a condition trigger mode, the corresponding interface instance is controlled to wait for data to arrive, and a read timeout flag is recorded when the waiting time exceeds the read timeout time. Based on the number of empty reads, the read timeout flag, and the node update status of the data packet circular buffer, an interface read stability parameter is generated, and the interface read stability parameter is written into the read status flag of the original data packet sequence.

5. The automotive-grade multi-source sensor data unified diagnostic method as described in claim 1, characterized in that, Step S30, based on the original data packet sequence, involves performing frame data preprocessing using a template method and a circular buffer to output a standardized frame message sequence. This step specifically includes: Step S301: Distribute the original data packet sequence to the corresponding sensor plug-in instance according to the interface source identifier and device identifier in the original data packet sequence; Step S302: The sensor plugin instance calls the template method in the corresponding sensor base class to perform protocol parsing, data integrity verification, and frame structure encapsulation on the original data packet sequence to obtain the sensor frame data sequence; Step S303: Write the sensor frame data sequence into the frame data circular buffer, and generate a standardized frame message sequence for each frame data, which includes a frame timestamp, frame cache index, frame validity status, and sensor type identifier.

6. The automotive-grade multi-source sensor data unified diagnostic method as described in claim 1, characterized in that, In step S40, based on the standardized frame message sequence, the sensor data publishing record generation task is executed using a publish-subscribe mode or a request-response mode, and a unified publishing record is output. This step specifically includes: Step S401: Query the corresponding communication adapter instance based on the communication adapter name in the standardized frame message sequence; Step S402: Determine whether the current standardized frame message adopts a publish-subscribe mode or a request-response mode based on the communication configuration parameters of the communication adapter instance; Step S403: When using the publish-subscribe mode, record the topic name, publication timestamp, and publication status of the corresponding standardized frame message; when using the request-response mode, record the request timestamp, response timestamp, and response status of the corresponding standardized frame message, and output a unified publication record.

7. The automotive-grade multi-source sensor data unified diagnostic method as described in claim 1, characterized in that, Step S50, which involves using heartbeat detection and a finite state machine to diagnose the operating status of multi-source sensors based on the unified release record and outputting the operating diagnosis results, specifically includes: Step S501: Based on the release timestamp, release status, and response status in the unified release record, and combined with the heartbeat information of the corresponding sensor plugin instance, generate the operation observation vector of each sensor; Step S502: Calculate the anomaly confidence level of each sensor based on the observed vector, where the anomaly confidence level of the i-th sensor at time t is... satisfy: in, This represents the interface readout delay of the i-th sensor at time t. This indicates the preset maximum interface read latency. This represents the end-to-end delay from plugin parsing to deployment completion for the i-th sensor at time t. This indicates the preset maximum end-to-end delay. This represents the actual frame rate of the i-th sensor within the current statistical window. This represents the reference frame rate of the i-th sensor. This represents the discrete anomaly flag of the i-th sensor at time t. , γ These represent the weighting coefficients corresponding to interface read latency, end-to-end latency, frame rate deviation, and discrete anomaly flag, respectively. Step S503: Based on the anomaly confidence level, a finite state machine is used to determine the operational diagnostic results of each sensor, wherein the operational state of the i-th sensor at time t is... satisfy: in, This represents the anomaly confidence threshold. This represents the consecutive anomaly count of the i-th sensor. This represents the continuous normal count of the i-th sensor. Indicates the number of times the anomaly has been confirmed to be stable. This indicates the number of times the system has been confirmed to be stable.

8. A unified diagnostic system for automotive-grade multi-source sensor data, applied to the unified diagnostic method for automotive-grade multi-source sensor data as described in any one of claims 1 to 7, characterized in that, The automotive-grade multi-source sensor data unified diagnostic system includes: The plugin instance building module is used to obtain the multi-source sensor configuration file and build a sensor plugin instance table based on the multi-source sensor configuration file using dynamic library loading and factory pattern. The interface data reading module is used to perform multi-type sensor interface reading tasks based on the sensor plug-in instance table and in adapter mode, and output the raw data packet sequence. The frame data preprocessing module is used to perform frame data preprocessing tasks based on the original data packet sequence, using a template method pattern and a circular buffer, and output a standardized frame message sequence. The release record generation module is used to perform sensor data release record generation tasks based on the standardized frame message sequence, using a publish-subscribe mode or a request-response mode, and output a unified release record. The unified diagnostic module is used to perform multi-source sensor operation status diagnosis based on the unified release record using heartbeat detection and finite state machine, and output the operation diagnosis results.

9. A unified diagnostic device for automotive-grade multi-source sensor data, characterized in that, The automotive-grade multi-source sensor data unified diagnostic device includes: a memory, a processor, and an automotive-grade multi-source sensor data unified diagnostic program stored in the memory and executable on the processor. When the automotive-grade multi-source sensor data unified diagnostic program is executed by the processor, it implements an automotive-grade multi-source sensor data unified diagnostic method according to any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes an automotive-grade multi-source sensor data unified diagnostic program, which, when executed by a processor, implements an automotive-grade multi-source sensor data unified diagnostic method according to any one of claims 1 to 7.

Images