Dynamic Dual-Threshold Health Monitoring Method and Media for Large-Scale RPA Clusters

Abstract

This invention relates to a dynamic dual-threshold health monitoring method and medium for large-scale RPA clusters, belonging to the field of RPA health monitoring technology. The method includes: obtaining the application system type and runtime of the current RPA task; obtaining a preset number of historical RPA task data closest to the current RPA task time, including task runtime, task duration, and data volume; calculating a dynamic baseline value and dynamic fluctuation intensity based on the task runtime and duration of all historical RPA tasks; calculating a data volume adjustment coefficient based on the data volume processed by the current RPA task and the data volume processed by historical RPA tasks; thereby calculating a dynamic dual threshold including a first runtime threshold and a second runtime threshold for health monitoring of the current RPA task. This solution can be applied to large-scale RPA clusters, reducing false alarm and false negative rates, and is better suited for hospital operations.

Description

Technical Field

[0001] This invention relates to the field of RPA health monitoring technology, specifically to a dynamic dual-threshold health monitoring method and medium for large-scale RPA clusters. Background Technology

[0002] With increasing digitalization, especially in hospital operations, more and more repetitive tasks are being handled by RPA robots, such as registration verification, prescription processing, lab report transmission, image downloading, medical record archiving, and medical insurance reconciliation. Large hospitals or medical groups typically operate hundreds or even thousands of RPA robots simultaneously, and these robots are assigned tasks that connect to different systems, interfaces, and time periods, resulting in significant differences in their execution time.

[0003] Current RPA operation monitoring mainly includes the following categories:

[0004] 1. Fixed timeout threshold monitoring: Set a uniform time limit for each type of task, and trigger an alarm if the timeout is exceeded.

[0005] 2. Heartbeat or process liveness monitoring: Only determines whether the RPA process is still running.

[0006] 3. Manual on-duty inspection: Maintenance personnel log in to the platform regularly to check the task status.

[0007] 4. Static alarms based on historical averages: using fixed historical statistical values ​​as the judgment criteria.

[0008] However, the aforementioned solutions suffer from significant performance differences among various healthcare systems, making it impossible for a single threshold to simultaneously adapt to multiple business scenarios such as HIS, LIS, EMR, and PACS. Furthermore, hospital operations exhibit substantial time-of-day fluctuations, such as peak outpatient hours, nighttime maintenance, and month-end reconciliation, making static thresholds prone to false alarms and missed alarms. For manual inspections in a thousand-level RPA cluster scenario, the inspection cost is extremely high, and the time required to detect anomalies is prolonged, failing to meet the continuity requirements of core hospital operations. Summary of the Invention

[0009] The technical problem to be solved by this application is to provide a dynamic dual-threshold health monitoring method and medium for large-scale RPA clusters, which has the characteristics of being able to be used for large-scale RPA clusters, reducing false alarm and false alarm rates, and being better suited to hospital operations.

[0010] One embodiment provides a dynamic dual-threshold health monitoring method for large-scale RPA clusters, comprising:

[0011] Get the application system type and runtime of the current RPA task;

[0012] Obtain a preset number of historical RPA task data that are closest to the current RPA task time, based on the application system type and runtime segment. For any historical RPA task data, the data includes the task execution time, task runtime, and amount of data processed. Among these, any historical RPA task data obtained represents data from tasks that have completed normally.

[0013] Calculate dynamic baseline values ​​and dynamic fluctuation intensity based on the task execution time and task duration of all historical RPA tasks;

[0014] Calculate the data volume adjustment coefficient based on the current data volume of RPA tasks and the historical data volume of RPA tasks;

[0015] Based on the dynamic benchmark value, dynamic fluctuation intensity and data volume adjustment coefficient, a dynamic dual threshold is calculated. The dynamic dual threshold includes a first running time threshold and a second running time threshold, wherein the first running time threshold is greater than the second running time threshold.

[0016] Based on the first runtime threshold and the second runtime threshold, perform health monitoring on the current RPA task.

[0017] Secondly, in one embodiment, a computer-readable storage medium is provided, wherein a program is stored in the medium, the program being loaded by a processor and executed as described above for the dynamic dual-threshold health monitoring method for large-scale RPA clusters.

[0018] The beneficial effects of this invention are:

[0019] By using historical RPA task data from the same application system type and runtime to derive the dual thresholds for health monitoring, the system can address false positives and false negatives caused by varying performance and runtime conditions across different medical systems, thereby reducing these rates. Since the acquired historical RPA task data represents a preset number of data points most recent to the current RPA task, the resulting dual thresholds are dynamic, better adapting to the current business scenario and further reducing false positives and false negatives. The calculated dynamic dual thresholds include a first runtime threshold and a second runtime threshold, with the first runtime threshold being greater than the second. This allows the system to monitor not only "timeout anomalies" but also "overly rapid anomalies," further reducing false negatives. Furthermore, by calculating a data volume adjustment coefficient based on the current and historical RPA task data volumes to determine the dynamic dual thresholds, the system further addresses the impact of the RPA task's data volume itself on the dynamic dual thresholds, further reducing false positives and false negatives. Attached Figure Description

[0020] Figure 1This is a schematic diagram of a dynamic dual-threshold health monitoring method for large-scale RPA clusters according to an embodiment of this application;

[0021] Figure 2 This application Figure 1 A schematic diagram of the method flow for one embodiment of step S30. Detailed Implementation

[0022] The present invention will now be described in further detail with reference to specific embodiments and accompanying drawings. Similar elements in different embodiments are referred to by associated similar element reference numerals. In the following embodiments, many details are described to facilitate a better understanding of this application. However, those skilled in the art will readily recognize that some features may be omitted in different situations, or may be replaced by other elements, materials, or methods. In some cases, certain operations related to this application are not shown or described in the specification. This is to avoid obscuring the core parts of this application with excessive description. For those skilled in the art, detailed description of these related operations is not necessary; they can fully understand the related operations based on the description in the specification and general technical knowledge in the art.

[0023] Furthermore, the features, operations, or characteristics described in the specification can be combined in any suitable manner to form various embodiments. At the same time, the steps or actions in the method description can be rearranged or adjusted in a manner obvious to those skilled in the art. Therefore, the various orders in the specification and drawings are only for the clear description of a particular embodiment and do not imply a necessary order, unless otherwise stated that a particular order must be followed.

[0024] The serial numbers assigned to components in this document, such as "first" and "second," are used only to distinguish the described objects and have no sequential or technical meaning. The terms "connection" and "linkage" used in this application, unless otherwise specified, include both direct and indirect connections (linkages).

[0025] The applicant's research revealed that for monitoring fixed timeout thresholds, a uniform time limit is typically set for each type of task, triggering an alarm upon timeout. However, this approach suffers from significant performance differences across various medical systems, making it impossible to apply the same threshold to multiple business scenarios simultaneously. Setting a separate timeout threshold for each RPA instance is cumbersome and resource-intensive, especially for large-scale RPA clusters. The applicant also discovered that RPA may exhibit excessively rapid execution anomalies, such as clicking before the page has fully loaded, the process continuing despite an empty API response, or the process rapidly terminating due to reading cached old data. While these anomalies have short execution times, they represent failures or potential problems. However, current RPA monitoring primarily focuses on "timeout anomalies," making it difficult to identify "excessively rapid anomalies."

[0026] In view of this, this application provides a dynamic dual-threshold health monitoring method and medium for large-scale RPA clusters. Since the dual thresholds for health monitoring are obtained based on historical RPA task data of the same application system type and runtime, it can solve the problems of false positives and false negatives caused by poor performance of different medical systems and different runtimes, thereby reducing the false positive and false negative rates. Because the acquired historical RPA task data is a preset number of data points closest to the current RPA task time, the resulting dual thresholds are dynamic values, which can better adapt to the current business scenario, further reducing the false positive and false negative rates. Since the calculated dynamic dual thresholds include a first runtime threshold and a second runtime threshold, and the first runtime threshold is greater than the second runtime threshold, it can not only focus on "timeout anomalies" but also identify "overly fast anomalies," thereby further reducing the false negative rate. Furthermore, since the data volume adjustment coefficient is calculated based on the data volume processed by the current RPA task and the data volume processed by historical RPA tasks to calculate the dynamic dual thresholds, it further focuses on the impact of the RPA task's data volume itself on the dynamic dual thresholds, further reducing the false positive and false negative rates. The following is a detailed description of this solution.

[0027] One embodiment of this application provides a dynamic dual-threshold health monitoring method for large-scale RPA clusters. Please refer to [link / reference]. Figure 1 ,include:

[0028] Step S10: Obtain the application system type and runtime segment of the current RPA task.

[0029] In this application, the current RPA task is a large-scale RPA cluster comprising multiple RPA robots. Typically, in large hospitals or medical groups, hundreds or even thousands of RPA robots run simultaneously. If there is only one RPA task, the application system type and runtime of that single RPA task are obtained. If there are multiple RPA tasks, the application system type and runtime of all multiple RPA tasks are obtained.

[0030] The application system types typically include various business scenarios such as HIS, LIS, EMR, and PACS. As for runtime periods, as one embodiment of this application, these can include peak outpatient hours, nighttime maintenance hours, and month-end reconciliation hours, which can be configured according to needs by those skilled in the art.

[0031] Step S20: Obtain a preset number of historical RPA task data that are closest to the current RPA task time, based on the application system type and runtime segment.

[0032] For any historical RPA task data, the data includes task execution time, task runtime, and amount of data processed. Among these, any historical RPA task data obtained must be data from tasks that ended normally. That is, historical RPA task data that ended abnormally and historical RPA task data that are obviously distorted (such as data from manual interruptions, test samples, or samples during maintenance) need to be excluded.

[0033] As one embodiment of this application, historical RPA task data is obtained from a historical RPA task database. This database records previously completed RPA task data, including RPA tasks that ended normally and those that ended abnormally. Each recorded RPA task includes its start time, end time, data processing volume, task runtime identifier, and task execution result type (normal or abnormal). Therefore, the runtime of any historical RPA task can be obtained from the historical RPA task database, as well as a preset number of historical RPA tasks closest to the current RPA task. Furthermore, the obtained historical RPA task data belongs to the same application system type and runtime segment as the current health monitoring RPA task. This addresses the issues of false positives and false negatives caused by differences in performance and runtime segments between different medical systems, thereby reducing the false positive and false negative rates.

[0034] In some embodiments, the preset quantity mentioned above can be 20, 50, 100, etc., and can be set according to specific needs. The acquired task execution time can be either the start time or the end time of a historical RPA task, and can be set according to specific needs. Based on the task execution time, the order in which the acquired historical RPA task data occurred can be determined, thereby distinguishing the degree of influence on the current RPA task execution monitoring reference standard.

[0035] Step S30: Calculate the dynamic baseline value and dynamic fluctuation intensity based on the task execution time and task runtime of all historical RPA tasks.

[0036] In one embodiment, please refer to Figure 2 Step S30 may include:

[0037] Step S301: Calculate a dynamic baseline value based on the task execution time and task runtime of all historical RPA tasks.

[0038] In one embodiment, step S301 can be represented as:

[0039]

[0040]

[0041] in, Indicates the dynamic baseline value. This represents the weight of any historical RPA task i. i represents the runtime of any historical RPA task i, 1≤i≤N, where N represents the total number of historical RPA tasks; for any historical RPA task, the earlier its runtime, the smaller the value of i. Represents the time decay coefficient, 0 < <1. In one specific embodiment, You can take 0.5.

[0042] Step S302: Calculate the dynamic fluctuation intensity based on the dynamic baseline value and the task runtime.

[0043] Dynamic fluctuation intensity is used to characterize the degree of normal fluctuation in the recent operation of the current RPA task.

[0044] In one embodiment, step S302 can be represented as:

[0045]

[0046] in, Indicates the intensity of dynamic fluctuations.

[0047] Step S40: Calculate the data volume adjustment coefficient based on the data volume processed by the current RPA task and the data volume processed by the historical RPA tasks.

[0048] In one embodiment, step S40 can be represented as:

[0049]

[0050] in, This represents the data volume adjustment coefficient. This indicates the amount of data being processed by the current RPA task; This represents the amount of data processed by historical RPA tasks, which is the average or median of the amount of data processed by each historical RPA task.

[0051] The amount of data processed is used to characterize the scale of data processed by an RPA task. A larger amount of data requires more processing time, meaning a longer task runtime. In this embodiment, based on a data volume adjustment coefficient, the impact of the RPA task's data volume itself on the dynamic dual thresholds is further considered, thereby further reducing false positives and false negatives.

[0052] Step S50: Calculate the dynamic dual thresholds based on the dynamic baseline value, dynamic fluctuation intensity, and data volume adjustment coefficient. The dynamic dual thresholds include a first runtime threshold (upper threshold) and a second runtime threshold (lower threshold), with the first runtime threshold being greater than the second runtime threshold.

[0053] In one embodiment, step S50 can be represented as:

[0054]

[0055]

[0056] in, This represents the first runtime threshold. This represents the second runtime threshold. represents the data volume adjustment coefficient; k represents the preset confidence coefficient, which is used to control the coverage width of the dynamic dual threshold interval over the historical RPA task execution time fluctuations; This represents the preset minimum absolute duration threshold.

[0057] For the confidence coefficient k, the larger the value, the wider the threshold range, the lower the monitoring sensitivity, the fewer false alarms but the increased risk of missed alarms, and vice versa. In actual deployment, the value can be selected based on the business criticality of the task type, the degree of historical fluctuation, and the tolerance of the operation and maintenance manpower. The optimal range can be between 2 and 3.

[0058] The minimum absolute duration threshold is used to prevent the second runtime threshold from being too small and losing its engineering significance. In one embodiment, it is set as a preset ratio based on the lower limit of the normal execution time of the RPA task of the application system type or the dynamic baseline value. For example, 0.3 times the dynamic baseline value can be used as the minimum absolute duration threshold.

[0059] By setting a first runtime threshold, RPA tasks that time out can be identified; by setting a second runtime threshold, RPA tasks that execute too quickly can be identified.

[0060] Step S60: Perform health monitoring on the current RPA task based on the first runtime threshold and the second runtime threshold.

[0061] As one embodiment of this application, the health status of the current RPA task can be graded, including: when When, it is judged as too fast anomaly; when When, it is determined to be a healthy state; when At that time, it was determined to be a sub-healthy state; when At that time, it was determined to be a severely abnormal state. Among them, This indicates the runtime of the current RPA task. Based on this, step S60 may include:

[0062] Determine the relationship between the current RPA task execution time and the first and second runtime thresholds. If the current RPA task execution time is less than the second runtime threshold, output a judgment result indicating that the current RPA task is too fast and abnormal. If the current RPA task execution time is greater than the first runtime threshold but less than or equal to twice the first runtime threshold, output a judgment result indicating that the current RPA task is in a sub-healthy state. If the current RPA task execution time is more than twice the second runtime threshold, output a judgment result indicating that the current RPA task is in a severely abnormal state.

[0063] The result of the health status judgment can be output or not. As one embodiment of this application, if the current RPA task execution time is greater than or equal to the second runtime threshold and less than or equal to the first runtime threshold, then the judgment result that the current RPA task is in a healthy state is output.

[0064] Excessive speed exceptions may correspond to issues such as page not loading completely, API returning null values, process skipping, and rapid exit after element recognition failure; severe exceptions may correspond to issues such as system lag, API timeout, network congestion, and backend service failure.

[0065] In one embodiment, the method further includes: if the judgment result is an excessively fast abnormality or a severe abnormality, then an alarm is issued, and it is confirmed whether there is a false alarm. If so, then the first runtime threshold is increased and the second runtime threshold is decreased, thereby widening the range of the dual thresholds to reduce the false alarm rate.

[0066] In some embodiments, increasing the first runtime threshold and decreasing the second runtime threshold can be achieved by directly increasing the first runtime threshold and decreasing the second runtime threshold, such as by changing it according to a preset ratio. Alternatively, it can be achieved by modifying the confidence coefficient k and / or the data volume adjustment coefficient. To achieve this.

[0067] In one embodiment, the method further includes determining whether there is a missed alarm; if so, decreasing a first runtime threshold and increasing a second runtime threshold to narrow the range of the two thresholds and reduce the missed alarm rate.

[0068] In some embodiments, reducing the first runtime threshold and increasing the second runtime threshold can be achieved by directly decreasing the first runtime threshold and increasing the second runtime threshold, such as by changing it according to a preset ratio. Alternatively, it can be achieved by modifying the confidence coefficient k and / or the data volume adjustment coefficient. To achieve this.

[0069] Taking the monitoring of RPA tasks in the drug inventory synchronization process as an example, a hospital deployed 50 RPA robots for drug inventory synchronization, and the business system was HIS. After the system analyzed the 50 most recent valid execution records, the following results were obtained: =11.2 seconds, =2.5 seconds, =1, k=2, =0.3 Then we can get: =16.2 seconds, =6.2 seconds. If the actual runtime of an RPA task is 4.5 seconds, it can be determined as an excessively fast exception. Upon inspection, it was found that the page had not yet finished rendering, but the robot had clicked "next" in advance, which is a hidden failure caused by incomplete page loading.

[0070] One embodiment of this application provides a computer-readable storage medium storing a program, the stored program including methods that can be loaded by a processor and processed in any of the above embodiments.

[0071] Those skilled in the art will understand that all or part of the functions of the various methods in the above embodiments can be implemented by hardware or by computer programs. When all or part of the functions in the above embodiments are implemented by computer programs, the program can be stored in a computer-readable storage medium, which may include: read-only memory, random access memory, disk, optical disk, hard disk, etc., and the program is executed by a computer to achieve the above functions. For example, the program can be stored in the memory of a device, and when the program in the memory is executed by the processor, all or part of the above functions can be achieved. In addition, when all or part of the functions in the above embodiments are implemented by computer programs, the program can also be stored in a server, another computer, disk, optical disk, flash drive, or external hard drive, etc., and can be downloaded or copied to the memory of a local device, or the system of the local device can be updated. When the program in the memory is executed by the processor, all or part of the functions in the above embodiments can be achieved.

[0072] The above examples illustrate the present invention only to aid in understanding it and are not intended to limit the scope of the invention. Those skilled in the art can make various simple deductions, modifications, or substitutions based on the principles of this invention.

Claims

1. A dynamic dual-threshold health monitoring method for large-scale RPA clusters, characterized in that, include: Get the application system type and runtime of the current RPA task; Obtain a preset number of historical RPA task data that are closest to the current RPA task time, based on the application system type and runtime segment. For any historical RPA task data, the data includes the task execution time, task runtime, and amount of data processed. Among these, any historical RPA task data obtained represents data from tasks that have completed normally. Calculate dynamic baseline values ​​and dynamic fluctuation intensity based on the task execution time and task duration of all historical RPA tasks; Calculate the data volume adjustment coefficient based on the current data volume of RPA tasks and the historical data volume of RPA tasks; Based on the dynamic benchmark value, dynamic fluctuation intensity and data volume adjustment coefficient, a dynamic dual threshold is calculated. The dynamic dual threshold includes a first running time threshold and a second running time threshold, wherein the first running time threshold is greater than the second running time threshold. Based on the first runtime threshold and the second runtime threshold, perform health monitoring on the current RPA task.

2. The dynamic dual-threshold health monitoring method for large-scale RPA clusters as described in claim 1, characterized in that, The calculation of dynamic baseline values ​​and dynamic fluctuation intensity based on the task execution time and task runtime of all historical RPA tasks includes: Calculate dynamic baseline values ​​based on the task execution time and task runtime of all historical RPA tasks; The dynamic fluctuation intensity is calculated based on the dynamic baseline value and the task runtime.

3. The dynamic dual-threshold health monitoring method for large-scale RPA clusters as described in claim 2, characterized in that, The calculation of dynamic baseline values ​​based on the task execution time and task runtime of all historical RPA tasks includes: in, Indicates the dynamic baseline value. This represents the weight of any historical RPA task i. i represents the runtime of any historical RPA task i, 1≤i≤N, where N represents the total number of historical RPA tasks; for any historical RPA task, the earlier its runtime, the smaller the value of i. Represents the time decay coefficient, 0 < <1; The calculation of dynamic fluctuation intensity based on the dynamic benchmark value and task runtime includes: in, Indicates the intensity of dynamic fluctuations.

4. The dynamic dual-threshold health monitoring method for large-scale RPA clusters as described in claim 1, characterized in that, The calculation of the data volume adjustment coefficient based on the data volume processed by the current RPA task and the data volume processed by historical RPA tasks includes: in, This represents the data volume adjustment coefficient. This indicates the amount of data being processed by the current RPA task; This represents the amount of data processed by historical RPA tasks, which is the average or median of the amount of data processed by each historical RPA task.

5. The dynamic dual-threshold health monitoring method for large-scale RPA clusters as described in claim 3, characterized in that, The calculation of the dynamic dual threshold based on the dynamic benchmark value, dynamic fluctuation intensity, and data volume adjustment coefficient includes: in, This represents the first runtime threshold. This represents the second runtime threshold. represents the data volume adjustment coefficient; k represents the preset confidence coefficient, which is used to control the coverage width of the dynamic dual threshold interval over the historical RPA task execution time fluctuations; This represents the preset minimum absolute duration threshold.

6. The dynamic dual-threshold health monitoring method for large-scale RPA clusters as described in claim 5, characterized in that, The minimum absolute duration threshold is set as a preset ratio based on the lower limit of the normal execution time of RPA tasks of the application system type or the dynamic benchmark value.

7. The dynamic dual-threshold health monitoring method for large-scale RPA clusters as described in claim 1, characterized in that, The health monitoring of the current RPA task based on the first runtime threshold and the second runtime threshold includes: Determine the relationship between the current RPA task execution time and the first and second runtime thresholds. If the current RPA task execution time is less than the second runtime threshold, output a judgment result indicating that the current RPA task is too fast and abnormal. If the current RPA task execution time is greater than the first runtime threshold but less than or equal to twice the first runtime threshold, output a judgment result indicating that the current RPA task is in a sub-healthy state. If the current RPA task execution time is more than twice the second runtime threshold, output a judgment result indicating that the current RPA task is in a severely abnormal state.

8. The dynamic dual-threshold health monitoring method for large-scale RPA clusters as described in claim 7, characterized in that, The method further includes: if the judgment result is an excessively fast abnormality or a severe abnormality, then an alarm is issued, and it is confirmed whether the alarm is a false alarm. If so, the first runtime threshold is increased and the second runtime threshold is decreased.

9. The dynamic dual-threshold health monitoring method for large-scale RPA clusters as described in claim 7 or 8, characterized in that, The method further includes determining whether there are any missed alarms, and if so, decreasing the first runtime threshold and increasing the second runtime threshold.

10. A computer-readable storage medium, characterized in that, The medium stores a program that can be loaded and executed by a processor as described in any one of claims 1 to 9: a dynamic dual-threshold health monitoring method for large-scale RPA clusters.

Images