Fault monitoring method and system for touch interaction equipment

Abstract

The invention belongs to the technical field of reliability design of embedded systems, provides a fault monitoring method and system for touch interaction equipment, and is applied to embedded equipment based on a Linux system. The method comprises the following steps: acquiring running state multi-source data of the touch interaction equipment in real time; performing dynamic analysis on the data based on a preset fault prediction rule, and identifying potential soft fault symptoms; before the user perceives the abnormity, if a soft fault symptom is recognized, software reset operation on the touch controller is automatically triggered; recording the running state multi-source data, the exception judgment result, the self-healing operation and the execution result of the self-healing operation in the form of a structured log file, and storing a complete log in a recent preset time period by adopting a cyclic coverage strategy. According to the invention, early warning, automatic repair and high-fidelity tracing of faults of the touch equipment are realized, and the reliability and maintainability of a man-machine interaction system in an industrial scene are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of embedded system reliability design technology, specifically to a method and system for fault monitoring of touch interactive devices in industrial embedded equipment based on the Linux system, applicable to scenarios with strict requirements for high availability and traceability, such as rail transit, intelligent industrial control, and self-service terminals. Background Technology

[0002] In rail transit operations, touch-screen interactive devices (such as onboard control screens and platform service terminals) serve as the core carriers for human-machine interaction and control of critical equipment. Their operational accuracy, response reliability, and status traceability directly affect train safety and operational efficiency. Especially under high-density, long-term continuous operation conditions, if equipment malfunctions, fails to respond, or malfunctions in command execution, and cannot be identified and recovered in a timely manner, it may lead to operational delays or even safety accidents.

[0003] Meanwhile, complete operational logs, including equipment operating status, fault events, and user actions, are crucial for subsequent troubleshooting, operational optimization, and safety traceability. Ideally, the logs should cover the temporal correlation information between equipment status, user actions, and system responses. However, in existing technologies, the interactive functions and logging functions of touch devices in the rail transit field are often designed separately, resulting in the following drawbacks: On the one hand, the touch event handling module only focuses on real-time response and interface feedback, and does not associate touch behavior with the underlying state of the device (such as driver health and kernel abnormalities) in a model. On the other hand, log recording modules are mostly limited to simple passive storage of hardware-level fault codes (such as power failure and communication timeout), lacking structured and high-fidelity recording of the entire touch operation process (including operation trigger time, original touch coordinates, corresponding execution instructions and their system context).

[0004] The aforementioned deficiencies prevent maintenance personnel from effectively reconstructing the operational sequence and system environment prior to the failure from existing logs when interactive anomalies occur. This makes it difficult to distinguish whether the root cause is a touch hardware malfunction, driver software freeze, accidental touch, or operational logic flaw. This significantly prolongs troubleshooting time and increases on-site maintenance costs and operational risks.

[0005] Therefore, there is an urgent need for a method for monitoring and logging touch interactive devices that meets the high reliability requirements of rail transit. This method should be able to achieve deep integration of touch behavior and system status, proactive identification of abnormal patterns, automatic repair of soft faults, and structured, loss-proof, and traceable storage of data throughout the entire process. This would enable the construction of an integrated health management mechanism that integrates perception, analysis, self-healing, and auditing. Summary of the Invention

[0006] To address the technical challenges of early warning systems for touch-interactive device malfunctions, reliance on manual intervention for soft faults, and difficulties in root cause analysis due to the lack of structured correlation in operation logs, this invention discloses a method and system for monitoring touch-interactive device malfunctions. This method constructs a closed-loop embedded device health monitoring and self-healing framework encompassing "real-time acquisition – intelligent analysis – proactive self-healing – complete traceability." This framework identifies potential soft fault symptoms and automatically triggers repair mechanisms before the user perceives any abnormalities, effectively suppressing fault evolution and significantly reducing the field fault feedback rate. Simultaneously, key data throughout the process is recorded in a structured and high-fidelity manner, providing reliable on-site evidence for subsequent root cause analysis and system optimization.

[0007] The technical solution for implementing the present invention is as follows: On one hand, embodiments of the present invention provide a method for fault monitoring of a touch interactive device, the method comprising the following steps: S1. Real-time acquisition of multi-source data on the operating status of the touch interaction device, wherein the multi-source data on the operating status includes at least touch coordinate stream, device heartbeat signal, system kernel log and system resource usage information; S2. Based on preset fault prediction rules, perform dynamic analysis on the multi-source data of the operating status to identify potential soft fault symptoms and obtain anomaly judgment results. S3. If potential soft fault symptoms are identified before the user perceives any device malfunction, the corresponding self-healing operation will be automatically triggered to perform a software reset on the touch controller. S4. Record the multi-source data of the running status, the anomaly judgment result, the self-healing operation and its execution result in the form of a structured log file, and use a cyclic overwrite strategy to store the complete log within the most recent preset time period.

[0008] Further, in step S1, system kernel logs and system resource usage information are collected, including: S11. When the touch interaction device is powered on, check if the touch node exists. If it does not exist, trigger the system to restart and record the restart event. S12. Within the first predetermined time after the touch interaction device completes startup, collect the system kernel log and system resource usage information once, and generate an initial system kernel log file named with a timestamp. S13. Obtain the current system kernel log at a predetermined period and compare it with the previously stored system kernel log content; if there is new content, generate a new system kernel log file and synchronously record the current system resource usage information. Each generated system kernel log file and its corresponding system resource usage information are named with the current timestamp.

[0009] Furthermore, in step S2, the preset fault prediction rule includes any one or more of the following: The number of identical touch coordinate points exceeds a first threshold within a predetermined statistical period; The total number of cumulative touch events exceeds the second threshold within the predetermined statistical period; The number of touch points located in the screen edge area exceeds the third threshold within the predetermined statistical period; The device's heartbeat signal has not been updated for several consecutive heartbeat cycles.

[0010] Furthermore, the screen edge region refers to the annular area formed by extending a preset pixel distance from the four physical edges of the effective display area on the touch screen panel as a reference.

[0011] Further, in step S4, the structured record includes: The touch coordinate stream, the device heartbeat signal, the anomaly determination result, and the self-healing operation and its execution result are written into a touch-related log file, and the touch-related log file is named by date and stored in the first storage path; The system kernel log and system resource usage information are written to a system-level log file, and the system-level log file is organized by date and stored in the corresponding date directory under the second storage path.

[0012] Furthermore, when the number of touch-related log files exceeds a set limit, the earliest log file is automatically deleted according to a first-in-first-out (FIFO) principle. Similarly, when the number of date directories in the second storage path exceeds a set limit, the earliest log directory is automatically deleted according to a FIFO principle.

[0013] Furthermore, in step S3, after the self-healing operation is triggered, a dedicated reset log file is generated, and the reset time, triggering reason, and execution result are written into the touch-related log file or a separate audit log file.

[0014] On the other hand, embodiments of the present invention also provide a fault monitoring system for touch interactive devices. The system is deployed in an embedded device based on a Linux system and includes a data acquisition unit, a fault prediction unit, a self-healing execution unit, and a log recording and auditing unit.

[0015] The data acquisition unit is used to collect multi-source data on the operating status of the touch interaction device in real time. The multi-source data on the operating status includes at least touch coordinate stream, device heartbeat signal and system kernel log. The fault prediction unit is used to dynamically analyze the multi-source data of the operating status based on preset fault prediction rules, identify potential soft fault symptoms, and obtain anomaly judgment results. The self-healing execution unit is used to automatically trigger the corresponding self-healing operation and perform a software reset on the touch controller when a potential soft fault is detected before the user perceives the device abnormality. The logging and auditing unit is used to record the multi-source data of the running status, the anomaly judgment results, the self-healing operation and its execution results in the form of a structured log file, and to store the complete log within the most recent preset time period using a cyclic overwrite strategy.

[0016] Furthermore, the data acquisition unit includes multiple parallel task modules, specifically including a main task module, a heartbeat monitoring module, and a system status module.

[0017] The main task module is configured to continuously collect touch coordinate points and record them according to timestamps to obtain a touch coordinate stream; The heartbeat monitoring module is configured to periodically record the heartbeat signal of the touch device to obtain the device's heartbeat signal; The system status module is configured to detect the presence of touch nodes when the device starts up and to periodically collect system kernel logs and system resource usage information.

[0018] Furthermore, the system operates as a daemon process, with each unit working collaboratively to form a closed loop of proactive health monitoring and self-healing for touch-interactive devices.

[0019] The system of this invention is an embedded device health management framework that has undergone large-scale field validation. Through layered decoupling, rule-driven, and proactive self-healing design, it perfectly solves touchscreen and other potential soft-fault issues, significantly improving product reliability and user satisfaction. This architecture is highly scalable and reusable, and can serve as a fundamental component of embedded products, quickly ported to new projects for managing networks, sensors, power supplies, and any other modules requiring high availability. Furthermore, it is not only applicable to the rail transportation industry but can also be extended to other industrial sectors.

[0020] Compared with the prior art, the beneficial effects that at least one technical solution adopted in the embodiments of this specification can achieve include at least: 1. Proactively intervene when the touch IC is about to fail but has not completely crashed, nipping the problem in the bud; 2. The method of this invention enables most faults to be automatically recovered without manual restart, thus improving equipment availability; 3. The output structured log contains information such as the environment, operations, and system status before the failure, which facilitates accurate tracing during later analysis; 4. The layered decoupling architecture of this invention is scalable and can be quickly adapted to the monitoring of other modules such as networks, sensors, and power supplies. Attached Figure Description

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

[0022] Figure 1 This is a flowchart of the touch interaction device fault monitoring method of the present invention; Figure 2 This is an architecture diagram of the touch interaction device fault monitoring system of the present invention; Figure 3 This is the execution flow of each unit in the touch interaction device fault monitoring system of the present invention; Among them, 201 is the data acquisition unit; 202 is the fault prediction unit; 203 is the self-healing execution unit; and 204 is the log recording and auditing unit. Detailed Implementation

[0023] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0024] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features of the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] This invention provides a method for fault monitoring of touch interactive devices. This method is a complete embedded device health monitoring and self-healing framework. It adopts the design concept of shifting from passively responding to external field faults to actively predicting, recording, repairing and reporting. This method has been verified in actual projects and has successfully reduced the feedback of touch-related external field faults to almost zero, unless it is indeed due to physical hardware damage.

[0026] Specifically, see Figure 1 As shown, the method includes the following steps: S1. Real-time acquisition of multi-source data on the operating status of the touch interaction device, wherein the multi-source data on the operating status includes at least touch coordinate stream, device heartbeat signal, system kernel log and system resource usage information; S2. Based on preset fault prediction rules, perform dynamic analysis on the multi-source data of the operating status to identify potential soft fault symptoms and obtain anomaly judgment results. S3. If potential soft fault symptoms are identified before the user perceives any device malfunction, the corresponding self-healing operation will be automatically triggered to perform a software reset on the touch controller. S4. Record the multi-source data of the running status, the anomaly judgment result, the self-healing operation and its execution result in the form of a structured log file, and use a cyclic overwrite strategy to store the complete log within the most recent preset time period.

[0027] In one embodiment, step S1 involves collecting system kernel logs and system resource usage information, including: S11. When the touch interaction device is powered on, check if the touch node exists. If it does not exist, trigger the system to restart and record the restart event. S12. Within the first predetermined time after the touch interaction device completes startup, collect the system kernel log and system resource usage information once, and generate an initial system kernel log file named with a timestamp. S13. Obtain the current system kernel log at a predetermined period and compare it with the previously stored system kernel log content; if there is new content, generate a new system kernel log file and synchronously record the current system resource usage information. Each generated system kernel log file and its corresponding system resource usage information are named with the current timestamp.

[0028] In one embodiment, in step S2, the preset fault prediction rule includes any one or more of the following: (1) The number of identical touch coordinates exceeds the first threshold within a predetermined statistical period; (2) The total number of touch events accumulated within the predetermined statistical period exceeds the second threshold; (3) The number of touch points located in the screen edge area exceeds the third threshold during the predetermined statistical period; (4) The equipment heartbeat signal has not been updated in multiple consecutive heartbeat cycles.

[0029] Furthermore, in the preset fault prediction rules, the predetermined statistical period can be designed to be 10 seconds, the first threshold can be designed to be 8, the second threshold can be designed to be 200, and the third threshold can be designed to be 100, based on user needs or touchscreen characteristics. The screen edge area refers to the annular area formed by extending a preset pixel distance from the four physical edges of the effective display area on the touchscreen panel towards the center of the touchscreen panel.

[0030] Furthermore, the various rules and thresholds in the preset fault prediction rules can be updated and upgraded according to different user needs, different touch screens, and historical data.

[0031] In one embodiment, in step S4, the structured record includes: S41. Write the touch coordinate stream, the device heartbeat signal, the anomaly determination result, and the self-healing operation and its execution result into a touch-related log file, and name the touch-related log file by date and store it in the first storage path. S42. Write the system kernel log and system resource usage information into the system-level log file, and organize the system-level log file by date and store it in the corresponding date directory under the second storage path.

[0032] Furthermore, when the number of touch-related log files exceeds a set limit, the earliest log file is automatically deleted according to a first-in-first-out (FIFO) principle. Similarly, when the number of date directories in the second storage path exceeds a set limit, the earliest log directory is automatically deleted according to a FIFO principle.

[0033] In one embodiment, in step S3, after the self-healing operation is triggered, a dedicated reset log file is generated, and the reset time, triggering reason, and execution result are written into the touch-related log file or a separate audit log file.

[0034] The method of the present invention, in a first aspect, can perform proactive prevention. Compared with traditional log recording, which can only provide analytical clues after a failure occurs, it can monitor in real time through a rule engine and trigger a self-healing process in advance, nipping the failure in the bud, even before the user perceives the abnormality (such as the touch IC is about to become unresponsive but has not completely crashed). Secondly, it features automatic recovery. Since the vast majority of touch anomalies (over 90%) are "soft" faults in the driver layer or IC, they can be recovered through a reset operation. This invention achieves a fully automated closed loop of "discovery-diagnosis-repair," requiring no user intervention or device restart, greatly improving device availability and user experience, thereby directly reducing user feedback. Thirdly, it enables precise root cause analysis. For genuine hardware faults that cannot heal themselves, the detailed logs recorded by the system (including ambient light, touch points, and system messages from the minutes before the fault) provide developers with an irreplaceable snapshot of the situation, enabling precise location of hardware batch problems or design defects, allowing for source-level repair and preventing recurrence. Fourthly, it offers quantifiable reliability improvement. This invention significantly increases the mean time between failures (MTBF) for device touch input. The near absence of touch anomalies is the most powerful proof of the architecture's success, directly minimizing maintenance costs.

[0035] Based on the same inventive concept, this invention also provides a touch interaction device fault monitoring system, as described in the following embodiments. Since the principle of the touch interaction device fault monitoring system in solving problems is similar to that of the touch interaction device fault monitoring method, the implementation of the touch interaction device fault monitoring system can refer to the implementation of the touch interaction device fault monitoring method disclosed in the above embodiments, and repeated details will not be elaborated further. As used below, the terms "unit" or "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0036] Figure 2 This is a structural block diagram of a touch interaction device fault monitoring system disclosed in an embodiment of the present invention, such as... Figure 2 As shown, the system is deployed in an embedded device based on the Linux system and includes a data acquisition unit 201, a fault prediction unit 202, a self-healing execution unit 203, and a log recording and auditing unit 204. The structure is described below.

[0037] The data acquisition unit 201 is used to collect multi-source data on the operating status of the touch interaction device in real time. The multi-source data on the operating status includes at least touch coordinate stream, device heartbeat signal and system kernel log. The fault prediction unit 202 is used to dynamically analyze the multi-source data of the operating status based on preset fault prediction rules, identify potential soft fault symptoms, and obtain anomaly judgment results. The self-healing execution unit 203 is used to automatically trigger the corresponding self-healing operation and perform a software reset on the touch controller before the user perceives any abnormality in the device and before identifying potential soft fault symptoms. The log recording and auditing unit 204 is used to record the multi-source data of the running status, the anomaly judgment results, the self-healing operation and its execution results in the form of a structured log file, and to store the complete log within the most recent preset time period using a cyclic overwrite strategy.

[0038] In one embodiment, the data acquisition unit 201 is used to collect data from various devices in a unified manner, specifically including multiple parallel task modules, including a main task module, a heartbeat monitoring module, and a system status module.

[0039] The main task module is configured to continuously collect touch coordinate points and record them with timestamps to obtain a touch coordinate stream. The heartbeat monitoring module is configured to periodically record the heartbeat signal of the touch device to obtain the device heartbeat (IC) signal. The system status module is configured to detect the existence of touch nodes when the device starts up and periodically collect system kernel logs (dmesg) and system resource usage information. Furthermore, this unit can be easily expanded to access new data sources, such as sensor data (temperature, brightness), network status, process status, and custom hardware registers, providing a standardized data access paradigm for other products.

[0040] In one embodiment, the fault prediction unit 202 identifies potential soft fault symptoms by invoking the Rule Engine Layer, which stores preset fault prediction rules. In specific implementations, the preset fault prediction rules can be used to identify abnormal touch conditions, such as heartbeat timeout, excessive frequency, edge triggering, and coordinate lag.

[0041] Furthermore, the fault prediction rules within the rule engine layer can be extended. New diagnostic rules can be injected after analyzing fault modes, such as network module crashes or sensor drift, without modifying the underlying framework.

[0042] In one embodiment, the self-healing execution unit 203 can execute repair instructions issued by the rule engine, primarily performing the eSoftware_Reset operation. Furthermore, this unit has a scalable and rich library of self-healing actions, such as restarting processes, switching between primary and backup boards, reporting to the cloud platform, and entering safe mode. It also provides diverse recovery methods for different faults in different products.

[0043] In one embodiment, the logging and auditing unit 204 is used to persistently record all key information, mainly including multi-source data on running status, triggered events, executed actions and their results.

[0044] In one embodiment, the system operates as a daemon process, with each unit working collaboratively to form a closed loop of proactive health monitoring and self-healing for touch-interactive devices.

[0045] In specific implementation, such as Figure 3 The diagram illustrates the execution flow for monitoring, resetting, and recording faults in touch-interactive devices using multi-threading. A detailed explanation follows: 1) Thread 1 records the touchscreen's running information every 3 minutes and writes it to the log file according to the time. 2) After thread 2 is powered on, it checks the touch node once. If it is not found, it executes reboot and writes the reboot record to the log file according to the time. 3) Thread 2 stores dmesg information 1 minute after power-on and synchronously records the current system resource (such as CPU, DDR, etc.) usage. The generated record file is named with the time. 4) Thread 2 compares the dmesg information every 3 minutes. If there are any changes, it re-stores the dmesg information and synchronously records the current system resource (such as CPU, DDR and other usage) usage. The generated record file is named with the time. 5) The main thread continuously detects coordinate points, records coordinate point information once per second, and writes it to the log file according to the time. 6) The main thread continuously counts the number of coordinate points and checks every 10 seconds: if there are more than 8 identical coordinate points, more than 200 coordinate points, or more than 100 edge coordinate points, then execute eSoftware_Reset to reset the touch screen, record the eGTouch_xxx.log generated by the reset, and synchronously write the touch screen reset information to the log file according to the time. 7) Two folders will be generated: / home / monitortouch and / opt / log / . When there are more than 15 files under / home / monitortouch, the earlier log files will be automatically deleted according to the first-in-first-out principle. When there are more than 15 folders under / opt / log / , the earlier log files will be automatically deleted according to the first-in-first-out principle.

[0046] Compared with the prior art, the embodiments of the present invention achieve the following technical effects: 1. By collecting touch coordinate streams, heartbeat signals and kernel logs in real time, and dynamically analyzing abnormal patterns based on preset rules (such as repeated coordinates, high-frequency touches, edge mis-touches, etc.), the system can identify signs of impending failure of the touch controller before the user perceives the device lag or unresponsiveness, effectively nipping the fault in the bud and achieving early identification and proactive intervention of soft faults.

[0047] 2. By constructing a fully automatic self-healing closed loop, the system availability is greatly improved. Once a potential soft fault is detected, the system automatically triggers lightweight repair operations such as software reset (eSoftware_Reset) without manual intervention or a complete machine restart. More than 90% of touch driver hang-up faults can be recovered within seconds, significantly improving the continuous service capability of the equipment in critical scenarios such as rail transit.

[0048] 3. The touch operation (time, coordinates), system status (CPU / memory / dmesg), anomaly judgment criteria and self-healing execution results are uniformly recorded in a structured way according to timestamps, forming a three-in-one full-link log of "operation-status-response", providing complete on-site data for fault root cause analysis and greatly shortening the operation and maintenance troubleshooting cycle.

[0049] 4. The logs adopt a dual-path storage strategy (separating touch logs and system logs), and combine a circular overwrite and first-in-first-out (FIFO) cleanup mechanism to avoid the loss of critical data in limited storage space; in addition, even in the event of a sudden power outage, the logs already written can still be completely retained, meeting the stringent requirements of rail transit for data traceability.

[0050] 5. The method and system of the present invention adopt a modular design, realize architecture decoupling, configurable fault prediction rules, and data acquisition and self-healing logic can be adapted to other subsystems such as network modules, sensors or power management units, and have good platform portability and functional expansion potential.

[0051] In this embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-described touch interaction device fault monitoring methods.

[0052] Specifically, the computer device can be a computer terminal, a server, or a similar computing device.

[0053] In this embodiment, a computer-readable storage medium is provided, which stores a computer program that executes any of the above-described touch interaction device fault monitoring methods.

[0054] Specifically, computer-readable storage media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer-readable storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable storage media does not include transient media, such as modulated data signals and carrier waves.

[0055] Obviously, those skilled in the art should understand that the modules or steps of the above-described embodiments of the present invention can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of the present invention are not limited to any particular hardware and software combination.

[0056] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations can be made to the embodiments of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for fault monitoring of a touch interactive device, characterized in that, include: Real-time acquisition of multi-source data on the operating status of touch interaction devices, including at least touch coordinate stream, device heartbeat signal, system kernel log and system resource usage information; Based on preset fault prediction rules, the multi-source data of the operating status is dynamically analyzed to identify potential soft fault symptoms and obtain anomaly judgment results. If potential soft fault signs are detected before the user perceives any device malfunction, the corresponding self-healing operation will be automatically triggered to perform a software reset on the touch controller. The multi-source data of the running status, the anomaly judgment results, the self-healing operation and its execution results are recorded in the form of structured log files, and the complete logs within the most recent preset time period are stored using a cyclic overwrite strategy.

2. The method for fault monitoring of touch interactive devices according to claim 1, characterized in that, Collect system kernel logs and system resource usage information, including: When the touch interaction device is powered on, the system checks whether the touch node exists. If it does not exist, the system is restarted and the restart event is recorded. Within the first predetermined time after the touch interaction device completes startup, the system kernel log and system resource usage information are collected once, and an initial system kernel log file is generated by naming it with a timestamp. The system kernel log is retrieved at a predetermined interval and compared with the previously stored system kernel log content. If new content is found, a new system kernel log file is generated and the current system resource usage information is recorded synchronously. Each generated system kernel log file and its corresponding system resource usage information are named with the current timestamp.

3. The method for fault monitoring of touch interactive devices according to claim 1, characterized in that, The preset fault prediction rules include any one or more of the following: The number of identical touch coordinate points exceeds a first threshold within a predetermined statistical period; The total number of cumulative touch events exceeds the second threshold within the predetermined statistical period; The number of touch points located in the screen edge area exceeds the third threshold within the predetermined statistical period; The device's heartbeat signal has not been updated for several consecutive heartbeat cycles.

4. The method for fault monitoring of touch interactive devices according to claim 3, characterized in that, The screen edge region refers to the annular area formed by extending a preset pixel distance from the four physical edges of the effective display area on the touch panel as a reference.

5. The method for fault monitoring of touch interactive devices according to claim 1, characterized in that, The structured record includes: The touch coordinate stream, the device heartbeat signal, the anomaly determination result, and the self-healing operation and its execution result are written into a touch-related log file, and the touch-related log file is named by date and stored in the first storage path; The system kernel log and system resource usage information are written to a system-level log file, and the system-level log file is organized by date and stored in the corresponding date directory under the second storage path.

6. The method for fault monitoring of a touch interactive device according to claim 5, characterized in that, When the number of touch-related log files exceeds the set number, the earliest log file will be automatically deleted according to the first-in-first-out principle. When the number of date directories in the second storage path exceeds the set number, the earliest log directory will be automatically deleted according to the first-in-first-out principle.

7. The method for fault monitoring of touch interactive devices according to claim 1, characterized in that, After the self-healing operation is triggered, a dedicated reset log file is generated, and the reset time, triggering reason, and execution result are written into the touch-related log file or a separate audit log file.

8. A fault monitoring system for touch interactive devices, characterized in that, The system is deployed on a Linux-based embedded device and includes: The data acquisition unit is used to collect multi-source data on the operating status of the touch interaction device in real time. The multi-source data on the operating status includes at least touch coordinate stream, device heartbeat signal and system kernel log. The fault prediction unit is used to dynamically analyze the multi-source data of the operating status based on preset fault prediction rules, identify potential soft fault symptoms, and obtain anomaly judgment results. The self-healing execution unit is used to automatically trigger the corresponding self-healing operation and perform a software reset on the touch controller when potential soft fault symptoms are detected before the user perceives the device abnormality. The logging and auditing unit is used to record the multi-source data of the running status, the anomaly judgment results, the self-healing operation and its execution results in the form of a structured log file, and to store the complete log within the most recent preset time period using a cyclic overwrite strategy.

9. The touch interaction device fault monitoring system according to claim 8, characterized in that, The data acquisition unit includes multiple parallel task modules, specifically including: The main task module is configured to continuously collect touch coordinate points and record them according to timestamps to obtain a touch coordinate stream; The heartbeat monitoring module is configured to periodically record the heartbeat signal of the touch device to obtain the device's heartbeat signal; The system status module is configured to detect the presence of touch nodes when the device starts up and periodically collect system kernel logs and system resource usage information.

10. The touch interaction device fault monitoring system according to claim 7, characterized in that, The system operates as a daemon process, with each unit working collaboratively to form a closed loop of proactive health monitoring and self-healing for touch-interactive devices.

Images