Intelligent cabin probe data processing method and device and computer equipment

Abstract

The invention provides an intelligent cabin probe data processing method and device and computer equipment, relates to the technical field of intelligent cabin monitoring, and aims to realize full coverage of structural probe data categories of an intelligent cabin, efficient processing of high-frequency probe data and no loss of key probes and provide a system-level probe processing framework and interface support for data burying points. The scheme comprises the following steps: capturing a multi-source event of the intelligent cabin system; generating different first probe data according to different multi-source events, and caching the first probe data into a probe processing framework; implementing a cache and pop-up strategy on the first probe data by using the probe processing framework, popping up second probe data, and distributing the second probe data to a data burying point control; and uploading the second probe data to the cloud by using the data burying point control.

Description

Technical Field

[0001] This application relates to the field of intelligent cockpit monitoring technology, and in particular to an intelligent cockpit probe data processing method, apparatus, and computer equipment. Background Technology

[0002] With the rapid development of intelligent connected vehicles and in-vehicle electronic technology, intelligent cockpit systems have gradually become an important part of modern automobiles, with functions covering infotainment, driver assistance, in-vehicle connectivity, and safety monitoring.

[0003] However, to achieve cloud-based probe data reporting, the various applications running on the intelligent cockpit system require a separate third-party probe tracking SDK suite to meet the structured data vehicle-to-cloud transmission needs. However, the underlying system software, limited by the application environment, cannot directly integrate this third-party tracking SDK suite. This results in a lack of a low-cost probe data uploading method for the intelligent cockpit system's framework layer (FRAMEWORKS), onboard support layer (BSP), and cross-domain QNX layer. Furthermore, the existing intelligent cockpit system lacks a high-performance probe processing framework and standardized interface support, causing difficulties in implementing data tracking at both the framework and underlying software levels. Simultaneously, the lack of an efficient probe caching mechanism leads to high performance overhead and loss of critical probe data when third-party tracking SDK suites process high-frequency probe data from devices. Summary of the Invention

[0004] Based on this, it is necessary to address the shortcomings of existing technologies, such as incomplete coverage of structured probe data categories in intelligent cockpits, high processing load of high-frequency probe data, easy loss of key probe data, and difficulty in implementing data embedding. This requires providing an intelligent cockpit probe data processing method, apparatus, and computer equipment to achieve full coverage of structured probe data categories, efficient processing of high-frequency probe data, and prevention of key probe loss. The system-level probe processing framework and interface support should also be provided for data embedding.

[0005] To achieve the above-mentioned technical effects, the technical solution of the present invention is as follows: A method for processing probe data in a smart cockpit includes: S1. Capture multi-source events from the intelligent cockpit system; S2. Generate different first probe data based on different multi-source events, and cache the first probe data in the probe processing framework; S3. Using the probe processing framework, implement a caching and pop-up strategy for the first probe data, pop up the second probe data, and distribute the second probe data to the data embedding control; S4. Use the data embedding control to upload the second probe data to the cloud.

[0006] Preferably, the multi-source events include software events and device events; the software events include system crash events, application crash events, and application blocking events; the device events include device anomaly events, performance data acquisition events, thermal management status change events, power management status change events, memory usage change events, and log anomaly events; the first probe data includes system crash probe data, application crash probe data, application blocking probe data, device anomaly probe data, performance data acquisition probe data, thermal management status probe data, power management status change probe data, memory usage change probe data, and log anomaly probe data.

[0007] Preferably, different first probe data are generated using monitoring services, including crash monitoring services and device monitoring services. Cache of the first probe data into the probe processing framework includes: The crash monitoring service caches the system crash probe data, application anomaly probe data, and application blocking data into the probe processing framework through event triggering. The device monitoring service periodically collects the performance data acquisition probe data and caches the performance data acquisition probe data in the probe processing framework. The device monitoring service is triggered by real-time operating system status changes, and caches the thermal management status change probe data into the probe processing framework. The device monitoring service is triggered by a power transition and caches the power management status probe data into the probe processing framework. The device monitoring service periodically collects the memory usage probe data. If the memory usage probe data exceeds a preset threshold, the memory usage probe data is cached in the probe processing framework. The device monitoring service caches the corresponding log anomaly probe data into the probe processing framework at a fixed heartbeat cycle.

[0008] Preferably, generating the log anomaly probe data includes: Establish a log stream; Continuously feed the log stream into the log sniffing program; The log stream is identified by a log sniffing program at a fixed heartbeat cycle. If the log similarity in the log stream exceeds a preset threshold, the log anomaly probe data is generated.

[0009] Preferably, the step of using the probe processing framework to implement a caching and pop-up strategy for the first probe data, popping up the second probe data, and distributing the second probe data to the data tracking control includes: S41. Write the first probe data into a high-performance cache library through a preset multi-producer thread; S42. Transfer the first probe data from the high-performance cache library to a thread-safe queue; S43. The second probe data is asynchronously popped from the thread-safe queue through a preset single consumer thread and distributed to the data tracking control.

[0010] Preferably, the second probe data is standardized data that conforms to the upload format of the data embedding control.

[0011] Preferably, the data tracking control is a third-party tracking SDK suite.

[0012] The present invention also provides an intelligent cockpit probe data processing device, comprising: The event capture module is used to capture multi-source events of the intelligent cockpit system; The monitoring service module is used to generate different first probe data based on different multi-source events, and cache the first probe data into the probe processing framework; The probe data processing module is used to implement a caching and pop-up strategy for the first probe data using the probe processing framework, pop up the second probe data, and distribute the second probe data to the data embedding control. The probe data transmission module is used to upload the second probe data to the cloud using the data embedding control.

[0013] The present invention also provides a computer device, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; The memory is used to store at least one executable instruction that causes the processor to perform the operation of the intelligent cockpit probe data processing method.

[0014] The present invention also provides a computer-readable storage medium storing at least one executable instruction, which, when executed on a computer device, causes the computer device to perform the operation of the person image generation method.

[0015] Compared with the prior art, the beneficial effects of the technical solution of the present invention are: This invention proposes a method, apparatus, and computer device for processing probe data in an intelligent cockpit. It captures multi-source events from an intelligent cockpit system; generates different first probe data based on these events to cover more probe data categories; caches the first probe data in a probe processing framework to effectively integrate multi-source probe data; utilizes the probe processing framework to implement a caching and pop-up strategy for the first probe data, popping up second probe data and distributing it to a data tracking control to achieve efficient probe data processing and prevent the loss of critical probes; finally, the data tracking control enables highly reliable cloud deployment of probe data; ultimately filling the gap in the tracking link and improving cockpit fault diagnosis efficiency and system stability. Attached Figure Description

[0016] Figure 1 This is a flowchart of the intelligent cockpit probe data processing method in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the intelligent cockpit probe data processing method in an embodiment of the present invention. Figure 3 This is a schematic diagram illustrating the data upload to the cloud for the intelligent cockpit probe data processing method in an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the caching and pop-up strategies in an embodiment of the present invention; Figure 5 This is a structural block diagram of the intelligent cockpit probe data processing system in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of a computer device proposed in an embodiment of the present invention.

[0017] 61. Processor; 62. Memory; 63. Communication interface; 64. Communication bus; 65. Executable instructions. Detailed Implementation

[0018] The accompanying drawings are for illustrative purposes only and should not be construed as limiting the scope of this patent. It is understandable to those skilled in the art that some well-known details may be omitted from the accompanying drawings; The positional relationships depicted in the accompanying drawings are for illustrative purposes only and should not be construed as limiting this patent. To better illustrate this embodiment, some parts of the accompanying drawings may be omitted, enlarged, or reduced, and do not represent actual dimensions. The descriptions of directions such as "up" and "down" are not intended to limit this patent. To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments.

[0019] Example 1 like Figure 1 and Figure 2 As shown, this embodiment provides a smart cockpit probe data processing method, including: S1. Capture multi-source events from the intelligent cockpit system; In S1, the multi-source events include software events and device events. The software events include system crash events, application crash events, and application blocking events. The device events include device abnormal events, performance data acquisition events, thermal management status change events, power management status change events, memory usage change events, and log abnormal events.

[0020] S2. Based on different multi-source events, use the monitoring service to generate different first probe data, and cache the first probe data into the probe processing framework; In S2, based on system crash events, system crash probe data is generated using the monitoring service: a dedicated program SYSTEMDUMPER is built to capture watchdog events caused by deadlock in the framework layer; this dedicated program is entrusted to accurately identify system crash anomalies, crash types, and times and transmit them to the crash monitoring service CRASHMONITOR to generate system crash probe data.

[0021] More specifically, the cockpit jamming and restart behavior caused by a BINDER inter-process deadlock event occurring at the system framework layer is delegated to the cockpit system's WATCHDOG watchdog mechanism for capture. Simultaneously, a dedicated SYSTEMDUMPER acquisition program provided by this invention is activated to perform cross-sectional TRACE information acquisition of critical cockpit system processes and transmit it to the crash monitoring service CRASHMONITOR to generate system crash probe data.

[0022] In S2, application crash probe data is generated based on application crash events: the cockpit application crash anomaly monitoring mechanism JAVADUMPER is deployed to the underlying system. By monitoring the DROPBOX directory from the framework layer as the entry point for crash event identification, it accurately identifies the application name, crash time, and root cause of the cockpit application crash and generates application crash probe data.

[0023] In S2, application blocking probe data is generated based on application blocking events: the cockpit application crash anomaly monitoring mechanism JAVADUMPER is deployed to the underlying system. By monitoring the DROPBOX directory from the framework layer as the entry point for execution blocking time identification, it accurately identifies the cockpit execution blocking application name, execution blocking time, and blocking root cause and transmits them to the crash monitoring service CRASHMONITOR to generate application blocking probe data.

[0024] In S2, based on device anomaly events, device anomaly probe data is generated: The camera fault diagnosis program deployed on the cockpit QNX system is transmitted via a shared-memory cross-domain communication middleware. Based on camera anomaly events such as image sensor communication errors, image sensor configuration errors, image sensor frame synchronization errors, image sensor over-temperature anomalies, serializer / deserializer configuration errors, power management chip failures, and voltage over / under anomalies, this data is transmitted to the Device Monitoring Service (DEVICEMONITOR) to generate camera anomaly probe data. I2C communication anomaly events originating from the cockpit MCU domain are monitored via cross-domain communication middleware and transmitted to the Device Monitoring Service (DEVICEMONITOR) to generate communication anomaly probe data.

[0025] In S2, based on the performance data acquisition event, performance data acquisition probe data is generated: the performance capture program is executed on the cockpit QNX system side to capture raw performance data, and a fixed periodic method is configured to implement performance data acquisition. The performance probe data is transmitted to the device monitoring service DEVICEMONITOR provided by this invention through a shared memory cross-process transmission method to generate performance data acquisition probe data.

[0026] In S2, thermal management status probe data is generated based on thermal management status change events: thermal management status change events identified by the cockpit QNX system are transmitted to the device monitoring service DEVICEMONITOR through a shared memory cross-domain communication middleware to generate thermal management status probe data.

[0027] In S2, power management status probe data is generated based on power management status change events: the power monitoring program listens for status transition events provided by the cockpit power management basic service, transmits them to the device monitoring service DEVICEMONITOR, and generates power management status probe data.

[0028] In S2, memory usage probe data is generated based on memory usage change events: The memory monitoring program relies on a fixed-period heartbeat mechanism to listen for changes in cockpit memory usage values ​​and transmits them to the device monitoring service DEVICEMONITOR to generate memory usage probe data.

[0029] In S2, log anomaly probe data is generated based on log anomaly events. Located on the LOGD service side of the cockpit's underlying system, a streaming cockpit log stream is established via SOCKET communication and streamed to the LOGSNIFFER program provided in this invention. The LOGSNIFFER program is synchronously configured with rule-based anomaly log key-value rules and utilizes a sliding window caching mechanism to efficiently compress the cockpit log stream. The LOGSNIFFER program implements a fixed-period heartbeat mechanism, performing transcoding operations on the cached log blocks each time the heartbeat window is reached. If the preset cockpit fault log similarity exceeds a preset value, the LOGSNIFFER program, based on the log anomaly event, transmits it to the DEVICEMONITOR service to generate log anomaly probe data.

[0030] In S2, when an abnormal event in the cockpit network is detected by the Ethernet protocol stack, it transmits the abnormal event to the LOGSNIFFER program by outputting a fixed-format abnormal log to the cockpit log system. Upon reaching a fixed heartbeat cycle, the LOGSNIFFER program performs batch identification of cached logs based on rules, and the abnormal event is then distributed to the DEVICEMONITOR service. Similarly, when an abnormal event in the cockpit positioning is detected at the GPS protocol layer, it transmits the source of the abnormal event to the LOGSNIFFER program by outputting a fixed-format abnormal log to the cockpit log system. Upon reaching a fixed heartbeat cycle, the LOGSNIFFER program performs batch identification of cached logs based on rules, and the abnormal event is then distributed to the DEVICEMONITOR service.

[0031] S3. Use the monitoring service to cache the first probe data into the probe processing framework; S4. Using the probe processing framework, perform cache management and queue scheduling on the first probe data, pop up the second probe data, and distribute the second probe data to the data embedding control; Specifically, the second probe data is standardized data that conforms to the upload format of the data embedding control.

[0032] In S4, considering the high frequency and diverse categories of cockpit probe data, a multi-producer thread is constructed to write probe data to a high-performance cache library. The temporary storage space size and time-based eviction policy of the high-performance cache library are configured. Simultaneously, a single consumer is configured to pop cached probes asynchronously. Probe data is transferred to a thread-safe queue (BLOCKINGQUEUE) and processed by a single consumer thread. When probe data is evicted due to size exceeding limits or expiration, an asynchronous operation ensures that the listener does not block the producer. An LRU (Least Recently Used) eviction policy is configured for the high-performance cache library supporting the probe data processing framework.

[0033] S5. Use the data embedding control to upload the second probe data to the cloud.

[0034] In S5, the data tracking control is a third-party tracking SDK suite. In this embodiment, a host program is built to connect to the cache library consumer. The host program transmits the released probes to the third-party tracking SDK suite and finally transmits the structured probe data to the cloud.

[0035] Example 2 Based on relevant technical information, in order to process probe data more comprehensively in a smart cockpit, the vehicle often needs to have the ability to process probe data from the cockpit system framework layer FRAMEWORKS, the onboard support layer BSP, and the cockpit cross-domain QNX layer. When problems are encountered during development or after product release, cockpit probe data can be pulled from the vehicle cloud infrastructure backend to achieve the purpose of fault location.

[0036] However, if the vehicle's instrument cluster and entertainment system control ECU malfunctions, the lack of more comprehensive structured probe data on the fault characteristics means that the retrieved probe data cannot effectively record the fault characteristics, thus making fault location impossible.

[0037] Based on this, the structured probe data processing method provided in the embodiments of the present invention, such as... Figure 3 As shown, this invention fills the gap in the link between the underlying system data and the application layer third-party tracking SDK suite by constructing a cockpit probe processing framework. Based on the existing acquisition of application layer probe data, the invention enriches the categories of cockpit system probe data through shared memory communication and log stream sniffing mechanisms. Furthermore, this invention provides a high-performance MPSC caching mechanism implemented within the probe processing framework and integrates an efficient LRU cache eviction strategy. This can solve the problem of critical probe data loss and effectively address the performance consumption issues caused by high-frequency probes.

[0038] The process includes the following steps: Step 1: System and application crash data capture mechanism: This embodiment provides a method for capturing system and application crash data. If a crash occurs in the human-computer interaction application, framework layer service, or underlying software on the SOC, a tombstone file collection program is triggered by registering the kernel CORE_PATTERN; and abnormal crash data is captured by listening for the DROPBOX signal indicating application runtime abnormality. The crash event is recorded as structured probe data in storage cells, which can be used in conjunction with other category data to locate vehicle faults.

[0039] In addition, this embodiment provides a WATCHDOG event capture mechanism caused by deadlock at the system framework layer. This is achieved through the SYSTEMDUMPER program in this embodiment, which collects key information about critical system processes via TRACE. Cockpit system crash events are then transmitted to the probe processing framework.

[0040] Step 2, Build the cockpit crash monitoring service CRASHMONITOR: This embodiment provides a crash monitoring program to receive crash events transmitted from step 1. The crash monitoring program performs a structured transformation of the crash probes and transmits the transformed probe data as a multi-producer model to the S104 cockpit probe processing framework for caching.

[0041] Step 3, Build the DEVICEMONITOR cockpit equipment monitoring service: This embodiment provides a device monitoring program as a non-crash-prone cockpit data receiver. It listens for device performance data, thermal management data, camera fault data, Ethernet fault data, sensor malfunction data, and display status anomaly data transmitted from the cross-domain QNX side via shared memory. In addition, the device monitoring program still needs to receive MCU connection fault data via SPI communication.

[0042] This embodiment provides an equipment monitoring program that monitors cockpit power management status changes in real time by registering a power management listening method. After a power management status change is detected, probe data is generated and submitted to the MPSC cache by the equipment monitoring program.

[0043] Step 4: Monitor cross-domain device data via shared memory. This embodiment provides a shared-memory cross-domain communication pipeline to monitor device performance data, camera anomaly data, thermal management data, sensor malfunction data, and display status anomaly data distributed from the cockpit instrument domain diagnostic service. Through a cross-domain communication middleware deployed in the cockpit, device monitoring data is received to the DEVICEMONITOR side. Furthermore, device monitoring probes are passed to the cockpit probe processing framework.

[0044] Step 5, Activate the rule-based log stream sniffing service: This embodiment provides a log stream sniffing program, LOGSNIFFER, which establishes real-time log streaming communication with the LOGD service SOCKET at the cockpit system's underlying layer. Furthermore, to achieve high-rate compression of the streaming log data, this embodiment employs a sliding window-based caching design and configures a fixed sniffing heartbeat cycle for batch processing of cockpit anomaly logs.

[0045] This embodiment provides a log stream sniffing program that identifies preset abnormal log sources based on rules. It calculates a similarity index for the streaming log sources using preset abnormal log key-value pairs. If the similarity index is higher than a certain preset value, it indicates that an abnormal log event occurred within the current sliding window. Furthermore, the abnormal logs are transcoded into fault probes by the sniffing program and transmitted to the cockpit probe processing framework.

[0046] Step 6, Construct a system-level probe processing framework and a high-performance cache: like Figure 4 As shown, this embodiment provides a multi-producer, single-consumer cache design. To avoid the problem of untimely processing of concurrent probes in the cockpit, a LOCK FREE configuration is adopted for multi-producer write operations. Simultaneously, a high-performance cache library temporary storage space size and time eviction policy are configured. Furthermore, a single consumer is configured to release cache probes asynchronously.

[0047] This embodiment provides an LRU cache eviction mechanism and transfers probe data to a thread-safe queue (BLOCKING QUEUE). This measure avoids blocking behavior caused by concurrent release of consumer probes.

[0048] This embodiment provides a thread-safe queue secondary cache. After the probe data flows to the thread-safe queue for queuing and processing, it is distributed to the device monitoring program after integrating the third-party tracking SDK suite. Furthermore, the device monitoring program performs real-time probe data cloud background transmission operations.

[0049] Step 7: Activate the probe to report to the cloud via the device monitoring program: This embodiment provides a device monitoring program to enable the execution of a third-party tracking SDK suite and to interface with probe data released from a thread-safe queue. Additionally, it transmits probe data to the cloud backend infrastructure under conditions of good network connectivity.

[0050] Example 3 like Figure 5 As shown, this embodiment provides an intelligent cockpit probe data processing device, including: The event capture module is used to capture multi-source events of the intelligent cockpit system; The monitoring service module is used to generate different first probe data based on different multi-source events, and cache the first probe data into the probe processing framework; The probe data processing module is used to implement a caching and pop-up strategy for the first probe data using the probe processing framework, pop up the second probe data, and distribute the second probe data to the data embedding control. The probe data transmission module is used to upload the second probe data to the cloud using the data embedding control.

[0051] This embodiment proposes an intelligent cockpit probe data processing device. By capturing multi-source events from the intelligent cockpit system, different first probe data are generated based on different multi-source events to cover more probe data categories. Then, the first probe data is cached into a probe processing framework to achieve effective integration of multi-source probe data. The probe processing framework is then used to implement a caching and pop-up strategy on the first probe data to pop up second probe data, which is then distributed to a data tracking control to achieve efficient probe data processing and prevent the loss of key probes. Finally, the data tracking control enables highly reliable cloud uploading of probe data. Ultimately, this fills the gap in the tracking link and improves the efficiency of cockpit fault diagnosis and system stability.

[0052] Example 4 like Figure 6 As shown, this embodiment also proposes a computer device, including: a processor 61, a memory 62, a communication interface 63, and a communication bus 64, wherein the processor 61, the memory 62, and the communication interface 63 communicate with each other through the communication bus 64; The processor 61, memory 62, and communication interface 63 communicate with each other via a communication bus 64. The communication interface 63 is used to communicate with other network elements, such as clients or other servers. The processor 61 executes executable instructions 65, specifically performing the operations of the described character image generation method. Specifically, the executable instructions 65 may include program code. The processor 61 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The computer device includes one or more processors, which may be of the same type, such as one or more CPUs; or they may be of different types, such as one or more CPUs and one or more ASICs.

[0053] Memory 62 is used to store executable instructions 65. Memory 62 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0054] Executable instruction 65 can be invoked by processor 61 to cause the computer device to perform the following operations: S1. Capture multi-source events from the intelligent cockpit system; S2. Generate different first probe data based on different multi-source events, and cache the first probe data in the probe processing framework; S3. Using the probe processing framework, implement a caching and pop-up strategy for the first probe data, pop up the second probe data, and distribute the second probe data to the data embedding control; S4. Use the data embedding control to upload the second probe data to the cloud.

[0055] This embodiment proposes a computer device for processing probe data in an intelligent cockpit. It captures multi-source events from the intelligent cockpit system; generates different first probe data based on these events to cover more probe data categories; caches the first probe data into a probe processing framework to effectively integrate multi-source probe data; then uses the probe processing framework to implement a caching and pop-up strategy on the first probe data, popping up second probe data and distributing it to a data tracking control to achieve efficient probe data processing and prevent the loss of critical probes; finally, the data tracking control enables highly reliable cloud upload of probe data; ultimately filling the gap in the tracking link and improving cockpit fault diagnosis efficiency and system stability.

[0056] Example 5 This embodiment proposes a computer-readable storage medium storing at least one executable instruction. When the executable instruction is executed on a computer device, it causes the computer device to perform the operation of the person image generation method, specifically including the following steps: S1. Capture multi-source events from the intelligent cockpit system; S2. Generate different first probe data based on different multi-source events, and cache the first probe data in the probe processing framework; S3. Using the probe processing framework, implement a caching and pop-up strategy for the first probe data, pop up the second probe data, and distribute the second probe data to the data embedding control; S4. Use the data embedding control to upload the second probe data to the cloud.

[0057] This embodiment proposes a computer-readable storage medium for intelligent cockpit probe data processing. It captures multi-source events from the intelligent cockpit system; generates different first probe data based on different multi-source events to cover more probe data categories; then caches the first probe data into a probe processing framework to achieve effective integration of multi-source probe data; furthermore, it uses the probe processing framework to implement a caching and pop-up strategy on the first probe data, popping up second probe data and distributing the second probe data to a data tracking control to achieve efficient probe data processing and prevent the loss of critical probes; finally, it uses the data tracking control to achieve highly reliable cloud deployment of probe data; ultimately filling the gap in the tracking link and improving cockpit fault diagnosis efficiency and system stability.

[0058] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. For those skilled in the art, other variations or modifications can be made based on the above description. It is impossible to exhaustively list all the implementation methods here. All obvious variations or modifications derived from the technical solutions of the present invention are still within the protection scope of the present invention.

Claims

1. A method for processing probe data in an intelligent cockpit, characterized in that, include: S1. Capture multi-source events from the intelligent cockpit system; S2. Generate different first probe data based on different multi-source events, and cache the first probe data in the probe processing framework; S3. Using the probe processing framework, implement a caching and pop-up strategy for the first probe data, pop up the second probe data, and distribute the second probe data to the data embedding control; S4. Use the data embedding control to upload the second probe data to the cloud.

2. The intelligent cockpit probe data processing method according to claim 1, characterized in that, The multi-source events include software events and device events; the software events include system crash events, application crash events, and application blocking events; the device events include device anomaly events, performance data acquisition events, thermal management status change events, power management status change events, memory usage change events, and log anomaly events; the first probe data includes system crash probe data, application crash probe data, application blocking probe data, device anomaly probe data, performance data acquisition probe data, thermal management status probe data, power management status probe data, memory usage probe data, and log anomaly probe data.

3. The intelligent cockpit probe data processing method according to claim 2, characterized in that, Different first probe data are generated using monitoring services, including crash monitoring services and device monitoring services. Cache of the first probe data into the probe processing framework includes: The crash monitoring service caches the system crash probe data, application anomaly probe data, and application blocking data into the probe processing framework through event triggering. The device monitoring service periodically collects the performance data acquisition probe data and caches the performance data acquisition probe data in the probe processing framework. The device monitoring service is triggered by real-time operating system status changes, and caches the thermal management status probe data into the probe processing framework. The device monitoring service is triggered by a power transition and caches the power management status probe data into the probe processing framework. The device monitoring service periodically collects the memory usage probe data. If the memory usage probe data exceeds a preset threshold, the memory usage probe data is cached in the probe processing framework. The device monitoring service caches the log anomaly probe data into the probe processing framework at a fixed heartbeat cycle.

4. The intelligent cockpit probe data processing method according to claim 2, characterized in that, Generating the log anomaly probe data includes: Establish a log stream; Continuously feed the log stream into the log sniffing program; The log stream is identified by a log sniffing program at a fixed heartbeat cycle. If the log similarity in the log stream exceeds a preset threshold, the log anomaly probe data is generated.

5. The intelligent cockpit probe data processing method according to any one of claims 1-4, characterized in that, The step of using the probe processing framework to implement a caching and pop-up strategy for the first probe data, popping up the second probe data, and distributing the second probe data to the data tracking control includes: S41. Write the first probe data into a high-performance cache library through a preset multi-producer thread; S42. Transfer the first probe data from the high-performance cache library to a thread-safe queue; S43. The second probe data is asynchronously popped from the thread-safe queue through a preset single consumer thread and distributed to the data tracking control.

6. The intelligent cockpit probe data processing method according to claim 5, characterized in that, The second probe data is standardized data that conforms to the upload format of the data embedding control.

7. The intelligent cockpit probe data processing method according to any one of claims 1-4, characterized in that, The data tracking control is a third-party tracking SDK suite.

8. A smart cockpit probe data processing device, characterized in that, include: The event capture module is used to capture multi-source events of the intelligent cockpit system; The monitoring service module is used to generate different first probe data based on different multi-source events, and cache the first probe data into the probe processing framework; The probe data processing module is used to implement a caching and pop-up strategy for the first probe data using the probe processing framework, pop up the second probe data, and distribute the second probe data to the data embedding control. The probe data transmission module is used to upload the second probe data to the cloud using the data embedding control.

9. A computer device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation of the smart cockpit probe data processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The storage medium stores at least one executable instruction, which, when executed on a computer device, causes the computer device to perform the operation of the intelligent cockpit probe data processing method as described in any one of claims 1 to 7.

Images