Device fault monitoring reporting method and device of IVI, medium and equipment

Abstract

This invention provides a method, apparatus, medium, and device for monitoring and reporting device faults in in-vehicle infotainment systems (IVIs), belonging to the field of fault diagnosis technology for in-vehicle infotainment systems. The method deploys a fault monitoring agent in kernel space, captures faults, constructs a message containing a unique fault type identifier field, queries a hash index table using the unique fault type identifier as the key to perform aggregation judgment, and stores the filtered message in a cache queue. A kernel sending thread sends the message to user space via Netlink. The kernel sending thread is initially in a sleep state and is only awakened when the cache queue is not empty. After the cache queue is cleared, the kernel sending thread returns to a sleep state. This method enables all-weather, blind-spot-free monitoring, fault aggregation, extreme real-time performance and resource balancing, resource efficiency optimization, and accurate diagnostic support.

Description

Technical Field

[0001] This invention relates to the field of fault diagnosis technology for in-vehicle infotainment systems, and in particular to a method, device, medium, and equipment for monitoring and reporting device faults in an IVI. Background Technology

[0002] With the development of intelligent connected vehicles, the integration level of IVI (In-Vehicle Infotainment) systems continues to improve, and their reliability directly affects driving safety and user experience. The monitoring and reporting of device faults in IVI is a key link to ensure its reliability.

[0003] An existing IVI device fault monitoring and reporting scheme employs a user-space polling combined with log recording. Specifically, a monitoring service is deployed in user space, polling the device status interface and kernel log file every 10 seconds. Fault information is extracted and stored locally, then synchronized to the cloud via a cellular network. Text logs are used to record fault IDs and occurrence times, without caching or filtering mechanisms. However, the polling interval results in a fault detection delay exceeding 10 seconds, failing to meet the immediacy requirements of remote diagnostics and exhibiting a lack of real-time performance. High-frequency polling consumes 5%-8% of CPU resources, and repeated fault reporting exhausts network bandwidth and cloud storage, leading to significant resource waste. Faults are completely lost within the 30-60 seconds between kernel startup and user-space service readiness, creating monitoring blind spots. Furthermore, the scheme only contains basic fault information, lacking system context, making it difficult to pinpoint the root cause and resulting in insufficient diagnostic capabilities.

[0004] Another IVI device fault monitoring and reporting scheme adopts a kernel event notification combined with a simple caching mechanism. Specifically, the device driver notifies the user-space service via a Signal mechanism (SIGUSR1 signal), and fault data is stored in shared memory. The user-space sets up a FIFO cache queue with a capacity of 20 to temporarily store messages when the network is interrupted. A custom binary format is used to store the fault ID and device number. However, its signal can only transmit notifications and relies on shared memory to transmit data, increasing system complexity and race conditions, and has communication limitations. When the queue is full, the latest message is directly discarded, which may result in the loss of high-priority faults. There is no aggregation mechanism, and high-frequency faults quickly fill the cache, resulting in caching strategy defects. No index optimization is used, and matching similar faults requires traversing the queue, with a time complexity of O(n), resulting in low aggregation efficiency. The user-space cache initialization lags behind kernel startup, making it unable to capture faults during the boot phase, resulting in the loss of boot faults. Summary of the Invention

[0005] The present invention aims to solve at least one of the technical problems existing in the prior art, and proposes a device, apparatus, medium and equipment for device fault monitoring and reporting of IVI.

[0006] In a first aspect, embodiments of the present invention provide a device fault monitoring and reporting method for an IVI (Integrated Device Component), comprising the following steps:

[0007] S100, deploys a fault monitoring agent in the kernel space, captures a fault, constructs a message containing a unique identifier field for the fault type, queries the hash index table with the unique identifier of the fault type as the key to perform aggregation judgment, and stores the message in the cache queue after filtering.

[0008] S200: The kernel sending thread sends messages to user space via Netlink. The kernel sending thread is initially in a sleeping state and is only awakened when the cache queue is not empty. After the cache queue is cleared, the kernel sending thread returns to the sleeping state.

[0009] Furthermore, in step S100, deploying the fault monitoring agent includes adding polling and interrupt response functions with set time intervals to the IVI device driver, reading the status register in real time, detecting cyclic redundancy check errors and initialization failures; and registering an event notification chain to capture kernel-level faults.

[0010] Furthermore, in step S100, the message is constructed according to the Netlink protocol specification, including a message header and a custom fault body. The extended fields of the custom fault body include a unique identifier for the fault type, severity level, kernel timestamp, occurrence count, and fault description.

[0011] Further, in step S100, querying the hash index table using the unique fault type identifier as the key to perform aggregation judgment, and storing the message in the cache queue after filtering includes: querying the hash index table using the unique fault type identifier of the message as the key; if there is a message with the same unique fault type identifier in the cache queue, updating the occurrence count and kernel timestamp fields of the message in the cache queue, and then discarding the constructed message; if there is no message with the same unique fault type identifier in the cache queue, storing the constructed message in the cache queue and updating the hash index table.

[0012] Furthermore, if there is no message with the same unique identifier of the same fault type in the cache queue, and the cache queue is not full, the constructed message is directly stored in the cache queue and the hash index table is updated; if the cache queue is full, the message discarding policy is executed first to release the cache space, and then the constructed message is stored in the cache queue and the hash index table is updated.

[0013] Furthermore, the message discarding strategy is to remove the earliest enqueued message, or discard the lowest priority message in the queue, and if the priorities are the same, remove the earliest one.

[0014] Furthermore, in step S200, the kernel sending thread is triggered by the following methods: new message enqueueing, sending retry, and power-on retransmission. New message enqueueing is triggered by waking up the sending thread immediately after the message is enqueued through preprocessing using the wake_up_process() function. Sending retry is triggered by waking up the thread synchronously after the failed message is re-enqueued. Power-on retransmission is triggered by sending a notification after the user-mode service is ready, waking up the sending thread to transmit fault messages temporarily stored during the power-on phase in batches.

[0015] Further, in step S200, after the kernel sending thread is woken up, it enters a loop processing flow, specifically as follows: The queue is locked using a spinlock, and it is determined whether the queue is empty; if the queue is not empty, the head message is retrieved, unlocked, and then the nlmsg_unicast() function is called to send it to user space; if the sending is successful, the message memory is released, and the queue is re-locked to determine if it is empty; if the sending fails, the message is reinserted into the head of the queue, the retransmission count is updated, and the queue status is re-determined; if the queue is empty, the queue is unlocked, and the schedule() function is called to put the thread into a sleep state, waiting for the next wake-up.

[0016] Further, in step S200, the kernel sending thread sends the message to user space via Netlink, including the following steps: creating a Netlink Socket, binding the NETLINK_FAULT_MSG protocol, and blocking to receive kernel messages through the recvfrom() function; parsing the message body, performing frequency filtering and fault correlation analysis in conjunction with the JSON format rule base; and encapsulating the fault information and system context into a multi-layer JSON packet and sending it to user space.

[0017] Secondly, embodiments of the present invention provide a device fault monitoring and reporting system for an IVI (Integrated Device VI), comprising:

[0018] Fault detection module, used to detect component faults in the in-vehicle infotainment system;

[0019] The message construction module is used to construct messages that include a unique identifier field for the fault type;

[0020] The message preprocessing module is used to query the hash index table using the unique identifier of the fault type as the key to perform aggregation judgment, and store the filtered messages into the cache queue.

[0021] The sending module is used to trigger the wake-up of the kernel sending thread to send messages to user space via Netlink. The kernel sending thread is initially in a sleeping state and is only triggered to wake up when the cache queue is not empty. After the cache queue is cleared, the kernel sending thread returns to the sleeping state.

[0022] Thirdly, embodiments of the present invention provide an electronic device, including:

[0023] One or more processors;

[0024] Memory, used to store one or more programs;

[0025] When the one or more programs are executed by the one or more processors, the one or more processors perform the method as described above.

[0026] Fourthly, embodiments of the present invention provide a computer-readable medium storing a computer program, which, when executed by a processor, implements the steps of the method described above.

[0027] The device fault monitoring and reporting method, system, medium, and device provided by this invention deploy a fault monitoring agent in the kernel space. After capturing a fault, a message containing a unique identifier field for the fault type is constructed. The unique identifier for the fault type is used as the key to query a hash index table to perform aggregation judgment. After filtering, the message is stored in a cache queue. The kernel sending thread sends the message to the user space through Netlink. The kernel sending thread is initially in a sleep state and is only triggered to wake up when the cache queue is not empty. After the cache queue is cleared, the kernel sending thread returns to the sleep state. It can achieve all-time, blind-spot-free monitoring, fault aggregation, extreme real-time performance and resource balance, resource efficiency optimization, and accurate diagnostic support. Attached Figure Description

[0028] Figure 1 A schematic flowchart of a device fault monitoring and reporting method for an IVI provided in an embodiment of the present invention;

[0029] Figure 2 A flowchart illustrating the overall process of a device fault monitoring and reporting method for an IVI (Integrated Device Component) provided in this embodiment of the invention;

[0030] Figure 3 This invention provides an architecture diagram of a device fault monitoring and reporting device for an IVI (Integrated Device Component).

[0031] Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0032] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0033] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0034] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0035] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0036] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0037] This invention provides a device fault monitoring and reporting method for IVI (Integrated Device Components), see reference. Figure 1 As shown, the method includes the following steps:

[0038] S100 deploys a fault monitoring agent in the kernel space. After capturing a fault, it constructs a message containing a unique identifier field for the fault type. It then queries the hash index table using the unique identifier of the fault type as the key to perform aggregation judgment, and stores the filtered message in the cache queue.

[0039] In one embodiment, deploying a fault monitoring agent includes adding polling and interrupt response functions at set time intervals to the IVI's device driver, reading the status register in real time, detecting CRC (Cyclic Redundancy Check) errors and initialization failures, and registering an event notification chain to capture kernel-level faults.

[0040] Specifically, fault monitoring includes hardware monitoring and kernel listening. Hardware monitoring includes adding 1ms interval polling and interrupt response functions to the drivers of key devices such as eMMC, GPU, camera, display, and sensor to read the status register in real time and detect faults such as CRC errors and initialization failures. Kernel listening includes registering an event notification chain to capture kernel-level faults such as memory errors and bus anomalies.

[0041] In one embodiment, the message is constructed according to the Netlink protocol specification and includes a message header and a custom fault body. The extended fields of the custom fault body include a unique identifier for the fault type (fault_id), a severity level, a kernel timestamp, an occurrence count, and a fault description.

[0042] Specifically, the message header `struct nlmsghdr` defines the length, type, sequence number, and port ID to ensure ordered transmission. The fault body (`struct fault_kernel_msg`) has the following extended fields:

[0043] struct fault_kernel_msg {

[0044] __u32 fault_id; / / Unique identifier for fault type

[0045] __u8 severity; / / Severity level (ERROR / WARNING / INFO)

[0046] __u64 timestamp; / / Kernel timestamp

[0047] __u32 occur_count; / / Number of occurrences

[0048] char description

[256] ; / / Fault description

[0049] };

[0050] In one embodiment, see Figure 2As shown, querying the hash index table using the unique fault type identifier as the key to perform aggregation judgment, and storing the message in the cache queue after filtering includes: querying the hash index table using the unique fault type identifier of the message as the key; if there is a message with the same unique fault type identifier in the cache queue, update the occurrence count and kernel timestamp fields of the message in the cache queue, and discard the constructed message; if there is no message with the same unique fault type identifier in the cache queue, store the constructed message in the cache queue and update the hash index table.

[0051] The hash index table uses a hash structure with fault_id as the unique key to map the storage location of fault messages in the cache queue, achieving O(1) lookup efficiency. Fault messages with the same fault_id are merged by updating the occurrence count, last timestamp, and associated device list through message aggregation, avoiding duplicate storage and reporting.

[0052] In the preferred embodiment, see Figure 2 As shown, if there is no message with the same unique identifier of the same fault type in the cache queue, and the cache queue is not full, the constructed message is directly stored in the cache queue and the hash index table is updated; if the cache queue is full, the message discarding policy is executed first to release the cache space, and then the constructed message is stored in the cache queue and the hash index table is updated.

[0053] In one embodiment, the message discarding strategy is to remove the earliest enqueued message, or discard the lowest priority message in the queue, or remove the earliest message if they are of the same priority.

[0054] Specifically, the aggregation judgment includes: querying the hash index table with the new message fault_id as the key, and completing the matching in O(1) time level; if the match is successful, updating the occurrence_count (+1) and timestamp (current time) of the corresponding message in the queue, and appending the device ID (device_id) of the new message to the device list (device_list) for deduplication, and discarding the new message; if the match fails: it is determined to be a new fault, and the discarding policy process is entered. When the queue is full (default 100 messages), the discarding policy of either discarding the oldest or prioritizing the message is executed. Discarding the oldest means removing the earliest message that was enqueued to free up space; prioritizing the message means discarding the lowest priority message in the queue, and if the priorities are the same, the earliest one is removed. Operation record: synchronously update the "overflow count" for operation and maintenance analysis.

[0055] Specifically, the cache queue management method is as follows: Queue structure: A doubly linked list queue, combined with a hash index table to achieve a hybrid architecture of "fast lookup + flexible storage". Index design: The hash table uses fault_id as the key and message node pointers as values. During aggregation, the target is directly located without traversing the queue. Synchronization mechanism: Read and write operations on the queue and index table are protected by a spinlock (spinlock_t) to avoid race conditions. Boot cache: The queue is initialized immediately after kernel startup to temporarily store faults before user-mode readiness; batch retransmission is triggered upon receiving a readiness notification.

[0056] S200: The kernel sending thread sends messages to user space via Netlink. The kernel sending thread is initially in a sleeping state and is only awakened when the cache queue is not empty. After the cache queue is cleared, the kernel sending thread returns to the sleeping state.

[0057] Specifically, the kernel sending thread is independent of the fault-catching kernel thread and is dedicated to dequeuing messages from the buffer queue and transmitting them via Netlink, ensuring real-time communication. Thread state management: The sending thread is created when the kernel module is loaded, initially in a sleeping state, not consuming CPU resources; it is only awakened and enters the running state when the buffer queue is not empty.

[0058] In one embodiment, the kernel sending thread is triggered by three methods: new message enqueueing, sending retry, and boot retransmission. New message enqueueing triggers the sending thread to be woken up immediately by the wake_up_process() function after the message is preprocessed and enqueued, ensuring that new fault messages are transmitted quickly. Sending retry triggers the thread to be woken up synchronously after the failed message is re-enqueued, avoiding message delays. Boot retransmission triggers a notification sent after the user-mode service is ready, waking up the sending thread to transmit fault messages temporarily stored during the boot phase in batches.

[0059] In one embodiment, after the kernel sending thread is woken up, it enters a loop processing flow as follows: The queue is locked using a spinlock, and it is checked whether the queue is empty; if the queue is not empty, the head message is retrieved, unlocked, and then the `nlmsg_unicast()` function is called to send it to user space; if the sending is successful, the message memory is released, and the queue is re-locked to check if it is empty; if the sending fails, the message is reinserted into the head of the queue, the retransmission count is updated, and the queue status is re-checked; if the queue is empty, the queue is unlocked, and the `schedule()` function is called to put the thread into a sleep state, waiting for the next wake-up.

[0060] In this embodiment, thread safety of queue operations is achieved through spinlocks to avoid race conditions with the enqueue operation of the preprocessing module; the re-enqueue mechanism ensures that messages that fail to be sent are not lost.

[0061] In one embodiment, the kernel sending thread sends messages to user space via Netlink, including the following steps: creating a Netlink Socket, binding the NETLINK_FAULT_MSG protocol, and blocking the reception of kernel messages through the recvfrom() function; parsing the message body, performing frequency filtering and fault correlation analysis in conjunction with a JSON format rule base; and encapsulating the fault information and system context into a multi-layered JSON packet and sending it to user space.

[0062] Specifically, the user space fault management daemon process is as follows:

[0063] 1. Netlink Listener Thread: Creates a Netlink Socket, binds it to the NETLINK_FAULT_MSG protocol, and receives kernel messages in a blocking manner using recvfrom().

[0064] 2. Message parsing and diagnosis: Parse the message body, combine it with the JSON format rule base to perform frequency filtering (set a silent period to suppress invalid alarms) and fault correlation analysis.

[0065] 3. Standardized Encapsulation: Encapsulate fault information and system context (CPU utilization, memory status, etc.) into a four-layer JSON package, as shown in the example below:

[0066] {

[0067] "metadata": {"vin": "LFVXXXXXXXXXXXXXXX", "timestamp":1718888888},

[0068] "device_info": {"ivi_version": "V2.5.0", "soc_model": "SM8250"},

[0069] "fault_body": {

[0070] "fault_id": 0x0001,

[0071] "severity": "ERROR",

[0072] "occur_count": 5,

[0073] "description": "Storage device initialization failed"

[0074] },

[0075] "context_info": {"cpu_usage": "35%", "mem_usage": "42%"}

[0076] }

[0077] This invention deploys a fault monitoring agent in kernel space. After capturing a fault, it constructs a message containing a unique fault type identifier field. Using the unique fault type identifier as the key, it queries a hash index table to perform aggregation and judgment. After filtering, the message is stored in a cache queue. A kernel sending thread sends the message to user space via Netlink. The kernel sending thread is initially in a sleep state and is only awakened when the cache queue is not empty. After the cache queue is cleared, the kernel sending thread returns to a sleep state. This enables: 24 / 7 monitoring without blind spots: kernel cache coverage during boot, achieving 100% fault capture coverage and completely solving the blind spot problem of existing technologies; fault aggregation: when there are high-frequency faults... When reporting frequent faults, faults can be aggregated by fault_id to prevent frequent faults from affecting the reporting of other faults; extreme real-time performance and resource balance: the sending thread is woken up when the queue is not empty, and the message transmission latency is controlled within 1ms, which is 2000 times better than the polling mode; the thread sleep mechanism avoids invalid wake-ups, and the kernel CPU usage is reduced by 10%-15% compared with the timed wake-up mode; resource efficiency optimization: the hash index improves the aggregation judgment efficiency by 10 times, reduces invalid reports by 95% for faults with the same fault_id, and improves cache utilization by 60%; accurate diagnostic support: the standardized data packet contains the complete context, and the fault location time is shortened from 24 hours to less than 2 hours.

[0078] This invention also provides a device fault monitoring and reporting device for IVI, see reference. Figure 3 As shown, the system includes:

[0079] Fault capture module 11 is used to capture device faults in the in-vehicle infotainment system;

[0080] Message construction module 12 is used to construct a message containing a unique identifier field for the fault type;

[0081] The message preprocessing module 13 is used to query the hash index table with the fault type unique identifier as the key to perform aggregation judgment, and store the message in the cache queue after filtering.

[0082] The sending module 14 is used to trigger the wake-up of the kernel sending thread to send messages to user space via Netlink. The kernel sending thread is initially in a sleeping state and is only triggered to wake up when the cache queue is not empty. After the cache queue is cleared, the kernel sending thread returns to the sleeping state.

[0083] This invention also provides an electronic device, see below. Figure 4As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement a device fault monitoring and reporting method as described in any of the above embodiments of the IVI; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0084] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0085] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0086] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0087] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps in the device fault monitoring and reporting method of any of the IVIs described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0088] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0089] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0090] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0091] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0092] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0093] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0094] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0095] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0096] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0097] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A device fault monitoring and reporting method for an IVI (Integrated Device Component), characterized in that, Includes the following steps: S100, deploys a fault monitoring agent in the kernel space, captures a fault, constructs a message containing a unique identifier field for the fault type, queries the hash index table with the unique identifier of the fault type as the key to perform aggregation judgment, and stores the message in the cache queue after filtering. S200: The kernel sending thread sends messages to user space via Netlink. The kernel sending thread is initially in a sleeping state and is only awakened when the cache queue is not empty. After the cache queue is cleared, the kernel sending thread returns to the sleeping state.

2. The method according to claim 1, characterized in that, In step S100, deploying the fault monitoring agent includes adding polling and interrupt response functions with set time intervals to the IVI device driver, reading the status register in real time, detecting cyclic redundancy check errors and initialization failures; and registering an event notification chain to capture kernel-level faults.

3. The method according to claim 1, characterized in that, In step S100, the message is constructed according to the Netlink protocol specification, including a message header and a custom fault body. The extended fields of the custom fault body include a unique identifier for the fault type, severity level, kernel timestamp, occurrence count, and fault description.

4. The method according to claim 3, characterized in that, In step S100, querying the hash index table using the unique fault type identifier as the key to perform aggregation judgment, and storing the message in the cache queue after filtering includes: querying the hash index table using the unique fault type identifier of the message as the key; if there is a message with the same unique fault type identifier in the cache queue, updating the occurrence count and kernel timestamp fields of the message in the cache queue, and then discarding the constructed message; if there is no message with the same unique fault type identifier in the cache queue, storing the constructed message in the cache queue and updating the hash index table.

5. The method according to claim 4, characterized in that, If there is no message with the same unique identifier of the same fault type in the cache queue, and the cache queue is not full, the constructed message is directly stored in the cache queue and the hash index table is updated; if the cache queue is full, the message discarding policy is executed first to release the cache space, and then the constructed message is stored in the cache queue and the hash index table is updated.

6. The method according to claim 5, characterized in that, The message discarding strategy is to remove the earliest enqueued message, or discard the lowest priority message in the queue; if messages are of the same priority, the earliest one is removed.

7. The method according to claim 1, characterized in that, In step S200, the kernel sending thread is triggered by the following methods: new message enqueueing, sending retry, and power-on retransmission. New message enqueueing triggers the sending thread to be woken up immediately by the wake_up_process() function after the message is preprocessed and enqueued. Sending retry triggers the thread to be woken up synchronously after the failed message is re-enqueued. Power-on retransmission triggers a notification to be sent after the user-mode service is ready, which wakes up the sending thread to transmit the fault messages temporarily stored during the power-on phase in batches.

8. The method according to claim 1, characterized in that, In step S200, after the kernel sending thread is woken up, it enters the loop processing flow, which is as follows: the queue is locked by a spinlock, and it is determined whether the queue is empty; if the queue is not empty, the head message is retrieved, and after unlocking, the nlmsg_unicast() function is called to send it to user space; If the message is successfully sent, the message memory is released, and the queue is relocked to check if it is empty. If the message fails to be sent, the message is reinserted at the head of the queue, the retransmission count is updated, and the queue status is rechecked. If the queue is empty, the queue is unlocked, and the schedule() function is called to put the thread into a sleep state, waiting for the next wake-up.

9. The method according to claim 1, characterized in that, In step S200, the kernel sending thread sends a message to user space via Netlink, including the following steps: creating a Netlink Socket, binding the NETLINK_FAULT_MSG protocol, and blocking the reception of kernel messages through the recvfrom() function; parsing the message body, performing frequency filtering and fault correlation analysis in conjunction with the JSON format rule base; and encapsulating the fault information and system context into a multi-layer JSON packet and sending it to user space.

10. A device fault monitoring and reporting device for an IVI (In-Vehicle Component) system, characterized in that, include: Fault detection module, used to detect component faults in the in-vehicle infotainment system; The message construction module is used to construct messages that include a unique identifier field for the fault type; The message preprocessing module is used to query the hash index table using the unique identifier of the fault type as the key to perform aggregation judgment, and store the filtered messages into the cache queue. The sending module is used to trigger the wake-up of the kernel sending thread to send messages to user space via Netlink. The kernel sending thread is initially in a sleeping state and is only triggered to wake up when the cache queue is not empty. After the cache queue is cleared, the kernel sending thread returns to the sleeping state.

11. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 9.

12. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 9.

Images