A distributed screen inspection and repair control method, system, device and medium

Abstract

This specification discloses a distributed screen inspection and repair control method, system, device, and medium. The method uses a monitoring module deployed on the screen terminal to collect real-time operating parameters and playback status logs of the screen device. The collected data is processed to extract key health data and generate a terminal status vector. This terminal status vector is then input into a pre-trained diagnostic model. Rule matching and anomaly detection algorithms are used to evaluate and calculate the terminal's health status. Based on the real-time health score of the terminal calculated by the diagnostic model, fault types are identified and fault levels are determined. Corresponding remote repair strategies are executed, and post-repair status data is collected to verify the repair effect and update the terminal's health status. This method effectively solves the problems of poor real-time performance, high labor costs, and slow fault recovery in existing screen maintenance, demonstrating significant technological advancement and broad engineering application value.

Description

Technical Field

[0001] This invention relates to the field of terminal operation and maintenance management technology, and more specifically, to a distributed screen inspection and repair control method, system, device and medium. Background Technology

[0002] With the development of smart cities and digital commerce, outdoor screens, as an important carrier for information dissemination and commercial display, are widely deployed in business districts, transportation hubs, community entrances and exits, and public places. These screens are typically characterized by a large number of deployments, wide distribution, complex working environments, susceptibility to factors such as temperature, humidity, light, and network quality, and high requirements for continuous and stable operation; any failure will directly cause losses.

[0003] Currently, the operation and maintenance management of outdoor screens mainly adopts manual periodic inspection, simple online monitoring, and passive fault reporting. These methods have obvious shortcomings in practical applications, including poor real-time performance, weak fault location capabilities, extremely high costs for manual inspection and on-site repair, inability to automatically handle common faults, and insufficient operation and maintenance decision-making information. Even when work orders are generated, they often lack detailed diagnostic information, resulting in low on-site troubleshooting efficiency.

[0004] Therefore, there is an urgent need to research a systematic solution that can perceive and diagnose the operating status of screen terminals in real time and support remote repair. Summary of the Invention

[0005] This specification provides a distributed screen inspection and repair control method, system, device, and medium to overcome at least one technical problem existing in related technologies.

[0006] According to a first aspect of the embodiments of this specification, a distributed screen inspection and repair control method is provided, comprising: The monitoring module deployed on the screen terminal collects the screen device's operating parameters and playback status logs in real time. The collected data is processed to extract key health data, including device operating temperature, ambient light intensity, network connection status and latency, processor and memory usage, and process logs, and a terminal status vector is generated. The terminal state vector is input into a pre-trained diagnostic model. The terminal health status is evaluated and calculated through rule matching and anomaly detection algorithms. The real-time health status of the terminal is calculated based on the diagnostic model, and the fault type and fault level are identified. Based on the fault type and fault level, execute the corresponding remote repair strategy, collect the status data after repair, verify the repair effect, and update the terminal health status.

[0007] Preferably, the steps of inputting the terminal state vector into a pre-trained diagnostic model, evaluating and calculating the terminal health status through rule matching and anomaly detection algorithms, calculating the terminal's real-time health score based on the diagnostic model, identifying the fault type, and determining the fault level include: Input the terminal state vector into the pre-trained diagnostic model. in, This is the preprocessed terminal state vector. For terminal state components; A pre-trained diagnostic model uses rule matching and anomaly detection algorithms to assess the terminal's health status, resulting in the terminal's real-time health level. in, Characterizes the real-time health of the terminal. This is the normalization function for the terminal state components. These are the indicator weight parameters; The terminal's real-time health status is calculated based on the diagnostic model, and the terminal's status is obtained according to a preset range threshold, including normal status, sub-health status, fault risk status, and severe fault status.

[0008] Preferably, the diagnostic model is trained using rule matching and anomaly detection algorithms, and a two-layer diagnostic mechanism is adopted to identify fault types, including: The first layer is the rule matching layer, which identifies known faults such as network anomalies, hardware overheating, and playback stuttering based on preset threshold rules; The second layer is the anomaly detection layer, which detects abnormal fluctuations in operating parameters and identifies unknown fault modes based on the statistical baseline of historical operating data.

[0009] Preferably, after the step of inputting the terminal state vector into a pre-trained diagnostic model and evaluating the terminal health status using rule matching and anomaly detection algorithms, the method further includes: Calculate the rate of change of the terminal health status in the current period compared to the terminal health status in the previous period, and record the duration of continuous abnormalities when the health status is below a preset threshold. ; in, The rate of change in terminal health. The terminal health status for the current period. The terminal health status for the previous cycle; Based on the duration of the anomaly, the inertial correction factor is calculated using the inertial correction function. in, As the inertia correction factor, The terminal health status for the current period. This is the jitter suppression coefficient. For the duration of the abnormality, This is the time decay coefficient; When the duration of the anomaly is less than a preset time threshold, the terminal state is determined based on the inertia correction factor. When the duration of the abnormality is not less than the preset time threshold, the actual fault status is determined based on the current terminal health status.

[0010] Preferably, the steps of executing the corresponding remote repair strategy according to the fault type and fault level, collecting the status data after repair, verifying the repair effect, and updating the terminal health status include: The terminal status is mapped to the repair level. The repair level includes software process restart, module-level reload, and system-level restart. The initial repair level corresponding to the sub-healthy state is software process restart, the initial repair level corresponding to the fault risk state is module-level reload, and the initial repair level corresponding to the severe fault state is system-level restart. The corresponding initial repair level is executed based on the determined terminal status. If the initial repair level fails, the repair level is upgraded to the next level until the fault is eliminated or the highest repair level is reached.

[0011] Preferably, after the steps of executing the corresponding remote repair strategy according to the fault type and fault level, collecting the repaired status data, verifying the repair effect, and updating the terminal health status, the method further includes: The number of times a repair operation is performed on the same screen terminal within a unit of time is counted, and the repair cooldown time is dynamically adjusted according to the number of counts. The cooldown time is executed according to the preset number threshold. The more repairs are performed, the longer the cooldown time is. During the cooldown time, new repair operations are prohibited.

[0012] Preferably, after the steps of executing the corresponding remote repair strategy according to the fault type and fault level, collecting the repaired status data, verifying the repair effect, and updating the terminal health status, the method further includes: When a remote repair strategy fails to execute or the fault level is determined to be a critical fault, an operation and maintenance work order is automatically generated. The operation and maintenance work order includes the fault type, fault level, a summary of the status data for the most recent period, and a record of the repair operations that have been attempted.

[0013] According to a second aspect of the embodiments of this specification, a distributed screen inspection and repair control system is provided, including a data monitoring module, a status diagnosis module, and a fault repair module, wherein... The data monitoring module is configured to collect screen device operating parameters and playback status logs in real time through a monitoring module deployed on the screen terminal, process the collected data, extract key health data, including device operating temperature, ambient light intensity, network connection status and latency, processor and memory usage, and process logs, and generate a terminal status vector. The status diagnosis module is configured to input the terminal status vector into a pre-trained diagnostic model, evaluate and calculate the terminal health status through rule matching and anomaly detection algorithms, and identify the fault type and determine the fault level based on the real-time health status of the terminal calculated by the diagnostic model. The fault repair module is configured to execute corresponding remote repair strategies based on the fault type and fault level, collect post-repair status data, verify the repair effect, and update the terminal health status.

[0014] According to a third aspect of the embodiments of this specification, a computing device is provided, including a storage device and a processor, wherein the storage device is used to store a computer program, and the processor runs the computer program to cause the computing device to perform the steps of the distributed screen inspection and repair control method described above.

[0015] According to a fourth aspect of the embodiments of this specification, a storage medium is provided that stores a computer program used in the computing device, which, when executed by a processor, implements the steps of the distributed screen inspection and repair control method.

[0016] The beneficial effects of the embodiments in this specification are as follows: This specification provides a distributed screen inspection and repair control method, system, device, and medium. The method uses a monitoring module deployed on the screen terminal to collect real-time operating parameters and playback status logs of the screen device. The collected data is processed to extract key health data, including device operating temperature, ambient light intensity, network connection status and latency, processor and memory usage, and process logs, generating a terminal state vector. This terminal state vector is then input into a pre-trained diagnostic model. Rule matching and anomaly detection algorithms are used to evaluate and calculate the terminal's health status. Based on the real-time health score calculated by the diagnostic model, fault types are identified and fault levels are determined. Corresponding remote repair strategies are then executed. This achieves real-time visual monitoring of the screen terminal's health status, automatically identifies and handles common faults, significantly reduces the frequency of manual inspections, lowers maintenance costs, and improves maintenance efficiency, providing reliable intelligent operation and maintenance support for large-scale screen systems.

[0017] The innovative aspects of the embodiments in this specification include: 1. The distributed architecture of terminal monitoring and cloud-based collaborative diagnosis adopted in this specification improves the monitoring efficiency and scalability of large-scale screen systems, which is one of the innovative points of the embodiments in this specification.

[0018] 2. The health status quantitative assessment model based on terminal monitoring data in this specification quantifies the health status reasonably. The intelligent diagnostic mechanism that combines rule matching and anomaly detection, while taking into account the ability to quickly locate known faults and discover unknown anomalies, is one of the innovative points of the embodiments in this specification.

[0019] 3. In this specification, the fault classification and repair strategy mapping mechanism refines the repair level according to the fault level, thereby improving the repair success rate. Furthermore, the automatic work order generation carries diagnostic context log information, which significantly improves the troubleshooting efficiency when manual intervention is required. This is one of the innovative points of the embodiments in this specification. Attached Figure Description

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

[0021] Figure 1 This is a flowchart illustrating a distributed screen inspection and repair control method provided in one embodiment of this specification. Figure 2 This is a schematic diagram of a distributed screen inspection and repair control system provided in one embodiment of this specification; Figure 3 This is a schematic diagram of the structure of a computing device provided in one embodiment of this specification; Figure 4 This is a schematic diagram of the structure of a storage medium provided in one embodiment of this specification. Detailed Implementation

[0022] The technical solutions in the embodiments of this specification 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.

[0023] It should be noted that the terms "comprising" and "having," and any variations thereof, in the embodiments and drawings of this specification are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0024] This specification discloses a distributed screen inspection and repair control method, system, device, and medium, which will be described in detail below.

[0025] Figure 1 This is a flowchart illustrating a distributed screen inspection and repair control method provided in one embodiment of this specification. Figure 1 As shown, a distributed screen inspection and repair control method includes: S110. The monitoring module deployed on the screen terminal collects the screen device's operating parameters and playback status logs in real time, processes the collected data, extracts key health data, including device operating temperature, ambient light intensity, network connection status and latency, processor and memory usage, and process logs, and generates a terminal status vector.

[0026] S120. Input the terminal state vector into the pre-trained diagnostic model, evaluate and calculate the terminal health status through rule matching and anomaly detection algorithms, calculate the real-time health of the terminal based on the diagnostic model, identify the fault type and determine the fault level.

[0027] In a specific embodiment, the steps of inputting the terminal state vector into a pre-trained diagnostic model, evaluating and calculating the terminal's health status through rule matching and anomaly detection algorithms, calculating the terminal's real-time health score based on the diagnostic model, identifying the fault type, and determining the fault level include: Input the terminal state vector into the pre-trained diagnostic model. in, This is the preprocessed terminal state vector. For terminal state components; A pre-trained diagnostic model uses rule matching and anomaly detection algorithms to assess the terminal's health status, resulting in the terminal's real-time health level. in, Characterizes the real-time health of the terminal. This is the normalization function for the terminal state components. These are the indicator weight parameters; The terminal's real-time health status is calculated based on the diagnostic model, and the terminal's status is obtained according to a preset range threshold, including normal status, sub-health status, fault risk status, and severe fault status.

[0028] In a specific embodiment, the diagnostic model is trained using rule matching and anomaly detection algorithms, and a two-layer diagnostic mechanism is adopted to identify fault types, including: The first layer is the rule matching layer, which identifies known faults such as network anomalies, hardware overheating, and playback stuttering based on preset threshold rules; The second layer is the anomaly detection layer, which detects abnormal fluctuations in operating parameters and identifies unknown fault modes based on the statistical baseline of historical operating data.

[0029] In a specific embodiment, after the step of inputting the terminal state vector into a pre-trained diagnostic model and evaluating the terminal health status through rule matching and anomaly detection algorithms, the method further includes: Calculate the rate of change of the terminal health status in the current period compared to the terminal health status in the previous period, and record the duration of continuous abnormalities when the health status is below a preset threshold. ; in, The rate of change in terminal health. The terminal health status for the current period. The terminal health status for the previous cycle; Based on the duration of the anomaly, the inertial correction factor is calculated using the inertial correction function. in, As the inertia correction factor, The terminal health status for the current period. This is the jitter suppression coefficient. For the duration of the abnormality, This is the time decay coefficient; When the duration of the anomaly is less than a preset time threshold, the terminal state is determined based on the inertia correction factor. When the duration of the abnormality is not less than the preset time threshold, the actual fault status is determined based on the current terminal health status.

[0030] A health inertia suppression correction mechanism is introduced. Based on the duration of continuous abnormalities where the health score is below a preset threshold, the inertia correction factor is dynamically adjusted to suppress misjudgments of health status caused by instantaneous environmental fluctuations.

[0031] When indicators such as network latency, CPU usage, and temperature experience short-term spikes, the health score will instantly drop into a "risk state," potentially triggering remote repairs or generating work orders. When the anomaly duration is very short, the inertial correction factor has a strong suppressive effect, preventing false triggers; as the anomaly duration increases, the suppressive factor gradually weakens, and the system enters a true fault judgment phase. This prevents momentary jitter from triggering false repairs, reduces the number of invalid remote restarts, improves the stability of health assessments, and enhances system reliability.

[0032] S130. Based on the fault type and fault level, execute the corresponding remote repair strategy, collect the status data after repair, verify the repair effect, and update the terminal health status.

[0033] In a specific embodiment, the steps of executing the corresponding remote repair strategy according to the fault type and fault level, collecting the repaired status data, verifying the repair effect, and updating the terminal health status include: The terminal status is mapped to the repair level. The repair level includes software process restart, module-level reload, and system-level restart. The initial repair level corresponding to the sub-healthy state is software process restart, the initial repair level corresponding to the fault risk state is module-level reload, and the initial repair level corresponding to the severe fault state is system-level restart. The corresponding initial repair level is executed based on the determined terminal status. If the initial repair level fails, the repair level is upgraded to the next level until the fault is eliminated or the highest repair level is reached.

[0034] Remote repair performs corresponding operations based on the fault type, including but not limited to: restarting the playback process, reconnecting the network module, rolling back parameter configurations, soft restarting the device, and triggering the terminal self-test process. After the repair operation is executed, the terminal status is re-collected to verify the repair effect.

[0035] Selecting the appropriate repair level based on the severity of the fault, rather than directly performing the highest-intensity repair operation, is beneficial for maintaining system stability. To avoid frequent repeated repairs, the embodiments in this specification further introduce a repair cooling mechanism.

[0036] In a specific embodiment, after the steps of executing the corresponding remote repair strategy according to the fault type and fault level, collecting the repaired status data, verifying the repair effect, and updating the terminal health status, the method further includes: The number of repair operations performed on the same screen terminal within a unit of time is counted, and the repair cooldown time is dynamically adjusted according to the number of counts. The cooldown time is executed according to the preset number threshold. The more repairs are performed, the longer the cooldown time is. During the cooldown time, new repair operations are prohibited to avoid excessive repair actions, prevent "repair itself from becoming a source of failure", extend the life of the equipment, and further improve the stability of the system.

[0037] In a specific embodiment, after the steps of executing the corresponding remote repair strategy according to the fault type and fault level, collecting the repaired status data, verifying the repair effect, and updating the terminal health status, the method further includes: When a remote repair strategy fails or a fault is determined to be a critical fault, an operation and maintenance work order is automatically generated. The operation and maintenance work order includes the fault type, fault level, a summary of the status data for the most recent period, and a record of the repair operations that have been attempted, thereby significantly reducing manual troubleshooting time.

[0038] Figure 2 This is a schematic diagram of a distributed screen inspection and repair control system provided as an embodiment of this specification. Figure 2 As shown, a distributed screen inspection and repair control system 200 includes a data monitoring module 210, a status diagnosis module 220, and a fault repair module 230, wherein... The data monitoring module 210 is configured to collect screen device operating parameters and playback status logs in real time through a monitoring module deployed on the screen terminal, process the collected data, extract key health data, including device operating temperature, ambient light intensity, network connection status and latency, processor and memory usage, and process logs, and generate a terminal status vector.

[0039] The status diagnosis module 220 is configured to input the terminal status vector into a pre-trained diagnostic model, evaluate and calculate the terminal health status through rule matching and anomaly detection algorithms, and identify the fault type and determine the fault level based on the real-time health status of the terminal calculated by the diagnostic model.

[0040] The fault repair module 230 is configured to execute the corresponding remote repair strategy according to the fault type and fault level, collect the status data after repair, verify the repair effect and update the terminal health status.

[0041] Figure 3 This is a schematic diagram of the structure of a computing device provided in one embodiment of this specification. Figure 3 As shown, a computing device 300 includes a storage device 310 and a processor 320. The storage device 310 stores a computer program, and the processor 320 runs the computer program to enable the computing device 300 to perform the steps of the distributed screen inspection and repair control method described above.

[0042] Figure 4 This is a schematic diagram of the structure of a storage medium provided in one embodiment of this specification. For example... Figure 4As shown, a storage medium 400 stores a computer program 410 used in the computing device, which, when executed by a processor, implements the steps of the distributed screen inspection and repair control method.

[0043] In summary, the embodiments of this specification provide a distributed screen inspection and repair control method, system, device, and medium. This method, through an architecture of terminal monitoring and cloud-based collaborative diagnosis, enables real-time monitoring, health assessment, intelligent fault diagnosis, and automatic remote repair of the operating status of outdoor screens, thereby improving the overall stability of screen operation, reducing manual maintenance workload, and enhancing the intelligence level of screen inspection.

[0044] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of one embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing the present invention.

[0045] Those skilled in the art will understand that the modules in the apparatus of the embodiments can be distributed in the apparatus of the embodiments as described in the embodiments, or they can be located in one or more devices different from this embodiment with corresponding changes. The modules of the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0046] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A distributed screen inspection and repair control method, characterized in that, include: The monitoring module deployed on the screen terminal collects the screen device's operating parameters and playback status logs in real time. The collected data is processed to extract key health data, including device operating temperature, ambient light intensity, network connection status and latency, processor and memory usage, and process logs, and a terminal status vector is generated. The terminal state vector is input into a pre-trained diagnostic model. The terminal health status is evaluated and calculated through rule matching and anomaly detection algorithms. The real-time health status of the terminal is calculated based on the diagnostic model, and the fault type and fault level are identified. Based on the fault type and fault level, execute the corresponding remote repair strategy, collect the status data after repair, verify the repair effect, and update the terminal health status.

2. The method according to claim 1, characterized in that, The steps of inputting the terminal state vector into a pre-trained diagnostic model, evaluating the terminal's health status through rule matching and anomaly detection algorithms, calculating the terminal's real-time health score based on the diagnostic model, identifying fault types, and determining fault levels include: Input the terminal state vector into the pre-trained diagnostic model. in, This is the preprocessed terminal state vector. For terminal state components; A pre-trained diagnostic model uses rule matching and anomaly detection algorithms to assess the terminal's health status, resulting in the terminal's real-time health level. in, Characterizes the real-time health of the terminal. This is the normalization function for the terminal state components. These are the indicator weight parameters; The terminal's real-time health status is calculated based on the diagnostic model, and the terminal's status is obtained according to a preset range threshold, including normal status, sub-health status, fault risk status, and severe fault status.

3. The method according to claim 2, characterized in that, The diagnostic model is trained using rule matching and anomaly detection algorithms. It employs a two-layer diagnostic mechanism to identify fault types, including: The first layer is the rule matching layer, which identifies known faults such as network anomalies, hardware overheating, and playback stuttering based on preset threshold rules; The second layer is the anomaly detection layer, which detects abnormal fluctuations in operating parameters and identifies unknown fault modes based on the statistical baseline of historical operating data.

4. The method according to claim 2, characterized in that, After the steps of inputting the terminal state vector into a pre-trained diagnostic model and evaluating the terminal health status using rule matching and anomaly detection algorithms, the method further includes: Calculate the rate of change of the terminal health status in the current period compared to the terminal health status in the previous period, and record the duration of continuous abnormalities when the health status is below a preset threshold. ; in, The rate of change in terminal health. The terminal health status for the current period. The terminal health status for the previous cycle; Based on the duration of the anomaly, the inertial correction factor is calculated using the inertial correction function. in, As the inertia correction factor, The terminal health status for the current period. This is the jitter suppression coefficient. For the duration of the abnormality, This is the time decay coefficient; When the duration of the anomaly is less than a preset time threshold, the terminal state is determined based on the inertia correction factor. When the duration of the abnormality is not less than the preset time threshold, the actual fault status is determined based on the current terminal health status.

5. The method according to claim 2, characterized in that, The steps described above, including executing corresponding remote repair strategies based on fault type and fault level, collecting post-repair status data, verifying repair effectiveness, and updating terminal health status, include: The terminal status is mapped to the repair level. The repair level includes software process restart, module-level reload, and system-level restart. The initial repair level corresponding to the sub-healthy state is software process restart, the initial repair level corresponding to the fault risk state is module-level reload, and the initial repair level corresponding to the severe fault state is system-level restart. The corresponding initial repair level is executed based on the determined terminal status. If the initial repair level fails, the repair level is upgraded to the next level until the fault is eliminated or the highest repair level is reached.

6. The method according to claim 1, characterized in that, After the steps of executing the corresponding remote repair strategy according to the fault type and fault level, collecting the status data after repair, verifying the repair effect, and updating the terminal health status, the method further includes: The number of times a repair operation is performed on the same screen terminal within a unit of time is counted, and the repair cooldown time is dynamically adjusted according to the number of counts. The cooldown time is executed according to the preset number threshold. The more repairs are performed, the longer the cooldown time is. During the cooldown time, new repair operations are prohibited.

7. The method according to claim 1, characterized in that, After the steps of executing the corresponding remote repair strategy according to the fault type and fault level, collecting the status data after repair, verifying the repair effect, and updating the terminal health status, the method further includes: When a remote repair strategy fails to execute or the fault level is determined to be a critical fault, an operation and maintenance work order is automatically generated. The operation and maintenance work order includes the fault type, fault level, a summary of the status data for the most recent period, and a record of the repair operations that have been attempted.

8. A distributed screen inspection and repair control system, characterized in that, It includes a data monitoring module, a status diagnosis module, and a fault repair module, among which... The data monitoring module is configured to collect screen device operating parameters and playback status logs in real time through a monitoring module deployed on the screen terminal, process the collected data, extract key health data, including device operating temperature, ambient light intensity, network connection status and latency, processor and memory usage, and process logs, and generate a terminal status vector. The status diagnosis module is configured to input the terminal status vector into a pre-trained diagnostic model, evaluate and calculate the terminal health status through rule matching and anomaly detection algorithms, and identify the fault type and determine the fault level based on the real-time health status of the terminal calculated by the diagnostic model. The fault repair module is configured to execute corresponding remote repair strategies based on the fault type and fault level, collect post-repair status data, verify the repair effect, and update the terminal health status.

9. A computing device, characterized in that, The device includes a storage device and a processor, the storage device being used to store a computer program, and the processor running the computer program to cause the computing device to perform the steps of the method according to any one of claims 1-7.

10. A storage medium, characterized in that, It stores a computer program used in the computing device of claim 9, which, when executed by a processor, implements the steps of the method of any one of claims 1-7.

Images