Abnormal handling methods, equipment, media and products of medical testing platforms

CN122575663APending Publication Date: 2026-08-14SHANGHAI YUEMI INFORMATION TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-05-18
Publication Date
2026-08-14

AI Technical Summary

Technical Problem

[0005]本申请提供了一种医疗检测平台的异常处置方法、设备、介质及产品,以解决现有技术中医疗流水线在处理局部异常时,因盲目截停导致轨道拥堵和效率低下的技术问题

Benefits of technology

1、通过采用上述技术方案,接收局部异常信号并提取异常类型标识与当前检测仪器,在异常处置代价数据库中匹配目标处置剧本及目标标准耗时时长,使系统能准确量化局部故障的恢复代价。进而计算目标检测样本在第一检测路径各第一仪器节点上的偏移时间区间,并检测其与后续检测样本在第二检测路径各第二仪器节点上的预设占用时间区间是否存在重叠。若重叠,则基于当前载具位置确定上游轨道挡停机构,生成包含目标标准耗时时长的协同处置剧本,驱动目标载具恢复并对后续载具增加等量延迟。该过程将异常恢复耗时与全线调度时空状态结合,实现了对潜在冲突载具的精准拦截与定时释放,避免了盲目且无限期的物理隔离造成的轨道拥堵,维持了流水线整体物流节拍的动态平衡。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122575663A_ABST
    Figure CN122575663A_ABST
Patent Text Reader

Abstract

This application provides an anomaly handling method, equipment, medium, and product for a medical testing platform, relating to the field of medical testing technology. The method includes: receiving a local anomaly signal; matching a target handling script and a target standard time duration in a database; calculating the offset time interval of the target test sample and detecting whether it overlaps with the preset time interval of subsequent test samples; if overlap exists, determining an upstream track stopping mechanism based on the current vehicle position of the subsequent test sample, and generating a collaborative handling script; driving the target vehicle to perform anomaly recovery according to the target handling script, and driving the upstream track stopping mechanism according to the collaborative handling script to add a delay equal to the standard time duration to subsequent vehicles. This solves the problem of track congestion and low efficiency caused by blindly stopping vehicles when handling local anomalies in medical pipelines.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of medical testing technology, specifically to a method, equipment, medium, and product for handling anomalies in a medical testing platform. Background Technology

[0002] Automated medical testing pipelines are widely used in modern testing centers. They use complex transport tracks to schedule massive sample carriers, allowing them to flow at high speed between different types of testing instruments to complete various medical tests, thereby significantly improving the efficiency of large-scale sample processing.

[0003] In assembly line operation, local anomalies such as mechanical jams often occur. Existing technologies typically employ a hard isolation strategy based on area status: when a certain instrument or track node malfunctions, the main control system immediately marks the area where that node is located as locked. For subsequent vehicles, the system monitors their position through track sensors. Once it detects that a subsequent vehicle is about to enter the locked fault area, it directly triggers a mechanical baffle at the area boundary to stop it in place until the fault is completely resolved and the area is unlocked, at which point the intercepted vehicles are released uniformly.

[0004] As medical testing demands increasingly higher sample turnover and overall throughput, pipeline topologies are becoming more complex and intertwined. Under the aforementioned passive, rigid isolation strategy, indiscriminate boundary interception leads to a rapid accumulation of subsequent vehicles outside the fault zone, causing severe physical congestion on the tracks. Simultaneously, this indefinite waiting severely disrupts the overall logistics rhythm, causing some time-sensitive samples to experience reagent reaction timeouts due to prolonged track dwell, ultimately resulting in a significant drop in the overall pipeline's operational efficiency or even partial paralysis. Summary of the Invention

[0005] This application provides a method, equipment, medium, and product for handling anomalies in a medical testing platform, in order to solve the technical problems of track congestion and low efficiency caused by blindly stopping medical pipelines when handling local anomalies in the prior art.

[0006] Firstly, this application provides a method for handling anomalies in a medical testing platform, including: Receive local anomaly signals reported by instrument nodes of automated production line equipment, parse the anomaly type identifier from the local anomaly signals, and find the current detection instrument of the target vehicle corresponding to the local anomaly signal; Based on the anomaly type identifier and the current detection instrument in the preset anomaly handling cost database, the target handling script for eliminating the local fault corresponding to the local anomaly signal and the target standard time consumption corresponding to the target handling script are matched and extracted; wherein, the anomaly handling cost database is a data table that records the handling scripts and the standard time consumption corresponding to various mechanical anomalies; Based on the target standard consumption time, calculate the offset time interval of the target detection sample on each of the first instrument nodes of the first detection path after the target treatment script; Detect whether each offset time interval overlaps with the preset occupied time interval of each subsequent detection sample at each second instrument node in the second detection path; If there is overlap, the upstream track blocking mechanism for physical interception is determined based on the current vehicle position corresponding to the subsequent detection sample, and a collaborative handling script containing the target standard consumption time is generated based on the upstream track blocking mechanism. The target vehicle is driven to perform anomaly recovery according to the target handling script, and the upstream track stopping mechanism is driven according to the collaborative handling script to add a delay equal to the target standard time to the detection process of subsequent vehicles.

[0007] Optionally, detect whether each offset time interval overlaps with the preset occupied time interval of each subsequent detection sample at each second instrument node in the second detection path, including: Identify the shared instrument nodes between the first and second detection paths; For each shared instrument node, obtain the start time and end time of the target detection sample after offset on the shared instrument node; From the preset global scheduling schedule, obtain the preset start time and preset end time of the subsequent detection samples on the second detection path on the shared instrument node; wherein, the global scheduling schedule is a data table that records the preset start time and preset end time of the detection samples on each instrument node; When the preset start time of subsequent detection samples is earlier than the end time of occupancy after offset, and the preset end time of occupancy of subsequent detection samples is later than the start time of occupancy after offset, it is determined that the offset time interval overlaps with the preset occupancy time interval of subsequent detection samples.

[0008] Optionally, based on the current vehicle position corresponding to subsequent detection samples, an upstream track braking mechanism for physical interception is determined, including: Based on the conflicting instrument nodes that overlap with the current vehicle position and offset time interval and the preset occupied time interval, the track segment from the current vehicle position to the conflicting instrument node on the second detection path is determined as a candidate track segment; Identify all candidate stopping mechanisms on the candidate track segment and obtain the topology sharing weight of the track position where each candidate stopping mechanism is located; wherein, the topology sharing weight is proportional to the number of different detection paths passing through the track position; The target candidate stopping mechanism with the smallest topology sharing weight is selected and determined as the upstream track stopping mechanism.

[0009] Optionally, after the step of detecting whether each offset time interval overlaps with the preset occupied time interval of each subsequent detection sample at each second instrument node in the second detection path, the method further includes: If there is overlap, calculate the time intersection between the offset time interval that causes the overlap and the preset occupied time interval to obtain the overlap duration; The sum of the overlap duration and the preset equipment safety buffer duration is used as the adaptive delay duration, and an adaptive collaborative handling script containing the adaptive delay duration is generated based on the upstream track stopping mechanism. The target vehicle is driven to perform anomaly recovery based on the target handling script, and the upstream track braking mechanism is driven to add a delay equal to the adaptive delay duration to the detection process of subsequent vehicles based on the adaptive collaborative handling script.

[0010] Optionally, prior to the steps of driving the upstream track stopping mechanism according to the collaborative handling script, the method further includes: Within the preset concurrent detection time window, determine whether multiple local abnormal signals reported by different instrument nodes are received; If multiple local anomaly signals are received, then obtain the corresponding collaborative handling scripts for each local anomaly signal and the upstream track stopping mechanisms pointed to by each collaborative handling script. The system detects whether there are conflicting scenarios where at least two coordinated response scenarios point to the same upstream track stopping mechanism; If a conflict exists, extract the delay periods corresponding to at least two collaborative handling scripts and determine whether there is a time overlap between the delay periods; If there is no overlap between the delay periods, then at least two collaborative processing scripts are merged into a time-sharing collaborative processing script according to the order of the delay start times of the delay periods. The time-sharing collaborative processing script contains multiple stop-release instruction pairs that are executed sequentially, and the time-sharing collaborative processing script is used as the collaborative processing script. If there are overlapping periods among the delay periods, the earliest delay start time in at least two collaborative handling scripts will be used as the merged delay start time, and the latest delay end time will be used as the merged delay end time to generate a unified collaborative handling script, which will then be used as the collaborative handling script.

[0011] Optionally, after driving the target vehicle to perform anomaly recovery steps according to the target disposal script, the method further includes: After the target vehicle is restored from an anomaly, record the actual time taken for the target disposal script and calculate the time deviation between the actual disposal time and the target standard time. The time-consuming deviation values ​​are categorized and stored according to the anomaly type identifier and the equipment identifier of the current testing instrument, forming a corresponding historical deviation sequence; When the number of deviation records in the historical deviation sequence reaches the preset statistical window length, it is detected whether the number of consecutive deviations in the same direction in the historical deviation sequence exceeds the preset drift judgment threshold. If the drift judgment threshold is exceeded, the drift correction amount is calculated based on the time-consuming deviation values ​​within the drift judgment threshold range in the historical deviation sequence, and the standard time consumption in the abnormal handling cost database is updated to the sum of the standard time consumption and the drift correction amount.

[0012] Optionally, after determining the upstream track stopping mechanism for physical interception based on the current vehicle position corresponding to subsequent detection samples, the method further includes: Obtain the physical buffer capacity of the track segment located upstream of the upstream track stopping mechanism on the second detection path; wherein, the physical buffer capacity is the maximum number of vehicles that the track segment can accommodate at the same time; Obtain the sample inflow rate of the track segment within the current operating cycle; The number of backlogged vehicles expected to arrive at the track segment during the blocking operation of the upstream track blocking mechanism is calculated based on the product of the target standard time and the sample inflow rate. Calculate the ratio of the number of backlogged vehicles to the physical buffer capacity; If the ratio is greater than the first preset threshold and less than or equal to the second preset threshold, then the maximum inflow rate allowed to be received by the track segment during the blocking period is calculated based on the quotient of the physical buffer capacity and the target standard consumption time, and the delivery rate of the detection sample to the second detection path is controlled to be reduced to the maximum inflow rate. If the ratio is greater than the second preset threshold, the delivery of detection samples to the second detection path will be suspended. If the ratio is less than or equal to the first preset threshold, the current delivery rate will remain unchanged.

[0013] Secondly, embodiments of this application provide an anomaly handling device for a medical testing platform. The anomaly handling device for the medical testing platform includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the anomaly handling device of the medical testing platform to perform the method described in the first aspect and any possible implementation thereof.

[0014] Thirdly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on an anomaly handling device of a medical testing platform, cause the anomaly handling device of the medical testing platform to execute the method described in the first aspect and any possible implementation thereof.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an anomaly handling device of a medical testing platform, cause the anomaly handling device of the medical testing platform to perform the method described in the first aspect and any possible implementation thereof.

[0016] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. By adopting the above technical solution, the system receives local anomaly signals and extracts anomaly type identifiers, matching them with the current detection instruments. It then matches the target handling script and target standard time duration in the anomaly handling cost database, enabling the system to accurately quantify the recovery cost of local faults. Furthermore, it calculates the offset time interval of the target detection sample at each of the first instrument nodes on the first detection path and checks whether it overlaps with the preset occupied time interval of subsequent detection samples at each of the second instrument nodes on the second detection path. If there is an overlap, the upstream track stopping mechanism is determined based on the current vehicle position, generating a collaborative handling script containing the target standard time duration. This drives the target vehicle to recover and adds an equal delay to subsequent vehicles. This process combines the anomaly recovery time with the overall line scheduling spatiotemporal state, achieving precise interception and timely release of potentially conflicting vehicles. This avoids track congestion caused by blind and indefinite physical isolation, maintaining the dynamic balance of the overall logistics rhythm of the production line.

[0017] Compared to traditional global shutdown or coarse-grained interception strategies, this solution can significantly reduce the number of invalid stops on the pipeline under the same sample inflow rate, effectively reduce the track buffer occupancy rate, thereby shortening the average turnaround time of samples and greatly reducing the timeout rate of time-sensitive samples (such as emergency samples and easily degradable samples), which greatly improves the overall operating efficiency and fault tolerance of the automated pipeline.

[0018] 2. By adopting the above technical solution, the shared instrument nodes between the first and second detection paths are determined. The occupied time after offset is compared with the preset occupied time using the global scheduling schedule to accurately determine whether there is overlap between the offset time interval and the preset occupied time interval. After confirming the overlap, candidate track segments are determined based on the current vehicle position and the conflicting instrument nodes. The topology sharing weight of the track positions of each candidate stopping mechanism is obtained, and the target candidate stopping mechanism with the smallest topology sharing weight is selected as the upstream track stopping mechanism. The topology sharing weight is proportional to the number of different detection paths passing through that position; selecting the mechanism with the smallest weight means that the interception point carries the fewest cross-traffic services. This mechanism, based on accurate identification of spatiotemporal conflicts, minimizes the impact of physical interception actions on unrelated detection paths, preventing large-scale path blockage caused by local anomaly handling, and ensuring the normal flow of non-conflicting samples under complex topologies.

[0019] 3. By adopting the above technical solution, after detecting overlapping time intervals, the overlap duration is calculated and combined with the preset equipment safety buffer duration to obtain an adaptive delay duration, generating an adaptive collaborative handling script, making delay control more in line with actual conflict requirements. When multiple local abnormal signals are received within the concurrent detection time window, the conflict situation where each collaborative handling script points to the same upstream track stopping mechanism is detected. The delay period is extracted to determine time overlap. If there is no overlap, they are merged sequentially into a time-sharing collaborative handling script containing multiple stop-release command pairs; if there is overlap, the earliest start and latest end times are extracted to generate a unified collaborative handling script. This process systematically resolves command conflicts on the same physical node when multiple abnormalities occur concurrently, ensuring that the underlying hardware executes coherent and logically consistent interception commands during complex concurrent scheduling, improving the platform's handling reliability under multiple fault conditions.

[0020] 4. By adopting the above technical solution, the actual processing time is recorded after anomaly recovery, and the time deviation value between the actual processing time and the target standard processing time is calculated to form a historical deviation sequence. When the continuous deviation in the same direction exceeds the drift judgment threshold, the drift correction amount is calculated, and the standard processing time in the anomaly processing cost database is updated, giving the system the ability to dynamically self-calibrate the anomaly processing time data. At the same time, the physical buffer capacity and sample inflow rate of the upstream track segment of the upstream track stopping mechanism are obtained. Combined with the target standard processing time, the number of backlogged vehicles is calculated, and the throttling level is determined according to the ratio of the backlogged vehicle to the physical buffer capacity, dynamically reducing the delivery rate or suspending the delivery of detection samples. This process links the underlying physical capacity limit with the source control, actively curbing the influx of excessive vehicles when performing long-term stopping, and preventing physical overflow and deadlock failures caused by exceeding the maximum number of vehicles in local track segments. Attached Figure Description

[0021] Figure 1This is a flowchart illustrating an abnormal handling method for a medical testing platform in an embodiment of this application; Figure 2 This is another flowchart illustrating the abnormal handling method of the medical testing platform in this application embodiment; Figure 3 This is a schematic diagram of the physical device structure of an anomaly handling device of a medical testing platform in this application embodiment. Detailed Implementation

[0022] To enable those skilled in the art to better understand the technical solutions in this specification, 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 this application, and not all embodiments.

[0023] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0024] In the description of the embodiments of this application, the term "multiple" means two or more. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0025] This application provides a method for handling anomalies in a medical testing platform, referencing... Figure 1 , Figure 1 This is a flowchart illustrating an anomaly handling method for a medical testing platform provided in this application embodiment. The method includes: Step S101: Receive local abnormal signals reported by the instrument nodes of the automated production line equipment, parse the abnormal type identifier from the local abnormal signals, and find the current detection instrument of the target vehicle corresponding to the local abnormal signal. Automated production line equipment refers to mechatronic systems used in medical testing laboratories for the automated transport and processing of samples, such as large-scale biochemical and immunological automated production lines containing tracks, conveyor belts, and various analytical modules. Instrument nodes refer to physical stations within the production line network that possess independent processing or detection functions, such as centrifuge nodes, capping machine nodes, or specific biochemical analyzer nodes on the production line. Local anomaly signals are alarm data packets sent to the upper-level control system when the underlying hardware detects an abnormal state during operation, such as timeout alarm signals triggered by sensor obstruction or motor current overload alarm signals. Anomaly type identifiers are codes or fields in the alarm data packet used to uniquely distinguish the type of fault, such as error code E-102 representing "robotic arm grasping failure" or error code E-205 representing "barcode reading timeout." Target carriers refer to the sample transport vehicles currently at the fault location and directly affected by the anomaly, such as independent metal trays carrying single blood collection tubes or test tube racks carrying multiple test tubes on the production line. The current detection instrument refers to the specific equipment unit that the target vehicle is docked or being processed at the moment of the anomaly, such as the specific model of the immunoluminescence analysis module where the target vehicle is stuck.

[0026] In the daily processing of large volumes of samples at medical testing centers, this step is triggered when unexpected situations such as mechanical malfunctions or communication interruptions occur in the underlying hardware. Specifically, the main control system monitors the status broadcasts of each hardware unit in real time via the underlying communication bus. Once an alarm data packet is received, the system performs data frame decomposition and extracts a specific error code as an anomaly type identifier. Simultaneously, based on the device network address or physical port number in the alarm data packet, the system performs a reverse lookup in the global device mapping table to locate the absolute physical location of the fault. Combined with the last check-in record from the RFID system or barcode scanning system, the system identifies the specific sample tray currently being processed at that location as the target carrier, thereby confirming the current testing instrument on which the carrier is located. This provides precise physical coordinates and the object basis for subsequent fault classification and recovery.

[0027] Step S102: Based on the anomaly type identifier and the current detection instrument in the preset anomaly handling cost database, match and extract the target handling script for eliminating the local fault corresponding to the local anomaly signal and the target standard time duration corresponding to the target handling script; wherein, the anomaly handling cost database is a data table that records the handling scripts and standard time durations corresponding to various mechanical anomalies. The anomaly handling cost database refers to a relational data table stored within the control system, pre-loaded with various fault codes, corresponding solution instruction sets, and estimated recovery times. Examples include an SQL database table containing error code columns, recovery script path columns, and average recovery time columns. A local fault represents a non-global shutdown event occurring in a single hardware unit or a local track segment. For example, a tube tipping fault occurring only in the sample inlet track of biochemical analyzer #2, without affecting the operation of biochemical analyzer #1. The target handling script represents the sequence of operation codes automatically invoked by the system for a specific fault, containing a series of mechanical reset and initialization instructions. Examples include execution scripts containing low-level control instructions such as "stop sample inlet," "reset robotic arm," and "release gripper." The target standard recovery time refers to the estimated standard time consumed to complete the above operation sequence code and restore the system to normal operation. For example, the system sets the standard recovery time for the robotic arm reset process to 45 seconds or the standard recovery time for the reagent needle cleaning process to 120 seconds.

[0028] This step is executed after the system successfully parses the specific error type and locates the physical node where the fault occurred, and it is necessary to assess the recovery cost of the fault and generate an automated solution. Specifically, the main control system uses the parsed anomaly type identifier and the device model of the currently faulty detection instrument as the joint query key value to initiate a retrieval request to the local configuration server. The system performs precise matching in the anomaly handling cost database, extracting the standardized recovery process code pre-calibrated by engineers and the average time required for the process derived from historical statistics. If multiple versions of the script exist in the database, the system will prioritize the instruction set that best matches the current hardware firmware version. This process transforms unpredictable physical faults into quantifiable and executable time parameters and control instructions for the system, providing data support for subsequent global scheduling adjustments.

[0029] Step S103: Based on the target standard consumption time, calculate the offset time interval of the target detection sample on each first instrument node of the first detection path after the target treatment script; The target sample refers to a biological sample loaded in a malfunctioning instrument that needs to undergo specific medical testing, such as a blood or urine sample from a patient in a specific test tube. The first testing path represents the pre-planned flow route and testing sequence of the sample on the automated line according to the doctor's orders, such as the physical movement trajectory from the centrifuge to the biochemical analyzer and then to the immunoassay analyzer. The first instrument node refers to each independent testing device that the sample needs to stop at and be processed sequentially along the planned route, such as a specific model of biochemical detection module or chemiluminescence immunoassay module that has not yet been reached in the path. The offset time interval indicates the time period during which the arrival time of the sample at subsequent nodes is delayed due to the malfunction. For example, if a biochemical analyzer was originally scheduled to be used from 10:00 to 10:05, but is delayed by 45 seconds due to the malfunction, the new usage time period becomes 10:00:45 to 10:05:45.

[0030] After obtaining the accurate time cost required for fault recovery, this step is performed to assess the timing impact of this local delay on the entire subsequent detection process of the sample. Specifically, the scheduling system extracts the original global timetable of the target detection sample, and uses the obtained target standard time consumption as a fixed time increment, adding it to the original planned arrival and departure times of each first instrument node that the sample has not yet reached on the first detection path. The system updates the timestamps of each node in its lifecycle by traversing all subsequent nodes to be visited for the sample. This calculation is not just a simple overall translation; the system also combines the physical transmission distance between nodes and the rated operating speed of the track conveyor belt to re-verify whether the translated time nodes meet the minimum sample injection interval requirements of each device, ultimately generating a new set of node occupancy time windows with delay attributes, thereby transforming the local fault consumption time into a dynamic spatiotemporal mapping of the entire path.

[0031] Step S104: Detect whether each offset time interval overlaps with the preset occupied time interval of each subsequent detection sample on each second instrument node of the second detection path; Subsequent testing samples refer to biological samples that enter the automated pipeline equipment for testing after the target testing sample in chronological order. Examples include patient serum samples waiting in line for the next tube of biochemical analyzer or urine samples introduced in subsequent batches. The second testing path represents the physical transport route of subsequent testing samples within the pipeline network according to system scheduling instructions. Examples include the trajectory from the sample buffer module to a specific immunoassay module or the flow route from the centrifuge to the dispensing machine. The second instrument node represents the individual physical stations with independent processing capabilities included in the second testing path, such as the planned access of the 3rd biochemical analyzer node or the 4th chemiluminescence immunoassay analyzer node for subsequent testing samples. The preset occupied time interval refers to the time period allocated by the scheduling system to exclusively occupy a specific instrument node for a sample under normal conditions. Examples include the time period originally planned by the system for a sample to occupy the centrifuge node from 10:05:00 to 10:10:00 or the time period to occupy the sample injection robotic arm from 10:12:00 to 10:12:15. Overlap indicates that two time periods intersect on the time axis. For example, the offset time interval 10:05:30 to 10:06:30 and the preset occupied time interval 10:06:00 to 10:07:00 conflict during the period from 10:06:00 to 10:06:30.

[0032] After calculating the offset time interval of the target detection sample caused by a local fault, this step is executed to prevent sample collisions or resource preemption conflicts in the pipeline network caused by this delay. Specifically, the main control system traverses the preset occupied time intervals of all subsequent detection samples that have not yet been detected in the scheduling database. The system uses the offset time interval of the target detection sample on each first instrument node as a comparison benchmark, and uses a time axis intersection algorithm to compare the values ​​one by one with the preset occupied time intervals of each subsequent detection sample on each second instrument node. The system not only compares the time allocation on the same detection equipment, but also compares the occupied time of shared physical resources such as common track intersection points and robotic arm grasping areas. Through multi-dimensional spatiotemporal matrix calculation, the system identifies all node records that intersect in the time and spatial dimensions, thereby accurately identifying potential global scheduling conflict points caused by local faults.

[0033] Optionally, step S104 can refer to the following more specific solutions; Identify the shared instrument nodes between the first and second detection paths; For each shared instrument node, obtain the start time and end time of the target detection sample after offset on the shared instrument node; From the preset global scheduling schedule, obtain the preset start time and preset end time of the subsequent detection samples on the second detection path on the shared instrument node; wherein, the global scheduling schedule is a data table that records the preset start time and preset end time of the detection samples on each instrument node; When the preset start time of subsequent detection samples is earlier than the end time of occupancy after offset, and the preset end time of occupancy of subsequent detection samples is later than the start time of occupancy after offset, it is determined that the offset time interval overlaps with the preset occupancy time interval of subsequent detection samples.

[0034] In this context, a shared instrument node refers to the same underlying hardware device where the first and second detection paths spatially intersect in terms of physical topology. For example, it could be the same centrifuge node (No. 3) or the same type A biochemical analysis module into which both the target sample and subsequent samples need to enter sequentially. The offset start time indicates the specific time at which the target sample, after experiencing a local fault and the superimposed target standard timeout, is expected to begin entering and exclusively occupying a particular detection device. For example, the injection timestamp of 10:05:45, calculated by the system after recalculation. The offset end time indicates the specific time at which the target sample completes processing on the aforementioned device and releases its physical occupancy rights. For example, the sample exit timestamp of 10:10:45, when the target sample leaves centrifuge node No. 3. The global scheduling timetable refers to a global relational database table maintained in the main control system's memory, recording the planned flow timeline of all samples in transit across various hardware nodes. For example, it could be a two-dimensional data matrix containing fields for sample identification code, device number, planned entry time, and planned exit time. The preset start time of occupancy represents the absolute timestamp at which, under ideal conditions without any malfunctions, the system originally planned to allocate time for subsequent test samples to begin using the specific equipment. For example, 10:08:00 was the original time when subsequent test samples were scheduled to enter the type A biochemical analysis module. The preset end time of occupancy refers to the original absolute timestamp at which, under ideal conditions, subsequent test samples completed the specific equipment processing and relinquished equipment resources. For example, 10:13:00 was the original time when subsequent test samples were scheduled to leave the type A biochemical analysis module.

[0035] After the system obtains the time interval of the full path offset of the target detection sample caused by a local fault, this scheme is executed to reduce the computational complexity of global conflict detection and accurately locate the specific physical nodes of spatiotemporal overlap. Specifically, the main control system first performs a set intersection operation on the node sequences of the first and second detection paths to filter out shared instrument nodes that are physically contained in both paths, thereby filtering out independent nodes that do not compete for resources. Subsequently, for each selected shared instrument node, the system extracts the offset start time and offset end time of the target detection sample after the superimposed delay from memory. At the same time, the system retrieves the preset global scheduling schedule through the database query interface to accurately read the original preset start time and preset end time of subsequent detection samples on the shared instrument node.

[0036] Next, the system uses a time axis intersection determination algorithm to perform Boolean logic operations on the four extracted timestamps. The strict mathematical condition for the system to determine if time intervals overlap is: the preset start time of subsequent detection samples is earlier than the offset end time of the target detection sample on the time axis, and the preset end time of subsequent detection samples is later than the offset start time of the target detection sample on the time axis. For example, if the offset start time of the target detection sample at centrifuge node 3 is 10:05:45 and the offset end time is 10:10:45; while the preset start time of subsequent detection samples is 10:08:00 and the preset end time is 10:13:00, then 10:08:00 is earlier than 10:10:45, and 10:13:00 is later than 10:05:45, and the system determines that there is an overlap. For example, if the target sample's initial occupation time after offset in the type A biochemical analysis module is 10:20:00, and its occupation time ends at 10:25:00; and the preset occupation start time for subsequent samples is 10:26:00, and the preset occupation end time is 10:30:00, then 10:26:00 is not earlier than 10:25:00, and the system determines that there is no overlap. Through this interval cross-comparison based on shared nodes and absolute timestamps, the system can accurately identify subsequent resource contention conflicts caused by local faults with extremely low computational power consumption.

[0037] Step S105: If there is overlap, determine the upstream track blocking mechanism for physical interception based on the current vehicle position corresponding to the subsequent detection sample, and generate a collaborative handling script containing the target standard time duration based on the upstream track blocking mechanism. The current carrier position refers to the real-time physical coordinates of the carrier carrying subsequent test samples within the automated production line equipment track network. For example, a test tube rack is currently located at the XY coordinate point of section A of the main conveyor belt, or an independent tray is located at the position of sensor number 2 on the buffer track. The upstream track stop mechanism refers to electromechanical actuators installed on the conveyor track, located in front of the current carrier position, and capable of blocking the carrier's forward movement. Examples include pneumatic stop cylinders mounted on the side of the track, electromagnetically controlled stop levers, or conveyor belt segment motors with braking functions. The collaborative handling script represents a set of linkage control instructions automatically generated by the system for equipment in non-faulty areas to avoid resource conflicts. Examples include control scripts containing instructions such as "trigger cylinder number 3 to extend," "maintain the blocking state for 45 seconds," and "retract the cylinder after 45 seconds," or control code containing "reduce the speed of the upstream conveyor belt section B motor."

[0038] This step is executed when the system confirms through a time axis intersection algorithm that the delay of the target detection sample will pose a risk of resource contention or physical collision with subsequent detection samples. Specifically, the main control system obtains the current vehicle position of the subsequent detection sample through an RFID reader or photoelectric sensor network. The system, combined with the physical topology diagram of the pipeline, backtracks along the second detection path to find the upstream track stopping mechanism that is closest to the current vehicle position and is in an idle state. After confirming the interception node, the system uses the obtained target standard duration as a core parameter to generate a collaborative handling script. This script directly converts the target standard duration into the action maintenance time of the upstream track stopping mechanism, ensuring that the duration of the interception action is strictly aligned with the recovery period of the local fault on the time scale. This allows for the resolution of spatiotemporal conflicts through local physical blocking without altering the global scheduling topology.

[0039] Furthermore, if there is no overlap, the target vehicle is directly driven to perform anomaly recovery according to the target disposal script.

[0040] Optionally, based on the current vehicle position corresponding to the subsequent detection samples, the upstream track blocking mechanism for physical interception can be determined, and the following more specific solutions can be referenced; Based on the conflicting instrument nodes that overlap with the current vehicle position and offset time interval and the preset occupied time interval, the track segment from the current vehicle position to the conflicting instrument node on the second detection path is determined as a candidate track segment; Identify all candidate stopping mechanisms on the candidate track segment and obtain the topology sharing weight of the track position where each candidate stopping mechanism is located; wherein, the topology sharing weight is proportional to the number of different detection paths passing through the track position; The target candidate stopping mechanism with the smallest topology sharing weight is selected and determined as the upstream track stopping mechanism.

[0041] In this context, a conflicting instrument node refers to a specific underlying hardware device that, during timeline intersection comparison, is determined by the system to be a point where the target sample and subsequent samples will compete for resources or physically collide. Examples include the centrifuge #3 or the type A biochemical analysis module, which exhibits time overlap. A candidate track segment refers to a continuous transport track in the automated pipeline's physical network, extending from the current physical coordinates of the subsequent sample to the conflicting instrument node. For example, the 8-meter track path from sensor #2 on the main conveyor belt to the centrifuge inlet #3. Candidate blocking mechanisms represent all electromechanical components with blocking functions installed on the aforementioned candidate track segment, such as the three pneumatic blocking cylinders distributed along this 8-meter track. Topology sharing weight is a quantitative evaluation metric used to measure the "commonness" of a physical track location within the overall pipeline network topology; this weight is proportional to the number of different detection paths passing through that location. For example, the main circulation track of a pipeline may have thousands of samples passing through dozens of different flow paths every day, and its topology sharing weight may be as high as 50; while the dedicated sample introduction branch track of a specific chemiluminescence immunoassay analyzer may only have a topology sharing weight of 2, as only samples that need to be tested enter the track.

[0042] After the system confirms that subsequent detection samples need to be physically intercepted to avoid conflicts, this scheme is implemented to minimize the negative impact of such manual interception on the overall throughput of the pipeline. Specifically, the main control system first extracts candidate track segments from the current vehicle position to the conflicting instrument node by combining the pipeline's 3D topology map. Since there may be multiple candidate stopping mechanisms capable of performing interception actions on this segment, the system needs to perform intelligent optimization. The system will traverse and identify all candidate stopping mechanisms on the segment and call the underlying database to calculate or obtain the topology sharing weight of each mechanism's location. The core optimization logic of the system is: select the target candidate stopping mechanism with the smallest topology sharing weight as the upstream track stopping mechanism for the final interception task. Because the smaller the weight, the more remote the location is, and the more it belongs to the "dedicated" route; intercepting at this location will only block the subsequent detection samples that need to be delayed, and will not needlessly involve and block other normal samples going to different destinations, as would be done when intercepting on the "main road".

[0043] The following example illustrates this process. Assume the sample being tested is currently at the "main artery start point" of the pipeline, about to proceed to the "Biochemical Analyzer No. 4," where a conflict will occur. From the current location to the candidate track segment of Biochemical Analyzer No. 4, three candidate stopping mechanisms are sequentially distributed: stopping mechanism A (located in the middle of the main artery), stopping mechanism B (located in the main artery of the biochemical testing area), and stopping mechanism C (located on the sample injection side track dedicated to Biochemical Analyzer No. 4). The system calculates that there are 120 paths passing through stopping mechanism A (all samples must pass through it), with a topology sharing weight of 120; 40 paths passing through stopping mechanism B (all biochemical samples must pass through it), with a weight of 40; and only one path passing through stopping mechanism C (only samples going to Biochemical Analyzer No. 4 pass through it), with a weight of 1. According to the selection logic, the system will choose stopping mechanism C, with the lowest topology sharing weight, as the upstream track stopping mechanism. To give another example, if a subsequent vehicle is very close to the conflict node, and there are only two mechanisms on the candidate track segment: one is a regional branch track stop with a weight of 15, and the other is a device buffer track stop with a weight of 5. The system will also select the device buffer track stop with a weight of 5 to perform the interception. Through this spatial optimization strategy based on topology weights, the system achieves the goal of resolving local spatiotemporal conflicts while maximizing the smooth and efficient operation of the global pipeline network.

[0044] Step S106: Drive the target vehicle to perform anomaly recovery according to the target handling script, and drive the upstream track stopping mechanism according to the collaborative handling script to add a delay equal to the target standard time to the detection process of subsequent vehicles; In this context, "subsequent carrier" refers to the physical transport vehicle that carries subsequent test samples and moves on an automated production line, such as a five-well test tube rack for subsequent blood samples or a single-tube magnetic tray for subsequent urine samples. "Delay" is used to describe a physical state in which the travel time of the subsequent carrier on the track is artificially extended through physical intervention, such as a 45-second delay when the subsequent carrier is forced to stop and wait in front of a pneumatic stop cylinder, or an additional 120 seconds of travel time added while circling in a buffer track.

[0045] This step is executed when the system enters the substantive physical intervention and anomaly recovery phase after completing all conflict detection and generating target handling scripts for faulty nodes and collaborative handling scripts for non-faulty nodes. Specifically, the main control system issues two sets of parallel control commands to the underlying hardware through a programmable logic controller. The first set of commands sends electrical signals such as mechanical reset and error clearing to the current detection instrument according to the target handling script, driving the target vehicle out of the stuck state and restoring the normal detection process. The second set of commands sends trigger signals to the upstream track stopping mechanism according to the collaborative handling script, such as controlling the solenoid valve to extend the cylinder and physically intercept the running subsequent vehicle. The upstream track stopping mechanism maintains the interception state for a time strictly equal to the target standard time. After this time is exhausted, the system controls the upstream track stopping mechanism to release the subsequent vehicle. Through this dual-parallel hardware-driven mechanism, the system physically forces the progress of the subsequent vehicle to shift backward, ensuring that the time it arrives at the conflict node is precisely isolated from the time the target vehicle leaves the node, achieving smooth absorption of local anomalies and automatic restoration of global operational order.

[0046] Optional, see reference Figure 2 After step S104, steps S107-S109 can also be executed; Step S107: If there is an overlap, calculate the time intersection between the offset time interval that causes the overlap and the preset occupied time interval to obtain the overlap duration. Specifically, the main control system extracts the start and end times of the target detection sample's occupation after offset at that node, as well as the preset start and end times of subsequent detection samples' occupation. The system compares these four timestamps, extracts the overlapping time period, and calculates the absolute duration of that time period.

[0047] For example: Suppose the target sample's offset time interval in centrifuge #2 is from 10:05:00 to 10:15:00. The subsequent sample's planned time interval in centrifuge #2 is from 10:12:00 to 10:22:00. The system calculates the time intersection to be from 10:12:00 to 10:15:00, with an overlap duration of 3 minutes.

[0048] If the target sample is within the offset time interval of the immune analysis module from 14:30:00 to 14:40:00, while the preset time interval for subsequent samples is from 14:28:00 to 14:35:00, the system calculates the time intersection to be from 14:30:00 to 14:35:00, with an overlap duration of 5 minutes.

[0049] Step S108: The sum of the overlap duration and the preset equipment safety buffer duration is used as the adaptive delay duration, and an adaptive collaborative handling script containing the adaptive delay duration is generated according to the upstream track stopping mechanism. The equipment safety buffer duration refers to a fixed time margin pre-set by the system to absorb mechanical movement errors and network communication delays, such as a preset 15 seconds or 30 seconds. The adaptive delay duration is the total time value obtained by adding the overlap duration to the equipment safety buffer duration, representing the actual time required for subsequent vehicles to be intercepted. The adaptive collaborative handling script refers to the underlying hardware control instruction set containing this adaptive delay duration parameter.

[0050] After calculating the precise overlap duration, to ensure that the physical interception time not only covers the conflict time but also allows for sufficient mechanical reset and physical space intervals, the main control system reads the equipment safety buffer duration set for this type of instrument node from the database and performs a mathematical addition operation with the overlap duration obtained in step S107. Subsequently, the system uses the calculated adaptive delay duration as a parameter and writes it into the control script for the upstream track stopping mechanism.

[0051] For example, following the previous example of an overlap duration of 3 minutes (180 seconds), assume the system's set equipment safety buffer duration is 20 seconds. The system calculates an adaptive delay duration of 200 seconds. Subsequently, the system generates an adaptive collaborative handling script containing the instruction: "Control the extension of the stop cylinder of upstream track A section to maintain the blocking state for 200 seconds."

[0052] In the aforementioned example with an overlap duration of 5 minutes (300 seconds), if the equipment safety buffer duration is set to 30 seconds, the adaptive delay duration is 330 seconds. The script generated by the system contains the instruction: "Control the electromagnetic brake of the upstream conveyor belt to close and maintain the braking state for 330 seconds."

[0053] The safety buffer time can be specifically determined by the instrument's shortest sample injection interval, the track braking response time, and the vehicle positioning error. For example, at a node of a certain type of biochemical analyzer, the shortest sample injection interval required for needle cleaning and robotic arm reset is 12 seconds; the maximum braking response time of the track solenoid valve from receiving the PLC command to the cylinder fully extending is 1.5 seconds; considering the ±5 mm physical positioning error caused by the sliding inertia of the vehicle on the conveyor belt, based on a track running speed of 0.5 m / s, the system needs to calculate and reserve an additional 1.5 seconds for positioning error compensation time. The system superimposes the above three underlying physical parameters (12 seconds + 1.5 seconds + 1.5 seconds) to calculate the equipment safety buffer time specific to this node as 15 seconds. This refined calculation based on multi-dimensional hardware parameters ensures that an absolutely safe physical distance is always maintained between the two vehicles under complex working conditions, thereby significantly improving the accuracy of collision avoidance control and the engineering feasibility of the solution.

[0054] Step S109: Drive the target vehicle to perform anomaly recovery according to the target handling script, and drive the upstream track stopping mechanism according to the adaptive collaborative handling script to add a delay equal to the adaptive delay time to the detection process of subsequent vehicles; Specifically, the main control system synchronously sends two control signals via a programmable logic controller (PLC). The first signal is sent to the fault node according to the target handling script, driving the target vehicle to unblock and continue subsequent detection. The second signal is sent to the upstream track stopping mechanism according to the adaptive collaborative handling script, triggering its physical interception action. The interception duration is precisely matched with the adaptive delay time, and the vehicle is automatically released after the countdown ends.

[0055] For example: The main control system sends a reset command to the malfunctioning robotic arm, which resumes its grasping action, and the target carrier continues to move forward. Simultaneously, the main control system sends a high-level signal to the stop cylinder in section A of the upstream track. The cylinder extends to block the test tube rack carrying subsequent test samples. The cylinder remains extended for 200 seconds (i.e., the adaptive delay time). After 200 seconds, the system sends a low-level signal, the cylinder retracts, and the test tube rack resumes passage.

[0056] The main control system sends a clear error command to the biochemical analyzer where a communication timeout occurred, and the target vehicle re-enters the sample loading queue. Simultaneously, the main control system energizes the upstream electromagnetic brake to secure the subsequent vehicle on the buffer track. The brake remains energized for 330 seconds, after which it is de-energized and released, allowing the subsequent vehicle to continue towards the biochemical analyzer. This resolves the time conflict and ensures a safe physical distance between the two vehicles through a safety buffer period.

[0057] Optionally, before the upstream track stopping mechanism is driven according to the collaborative handling script, the following scheme can also be executed: Step S110: Within the preset concurrent detection time window, determine whether multiple local abnormal signals reported by different instrument nodes have been received. The concurrent detection time window refers to an extremely short absolute time period set by the main control system to collect and determine multiple low-level hardware alarm events that are highly close in time, such as a set time span of 5 or 10 seconds. Local anomaly signals refer to the level interrupt or network alarm data packets sent to the main control system by individual hardware modules on the pipeline when their operation is obstructed.

[0058] To prevent the system from isolating different faults that occur almost simultaneously and causing chaos in the global control logic when the automated production line is operating at high speed, this step is performed. Specifically, the main control system starts a timer to continuously monitor the control bus of the underlying devices. When the first local anomaly signal is received, the system records the timestamp and continuously monitors whether other instrument nodes in different physical locations also report anomaly signals within the subsequent concurrent detection time window. The system performs Boolean logic judgment by counting the number of anomaly signals received within this time window and the source node number.

[0059] For example: Suppose the system's concurrent detection time window is set to 5 seconds. At 10:00:00, the main control system receives a "motor speed abnormality" signal reported by centrifuge No. 1; immediately following at 10:00:03, the system receives a "barcode reading failure" signal reported by dispensing module No. 4. Since these two signals occur within the 5-second window and originate from different nodes, the system's judgment is "yes".

[0060] Step S111: If multiple local abnormal signals are received, then obtain the corresponding collaborative handling scripts for each local abnormal signal and the upstream track blocking mechanisms pointed to by each collaborative handling script. The collaborative handling script refers to the low-level execution file generated independently by the main control system for each local abnormal signal, containing specific delay durations and control instructions. The upstream track blocking mechanism refers to the specific hardware device number (such as a MAC address or bus node ID) explicitly specified in the script instructions that needs to perform physical interception actions.

[0061] After the system confirms that multiple concurrent faults have occurred, this step is performed to obtain all control commands to be executed and their corresponding physical execution units. Specifically, the main control system calls the corresponding algorithm module to independently generate a corresponding collaborative handling script based on the characteristics and impact range of each local abnormal signal. Subsequently, the system parses the instruction code of these scripts and extracts the target hardware identifier (i.e., the physical address of the stopping mechanism) to be controlled by each script.

[0062] For example, consider the aforementioned instance of concurrent failures in the centrifuge and dispensing module. The main control system generates a "cooperative handling script A" for the centrifuge failure, and analysis of this script reveals that the execution hardware it points to is "track stop cylinder 01"; simultaneously, a "cooperative handling script B" is generated for the dispensing module failure, and analysis reveals that the execution hardware it points to is "track stop cylinder 05".

[0063] Step S112: Detect whether there is a conflict situation where at least two collaborative handling scenarios point to the same upstream track stopping mechanism; After obtaining the handling scripts and target hardware corresponding to all concurrent faults, this step is executed to prevent the underlying hardware from receiving conflicting control commands that could lead to mechanical failure or logical deadlock. Specifically, the main control system stores the hardware identifiers of all stopping mechanisms extracted in step S111 into an array or hash table, and checks for duplicate hardware identifiers in the data structure using a traversal comparison algorithm. If duplicates are found, it indicates that multiple scripts need to control the same physical mechanism, thus determining a conflict situation.

[0064] For example, in the centrifuge and dispensing module instance, script A points to "track stop cylinder 01", and script B points to "track stop cylinder 05". The system compares the hardware identifiers "01" and "05" and finds that they are inconsistent. Therefore, it determines that there is no conflict, and the system can issue these two scripts in parallel.

[0065] Step S113: If a conflict exists, extract the delay time periods corresponding to at least two collaborative handling scripts, and determine whether there is a time overlap between the delay time periods. The delay period refers to the specific absolute time interval (including the start and end times of the delay) set in the collaborative handling script, which requires the underlying blocking mechanism to maintain a physical blocking state. Time overlap refers to the time regions where two or more delay periods overlap on the absolute time axis.

[0066] After determining in step S112 that multiple scripts point to the same physical stopping mechanism, this step is executed to determine whether these control commands will interfere with each other in the time dimension. Specifically, the main control system parses the parameters of these conflicting scripts and extracts their respective set delay start and end times. The system uses a numerical comparison algorithm to analyze whether these time intervals have any overlap.

[0067] For example: Suppose the system determines that both collaborative handling scenarios A and B point to "track 3 stop cylinder". The system extracts the delay period for scenario A as 10:05:00 to 10:06:00 and the delay period for scenario B as 10:07:00 to 10:08:00. After numerical comparison, the system determines that these two delay periods are completely offset on the timeline and there is no time overlap.

[0068] Step S114: If there is no overlap between the delay periods, then at least two collaborative processing scripts are merged into a time-sharing collaborative processing script according to the order of the delay start times of the delay periods. The time-sharing collaborative processing script contains multiple stop-release instruction pairs executed in sequence, and the time-sharing collaborative processing script is used as the collaborative processing script. Among them, the time-sharing collaborative handling script refers to a combined control file generated by rearranging multiple independent control tasks that do not overlap in time. The stop-release command pair refers to a complete combination of electronic control signals that controls the underlying mechanism to execute a "stop" and then "release" the stop.

[0069] After confirming that multiple delay periods targeting the same organization do not overlap, this step is executed to improve the efficiency of control command issuance and avoid communication overhead caused by multiple issuances. Specifically, the main control system sorts these delay periods in ascending order based on their start times. Subsequently, the system concatenates these independent control commands in chronological order to generate a time-sharing collaborative processing script containing multiple continuous action stages, and replaces the original multiple independent scripts with this script before issuing it to the underlying hardware.

[0070] For example: This follows the examples of script A (10:05:00-10:06:00) and script B (10:07:00-10:08:00). Since there is no overlap, the system merges them according to their chronological order. The generated time-sharing collaborative processing script contains two pairs of instructions: the first pair controls cylinder 3 to extend at 10:05:00 and retract at 10:06:00; the second pair controls the cylinder to extend again at 10:07:00 and retract at 10:08:00.

[0071] Step S115: If there are overlapping periods between the delay periods, the earliest delay start time in at least two collaborative processing scripts is taken as the merged delay start time, and the latest delay end time is taken as the merged delay end time, generating a unified collaborative processing script, and using the unified collaborative processing script as the collaborative processing script.

[0072] The merge delay start time refers to the timestamp with the smallest value among multiple overlapping time periods. The merge delay end time refers to the timestamp with the largest value among multiple overlapping time periods. A unified collaborative processing script refers to merging multiple control tasks with overlapping times into a single, continuous control file with a longer span.

[0073] After confirming that multiple delay periods targeting the same institution overlap, this step is executed to prevent mechanical oscillations or logical errors caused by the underlying hardware receiving contradictory "release" and "stop" commands within overlapping time periods. Specifically, the main control system extracts the start and end points of all overlapping time periods, obtains the merged delay start time by finding the minimum extreme value, and obtains the merged delay end time by finding the maximum extreme value. The system uses these two new time boundaries to generate a single, continuous blocking command, forming a unified and coordinated handling script.

[0074] For example, consider the instances from the aforementioned scripts C (14:20:00-14:25:00) and D (14:23:00-14:28:00). Due to overlap, the system extracts the earliest start time, 14:20:00, as the start time of the merge delay, and the latest end time, 14:28:00, as the end time of the merge delay. The system generates a unified collaborative handling script with the following instruction: control the main road electromagnetic barrier to open at 14:20:00 and maintain the barrier until 14:28:00 before releasing it.

[0075] Optionally, after driving the target vehicle through the anomaly recovery steps according to the target disposal script, the following options can also be executed: Step S116: After the abnormal recovery of the target vehicle is completed, record the actual processing time of the target disposal script and calculate the time deviation value between the actual processing time and the target standard processing time. The actual processing time refers to the absolute length of time elapsed from the moment the main control system issues the control command for the target processing script to the moment it receives the anomaly clearing status signal from the underlying hardware. The time deviation value is the difference between the actual processing time and the preset target standard processing time in the system database. This difference is positive or negative; a positive number indicates that the actual processing time exceeds the standard, and a negative number indicates that the actual processing time is shorter than the standard.

[0076] To quantify the difference between the preset handling time parameters and the actual physical execution time, the main control system extracts the start and end timestamps of the anomaly recovery process through its internal timer module, calculates the difference between the two to obtain the actual handling time. Subsequently, the system reads the target standard time duration corresponding to this type of anomaly from the database, subtracts the standard time from the actual time, and outputs the time deviation value.

[0077] For example: Suppose the target vehicle experiences a "test tube rack jamming" anomaly in centrifuge #1, and the database sets the target standard timeout to 40 seconds. The main control system records the actual time from issuing the reset command to the centrifuge responding normally as 46 seconds. The system calculates the timeout deviation to be +6 seconds (46 seconds - 40 seconds).

[0078] Step S117: Classify and store the time-consuming deviation values ​​according to the anomaly type identifier and the equipment identifier of the current testing instrument to form the corresponding historical deviation sequence; Among them, the anomaly type identifier refers to a code used to uniquely distinguish different fault categories (such as motor overload, communication timeout, etc.). The device identifier refers to the unique address code or number of the specific physical hardware where the anomaly occurred. The historical deviation sequence refers to a one-dimensional data set consisting of multiple time-consuming deviation values ​​belonging to the same device and of the same anomaly type, arranged in chronological order in the database.

[0079] After calculating the time-consuming deviation value for a single event, this step is performed to accumulate data for subsequent statistical analysis of equipment operating status. Specifically, the main control system extracts the anomaly type identifier and equipment identifier of this abnormal event, and locates the corresponding storage table or data column in a relational database or time-series database. Then, the system appends the time-consuming deviation value calculated in step S116 as a new element to the end of this data column, thereby continuously extending the historical deviation sequence under this specific condition.

[0080] For example, following the aforementioned example of centrifuge jamming, the main control system extracts the anomaly type identifier "ERR_JAM_01" and the device identifier "Centrifuge_01". The system finds the corresponding data table in the database and appends the value "+6 seconds" to the historical deviation sequence of that table, updating the sequence to [+2, -1, +4, +6].

[0081] Step S118: When the number of deviation records in the historical deviation sequence reaches the preset statistical window length, detect whether the number of consecutive deviations in the same direction in the historical deviation sequence exceeds the preset drift judgment threshold. The statistical window length refers to the sample size condition set by the system to trigger data analysis, such as 20 or 50 records. Continuous same-direction deviation refers to deviation values ​​that appear consecutively in chronological order within a sequence and have the same mathematical sign (both positive or both negative). The drift judgment threshold is the minimum number of continuous deviations required to determine if a systematic change has occurred in the mechanical performance or response time of the equipment.

[0082] As historical deviation sequences accumulate, this step is executed to filter out single random errors and accurately identify systematic execution time offsets caused by mechanical wear or aging of the underlying hardware. Specifically, the main control system monitors the length of each historical deviation sequence in real time. When the length equals the preset statistical window length, the detection algorithm is triggered. The algorithm iterates through the data at the end of the sequence, counts the number of consecutive positive or consecutive negative values, and compares this number with a preset drift judgment threshold.

[0083] For example: Suppose the system sets the statistical window length to 30 and the drift judgment threshold to 15. When the "ERR_JAM_01" sequence of "Centrifuge_01" accumulates to 30 data points, the system initiates detection. The algorithm finds that the last 18 deviation values ​​in the sequence are all positive (i.e., the actual time taken for 18 consecutive times is greater than the standard time). Since 18 is greater than the set threshold of 15, the system determines that the number of consecutive deviations in the same direction exceeds the drift judgment threshold.

[0084] Step S119: If the drift judgment threshold is exceeded, calculate the drift correction amount based on the time-consuming deviation values ​​in the historical deviation sequence that are within the drift judgment threshold range, and update the standard time consumption in the abnormal handling cost database to the sum of the standard time consumption and the drift correction amount.

[0085] The drift correction amount refers to the time compensation value obtained by performing mathematical statistics (such as calculating the arithmetic mean or median) on the continuous deviation data of the trigger threshold. The update standard time duration refers to permanently overlaying the calculated compensation value onto the original baseline time parameters in the database to guide future scheduling calculations.

[0086] After determining that a systematic drift has occurred in the execution time of the underlying hardware, this step is executed to resynchronize the scheduling parameters of the main control system with the actual operating state of the physical hardware. Specifically, the main control system extracts the values ​​that constitute continuous deviations in the same direction from the sequence and calculates their average value as the drift correction amount. Subsequently, the system accesses the anomaly handling cost database, reads the original standard execution time, adds it to the drift correction amount, and writes the sum back to the database, completing the adaptive calibration of the parameters.

[0087] For example, consider the instance of 18 consecutive positive deviations in the aforementioned centrifuge sequence. The main control system extracts these 18 deviation values ​​and calculates their arithmetic mean as +5 seconds (i.e., a drift correction of 5 seconds). The system reads the original standard duration of 40 seconds from the database, adds it to 5 seconds, and obtains 45 seconds. The system then updates the standard duration of this anomaly in the database to 45 seconds.

[0088] Optionally, after determining the upstream track stopping mechanism for physical interception based on the current vehicle position corresponding to subsequent detection samples, the following scheme can also be executed: Step S120: Obtain the physical buffer capacity of the track segment located upstream of the upstream track stopping mechanism on the second detection path; wherein, the physical buffer capacity is the maximum number of vehicles that the track segment can accommodate at the same time; The upstream side refers to the spatial orientation before the reference node, with the default direction of sample flow as the reference. For example, when samples flow from east to west, the area east of the stopping mechanism is the upstream side. The track segment refers to a continuous physical track in the second detection path extending in the opposite direction of sample flow from the location of the upstream track stopping mechanism, such as a 2-meter-long straight conveyor belt in front of the stopping device. The physical buffer capacity is the maximum number of vehicles that a track segment can simultaneously accommodate; it refers to the maximum number of vehicles that can be sequentially parked within the track segment without vehicles squeezing or derailing. For example, a certain track segment can hold a maximum of 20 sample tube holders. A vehicle is a physical container or base used to carry the test samples and move them on the track, such as a five-hole sample rack with an RFID tag.

[0089] To assess the static load-bearing capacity of the interception action on the local traffic state of the system, step S120 is executed. Specifically, the main control system locates the node coordinates of the currently determined upstream track stopping mechanism by reading the track topology configuration file loaded during system initialization. Subsequently, the main control system calculates the physical length of the track segment between this node coordinate and the previous diversion node or control node along the opposite direction of the sample flow. The main control system calls the preset physical length parameters of individual vehicles and the standard safety distance parameters between vehicles from the database, and uses the physical length of the track segment divided by the sum of the physical length of an individual vehicle and the standard safety distance parameter, rounded down to obtain the physical buffer capacity of the track segment. For example, if the main control system determines that the length of the track segment in front of the upstream track stopping mechanism is 1500 mm, the physical length of an individual vehicle is 25 mm, and the safety distance is 5 mm, then the main control system calculates that the physical buffer capacity of the track segment is 50 vehicles.

[0090] Step S121: Obtain the sample inflow rate of the track segment in the current operating cycle; The current operating cycle refers to the standard time window in which the system is currently performing monitoring and scheduling, such as the current 1-minute or 5-minute statistical cycle. The sample inflow rate refers to the number of vehicles entering the target track segment within a unit time window, used to represent the current traffic flow load of the system in that local area, for example, 0.5 vehicles per second.

[0091] Specifically, the main control system reads real-time counting data from RFID readers or photoelectric sensors installed at the track segment entrance to count the total number of vehicles passing through the entrance during the current operating cycle. Then, the main control system divides this total number of vehicles by the duration of the current operating cycle to calculate the sample inflow rate. The main control system also applies a moving average filter to the calculated sample inflow rate to eliminate errors caused by instantaneous flow fluctuations. For example, if the main control system uses photoelectric sensor data to determine that 20 vehicles entered the track segment during the past 10 seconds of the current operating cycle, it divides 20 by 10 to calculate the sample inflow rate as 2 vehicles per second during the current operating cycle.

[0092] Step S122: Calculate the number of backlogged vehicles expected to arrive at the track segment during the blocking operation of the upstream track blocking mechanism based on the product of the target standard time duration and the sample inflow rate. The "stopping period" refers to the duration during which the upstream track stopping mechanism is in a physical blocking state, such as the 30 seconds from when the barrier extends to when it retracts. The "backlog of vehicles" refers to the total number of vehicles that accumulate on the track segment because they cannot pass through the stopping point during the duration during which the upstream track stopping mechanism is in a blocking state. For example, it is estimated that 15 vehicles will be stuck on the track during the stopping period.

[0093] Specifically, the main control system extracts the target standard duration corresponding to the current target handling script from the anomaly handling cost database. The main control system uses this target standard duration as the estimated stopping period and multiplies it by the sample inflow rate by calling the multiplication module of the central processing unit. The main control system rounds up the product to obtain the estimated number of backlogged vehicles arriving at the track segment during the stopping period executed by the upstream track stopping mechanism. For example, if the main control system obtains a target standard duration of 25 seconds and a sample inflow rate of 2 vehicles per second, it multiplies 25 by 2 to calculate that the estimated number of backlogged vehicles arriving at the track segment during the stopping period executed by the upstream track stopping mechanism is 50.

[0094] Step S123: Calculate the ratio of the number of backlogged vehicles to the physical buffer capacity; Specifically, the main control system calls the division module, using the number of backlogged vehicles calculated in step S122 as the dividend and the physical buffer capacity obtained in step S120 as the divisor, to calculate a floating-point ratio. Subsequently, the main control system reads multiple preset ratio threshold ranges from the configuration database and compares the calculated ratio with each threshold range. Based on the specific threshold range the ratio falls into, the main control system matches and determines the throttling level corresponding to the current track segment, so that subsequent logic can trigger corresponding speed reduction or pause commands based on the determined throttling level. For example, if the main control system calculates that the number of backlogged vehicles is 45 and the physical buffer capacity is 50, the main control system calculates 45 divided by 50 to obtain a ratio of 0.9.

[0095] Step S124: If the ratio is greater than the first preset threshold and less than or equal to the second preset threshold, then calculate the maximum inflow rate that the track segment can accept during the blocking period based on the quotient of the physical buffer capacity and the target standard consumption time, and control the delivery rate of the detection sample to the second detection path to be reduced to the maximum inflow rate. The first preset threshold refers to a numerical indicator set in the system configuration database to define the boundary between light and moderate congestion, for example, a value of 0.6. The second preset threshold refers to a numerical indicator set in the system configuration database to define the boundary between moderate and heavy congestion, for example, a value of 1.0.

[0096] Specifically, the main control system uses a logic judgment module to compare values ​​and determine the interval, confirming that the ratio is strictly greater than the first preset threshold and less than or equal to the second preset threshold. Then, the main control system calls the division unit, using the obtained physical buffer capacity as the dividend and the target standard time duration as the divisor, to calculate a floating-point quotient. The main control system rounds this quotient down or retains a specified number of decimal places, setting it as the maximum inflow rate allowed for the track segment during the stop period. Next, the main control system generates control commands and sends them to the robotic arm or diversion switch controller responsible for sample input, forcibly modifying its operating parameters to reduce the rate at which samples are delivered to the second detection path to the calculated maximum inflow rate. For example, if the main control system determines that the ratio 0.8 is greater than the first preset threshold of 0.6 and less than the second preset threshold of 1.0, the main control system divides the physical buffer capacity of 50 by the target standard time of 25 seconds and calculates a quotient of 2. Based on this, the main control system sets the maximum inflow rate to 2 carriers per second and controls the delivery rate of the sample injection robot arm to decrease from the current 3 carriers per second to 2 carriers per second.

[0097] Step S125: If the ratio is greater than the second preset threshold, then stop delivering detection samples to the second detection path. Specifically, the main control system compares the values ​​through the logic judgment module to confirm that the ratio is strictly greater than the second preset threshold. Once the condition is met, the main control system immediately generates a high-priority emergency stop sampling command. The main control system sends this command to the programmable logic controller of the sampling module via the industrial fieldbus, cutting off the grasping action logic of the sampling robotic arm or locking the steering mechanism of the diversion switch, thereby physically suspending the delivery of test samples to the second detection path until the anomaly is resolved and the backlogged carrier is cleared. For example, if the main control system determines that the ratio 1.2 is greater than the second preset threshold 1.0, the main control system immediately sends a stop command to the sampling node, the sampling robotic arm stops placing the carrier containing the test sample into the second detection path, and the sampling action is completely stopped.

[0098] Step S126: If the ratio is less than or equal to the first preset threshold, then maintain the current delivery rate.

[0099] The current delivery rate refers to the existing frequency at which the sample delivery module or preceding node releases detection samples to the second detection path before triggering an abnormal interception event, such as maintaining the release of 2 samples per second.

[0100] Specifically, the main control system compares the values ​​through a logic judgment module to confirm that the ratio is strictly less than or equal to a first preset threshold. Once the condition is met, the main control system determines that the current local traffic situation is within a safe redundancy range, requiring no degradation or intervention. The main control system generates a status code to maintain the status quo and does not send any instructions to the programmable logic controller of the sample delivery module to modify parameters, thereby maintaining the current delivery rate and ensuring that the overall throughput efficiency of the system is not affected by minor anomalies. For example, if the main control system determines that the ratio of 0.4 is less than the first preset threshold of 0.6, the main control system does not trigger any throttling control logic, and the sample delivery robot continues to deliver samples to the second detection path at the current delivery rate of 2 samples per second.

[0101] The following describes the anomaly handling device of the medical testing platform in the embodiments of this invention from the perspective of hardware processing. Please refer to [link / reference needed]. Figure 3 This is a schematic diagram of the physical device structure of an anomaly handling device of a medical testing platform in this application embodiment.

[0102] It should be noted that, Figure 3 The structure of the abnormal handling device of the medical testing platform shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0103] like Figure 3As shown, the anomaly handling device of the medical testing platform includes a CPU 301, which can perform various appropriate actions and processes according to a program stored in the read-only memory ROM 302 or a program loaded from the storage section 308 into the random access memory RAM 303, such as executing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An I / O interface 305 is also connected to the bus 304.

[0104] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0105] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by CPU 301, it performs the various functions defined in the present invention.

[0106] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0107] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0108] Specifically, the anomaly handling device of the medical testing platform in this embodiment includes a processor and a memory. The memory stores a computer program, and when the computer program is executed by the processor, it implements the anomaly handling method of the medical testing platform provided in the above embodiment.

[0109] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the anomaly handling device of the medical testing platform described in the above embodiments; or it may exist independently and not assembled into the anomaly handling device of the medical testing platform. The storage medium carries one or more computer programs, which, when executed by a processor of the anomaly handling device of the medical testing platform, cause the anomaly handling device of the medical testing platform to implement the anomaly handling method of the medical testing platform provided in the above embodiments.

[0110] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for handling anomalies in a medical testing platform, characterized in that, Includes the following steps: Receive local anomaly signals reported by instrument nodes of automated production line equipment, parse the anomaly type identifier from the local anomaly signals, and find the current detection instrument of the target vehicle corresponding to the local anomaly signal; Based on the anomaly type identifier and the current detection instrument in the preset anomaly handling cost database, a target handling script for eliminating the local fault corresponding to the local anomaly signal and a target standard time consumption corresponding to the target handling script are matched and extracted; wherein, the anomaly handling cost database is a data table that records the handling scripts corresponding to various mechanical anomalies and the standard time consumption corresponding to the handling scripts; Based on the target standard consumption time, calculate the offset time interval of the target detection sample on each first instrument node of the first detection path after the target treatment script; Detect whether each of the aforementioned offset time intervals overlaps with the preset occupied time intervals of each subsequent detection sample at each of the second instrument nodes in the second detection path; If there is overlap, the upstream track blocking mechanism for physical interception is determined based on the current vehicle position corresponding to the subsequent detection sample, and a collaborative handling script containing the target standard time consumption is generated according to the upstream track blocking mechanism. The target vehicle is driven to perform anomaly recovery according to the target handling script, and the upstream track stopping mechanism is driven according to the collaborative handling script to add a delay equal to the target standard time to the detection process of the subsequent vehicle.

2. The method according to claim 1, characterized in that, The detection of whether each of the offset time intervals overlaps with the preset occupied time intervals of each subsequent detection sample at each of the second instrument nodes in the second detection path includes: Identify the shared instrument nodes between the first detection path and the second detection path; For each of the shared instrument nodes, the starting time and ending time of the target detection sample after offset on the shared instrument node are obtained; From the preset global scheduling schedule, obtain the preset start time and preset end time of subsequent detection samples on the second detection path on the shared instrument node; wherein, the global scheduling schedule is a data table that records the preset start time and preset end time of each detection sample on each instrument node; When the preset start time of the subsequent detection sample is earlier than the end time of the offset, and the preset end time of the subsequent detection sample is later than the start time of the offset, it is determined that the offset time interval overlaps with the preset occupancy time interval of the subsequent detection sample.

3. The method according to claim 1, characterized in that, The step of determining the upstream track stopping mechanism for physical interception based on the current vehicle position corresponding to the subsequent detection samples includes: Based on the current vehicle position and the conflicting instrument nodes that overlap with the offset time interval and the preset occupied time interval, the track segment on the second detection path from the current vehicle position to the conflicting instrument node is determined as a candidate track segment; Identify all candidate stopping mechanisms on the candidate track segment and obtain the topology sharing weight of the track position where each candidate stopping mechanism is located; wherein, the topology sharing weight is proportional to the number of different detection paths passing through the track position; The target candidate stopping mechanism with the smallest topology sharing weight is selected, and the target candidate stopping mechanism is determined as the upstream track stopping mechanism.

4. The method according to claim 1, characterized in that, After the step of detecting whether each of the offset time intervals overlaps with the preset occupied time intervals of each subsequent detection sample at each of the second instrument nodes in the second detection path, the method further includes: If there is an overlap, calculate the time intersection between the offset time interval that causes the overlap and the preset occupied time interval to obtain the overlap duration; The sum of the overlap duration and the preset equipment safety buffer duration is used as the adaptive delay duration, and an adaptive collaborative handling script containing the adaptive delay duration is generated according to the upstream track stopping mechanism. The target vehicle is driven to perform anomaly recovery according to the target handling script, and the upstream track stopping mechanism is driven according to the adaptive collaborative handling script to add a delay equal to the adaptive delay duration to the detection process of the subsequent vehicle.

5. The method according to claim 1, characterized in that, Prior to the step of driving the upstream track stopping mechanism according to the collaborative handling script, the method further includes: Within a preset concurrent detection time window, determine whether the local anomaly signal reported by multiple different instrument nodes has been received; If multiple local abnormal signals are received, then each of the collaborative handling scripts corresponding to each local abnormal signal and each of the upstream track blocking mechanisms pointed to by each collaborative handling script are obtained respectively. Detect whether there is a conflict where at least two of the aforementioned collaborative handling scenarios point to the same upstream track stopping mechanism; If the aforementioned conflict exists, at least two delay periods corresponding to the collaborative handling scripts are extracted, and it is determined whether there is a time overlap between the delay periods. If there is no overlap between the delay periods, then the at least two collaborative processing scripts are merged into a time-sharing collaborative processing script according to the order of the delay start times of the delay periods. The time-sharing collaborative processing script contains multiple stop-release instruction pairs that are executed sequentially, and the time-sharing collaborative processing script is used as the collaborative processing script. If there is an overlap between the delay periods, the earliest delay start time in the at least two collaborative processing scripts is taken as the merged delay start time, and the latest delay end time is taken as the merged delay end time, to generate a unified collaborative processing script, and the unified collaborative processing script is taken as the collaborative processing script.

6. The method according to claim 1, characterized in that, After the step of driving the target vehicle to perform anomaly recovery according to the target disposal script, the method further includes: After the abnormal recovery of the target vehicle is completed, the actual processing time of the target disposal script is recorded, and the time deviation value between the actual processing time and the target standard processing time is calculated. The time-consuming deviation values ​​are categorized and stored according to the anomaly type identifier and the device identifier of the current detection instrument to form a corresponding historical deviation sequence; When the number of deviation records in the historical deviation sequence reaches the preset statistical window length, it is detected whether the number of consecutive deviations in the same direction in the historical deviation sequence exceeds the preset drift judgment threshold. If the drift determination threshold is exceeded, the drift correction amount is calculated based on the time-consuming deviation values ​​in the historical deviation sequence that are within the drift determination threshold range, and the standard time consumption in the anomaly handling cost database is updated to the sum of the standard time consumption and the drift correction amount.

7. The method according to claim 1, characterized in that, After determining the upstream track stopping mechanism for physical interception based on the current vehicle position corresponding to the subsequent detection samples, the method further includes: Obtain the physical buffer capacity of the track segment located upstream of the upstream track stopping mechanism on the second detection path; wherein, the physical buffer capacity is the maximum number of vehicles that the track segment can accommodate at the same time; Obtain the sample inflow rate of the track segment during the current operating cycle; The number of backlogged vehicles expected to arrive at the track segment during the blocking operation of the upstream track blocking mechanism is calculated based on the product of the target standard time duration and the sample inflow rate. Calculate the ratio of the number of backlogged vehicles to the physical buffer capacity; If the ratio is greater than the first preset threshold and less than or equal to the second preset threshold, then the maximum inflow rate that the track segment is allowed to accept during the blocking period is calculated based on the quotient of the physical buffer capacity and the target standard consumption time, and the delivery rate of the detection sample to the second detection path is controlled to be reduced to the maximum inflow rate. If the ratio is greater than the second preset threshold, then the delivery of detection samples to the second detection path is suspended. If the ratio is less than or equal to the first preset threshold, the current delivery rate remains unchanged.

8. An anomaly handling device for a medical testing platform, characterized in that, The anomaly handling device of the medical testing platform includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the anomaly handling device of the medical testing platform to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on the anomaly handling device of the medical testing platform, the anomaly handling device of the medical testing platform performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the anomaly handling device of the medical testing platform, the anomaly handling device of the medical testing platform performs the method as described in any one of claims 1-7.