A fault diagnosis method and system for an on-vehicle handrail screen peripheral device

Abstract

This invention discloses a method and system for diagnosing peripheral faults in vehicle armrest screens: S1. The upper-layer active polling channel obtains the first fault detection result; the driving event channel obtains the second fault detection result; S2. Each peripheral maintains a status word, with each bit corresponding to a type of fault cause; when the fault state changes, a complete status word containing all identified fault bits is submitted; S3. The peripheral information and the complete status word are updated to the shared file node shared by the kernel and user space, generating a versioned status snapshot; S4. The user space daemon reads the status snapshot and verifies version consistency; combining the current fault bitmap and historical latched states, it is determined whether there is no fault, a current fault, or a historical fault; S5. Based on the determination result, a vehicle diagnostic link fault code is generated, retaining internal fine-grained fault information, and outputting a fault code compatible with the vehicle diagnostic protocol. Through the above mechanism, reliable fault capture, consistent status, and fault output compatible with the vehicle diagnostic protocol are achieved.

Description

Technical Field

[0001] This invention belongs to the fields of vehicle electronics, smart cockpit, embedded operating system and fault diagnosis technology, and specifically relates to a method and system for diagnosing faults in vehicle armrest screen peripherals. Background Technology

[0002] The in-vehicle armrest screen integrates various peripherals such as display, touch, audio, motor, sensors, and charging, each managed by a kernel driver. There are many possible causes for armrest screen peripheral failures, including bus communication failures, chip identifier read failures, register alarms, interrupt exceptions, missing timing signals, power supply abnormalities, and physical link abnormalities.

[0003] One existing approach to fault diagnosis involves upper-layer software polling driver nodes or registers one by one to obtain fault information. This approach increases bus access and system wake-up overhead and is prone to missing short-duration hardware alarms that occur before reset or power failure, resulting in the loss of transient fault information. Another approach involves the peripheral driver reporting only a single changed bit or Boolean value when a fault is detected. In application scenarios with multiple concurrent faults, fault recovery, or multiple instance devices, this can easily lead to fault state overwriting, making it impossible to completely record fault information.

[0004] In addition, vehicle diagnostic interfaces typically only output fixed diagnostic fault codes (DTCs) and their current / historical status, while the kernel layer needs to store the specific fault causes corresponding to the devices. If all fine-grained fault causes are directly exposed, it will increase the cost of DTC allocation and protocol maintenance. If only Boolean values ​​are output, it will be detrimental to fault location work in R&D, testing, and after-sales.

[0005] Therefore, a diagnostic mechanism is needed that can simultaneously achieve transient fault capture, fault state integrity, cross-layer data consistency, and historical fault traceability. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of the prior art. This invention provides a method and system for diagnosing faults in vehicle armrest screen peripherals. By using a driving event channel and an upper-layer active polling channel to achieve dual-channel acquisition, complete status word reporting, and a version snapshot mechanism, it enables reliable fault capture, consistent status, and fault output compatible with vehicle diagnostic protocols.

[0007] The technical solution of the present invention: a method for diagnosing faults in vehicle armrest screen peripherals, comprising the following steps: S1. Dual-channel fault result acquisition: The first fault detection result obtained by the upper-layer software from the driver node, chip register, or hardware abstraction layer is obtained through the upper-layer active polling channel; the second fault detection result reported in real time by the peripheral driver in scenarios such as chip identification, hardware interrupt request processing, interrupt / external interrupt cycle detection, register status reading, and bus communication failure is obtained through the driver event channel; the two channels of the same peripheral use the same fault bit definition; S2. Generate a complete status word: Maintain a status word for each peripheral device. The status word is an integer bit mask, and each bit of the status word corresponds to a type of fault cause. When the fault status changes, submit a complete status word including all the determined fault bits. S3. Generate cross-layer consistent snapshot: Update peripheral information and complete status words to the shared file node shared by kernel space and user space, and generate a status snapshot with version information; S4. Three-state transition determination: The user space daemon reads the state snapshot of the shared file node and verifies the consistency of the snapshot version; combined with the current fault bitmap and historical latch state, it determines and outputs three states: no fault, current fault, and historical fault. S5. Fault Code Output and Historical Latch Management: Based on the three-state judgment results, generate fault code records for the vehicle diagnostic link, retain fine-grained fault information internally, and output fault codes compatible with the vehicle diagnostic protocol externally; clear the historical latch only when there is no current fault and an authorized clear command after successful identity authentication is received.

[0008] Preferably, step S2 further includes: for chips with multi-level identification rollback paths having firmware identity identifiers and boot identity identifiers, waiting for all valid rollback paths to be executed, and setting or clearing identification and communication fault bits based on the final chip identification result to avoid false alarms caused by intermediate identification failures.

[0009] Preferably, step S2 further includes: when an overvoltage, undervoltage, overcurrent, or overtemperature hardware event is detected, the corresponding fault mask is bitwise ORed into the existing status word, and the updated complete status word is submitted.

[0010] Preferably, step S2 further includes: for the read-clear register, reading the register fault information before the peripheral device is reset, shut down, or powered off, and latching it into the software status word before the hardware clears the register contents.

[0011] Preferably, the status snapshot includes at least the peripheral type, complete status word, validity, acquisition source, monotonically increasing sequence number, and timestamp; the snapshot update is completed using at least one of the following methods: lock, sequence lock, read copy update, and double buffering. In step S4, verifying the consistency of the snapshot version specifically involves the daemon process checking the monotonically increasing sequence number before and after reading the snapshot. If the sequence number is inconsistent, the snapshot is read again.

[0012] Preferably, in step S4, the three-state transition determination is as follows: if the current fault bitmap is non-zero, it is determined to be a current fault and the historical latch is set; if the current fault bitmap is zero and the historical latch is valid, it is determined to be a historical fault; if both the current fault bitmap and the historical latch are invalid, it is determined to be no fault. The daemon process supports both pre-set periodic polling to read snapshots and event notification wake-up via polling, event polling, kernel event notification, or wait queue.

[0013] Preferably, the authorized clear command is triggered by authentication through at least one of the following methods: local clearing via physical key combination; diagnostic tool sending UDS protocol 0x14 clear diagnostic information service request; triggering by inputting operation code in the vehicle system engineer menu; generating a read-only and non-clearable clearing operation log when the clear command is executed, the log at least records the clearing time, clearing source, and state bitmap before clearing.

[0014] Preferably, the fault code record includes a fixed three-byte fault code and a one-byte status field; the status field 0x00 indicates no fault, 0x09 indicates the current fault, and 0x08 indicates a historical fault; internally, a fine-grained fault bitmap and timestamp are retained for fault location.

[0015] Preferably, it also includes an independently maintained historical fault storage area, which is independent of the current status word. The storage fields include device type, historical fault bitmap, first occurrence timestamp, last occurrence timestamp, occurrence count, and recovery timestamp. Each peripheral type retains a maximum of H recent historical records, and for consecutive occurrences of the same fault bit, only the latest record is retained within the recovery cycle. A total storage space limit is set; once exceeded, records are discarded according to a FIFO (First-In, First-Out) strategy prioritizing records with the earliest last occurrence timestamp. Historical records can be configured to be permanently retained or automatically expire after 90 days. The technical solution of the present invention: a vehicle armrest screen peripheral fault diagnosis system, including a peripheral driver fault detection module, a kernel fault aggregation module, a shared file node, a user space daemon process, a historical fault storage module, and a diagnostic code adaptation module; The peripheral driver fault detection module is used to obtain a first fault detection result through the upper-layer active polling channel and a second fault detection result through the driver event channel, and output the two fault detection results to the kernel fault aggregation module. The upper-layer active polling channel and the driver event channel corresponding to the same peripheral device adopt the same fault bit definition. The kernel fault aggregation module is used to receive two fault detection results, generate a complete status word containing all the determined fault bits when the fault status changes, and write the complete status word to a shared file node to generate a status snapshot carrying a monotonically increasing sequence number. The shared file node is shared by the kernel space and user space and is used to store the state snapshot; The user space daemon process is used to read the state snapshot and verify the monotonically increasing sequence number. If the sequence number is inconsistent, the snapshot is read again. It combines the current fault bitmap and the historical latch status to determine three states: no fault, current fault, and historical fault. The historical latch is cleared only when there is no current fault and an authorized clear command is received after successful identity authentication. The user space daemon process also interacts with the historical fault storage module and the diagnostic code adaptation module respectively. The historical fault storage module is used to store historical fault records; The diagnostic code adaptation module is used to output fault codes that are adapted to the vehicle diagnostic link based on the judgment result of the daemon process. The armrest screen peripherals include at least one of the following: display screen, backlight or screen power supply, touch panel, audio amplifier, vibration motor, gyroscope, ambient light sensor, charging chip, battery, and charging dock interface.

[0016] The vehicle armrest screen peripheral fault diagnosis method and system of the present invention have the following beneficial technical effects: (1) A dual-channel fault acquisition mechanism is adopted, which combines the upper-layer active polling channel and the driver event channel. The two channels use a unified fault bit definition for the same peripheral device, and the two acquisition methods complement each other. It can capture transient faults, read-and-clear register faults, and hardware alarms that disappear before reset or power failure by relying on the driver event channel, thereby reducing the failure to report faults. At the same time, it can realize the recovery detection of fault status by relying on the upper-layer active polling channel, while reducing the bus access and wake-up overhead of the system's regular polling, and improving the overall capture capability of various abnormal faults.

[0017] (2) When the peripheral fault status changes, a complete status word including all identified fault bits is submitted, instead of only reporting the fault bits that have changed this time. For hardware overvoltage, undervoltage, overcurrent, and overtemperature events, a bitwise OR method is used to accumulate fault masks, which can effectively suppress the fault status coverage problem in scenarios with multiple concurrent faults, fault recovery, and multiple instance peripherals, and ensure the integrity of fault status information. For multi-level chip identification backtracking paths, fault bits are set or cleared based on the final identification result after all paths are executed, avoiding false fault alarms caused by intermediate reading failures but subsequent successful identification; for read-clear registers, fault information can be latched into the software status word before the hardware clears the register contents, preserving easily lost fault evidence.

[0018] (3) The kernel generates a shared state snapshot carrying version information such as peripheral information, complete status word, monotonically increasing sequence number, and timestamp. The snapshot is updated using locks, sequence locks, read-copy updates, or double buffering mechanisms. When the user space daemon reads the snapshot, it verifies the sequence number. If the version is inconsistent, the snapshot is read again. This enables the kernel space and user space to obtain the same version of the complete fault state, avoiding the reading of incomplete data that is only partially updated, and ensuring the consistency of fault data across layers. The daemon can obtain the status through periodic polling, or it can be woken up by event notification through polling, event polling, kernel event notification, or waiting queue, flexibly adapting to different read triggering methods.

[0019] (4) Three-state migration control of no fault, current fault, and historical fault is achieved through the current fault bitmap and historical latches. Historical latches are not automatically cleared after fault recovery. They are only allowed to be cleared when there is no current fault and an authorized clearing command is received after authentication. The clearing operation generates a read-only and non-deletable operation log, which records the clearing time, clearing source, and the state bitmap before clearing, ensuring that the clearing behavior is traceable throughout. At the same time, a historical fault storage area is maintained independently, and the number of historical fault records and the total storage space are limited. When the storage capacity is exceeded, FIFO is performed according to the earliest and last occurrence timestamp. A historical record retention mode can also be configured to avoid the infinite expansion of the number of logs.

[0020] (5) A two-level output mechanism of internal fine-grained fault information and external fixed fault codes is adopted. The internal fine-grained fault bitmap, timestamp and other original fault information are fully retained, which is convenient for R&D, testing and after-sales fault location; the external output is a fixed fault code compatible with the vehicle diagnostic protocol, which does not require a large number of new DTCs to be allocated, reducing the cost of DTC allocation and protocol maintenance and modification, and taking into account the fault location requirements and the compatibility of the vehicle's existing diagnostic interface.

[0021] The diagnostic framework of this invention is a unified and universal architecture that can be adapted to various peripherals such as the display screen, touch panel, audio, motor, sensor, and charging of the armrest screen. It can be flexibly configured and enabled according to project needs and has good scalability. Attached Figure Description

[0022] Figure 1 This is an architecture diagram of a handrail screen peripheral device fault diagnosis system according to a specific embodiment of the present invention. The diagram shows the drivers of peripheral devices such as display, touch, audio, motor, sensor and charging. The upper path represents the upper layer active polling, and the lower path represents the driver event reporting. Figure 2 This is a flowchart illustrating the dual-channel acquisition, state aggregation, and three-state output of a specific embodiment of the present invention. Detailed Implementation

[0023] The technical solutions in this embodiment will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] like Figure 1 , 2 As shown, the present invention provides a method for diagnosing faults in vehicle armrest screen peripherals. The vehicle armrest screen peripherals include at least one of the following: display screen, backlight or screen power supply, touch panel, audio amplifier, vibration motor, gyroscope, ambient light sensor, charging chip, battery, and charging dock interface. Each type of armrest screen peripheral is managed by a kernel driver. Fault sources include bus communication failure, chip identifier reading failure, register alarm, interrupt, missing timing signal, power supply abnormality, or physical link abnormality.

[0025] The fault diagnosis method in this embodiment includes the following steps: S1, Dual-channel acquisition of fault results The system obtains the first fault detection result from the upper-layer software reading the driver node, chip registers, or hardware abstraction layer through the upper-layer active polling channel; and obtains the second fault detection result reported in real time by the peripheral driver in scenarios such as chip identification (probe), hardware interrupt request (IRQ) processing, interrupt / external interrupt (TE / EINT) cycle detection, register status reading, and bus communication failure through the driver event channel. The two channels of the same peripheral use the same fault bit definition.

[0026] The upper-layer active polling channel is triggered by a daemon process or diagnostic service according to a preset cycle or diagnostic request for reading operations; the driver event channel, when the driver executes probe, IRQ processing, TE / EINT periodic checks, register status readings, and communication failure detection, immediately updates the status word and calls the unified fault reporting interface once a hardware anomaly is detected. The fault results collected by the dual channels are sent to the kernel fault aggregation module, which merges the fault results according to source priority, timestamp, and validity period.

[0027] S2. Generate complete status word Maintain a status word for each peripheral device. The status word is an integer bitmask (e.g., a 32-bit unsigned integer). Each bit of the status word corresponds to a type of fault cause. When the fault status changes, submit a complete status word that includes all identified fault bits, rather than just the fault bits that have changed in this case.

[0028] For chips with multi-level identification rollback paths that have firmware identity identifiers (firmware ID) and boot identity identifiers (boot ID), after all valid rollback paths have been executed, the identification and communication fault bits are set or cleared based on the final chip identification result to avoid false alarms caused by intermediate identification path reading failures and subsequent identification path identification successes.

[0029] When overvoltage, undervoltage, overcurrent, or overtemperature hardware events are detected, the corresponding fault mask is bitwise ORed into the existing status word, and the updated complete status word is submitted.

[0030] For read-clear registers, register fault information is read before peripherals are reset, shut down, or powered off, and latched into a software status word before the hardware clears the register contents, thus converting the momentarily disappearing hardware alarm into a fault state that can be retained at the software level.

[0031] For the fault status obtained from periodic detection, perform set debouncing and clear debouncing processing.

[0032] S3. Generate a cross-layer consistent snapshot. Update peripheral information and complete status words to the shared file node shared by kernel space and user space, and generate a status snapshot with version information.

[0033] The state snapshot includes at least the peripheral type, complete state word, validity, acquisition source, monotonically increasing sequence number, and timestamp; the atomic update of the snapshot is completed using at least one of the following methods: lock, sequence lock, read copy update, and double buffering, to avoid intermediate states with partial updates.

[0034] S4, Tri-state transition determination The user space daemon reads the state snapshot of the shared file node and verifies the snapshot version consistency: the daemon checks the monotonically increasing sequence number before and after reading the snapshot. If the sequence number is inconsistent, it means that half-updated data has been read, so the snapshot is read again.

[0035] The daemon process supports both pre-set periodic polling for snapshot reading and event notification wake-up via polling, event polling (epoll), kernel event notification (uevent), or waiting queue. In other words, when the kernel-side fault state changes, the daemon process can be actively woken up to perform reading, without having to rely entirely on periodic polling.

[0036] The daemon process combines the current fault bitmap and historical latch states to determine three output states: no fault, current fault, and historical fault. If the current fault bitmap is non-zero, it is determined to be a current fault and the historical latch is set. If the current fault bitmap is zero and the historical latch is valid, it is determined to be a historical fault; If both the current fault bitmap and the historical latch are invalid, it is determined that there is no fault.

[0037] S5, Fault Code Output and Historical Latch Management The fault code record of the vehicle diagnostic link is generated based on the three-state determination result. It retains fine-grained fault information internally and outputs fault codes compatible with the vehicle diagnostic protocol externally. The historical latch is cleared only when there is no current fault and an authorized clear command is received after successful identity authentication.

[0038] The fault code record includes a fixed three-byte fault code and a one-byte status field; in this embodiment, the fixed three-byte fault code is 0xAE7008; the status field 0x00 indicates no fault, 0x09 indicates the current fault, and 0x08 indicates a historical fault; the system internally retains a fine-grained fault bitmap and timestamp for R&D, testing, and after-sales fault location.

[0039] Authorized clearing commands require authentication and can be triggered by at least one of the following methods: local clearing via physical key combination; OBD diagnostic tool sending a UDS protocol 0x14 clear diagnostic information service request; or vehicle system engineer entering an operation code in the menu. When a clearing command is executed, a read-only, non-deletable clearing operation log is generated. The log records at least the clearing time, clearing source, and a bitmap of the state before clearing. The clearing log cannot be deleted, ensuring full traceability of the clearing process.

[0040] This method also maintains a separate historical fault storage area, which is independent of the current status word. The stored fields include device type, historical fault bitmap, first occurrence timestamp, last occurrence timestamp, occurrence count, and recovery timestamp.

[0041] Each peripheral type retains a maximum of H recent historical records. In this embodiment, H is set to 10. During the continuous occurrence and recovery cycle of the same fault position, only the latest record is retained to avoid log flooding. The total storage space is set to a maximum of 512KB. After the storage space is exceeded, old records are eliminated according to the FIFO strategy of "earliest last occurrence timestamp".

[0042] The historical fault storage area supports configurable fault record retention policies, which include permanent retention until authorized deletion, or automatic expiration and deletion after a preset duration of 90 days.

[0043] This embodiment also discloses a vehicle armrest screen peripheral fault diagnosis system, used to implement the above-mentioned vehicle armrest screen peripheral fault diagnosis method.

[0044] The system includes a peripheral driver fault detection module, a kernel fault aggregation module, a shared file node, a user space daemon process, a historical fault storage module, and a diagnostic code adaptation module.

[0045] The peripheral driver fault detection module is used to output the first fault detection result obtained from the upper-layer active polling channel and the second fault detection result obtained from the driver event channel to the kernel fault aggregation module; The kernel fault aggregation module is used to generate a complete status word, and writes peripheral information and the complete status word into the shared file node to generate a status snapshot with version information; The user space daemon process is used to read the state snapshot in the shared file node, verify version consistency, and complete the three-state transition determination by combining the current fault bitmap with the historical latch state; the user space daemon process interacts with the historical fault storage module and the diagnostic code adaptation module respectively. The diagnostic code adapter module is used to output fault codes that are compatible with the vehicle diagnostic protocol.

[0046] This invention can be applied to peripheral fault diagnosis scenarios of in-vehicle armrest screens. It is suitable for smart cockpit armrest screen devices equipped with displays, touch screens, audio, motors, various sensors, and charging peripherals, and can realize peripheral fault collection, status consistency processing, fault judgment, and fault output compatible with in-vehicle diagnostic protocols.

Claims

1. A method for diagnosing faults in a vehicle-mounted armrest screen peripheral, characterized in that, Includes the following steps: S1. Dual-channel fault result acquisition: The first fault detection result is obtained by the upper-layer software reading the driver node, chip register, or hardware abstraction layer through the upper-layer active polling channel; the second fault detection result is obtained by the peripheral driver in real time in scenarios such as chip identification, hardware interrupt request processing, interrupt / external interrupt cycle detection, register status reading, or bus communication failure through the driver event channel; the two channels of the same peripheral use the same fault bit definition. S2. Generate a complete status word: Maintain a status word for each peripheral device. The status word is an integer bit mask, and each bit of the status word corresponds to a type of fault cause. When the fault status changes, submit a complete status word including all identified fault bits. S3. Generate cross-layer consistent snapshot: Update peripheral information and complete status words to the shared file node shared by kernel space and user space, and generate a status snapshot with version information; S4. Three-state transition determination: The user space daemon reads the state snapshot of the shared file node and verifies the consistency of the snapshot version; combined with the current fault bitmap and historical latch state, it determines and outputs three states: no fault, current fault, and historical fault. S5. Fault Code Output and Historical Latch Management: Based on the three-state judgment results, generate fault code records for the vehicle diagnostic link, retain fine-grained fault information internally, and output fault codes compatible with the vehicle diagnostic protocol externally; clear the historical latch only when there is no current fault and an authorized clear command after successful identity authentication is received.

2. The method for diagnosing peripheral faults of a vehicle armrest screen according to claim 1, characterized in that, Step S2 also includes: for chips with multi-level identification paths that have firmware identity identifiers and boot identity identifiers, wait for all valid rollback paths to be completed, and set or clear identification and communication fault bits according to the final chip identification result to avoid false alarms caused by intermediate identification failures.

3. The method for diagnosing peripheral faults of a vehicle armrest screen according to claim 1, characterized in that, Step S2 also includes: when an overvoltage, undervoltage, overcurrent, or overtemperature hardware event is detected, the corresponding fault mask is bitwise ORed into the existing status word, and the updated complete status word is submitted.

4. The method for diagnosing peripheral faults of a vehicle armrest screen according to claim 1, characterized in that, Step S2 also includes: for the read-clear register, reading the register fault information before the peripheral device is reset, shut down, or powered off, and latching it into the software status word before the hardware clears the register contents.

5. The method for diagnosing peripheral faults of a vehicle armrest screen according to claim 1, characterized in that, The status snapshot includes at least the peripheral type, complete status word, validity, acquisition source, monotonically increasing sequence number, and timestamp; the snapshot update is completed using at least one of the following methods: lock, sequence lock, read copy update, and double buffering. In step S4, verifying the consistency of the snapshot version specifically involves the daemon process checking the monotonically increasing sequence number before and after reading the snapshot. If the sequence number is inconsistent, the snapshot is read again.

6. The method for diagnosing peripheral faults of a vehicle armrest screen according to claim 1, characterized in that, In step S4, the three-state transition determination is as follows: if the current fault bitmap is non-zero, it is determined to be a current fault and the historical latch is set; if the current fault bitmap is zero and the historical latch is valid, it is determined to be a historical fault; if both the current fault bitmap and the historical latch are invalid, it is determined to be no fault. The daemon process supports both pre-set periodic polling to read snapshots and event notification wake-up via polling, event polling, kernel event notification, or wait queue.

7. The method for diagnosing peripheral faults of a vehicle armrest screen according to claim 1, characterized in that, The authorized clear command is triggered by authentication through at least one of the following methods: local clearing via physical key combination; diagnostic tool sending UDS protocol 0x14 clear diagnostic information service request; triggering by inputting operation code in the vehicle's infotainment system menu; generating a read-only, non-clearable clearing operation log when the clear command is executed, the log shall at least record the clearing time, clearing source, and bitmap of the state before clearing.

8. The method for diagnosing peripheral faults of a vehicle armrest screen according to claim 1, characterized in that, The fault code record includes a fixed three-byte fault code and a one-byte status field; the status field 0x00 indicates no fault, 0x09 indicates the current fault, and 0x08 indicates a historical fault; it internally retains a fine-grained fault bitmap and timestamp for fault location.

9. The method for diagnosing peripheral faults of a vehicle armrest screen according to claim 1, characterized in that, It also includes an independently maintained historical fault storage area, which is independent of the current status word. The storage fields include device type, historical fault bitmap, first occurrence timestamp, last occurrence timestamp, occurrence count, and recovery timestamp. Each peripheral type retains a maximum of H recent historical records. For consecutive occurrences of the same fault bit, only the latest record is retained during the recovery cycle. The total storage space is set to an upper limit. Once the limit is exceeded, the faults are discarded according to the FIFO strategy of "earliest last occurrence timestamp".

10. A fault diagnosis system for a vehicle-mounted armrest screen peripheral, characterized in that, This includes a peripheral driver fault detection module, a kernel fault aggregation module, a shared file node, a user space daemon process, a historical fault storage module, and a diagnostic code adaptation module. The peripheral driver fault detection module is used to obtain a first fault detection result through the upper-layer active polling channel and a second fault detection result through the driver event channel, and output the two fault detection results to the kernel fault aggregation module. The upper-layer active polling channel and the driver event channel corresponding to the same peripheral device adopt the same fault bit definition. The kernel fault aggregation module is used to receive two fault detection results, generate a complete status word containing all the determined fault bits when the fault status changes, and write the complete status word to a shared file node to generate a status snapshot carrying a monotonically increasing sequence number. The shared file node is shared by the kernel space and user space and is used to store the state snapshot; The user space daemon process is used to read the state snapshot and verify the monotonically increasing sequence number. If the sequence number is inconsistent, the snapshot is read again. It combines the current fault bitmap and the historical latch status to determine three states: no fault, current fault, and historical fault. The historical latch is cleared only when there is no current fault and an authorized clear command is received after successful identity authentication. The user space daemon process also interacts with the historical fault storage module and the diagnostic code adaptation module respectively. The historical fault storage module is used to store historical fault records; The diagnostic code adaptation module is used to output fault codes that are adapted to the vehicle diagnostic link based on the judgment result of the daemon process. The armrest screen peripherals include at least one of the following: display screen, backlight or screen power supply, touch panel, audio amplifier, vibration motor, gyroscope, ambient light sensor, charging chip, battery, and charging dock interface.

Images