Operation detection and self-repairing method and system of communication terminal

Abstract

The invention discloses an operation detection and self-repairing method and system of a communication terminal, and belongs to the technical field of communication. The method comprises the following steps: responding to startup of the communication terminal, and carrying out loop detection on a plurality of operation modules concurrently through at least two independent detection channels; obtaining an identifier of an abnormal target operation module based on detection; determining a repair strategy including soft reset, reloading an application program or loading a repair patch, and dynamically generating an external virtual storage unit to temporarily store runtime data of the module; controlling the target module to execute a repair strategy, and synchronously calling data in the virtual storage unit in a repair process to maintain related system services; and releasing the storage unit after repairing is completed. According to the invention, through dual-channel detection and dynamic resource management, accurate, rapid and lossless repair of the abnormal module is realized, global reset of the system is avoided, resource overhead is reduced, and stability of the communication terminal and user experience are significantly improved.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of communication technology, and in particular to a method and system for operation detection and self-repair of a communication terminal. Background Technology

[0002] The functions of communication terminals such as smartphones and tablets are becoming increasingly complex, and their software systems integrate numerous operating modules (such as system services, background processes, and applications). During long-term operation, these modules may malfunction due to software defects, resource contention, or external interference (such as freezing, crashing, or memory leaks), seriously affecting the stability of the terminal and the user experience.

[0003] Existing technologies mainly employ the following solutions to address this type of problem: 1. Watchdog timer global reset: Triggers a complete terminal restart when the system becomes unresponsive. While this method can restore the system, it forces all ongoing tasks to be interrupted, resulting in a poor user experience. Furthermore, restarting during critical communication processes can lead to business interruptions.

[0004] 2. Hardware Redundancy Backup: Backup idle modules are configured for critical modules, switching over when the main module fails. While this method improves reliability, it requires additional hardware resources, significantly increasing the terminal's manufacturing cost, design complexity, and static power consumption. 3. Software Redundancy Replacement: This involves adding idle modules at the software level to replace the currently running module that malfunctions. However, this method requires multiple backup instances to reside, which also increases the storage burden and runtime memory pressure on the communication terminal, leading to a decrease in system resource utilization.

[0005] In summary, existing technologies either sacrifice overall service continuity or incur significant hardware costs or ongoing software resource overhead, neither of which are optimal solutions. Therefore, there is an urgent need in this field for a solution that can accurately locate and quickly self-repair individual faulty modules, while avoiding global system resets, not relying on hardware redundancy, and reducing continuous resource burden.

[0006] The embodiments of the present invention are improvements made to solve the above problems. Summary of the Invention

[0007] The purpose of this invention is to provide a method and system for detecting and self-repairing the operation of a communication terminal. By implementing this invention, the problem of system-wide service interruption or high hardware costs caused by local module malfunctions in the prior art can be solved.

[0008] To achieve the aforementioned objective, in a first aspect, embodiments of the present invention provide a method for operational detection and self-repair of a communication terminal, the technical solution of which is: In response to the aforementioned communication terminal being powered on and running, multiple operating modules are cyclically detected concurrently through at least two independent detection channels. Specifically, the communication terminal cross-detects the aforementioned operating modules through channel 1 and channel 2. Based on the cyclic detection, the identification information of the target operating module with anomalies is obtained; A repair strategy corresponding to the target running module is determined. The repair strategy includes at least one of performing a soft reset on the target running module, reloading its application, or loading a repair patch. An external virtual storage unit is dynamically generated based on the repair strategy. The external virtual storage unit is used to temporarily store the runtime data of the target running module. The target running module is controlled to execute the repair strategy, and during the repair process, runtime data in the external virtual storage unit is retrieved synchronously to maintain the system services associated with the target running module; Upon determining that the target operating module has been repaired, the external virtual storage unit is released.

[0009] Based on the first aspect, in one possible implementation, multiple operating modules are cyclically detected concurrently through at least two independent detection channels (such as channel 1 and channel 2). In a specific embodiment, the first group of operating modules is detected through the first detection channel according to the first detection cycle. The second set of operating modules is tested through the second detection channel according to the second detection cycle; The first group of operating modules and the second group of operating modules are logically complementary (for example, the first group of operating modules are modules with odd numbers and the second group of operating modules are modules with even numbers), and the first detection cycle and the second detection cycle are staggered in time.

[0010] In this embodiment of the invention, by setting up dual channels with complementary logic and staggered detection cycles for concurrent detection, the detection tasks are load-balanced over time, effectively avoiding instantaneous system resource spikes caused by centralized detection. This mechanism not only reduces the continuous occupation of the main processor's computing resources in the communication terminal but also significantly shortens the average latency from the occurrence of a fault in the abnormal module to its identification, thereby gaining valuable time for subsequent rapid repair and improving the overall real-time performance and robustness of the system.

[0011] This method employs a concurrent dual-channel detection mechanism to dynamically monitor running modules. Upon detecting an abnormal module, an external virtual storage unit is dynamically generated to back up its operational state. Subsequently, a targeted repair strategy is executed, and the backup data is used to maintain relevant services during the repair process. After the repair is complete, the storage resources are released. This approach achieves lossless repair at the module level.

[0012] Secondly, embodiments of the present invention provide a communication terminal operation detection and self-repair system for implementing the method described in the first aspect, the system comprising: The detection module is configured to perform cyclic detection on multiple operating modules concurrently through at least two independent detection channels in response to the power-on operation of the communication terminal. An anomaly detection module is configured to obtain the identification information of a target running module that has an anomaly based on the cyclic detection. The repair management module is configured to determine the repair strategy corresponding to the target running module and dynamically generate an external virtual storage unit based on the repair strategy. The external virtual storage unit is used to temporarily store the runtime data of the target running module. The repair execution module is configured to control the target running module to execute the repair strategy, and during the repair process, synchronously retrieve runtime data from the external virtual storage unit to maintain the system services associated with the target running module; The resource recycling module is configured to release the external virtual storage unit in response to determining that the target running module has been repaired.

[0013] In one possible implementation, the detection module includes: The first detection unit is configured to detect the first group of operating modules through the first detection channel according to the first detection cycle; The second detection unit is configured to detect the second group of operating modules through the second detection channel according to the second detection cycle; Furthermore, the first set of operating modules and the second set of operating modules are logically complementary, and the first detection cycle and the second detection cycle are staggered in time.

[0014] In this embodiment, by decoupling functions and encapsulating them into specific modules that work collaboratively, the system architecture achieves hardware-based and solidified methodological processes. This modular design not only reduces the coupling between various functional components of the system, facilitating subsequent maintenance, upgrades, and functional expansion, but also enables the solution to be efficiently implemented through dedicated integrated circuits or firmware, thereby improving the execution efficiency and reliability of the entire operational detection and self-repair process.

[0015] Thirdly, embodiments of the present invention provide a communication terminal, which includes the operation detection and self-repair system as described in any one of the second aspects.

[0016] In this embodiment, by integrating the aforementioned operational detection and self-repair system into the communication terminal, the terminal acquires autonomous management and recovery capabilities for module-level faults. This significantly improves the stability and reliability of the terminal during long-term operation, effectively reducing problems such as system lag, application unresponsiveness, and even system restarts caused by software module anomalies, thereby providing users with a smoother and more continuous user experience. Simultaneously, this integrated solution requires no additional hardware redundancy, helping to control the terminal's design complexity and production costs.

[0017] Furthermore, the above summary does not enumerate all the features required for embodiments of the present invention, and other combinations of these feature groups may also constitute embodiments of the present invention.

[0018] The beneficial effects of this invention include: achieving efficient and comprehensive module monitoring through dual-channel interleaved detection; realizing on-demand resource allocation and reducing system overhead through dynamically generated and released virtual storage units; and ensuring the continuity of system services and improving terminal stability and user experience by synchronously retrieving backup data during repair. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the background art, the accompanying drawings used in the embodiments of the present invention or the background art will be described below.

[0020] Figure 1 This is a flowchart of a method according to an embodiment of the present invention.

[0021] Figure 2 This is a schematic diagram of the dual-channel detection mechanism according to an embodiment of the present invention.

[0022] Figure 3 This is a structural block diagram of the system according to an embodiment of the present invention. Detailed Implementation

[0023] To make the technical means, creative features, objectives and effects of the embodiments of the present invention easier to understand, the embodiments of the present invention are further described below in conjunction with the figures and specific embodiments. It should be understood that the specific embodiments described herein are merely for explaining the embodiments of the present invention and are not intended to limit the embodiments of the present invention.

[0024] To better understand the embodiments of the present invention, please refer to Figures 1 to 3As shown, the operation detection and self-repair method of a communication terminal includes: in response to the power-on operation of the communication terminal, performing cyclic detection on multiple operating modules concurrently through at least two independent detection channels, obtaining the identification information of the target operating module that is abnormal, such as by listening to the heartbeat signal periodically sent by the operating module, and determining that the target module is abnormal when no heartbeat signal of the target module is heard within a preset time. Specifically, in one feasible implementation, combined with Figure 1 As shown, the process of the present invention begins in step S101: the communication terminal is powered on, and after the operating system (e.g., Android, iOS, or HarmonyOS) is initialized, two independent detection channels are started. These detection channels can be implemented at the operating system kernel level, running as two high-priority background daemons. These two processes are managed by the operating system's process scheduler and execute in either true concurrency (on multi-core processors) or time-slice round-robin concurrency (on single-core processors), thereby continuously and cyclically monitoring all running modules in the system (including system service processes, critical background applications, etc.).

[0025] In one feasible implementation, step S102, the specific implementation of the above-mentioned cyclic detection is as follows: Figure 2 As shown. The first detection channel (channel 1) is configured to specifically detect running modules with odd sequence numbers (e.g., module 1, module 3, module 5, ..., module n-1). The second detection channel (channel 2) is configured to specifically detect running modules with even sequence numbers (e.g., module 2, module 4, module 6, ..., module n). The detection periods of the two channels can be configured to be the same (e.g., both 100ms), but their trigger times are staggered. For example, channel 1 starts the detection task at times t0, t2, t4..., while channel 2 starts at times t1, t3, t5....

[0026] In this embodiment, the logical grouping and time-interleaved detection mechanism based on parity numbers evenly distributes the concentrated detection computation evenly across different time slices, effectively smoothing the instantaneous occupancy of system resources and avoiding system lag or delay caused by the detection behavior itself, while ensuring real-time monitoring and blind-spot-free coverage. It is understood that the above-mentioned parity grouping is only a preferred logical complementary implementation method. Those skilled in the art can also group according to other logical rules such as module priority and functional category, all of which fall within the protection scope of this invention.

[0027] In one feasible implementation, step S103, obtaining the abnormal module identification information, is achieved by "listening" to the "heartbeat" signals periodically broadcast by each running module to the system message center or a specific Socket port. The heartbeat signal is a small data packet containing the module ID and a timestamp. If the first detection channel does not "read" the heartbeat signal of module 3 within two consecutive preset detection cycles (e.g., 200ms), module 3 is determined to be abnormal, and its identifier (ID=3) and abnormal status (no response) are "obtained". In addition to heartbeat detection, abnormal detection can also be achieved collaboratively through various methods such as "reading" the module's CPU utilization rate (consistently exceeding 95%), "detecting" the growth trend of its memory usage (whether there is a leak), or "verifying" the rationality of its output results.

[0028] In one feasible implementation, step S104, determining the repair strategy, is accomplished by "querying" a "matter type-repair strategy mapping table" pre-installed in the system firmware or security partition. This mapping table is a data structure, such as a JSON file or database table, that records correspondences such as "no response" -> "soft reset," "memory overflow" -> "reboot and clean up memory," and "functional logic error" -> "load online patch." For the "no response" exception of module 3, the system queries this mapping table and determines the repair action to be a "soft reset." Subsequently, the system's repair management module 303 (see...) Figure 3 The system sends a set of control instructions to a dedicated external virtual memory unit generation module. This external virtual memory unit generation module is preferably the operating system kernel's memory management unit (MMU) or a dedicated memory driver managed by the kernel. Storage control unit 3032 (see...) Figure 3 The system is configured to respond to the aforementioned instructions by calling the MMU's address mapping interface to dynamically "allocate" a contiguous or non-contiguous memory region of a specific size (e.g., 512KB) in the free address space of the terminal's dynamic random access memory (DRAM) or non-volatile memory (UFS), and map and mark it as an external virtual memory unit (VSU_3) dedicated to module 3. Subsequently, the system uses direct memory access (DMA) or memory copy instructions to "write" critical runtime data such as the current register context, function call stack, key configuration parameters, and unsaved session data of the module 3 process into the aforementioned memory region.

[0029] The specific implementation of the "load repair patch" action described above is as follows: When the policy determination unit 3031 queries the mapping table and determines that the repair action is "load repair patch," the repair execution module 304 first suspends the process of the target running module. Subsequently, the system downloads or reads a differential patch file corresponding to the target module and its specific abnormal version from a secure cloud server or local storage security patch area. Before loading, the system needs to verify the integrity and legality of the patch file through digital signature verification. Only after successful verification can subsequent operations be performed. The repair execution module 304 calls a secure patch loader, which, according to the instructions in the patch file, performs online, hot-update modifications to the code or data segments of the target running module in memory to fix known logical errors or security vulnerabilities without completely replacing the entire application. After the patch loading is complete, the process is resumed. The method of loading repair patches enables accurate and rapid error repair, avoiding the time overhead and resource waste caused by reloading the entire application, and is particularly suitable for repairing urgent online issues in released applications.

[0030] In this embodiment, the strategy is determined by querying a preset mapping table, making the repair decision-making process automated and efficient; and the storage space is dynamically allocated by a dedicated module controlled by instructions, realizing on-demand and precise allocation of resources, which is fundamentally different from the static backup scheme that always occupies resources.

[0031] In one feasible implementation, step S105 involves controlling the execution of a repair strategy. Based on a determined "soft reset" strategy, the repair execution module first sends a SIGTERM signal to the process of module 3, requesting graceful termination and waiting for a short timeout. If the process does not respond, a SIGKILL signal is sent to force termination. After the process completely exits, the system loader rereads the application image of module 3 from the storage medium (such as eMMC), loads it into memory, and starts a new process. During this process, the system "synchronously retrieves" the backed-up configuration data and user session data in the external virtual storage unit VSU_3. A proxy service module running in user space or kernel space is activated, which can be controlled by the repair execution module 304 (see...). Figure 3 This proxy service creates and manages services that temporarily take over service interfaces originally provided by module 3 (e.g., a Binder service or an HTTP API). This proxy service "reads" data cached in VSU_3 and responds to service requests from other modules or applications "based on" this data, thus maintaining service continuity without the user's awareness. Specifically, the process of the aforementioned proxy service module's "responding to external service requests based on cached data" is as follows: When the proxy service module receives a request (such as an RPC call or inter-system communication IPC message) destined for a target running module that is in a repair state, it first parses the type of the request. For query requests, the proxy service directly searches for and returns the corresponding result from the data cached in the external virtual storage unit (for example, if the target module is an address book service and the request is to query a contact, the proxy service performs the query from the cached relational database copy and returns the result). For write requests, the proxy service temporarily stores them in a temporary queue. This proxy service module continues to work "until the target running module returns to normal operation." The criterion for determining this state is: the repair execution module 304 sends a "repair complete, service handover" signal to the proxy service module. Once this signal is received, the proxy service module stops receiving new requests and forwards the write requests in the temporary queue to the target running module that has returned to normal operation for processing. After that, it enters a dormant state, completing the service handover.

[0032] In this embodiment, the mechanism of "parallel repair execution and data service proxy" is the core of achieving seamless business recovery. It ensures that even if a critical module fails temporarily, its upstream dependent services will not be interrupted or report errors, which greatly improves the robustness of the system and the user experience.

[0033] In one feasible implementation, step S106, determining the completion of the repair, is "determined" through multi-dimensional verification. The system verifies the restarted module 3 for: 1. Whether it can continuously and stably send heartbeat signals; 2. Whether its process status (which can be queried through the / proc file system in Linux) is running normally; 3. Whether it can correctly handle a set of predefined test cases or regression tests. Once all verification conditions are met, the repair is confirmed to be successful. The resource reclamation module then sends a request to the operating system kernel to "release" the physical and logical address space occupied by the external virtual storage unit VSU_3, unmap the memory, mark this part of the storage resource as free and available, and return it to the system memory pool.

[0034] In one feasible implementation, in step S107, after releasing storage resources, the system "records" detailed information about this anomaly repair event (including timestamp, module ID, anomaly type, repair strategy used, total repair time, repair result status, etc.) in a structured system event log file. The system can periodically (e.g., every morning) or after a certain amount of logs have accumulated, trigger a low-priority background data analysis task. This task, "based" on a large number of historical repair event logs, uses statistical analysis methods (e.g., calculating the success rate of different repair strategies for the same anomaly type, average repair time, etc.) to optimize the "anomaly type-repair strategy mapping table." For example, when the system detects that for the "slow memory growth" anomaly, the success rate of the "reboot and clean up memory" strategy (e.g., 90%) is significantly higher than that of the "soft reset" strategy (e.g., 70%), and that it has better long-term maintenance efficiency, the system will automatically update the corresponding entry in the mapping table, changing the default repair action to "reboot and clean up memory." This self-optimization mechanism ensures the continued effectiveness of the repair strategy.

[0035] For example, suppose the system's default repair strategy for anomalies like "slow memory growth" is configured as "soft reset" in the initial "anomaly type-repair strategy mapping table." During a week of runtime data collection, the system recorded 150 "slow memory growth" anomaly events. After statistical analysis of these 150 log entries, the data analysis task found that: Of these, 100 events used the default "soft reset" strategy, but the success rate of the module running stably for more than 1 hour after the repair was only 70% (i.e., 70 were successful, and 30 experienced abnormal memory growth again in a short period of time). In the other 50 events, due to system load or experimental strategies, the "reboot and clean up memory" strategy was actually used, with a success rate as high as 90% (45 successful and only 5 failed). Meanwhile, data analysis also shows that although the initial execution time of "reboot and clean up memory" is about 200 milliseconds longer on average than "soft reset", its success rate is higher and it avoids frequent anomalies and repeated repairs of the same module. In the long run, its average effective repair time is actually shortened by about 15% compared to the "soft reset" strategy.

[0036] Based on this analysis, the system concludes that for the "slow memory growth" anomaly, the "reboot and clean up memory" strategy has a 20 percentage point higher success rate (90% - 70% = 20%) than the "soft reset" strategy, and also offers better overall maintenance efficiency. Therefore, the system will automatically update the "anomaly type-repair strategy mapping table," changing the repair action for the "slow memory growth" anomaly from "soft reset" to "reboot and clean up memory."

[0037] In this embodiment, this self-learning and optimization mechanism based on historical data feedback enables the system's self-repair capability to continuously evolve, becoming increasingly intelligent and accurate, moving from "passive repair" to "proactive prevention and optimization".

[0038] In one feasible implementation, combined with Figure 3 As shown, the system 300 of the present invention can be integrated into the baseband processor or application processor of a communication terminal. The system 300 includes the following modules that communicate with each other via a system bus or internal interface: Reference Figure 3 As shown, the detection module 301 is configured to concurrently perform cyclic detection on multiple running modules in response to the power-on operation of the communication terminal through at least two independent detection channels. Specifically, this module is resident in memory as a daemon process after system startup. It includes a first detection unit 3011 and a second detection unit 3012. The first detection unit 3011 is configured to detect a first group of running modules (e.g., odd-order modules) through a first detection channel according to a first detection cycle (e.g., 100ms); the second detection unit 3012 is configured to detect a second group of running modules (e.g., even-order modules) through a second detection channel according to a second detection cycle (e.g., 100ms), and the start times of the two detection cycles are staggered by 50ms, thereby achieving true concurrent detection. The anomaly identification module 302 is configured to acquire the identification information of the target running module exhibiting anomalies based on the aforementioned cyclic detection. This module communicates with the detection module 301, receiving its raw detection data (such as heartbeat timeout signals and resource indicators). Internally, it runs an analysis engine that processes the data according to preset rules (such as "no heartbeat for two consecutive cycles"), ultimately outputting a structured information packet containing the anomaly module ID (such as process PID) and anomaly type code, thereby completing the identification and information acquisition of the target running module.

[0039] The repair management module 303 is configured to determine a repair strategy corresponding to the target running module and dynamically generate an external virtual storage unit based on the repair strategy. This module further includes: a strategy determination unit 3031, configured to receive an exception type code from the exception identification module 302 and query a pre-installed "exception type-repair strategy mapping table" in flash memory to determine the corresponding repair strategy (e.g., "no response" corresponds to "soft reset"); and a storage control unit 3032, configured to send a set of control instructions to a dedicated external virtual storage unit generation module (which may be a memory management unit (MMU) or a specific driver) based on the determined repair strategy. This instruction set dynamically generates an external virtual storage unit, the process of which includes: requesting a free area in physical memory, establishing a mapping from a virtual address to the physical address, and binding the mapping relationship to the target module ID to form a temporary storage space dedicated to that module.

[0040] The repair execution module 304 is configured to control the target running module to execute the repair strategy and, during the repair process, synchronously retrieve runtime data from the external virtual storage unit to maintain the system services associated with the target running module. This module receives repair strategy instructions from the repair management module 303. If the strategy is a "soft reset," the module sends a termination signal to the target process and restarts it. During the repair process, this module activates and manages a proxy service submodule. This proxy service submodule is configured to synchronously retrieve runtime data (such as configuration parameters and session context) from the generated external virtual storage unit and use this data to temporarily respond to service requests from other system components, thereby maintaining the associated system services until the target running module recovers.

[0041] Resource reclamation module 305 is configured to release the external virtual storage unit in response to determining that the target running module has completed repair. This module listens for a "repair successful" signal from repair execution module 304. Upon receiving this signal, it sends a release command to the external virtual storage unit generation module, unmaps the address, and marks the corresponding physical memory page as free, thereby completing resource reclamation.

[0042] The aforementioned modules can be firmware within a Trusted Execution Environment (TEE) in a modern smartphone system-on-a-chip (SoC), or a group of privileged, cooperating device drivers or kernel modules within an operating system kernel.

[0043] Further, see Figure 3The detection module 301 includes a first detection unit 3011 and a second detection unit 3012 that work together functionally. The first detection unit 3011 is configured to detect a first group of operating modules (e.g., modules with odd serial numbers) through a first detection channel according to a first detection cycle. The second detection unit 3012 is configured to detect a second group of operating modules (e.g., modules with even serial numbers) through a second detection channel according to a second detection cycle.

[0044] The first set of operating modules and the second set of operating modules are logically complementary, and the first detection cycle and the second detection cycle are staggered in time, thereby realizing a concurrent, efficient and low-resource-consumption cyclic detection mechanism.

[0045] See also Figure 3 The aforementioned repair management module 303 includes a policy determination unit 3031 and a storage control unit 3032. The policy determination unit 3031 is configured to query the "abnormal type-repair policy mapping table" pre-set in the system firmware or security partition based on the abnormal type detected by the abnormal identification module 302, so as to determine the repair action (such as soft reset, reload application or load repair patch) corresponding to the target running module.

[0046] The aforementioned storage control unit 3032 is configured to send control instructions to an external virtual storage unit generation module (such as the memory management unit MMU of the operating system kernel) based on the determined repair strategy, so as to dynamically allocate storage space corresponding to the target running module in the free area of ​​the memory, thereby generating the external virtual storage unit.

[0047] Based on the above embodiments, this application also provides a communication terminal, which includes the operation detection and self-repair system described in any of the above embodiments. The terminal can be a smartphone, tablet computer, in-vehicle infotainment system, 5G CPE device, or other intelligent communication device with a complex operating system.

[0048] In this embodiment, by integrating the aforementioned self-healing system into the communication terminal, the terminal acquires complete module-level fault autonomy capabilities from the chip layer to the system software layer. This significantly improves the stability and reliability of the terminal device in complex network environments and under long-term continuous operation conditions, effectively reducing application crashes, system lag, functional failures, and even unnecessary system restarts caused by software module anomalies, thereby providing end users with a smoother, more consistent, and more reliable user experience. Simultaneously, this pure software and system architecture innovation eliminates the need for additional dedicated hardware chips, helping terminal manufacturers significantly enhance product competitiveness while controlling costs and complexity.

[0049] It should be understood that the terms "one embodiment," "an embodiment," "a feasible implementation," or "some implementations" used throughout the specification mean that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of the present invention. Therefore, "one embodiment," "an embodiment," "a feasible implementation," or "some implementations" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Those skilled in the art should also recognize that the embodiments described in the specification are optional embodiments, and the actions and modules involved are not necessarily essential to the embodiments of the present invention.

[0050] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will 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 instructions. These instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0051] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0052] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0053] The above description is merely a specific embodiment of the present invention, but the protection scope of the embodiments of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the embodiments of the present invention should be included within the protection scope of the embodiments of the present invention. Therefore, the protection scope of the embodiments of the present invention should be determined by the protection scope of the claims.

Claims

1. A method for operational detection and self-repair of a communication terminal, characterized in that, include: In response to the power-on operation of the communication terminal, multiple operating modules are cyclically detected concurrently through at least two independent detection channels; Based on the cyclic detection, the identification information of the target operating module with anomalies is obtained; A repair strategy corresponding to the target running module is determined, and an external virtual storage unit is dynamically generated based on the repair strategy. The external virtual storage unit is used to temporarily store the runtime data of the target running module. The target running module is controlled to execute the repair strategy, and during the repair process, runtime data in the external virtual storage unit is retrieved synchronously to maintain the system services associated with the target running module; Upon determining that the target operating module has been repaired, the external virtual storage unit is released.

2. The method according to claim 1, characterized in that, The method of concurrently performing cyclic detection on multiple operating modules through at least two independent detection channels includes: The first group of operating modules is tested through the first detection channel according to the first detection cycle; The second set of operating modules is tested through the second detection channel according to the second detection cycle; The first set of operating modules and the second set of operating modules are logically complementary, and the first detection cycle and the second detection cycle are staggered in time.

3. The method according to claim 1, characterized in that, Based on the aforementioned cyclic detection, the identification information of the target operating module exhibiting anomalies is obtained, including through at least one of the following methods: The system monitors the heartbeat signals periodically sent by the operating module, and determines that the target module is abnormal if no heartbeat signal is detected from the target module within a preset time.

4. The method according to claim 1, characterized in that, Determine the repair strategy corresponding to the target running module, including: Based on the detected anomaly type, query the preset anomaly type-repair strategy mapping table to determine the corresponding repair action; The repair action includes at least one of the following: performing a soft reset on the target running module, reloading the application of the target running module, or loading a repair patch for the target running module.

5. The method according to claim 1, characterized in that, Based on the repair strategy, an external virtual storage unit is dynamically generated, including: Send control commands to an external virtual storage unit generation module to dynamically allocate storage space corresponding to the target running module in the free area of ​​the memory; Write the current register data, stack data, and configuration parameters of the target running module into the storage space.

6. The method according to claim 1, characterized in that, Controlling the target runtime module to execute the repair strategy, and synchronously retrieving runtime data from the external virtual storage unit during the repair process to maintain system services associated with the target runtime module, including: During the period when the target running module is reset or reloaded, a proxy service module reads data from the external virtual storage unit for caching and responds to external service requests based on the cached data until the target running module resumes normal operation.

7. The method according to claim 1, characterized in that, After releasing the external virtual storage unit, the method further includes: Record the event log for this anomaly repair event; The repair strategy was optimized based on historical repair event logs.

8. A system for detecting and self-repairing the operation of a communication terminal, characterized in that, include: The detection module is configured to perform cyclic detection on multiple operating modules concurrently through at least two independent detection channels in response to the power-on operation of the communication terminal. An anomaly detection module is configured to obtain the identification information of a target running module that has an anomaly based on the cyclic detection. The repair management module is configured to determine the repair strategy corresponding to the target running module and dynamically generate an external virtual storage unit based on the repair strategy. The external virtual storage unit is used to temporarily store the runtime data of the target running module. The repair execution module is configured to control the target running module to execute the repair strategy, and during the repair process, synchronously retrieve runtime data from the external virtual storage unit to maintain the system services associated with the target running module; The resource recycling module is configured to release the external virtual storage unit in response to determining that the target running module has been repaired.

9. The system according to claim 8, characterized in that, The detection module includes: The first detection unit is configured to detect the first group of operating modules through the first detection channel according to the first detection cycle; The second detection unit is configured to detect the second group of operating modules through the second detection channel according to the second detection cycle; The first set of operating modules and the second set of operating modules are logically complementary, and the first detection cycle and the second detection cycle are staggered in time.

10. The system according to claim 8, characterized in that, The repair management module includes: The strategy determination unit is configured to query a pre-defined anomaly type-repair strategy mapping table based on the detected anomaly type to determine the corresponding repair action; The storage control unit is configured to send control commands to an external virtual storage unit generation module to dynamically generate the external virtual storage unit.

Images