A multi-process cooperative management system for device anti-leaving

Abstract

The application discloses a kind of multi-process cooperative management systems for equipment anti-leave, it is related to flight equipment management technical field, and system is cooperatively managed by five modules of identity collection, equipment management, task management, state monitoring and early warning;Identity collection module generates personnel identity, area and equipment identification as first message;Equipment management module adopts RFID and visual double-channel comparison, confirms identification as second message after;Task management module obtains and analyzes first message, generates task number as third message;State monitoring module obtains second message screening equipment not homing, is associated with third message, generates early warning for the equipment not homing of task end;Early warning module obtains early warning message, pushes according to multilevel receiving end, and push timeout enters dead letter queue and is promoted in frequency again.The application realizes flight equipment anti-leave management and hierarchical early warning by multi-module cooperation, reduces equipment loss risk.

Description

Technical Field

[0001] This invention relates to the field of flight equipment management technology, and more specifically to a multi-process collaborative management system for preventing equipment from being left behind. Background Technology

[0002] The maritime rescue flight team undertakes near-shore emergency search and rescue missions. Its rescue aircraft (such as the Sikorsky S-76 helicopter) are characterized by high sortie rates and complex operating environments, requiring extremely high levels of maintenance safety. In aircraft maintenance operations, the standardized management of maintenance tools and equipment is a crucial element in ensuring flight safety and the successful completion of missions.

[0003] Currently, domestic and international aircraft maintenance companies generally use traditional tool warehouse management systems, recording equipment borrowing and returning through manual registration, barcode scanning, or simple spreadsheets. However, the existing management model has three major flaws in the highly dynamic and high-pressure scenario of maritime rescue:

[0004] Firstly, borrowing and returning equipment relies on manual registration, lacking electronic closed-loop tracking. When maintenance personnel borrow equipment, warehouse staff typically fill out paper forms manually or simply scan barcodes, and the same manual verification is required upon return. Due to the unpredictable and frequent nature of maritime rescue missions, omissions, errors, or even equipment loss are prone to occur, and it is impossible to track the specific location and status of equipment during the maintenance process in real time.

[0005] Secondly, the system lacks regional automatic monitoring and one-keyboard operation, resulting in delayed anomaly handling and a lack of linkage with the electronic dispatch procedure. Maintenance sites are often divided into multiple work areas (such as the apron, maintenance hangar, and parts warehouse). The existing system cannot automatically detect whether equipment has left its designated storage area or remains at the work site. When equipment is not returned to its designated location on time, anomaly handling relies on manual inspection, leading to delayed response. More critically, the equipment's return status is not linked to the pre-flight electronic dispatch procedure. Release personnel sign off based solely on verbal confirmation of tool integrity, resulting in unclear responsibility. If equipment is left inside the aircraft or in the work area, it could potentially cause a serious flight accident.

[0006] Third, existing general-purpose tool management systems are not designed for maritime rescue scenarios and lack proactive prevention and control capabilities such as preventing leftovers, electronic signature constraints, and automatic early warning management. Most tool management systems on the market operate in a passive recording mode, which cannot achieve real-time status detection under multi-process collaboration, task status correlation verification, and hierarchical early warning push, making it difficult to meet the high safety management needs of maritime rescue flight teams in high-intensity deployments and complex operating environments.

[0007] Therefore, there is an urgent need for a multi-process collaborative management system and method for preventing equipment from being left behind. Through multi-module collaboration, message queue communication, state machine verification, and multi-level early warning mechanisms, it can realize the full-process electronic closed-loop tracking, regional automatic monitoring, and proactive early warning of maintenance equipment from its issuance to its return. Summary of the Invention

[0008] To address the aforementioned issues, this invention proposes a multi-process collaborative management system for preventing equipment from being left behind. By employing multi-process collaboration, state machine verification, and adaptive time sliding window technology, combined with multi-level early warning and frequency amplification strategies, it achieves closed-loop tracking and proactive early warning for the entire maintenance process of equipment, effectively improving the safety and management efficiency of maritime rescue aviation maintenance.

[0009] A multi-process collaborative management system for preventing device legacy issues includes:

[0010] The identity acquisition module acquires the facial image of the maintenance personnel, extracts facial features and compares them with the pre-stored feature library. After the comparison is successful, it generates personnel identity information, current area information and unique identifier of the equipment picked up by the maintenance personnel, and writes the personnel identity information, area information and unique equipment identifier as the first message into the message queue.

[0011] The device management module obtains the unique identifier, current status, and timestamp of each device within the process area, and writes the unique identifier, current status, and timestamp of each device as a second message into the message queue.

[0012] The task management module retrieves the first message from the message queue, parses the personnel identity information and the unique identifier of the equipment from the first message, and generates a task order number based on the personnel identity information, the unique identifier of the equipment, the current timestamp, and the task information filled in by the maintenance personnel. This task order number is then written into the message queue as the third message.

[0013] The status detection module retrieves a second message from the message queue and filters out devices whose current status is outside the specified storage area based on the second message, thus obtaining a list of unreturned devices. For each device in the unreturned device list, the status detection process searches the message queue for a third message associated with the device's unique identifier. If no message is found, the device is skipped. If a message is found, the task number and task status are parsed from the third message. If the task status is "completed," the status detection process generates an abnormal warning message containing the device's unique identifier, task number, borrower information, and current timestamp, and writes it to the message queue as a fourth message.

[0014] The early warning module extracts the fourth message from the message queue and pushes the early warning messages sequentially according to the preset multi-level receiver order. Each level receiver must return an acknowledgment signal within the timeout threshold. If no acknowledgment is received within the timeout, the message is transferred to the dead letter queue and the frequency increase strategy is triggered to re-push the early warning message to the current level receiver and the previous level receiver.

[0015] Furthermore, in the equipment management module, the current status of each piece of equipment includes being in a designated storage area, being borrowed, under maintenance, and not yet returned to its original location;

[0016] Among them, the equipment that has been borrowed for identification purposes has not yet been completed and has been used normally; the equipment that has not been returned to its original location has been completed for identification purposes but has not been returned to its original location.

[0017] Furthermore, in the status detection module, searching for a third message associated with the device's unique identifier from the message queue specifically includes: using the device's unique identifier as the key, retrieving all relevant third messages within a preset time sliding window; the length of the time sliding window is preset to 1.5 times the standard task duration.

[0018] Based on the device's unique identifier, candidate messages are located within the retrieved third-party messages to obtain a candidate message set;

[0019] For each third message in the candidate message set, check whether its task state transition path meets the preset state machine rules. If it meets the state machine rules, take the message with the latest timestamp as the associated message. If it does not meet the rules, it is determined to be an abnormal state transition, and a consistency check message including the device's unique identifier, the abnormal state sequence, and the current timestamp is generated and written to the message queue.

[0020] Furthermore, the preset state machine rule is as follows: before the device changes from the borrowed state to the not returned state, there must be a valid path that passes through the maintenance process and the associated task is in progress.

[0021] Furthermore, the length L of the time sliding window can be configured in adaptive mode, and the specific configuration formula is as follows:

[0022] ;

[0023] ;

[0024] Where n is the number of historical time samples of the device from the most recent n times it went from being borrowed to being in the designated storage area; For the first Duration of the second historical return to its original position; This represents the average historical repositioning time. This is the scaling factor; and These are the preset minimum window length and maximum window length, respectively; This represents the function that takes the minimum value.

[0025] Furthermore, the identity acquisition process, device management process, task management process, status monitoring process, and early warning management process support centralized deployment, distributed deployment, and centralized and distributed collaborative deployment.

[0026] In a centralized deployment, all processes run on the same physical server or the same container cluster;

[0027] In distributed deployment, each process is deployed on different physical servers, virtual machines, or container instances and communicates across the network through message queues;

[0028] When deploying in a centralized and distributed manner, the process is divided into a core process group and an edge process group. The core process group includes a task management process and a status monitoring process, which are centrally deployed on the central server. The edge process group includes an identity collection process, a device management process, and an early warning management process, which are deployed on edge nodes in different physical areas.

[0029] Furthermore, it also includes a deployment controller, which dynamically displays the current system deployment scheme and the running status of each process, and issues dynamic instructions to each target server node through the flow table to add or destroy process instances.

[0030] The flow table includes target node identifier, process type, expected number of instances, flow table action, startup parameters, and flow table version number. When the deployment controller updates the flow table version, it distributes the new version flow table to each target server node. Each target node compares its current local flow table version with the received flow table version. If the version number increases, it performs a process instance addition or destruction operation based on the difference between the expected number of instances and the current number of running instances, and feeds the execution result back to the deployment controller for update display.

[0031] Furthermore, in the task management module, the task information filled in by maintenance personnel includes the task description, planned start time, and planned end time; the task order number generated by the task management process is composed of the department code, date serial number, and the last four digits of the equipment's unique identifier.

[0032] Furthermore, in the early warning module, the preset multi-level receiving end order is as follows: the first level is the maintenance personnel themselves, the second level is the maintenance personnel's direct supervisor, and the third level is the regional safety officer; the frequency increase strategy is as follows: the interval between re-pushing the early warning message to the current level and the previous level is shortened to half of the original interval, and the number of pushes is increased by one.

[0033] Furthermore, it also includes a dead-letter queue processing module, which is used to periodically scan the warning messages in the dead-letter queue. For each warning message, it records the duration of its stay in the dead-letter queue. If the duration exceeds the preset delay retry threshold, the message is removed from the dead-letter queue and resubmitted to the message queue entry of the warning module. If the same warning message is removed from the dead-letter queue and resubmitted a specified number of times without receiving an acknowledgment signal from any level of receiver, the message is written to the persistent alarm database and a system email notification to the administrator is triggered.

[0034] Furthermore, in the device management module, the unique identifier of the device is determined collaboratively by both the RFID identification channel and the visual identification channel:

[0035] The RFID identification channel reads the electronic tags of the equipment in the work area through the RFID reader to obtain the RFID identification mark and the tag signal quality;

[0036] After acquiring images from the device via image acquisition, the visual recognition channel obtains visual recognition labels and visual confidence levels through AI target recognition and OCR text recognition.

[0037] The device management process performs a double consistency comparison between the RFID identification tag and the visual identification tag of the same device. Only when the two are consistent and the overall identification confidence is not lower than the preset acceptance threshold, it is determined to be a double consistency confirmation. The device's unique identifier, current status, and timestamp are written as a second message to the message queue. Otherwise, a consistency verification message including conflict types is generated and written to the message queue.

[0038] The present invention adopts the above technical solution and has the following beneficial effects:

[0039] (1) The present invention achieves real-time recording and transmission of the status of equipment from requisition, maintenance to return to its original position through the collaborative work of the identity collection module, equipment management module and task management module, using message queue as carrier, forming electronic closed-loop management, and optimizing the omission and error problems caused by manual paper registration or verbal confirmation;

[0040] (2) This invention verifies the legal transition path of the equipment from being borrowed and under maintenance to not being returned to its original location by pre-setting state machine rules in the status detection module, automatically filters out the equipment that has not been returned to its original location and generates an abnormal warning message, and links the abnormal status with the process to avoid the release personnel releasing the aircraft based solely on verbal confirmation and to clarify the attribution of responsibility.

[0041] (3) The present invention pushes early warning messages in the order of multi-level receivers through the early warning module. If the message is not confirmed after the timeout, it is transferred to the dead letter queue and the frequency increase strategy is triggered. The message is then pushed to the current level and the previous level at the same time. The interval time is gradually shortened until the alarm is successful or the record is persisted, thereby improving the timeliness and reliability of abnormal handling.

[0042] (4) This invention supports three architectures: centralized deployment, distributed deployment, and centralized and distributed collaborative deployment. It also introduces a deployment controller based on the flow table mechanism, which enables the multi-process early warning management system to be flexibly adapted to various operation and maintenance scenarios and to elastically schedule process instances. This effectively improves the system's scalability, operation and maintenance efficiency, and environmental adaptability. Attached Figure Description

[0043] Figure 1 This is a flowchart of a method for a multi-process collaborative management system for preventing device legacy according to an embodiment of the present invention;

[0044] Figure 2 This is a flowchart illustrating the RFID and image OCR dual-consistency recognition and judgment process according to an embodiment of the present invention.

[0045] Figure 3 This is a diagram illustrating the distributed deployment scheme of the management system according to an embodiment of the present invention. Detailed Implementation

[0046] The present invention will be further described in detail below with reference to the embodiments and accompanying drawings, but the embodiments of the present invention are not limited thereto.

[0047] like Figure 1 As shown, this embodiment also discloses a multi-process collaborative management system for preventing device legacy issues, including:

[0048] S1, Identity Acquisition Module: The identity acquisition process acquires the facial image of the maintenance personnel, extracts facial features and compares them with the pre-stored feature library. After the comparison is successful, it generates personnel identity information, current area information, and the unique identifier of the equipment picked up by the maintenance personnel. The personnel identity information, area information, and unique equipment identifier are written as the first message to the message queue.

[0049] S2, the device management module, the device management process obtains the unique identifier, current status and timestamp of each device in the process area, and writes the unique identifier, current status and timestamp of each device as a second message into the message queue.

[0050] Specifically, in the equipment management module, the current status of each piece of equipment includes being in a designated storage area, borrowed, under maintenance, and not returned. Among them, "borrowed" indicates that the task has not yet been completed and the equipment has been used normally; "not returned" indicates that the task has been completed but the equipment has not been returned.

[0051] Specifically, in the device management module, the unique identifier of the device is determined collaboratively by both the RFID identification channel and the visual identification channel:

[0052] The RFID identification channel reads the electronic tags of the equipment in the work area through the RFID reader to obtain the RFID identification mark and the tag signal quality;

[0053] After acquiring images from the device via image acquisition, the visual recognition channel obtains visual recognition identifiers and visual confidence levels through AI target recognition and OCR (Optical Character Recognition) text recognition.

[0054] The device management process performs a double consistency comparison between the RFID identification tag and the visual identification tag of the same device. Only when the two are consistent and the overall identification confidence is not lower than the preset acceptance threshold, it is determined to be a double consistency confirmation. The device's unique identifier, current status, and timestamp are written as a second message to the message queue. Otherwise, a consistency verification message including conflict types is generated and written to the message queue.

[0055] Specifically, the visual recognition channel obtains visual recognition identifiers and visual confidence scores, including: image acquisition, where image acquisition units deployed in equipment storage areas, maintenance work areas, or handover channels periodically capture images or are triggered by RFID reading events to obtain image frames containing at least one piece of equipment; AI target recognition, where the image frames are input into a pre-trained deep neural network target detection model, outputting the bounding box, equipment category label, and classification confidence score for each equipment target in the image, and cropping the image to obtain equipment sub-images based on the bounding boxes; OCR text recognition, where text detection and recognition are performed on the nameplate, engraved number, or asset label text areas in the equipment sub-images, extracting character identifiers from the equipment surface, performing fuzzy matching with the unique identifiers of equipment in a pre-stored equipment database, and taking the one with the highest similarity as the OCR candidate identifier and OCR matching confidence score; and visual fusion, where the classification confidence score and OCR matching confidence score are weighted and fused to obtain the visual confidence score. When the visual confidence score is not lower than a preset visual threshold, the visual recognition identifier is jointly determined by the AI ​​equipment category and the OCR candidate identifier; otherwise, it is determined as visually unrecognized.

[0056] Specifically, the dual consistency comparison is handled according to the following scenarios: Scenario 1: Both RFID identification tags and visual identification tags exist and are identical, which is determined to be a dual consistency confirmation. The device's unique identifier, current status, timestamp, and comprehensive identification confidence level are written as a second message into the message queue. Scenario 2: RFID identification tags exist but there are no visual identification tags. This is determined to be a suspected tag cross-read or tag residue. A consistency verification message is generated, and the device is not temporarily counted as in place. Scenario 3: Visual identification tags exist but there are no RFID identification tags. This is determined to be a suspected tag detachment, damage, or metal obstruction. A consistency verification message is generated, and the device is temporarily recorded as physically in place based on the visual identification result, with a prompt for tag replacement. Scenario 4: Both RFID identification tags and visual identification tags exist but are different. This is determined to be an tag conflict. A consistency verification message is generated, and the device's status change is frozen until manual verification. The consistency verification message includes the device's visual identification tag, RFID identification tag, conflict type, image snapshot reference, confidence level, and current timestamp.

[0057] Specifically, the judgment rule for comprehensive identification confidence and double consistency confirmation is as follows: Visual confidence C_vis = α·p_ai + β·p_ocr, where p_ai is the AI ​​classification confidence, p_ocr is the OCR matching confidence, α and β are preset weights, and α + β = 1; the OCR matching confidence p_ocr is taken from the device database with the highest similarity, and the similarity sim(s,c) = 1 − Lev(s,c) / max(|s|,|c|), where s is the character identifier extracted by OCR, c is the unique device identifier in the device database, and Lev is the maximum similarity. Edit distance, |s|, |c| are string lengths; comprehensive recognition confidence C = w_r·q_rfid + w_v·C_vis, where q_rfid is the signal quality obtained by normalizing the received signal strength of the RFID tag, w_r and w_v are preset weights and w_r + w_v = 1; double consistency confirmation is determined if and only if the two channel identifiers are consistent and C is not less than T_accept, where T_accept is a preset acceptance threshold; T_accept, T_vis, α, β, w_r, and w_v can be configured according to the deployment scenario.

[0058] Specifically, when screening out devices that have not been returned to their designated locations, the status detection module uses double consistency confirmation as a prerequisite for the device to be "in the designated storage area": ​​only devices with double consistency confirmation are counted as returned to their designated locations; for devices with only RFID confirmation but no visual confirmation, they are not counted as returned to their designated locations and their consistency verification messages are retained, thereby preventing misjudgment of returned devices or omission of abandoned devices due to RFID cross-reading, missed reading, or tag retention.

[0059] Specifically, in the device management module, the unique device identifier is obtained collaboratively by the RFID identification channel and the visual identification channel, and is written into the second message after dual consistency identification and judgment. The execution process is as follows: Figure 2 As shown, it includes three parts: RFID identification channel, visual identification channel, and dual consistency identification judgment.

[0060] (a) RFID Identification Channel. The equipment management process reads the electronic tags of each device in the work area using an RFID reader to obtain a set of RFID identification marks. It also collects the received signal strength of each tag and normalizes it to obtain the tag signal quality q_rfid, with a value ranging from 0 to 1. This channel uses the existing RFID device unique identifier collection method, which is fast and does not require line of sight. However, it is prone to shielding and missed readings near metal bodies, cross-reading between adjacent storage areas, and it is difficult to detect when tags are detached, damaged, or tampered with.

[0061] (II) Visual Recognition Channel. The equipment management process acquires equipment images through image acquisition units deployed in equipment storage areas, maintenance work areas, and handover channels, and obtains visual recognition labels according to the following steps: Step 1, Image Acquisition: The image acquisition unit captures images periodically, or is triggered by RFID reading events, to acquire image frames containing one or more pieces of equipment; Step 2, AI Target Recognition: The image frames are input into a pre-trained deep neural network target detection model, such as a detector based on the YOLO series or Faster-RCNN, which outputs the bounding box, equipment category label, and classification confidence p_ai for each equipment target in the image, and cropped according to the bounding box to obtain equipment sub-images; Step 3, OCR Text Recognition: Text detection and text recognition are performed on text areas such as nameplates, laser-engraved numbers, asset tags, or tool numbers in the equipment sub-images. First, extract the character identifier 's' from the device surface. Then, perform a fuzzy match between 's' and the unique device identifier 'c' in the pre-stored device database. The similarity is calculated as sim(s,c)=1−Lev(s,c) / max(|s|,|c|), where Lev(s,c) is the edit distance between 's' and 'c', and |s| and |c| are the string lengths. The one with the highest similarity is selected as the OCR candidate identifier, and its similarity is the OCR matching confidence score p_ocr. Next, perform visual fusion. Calculate the visual confidence score as C_vis=α·p_ai+β·p_ocr, where α and β are preset weights and α+β=1. When C_vis is not less than the preset visual threshold T_vis, the visual identification identifier is jointly determined by the AI ​​device category and the OCR candidate identifier; otherwise, the device is deemed visually unrecognized. The visual recognition channel does not rely on electronic tags and can independently identify the physical location of the device and its actual serial number on the device surface. This allows the device to be detected even when tags are detached, damaged, or replaced, and provides independent cross-validation for RFID results.

[0062] (III) Dual Consistency Identification Judgment. The equipment management process compares the consistency of RFID tags and visual tags for the same equipment, and handles them according to the following situations: Situation 1, Dual Consistency: Both channel tags exist and are the same. Calculate the comprehensive identification confidence C = w_r·q_rfid + w_v·C_vis, where w_r and w_v are preset weights and w_r + w_v = 1. When C is not less than the preset acceptance threshold T_accept, it is determined as dual consistency confirmation. The equipment unique identifier, current status, timestamp, and comprehensive identification confidence C are written as the second message into the message queue and marked as dual consistency confirmation; Situation 2, RFID present, visual not present: The tag is read but the corresponding device is not identified in the image, mostly... In case of cross-reading between adjacent storage areas, misreading in neighboring areas, or tags left behind after equipment has left the site, a consistency verification message for suspected tag cross-reading or tag residue is generated, and the equipment is temporarily not counted as in place. In case of visual recognition but no RFID tag, the image identifies the equipment but does not read its tag, often due to the tag being detached, damaged, or obscured by a metal body. A consistency verification message for suspected tag failure is generated, and the equipment is temporarily recorded as physically in place based on the visual recognition result, with a prompt for on-site tag replacement or affixing. In case of dual-channel inconsistency, both channel identifiers exist but are different, often due to mislabeling, misplacement, or equipment swapping. A consistency verification message for identifier conflict is generated, and the equipment status change is frozen until manual verification. All of the above consistency verification messages include the equipment's visual identification identifier, RFID identification identifier, conflict type, image snapshot reference, confidence level, and current timestamp. After being written into the message queue, they can be used by the status detection module for linkage judgment and by manual review and retrieval of image snapshots for confirmation.

[0063] (iv) Linkage with anti-residualization determination. When screening for non-residualized devices, the status detection module uses double consistency confirmation as a prerequisite for the device to be in the designated storage area: the device is considered to be in the correct location only when double consistency confirmation is obtained; for devices that are only read by RFID but not visually confirmed, they are not considered to be in the correct location, and their consistency verification message is retained. Therefore, even if RFID cross-reading, missed reading, or tag retention occurs, the system will not mistakenly determine that the device has been in the correct location, thereby working in conjunction with the state machine verification and hierarchical early warning mechanism of this invention to further reduce the risk of device retention. For example, if a helicopter A retrieves tool kit 1 for maintenance, and the RFID tag on tool kit 1 falls off during onboard operations, a traditional RFID-only solution would miss or misjudge the case because it cannot read the tag. However, the visual recognition channel of this invention can still confirm the physical presence of tool kit 1 by recognizing its surface number through OCR, triggering the consistency check and relabeling prompt in scenario three to avoid omissions. Conversely, if a tag from the adjacent aircraft parts warehouse is read into the hangar maintenance area, the visual channel will trigger scenario two because there is no corresponding equipment in the image, thus avoiding misclassifying equipment that is not actually in place as having been returned to its original position.

[0064] S3, the task management module, retrieves the first message from the message queue, parses the personnel identity information and the unique identifier of the equipment from the first message, generates a task order number based on the personnel identity information, the unique identifier of the equipment, the current timestamp, and the task information filled in by the maintenance personnel, and writes it into the message queue as the third message.

[0065] Specifically, in the task management module, the task information filled in by maintenance personnel includes the task description, planned start time, and planned end time; the task order number generated by the task management process is composed of the department code, date serial number, and the last four digits of the equipment's unique identifier.

[0066] S4, the status detection module, is used by the status monitoring process to retrieve the second message from the message queue, filter out devices whose current status is not in the specified storage area based on the second message, and obtain a list of unreturned devices. For each device in the list of unreturned devices, the status monitoring process searches the message queue for a third message associated with the device's unique identifier. If not found, the device is skipped. If found, the task number and task status are parsed from the third message. If the task status is completed, the status monitoring process generates an abnormal warning message containing the device's unique identifier, task number, borrower information, and current timestamp, and writes it to the message queue as the fourth message.

[0067] Specifically, in the status detection module, searching for a third message associated with the device's unique identifier from the message queue includes: using the device's unique identifier as the key, retrieving all relevant third messages within a preset time sliding window; the length of the time sliding window is preset to 1.5 times the standard task duration.

[0068] Based on the device's unique identifier, candidate messages are located within the retrieved third-party messages to obtain a candidate message set;

[0069] For each third message in the candidate message set, check whether its task state transition path meets the preset state machine rules. If it meets the state machine rules, take the message with the latest timestamp as the associated message. If it does not meet the rules, it is determined to be an abnormal state transition, and a consistency check message including the device's unique identifier, the abnormal state sequence, and the current timestamp is generated and written to the message queue.

[0070] Specifically, the preset state machine rule is as follows: before a device changes from a borrowed state to a not returned state, there must be a valid path that passes through a maintenance-in-progress task and whose associated task state is in progress.

[0071] Specifically, the length L of the time sliding window can be configured in adaptive mode, and the specific configuration formula is as follows:

[0072] ;

[0073] ;

[0074] Where n is the number of historical time samples of the device from the most recent n times it went from being borrowed to being in the designated storage area; For the first Duration of the second historical return to its original position; This represents the average historical repositioning time. This is the scaling factor; and These are the preset minimum window length and maximum window length, respectively; This represents the function that takes the minimum value.

[0075] Specifically, in this system, the time sliding window is used by the status monitoring process to limit the time range of the query when retrieving task messages associated with the device's unique identifier from the message queue. This avoids performance bottlenecks caused by a full scan of the message queue. For devices with fast homing speeds, the window automatically narrows to quickly match the latest tasks and improve retrieval efficiency. For devices with slow homing speeds, the window is appropriately widened to accommodate task records within the normal range, preventing the omission of valid associations due to an excessively short window.

[0076] S5, the early warning module, is used by the early warning management process to extract the fourth message from the message queue and push the early warning messages sequentially according to the preset multi-level receiver order. Each level receiver must return an acknowledgment signal within the timeout threshold. If no acknowledgment is received within the timeout, the message is transferred to the dead letter queue and the frequency increase strategy is triggered to re-push the early warning message to the current level receiver and the previous level receiver.

[0077] Specifically, in the early warning module, the preset multi-level receiving end order is as follows: the first level is the maintenance personnel themselves, the second level is the maintenance personnel's direct supervisor, and the third level is the regional safety officer; the frequency increase strategy is as follows: the interval between re-pushing the early warning message to the current level and the previous level is shortened to half of the original interval, and the number of pushes is increased by one.

[0078] Specifically, the dead-letter queue processing module periodically scans the warning messages in the dead-letter queue. For each warning message, it records the duration it stays in the dead-letter queue. If the duration exceeds the preset delay retry threshold, the message is removed from the dead-letter queue and resubmitted to the message queue entry of the warning module. If the same warning message has been removed from the dead-letter queue and resubmitted a specified number of times without receiving confirmation from any level of receiver, the message is written to the persistent alarm database, and a system email notification to the administrator is triggered.

[0079] Specifically, the identity acquisition process, device management process, task management process, status monitoring process, and early warning management process support centralized deployment, distributed deployment, and centralized and distributed collaborative deployment.

[0080] In a centralized deployment, all processes run on the same physical server or the same container cluster;

[0081] In distributed deployment, each process is deployed on different physical servers, virtual machines, or container instances and communicates across the network through message queues;

[0082] When deploying in a centralized and distributed manner, the process is divided into a core process group and an edge process group. The core process group includes a task management process and a status monitoring process, which are centrally deployed on the central server. The edge process group includes an identity collection process, a device management process, and an early warning management process, which are deployed on edge nodes in different physical areas.

[0083] Specifically, the system also includes a deployment controller, which dynamically displays the current system deployment scheme and the running status of each process, and issues dynamic instructions to each target server node through the flow table to add or destroy process instances.

[0084] The flow table includes target node identifier, process type, expected number of instances, flow table action, startup parameters, and flow table version number. When the deployment controller updates the flow table version, it distributes the new version flow table to each target server node. Each target node compares its current local flow table version with the received flow table version. If the version number increases, it performs a process instance addition or destruction operation based on the difference between the expected number of instances and the current number of running instances, and feeds the execution result back to the deployment controller for update display.

[0085] Specifically, in this system, the flow table action field is the core instruction that drives each target node to perform specific operation and maintenance operations. After receiving a new version of the flow table, the node first verifies the version number to ensure the idempotency of the instruction, then parses the action field and executes the corresponding logic. For adding a process instance (ADD), the node starts a new process according to the startup parameters. During initialization, the process automatically requests a permission token from the message queue to complete the smooth transfer of permissions. For destroying an instance (REMOVE), the node calculates the difference based on the expected number of instances and terminates the redundant processes. Before exiting, the terminated process persists its cached task data and running status and transfers them to the message queue for other processes to continue processing. Subsequently, the process performs resource reclamation and self-destruction. For updating the configuration (UPDATE), the node applies the new startup parameters (such as message queue address and log level) to all running instances without adding or deleting processes, achieving hot updates of the configuration. After all actions are executed, the node feeds back the results to the deployment controller for update display, thereby realizing full lifecycle management functions such as permission transfer, data migration, and process self-destruction. Each management process collaborates through the message queue to complete the data processing and early warning management of device assets, reducing the complexity of system operation and maintenance and the cost of manual intervention.

[0086] Specifically, in a centralized deployment model, the identity acquisition process, device management process, task management process, status monitoring process, and early warning management process all run on the same physical server (e.g., an industrial-grade edge computing host) or the same container cluster. The message queue middleware (such as RabbitMQ or Redis) shares the same instance with this server. Processes communicate via local shared memory, Unix domain sockets, or a loopback network interface (127.0.0.1), without needing external switches or routers, resulting in communication latency typically below 1 millisecond. All modules share the same hardware resources and operating system environment, allowing system administrators to complete the overall deployment by maintaining only one device or one container orchestration file.

[0087] The core advantages of centralized deployment are: 1. Simple and quick deployment, without the need to configure complex network policies, load balancing or cross-node authentication, making it particularly suitable for temporary forward maintenance points of maritime rescue flight teams, small helicopter landing platforms or emergency repair sites; 2. Low operation and maintenance costs, log collection, monitoring and alarm, and software upgrades can all be completed centrally without the need for multi-node coordination; 3. High communication reliability, no network partition risk, and extremely low probability of message loss, making it suitable for scenarios with extremely high real-time requirements but a small number of devices (e.g., less than 50 devices).

[0088] Specifically, in the distributed deployment mode, each process is deployed on different physical servers, virtual machines, or container instances, communicating with each other across the network via message queues. Specifically: the identity collection process is deployed on a dedicated server at the maintenance base entrance, directly connected to high-definition cameras and ID card readers, responsible for collecting facial images and personnel information; the equipment management process is deployed in multiple instances based on area division—for example, one instance is deployed in the aircraft parts warehouse connected to a fixed RFID reader, and another instance is deployed in the hangar maintenance area connected to a Bluetooth AoA positioning base station, each instance independently collecting the unique identifier, current status, and timestamp of equipment within its area; the task management process is deployed on the business server of the dispatch center, interfacing with the maintenance work order system, responsible for generating task order numbers and writing them to a third-party message; the status monitoring process and the early warning management process are jointly deployed on an independent alarm server, ensuring that anomaly detection and push services are not interrupted due to the restart or failure of other modules. The processes communicate with each other using a highly available message queue cluster such as RabbitMQ mirrored queues, with network links based on 4G / 5G wireless networks, enterprise internal dedicated lines, or VPN tunnels.

[0089] like Figure 3 As shown, a cross-regional distributed high-availability architecture is demonstrated. The first base and the second base are connected through a message queue. The status monitoring process and the early warning process are distributed and deployed on multiple servers in the two bases (such as server b in the first base, server c and server d in the second base). This layout ensures that when the monitoring node in one base fails or the network is interrupted, the same process in the other base can still continuously obtain global data and perform detection tasks through the message queue, thereby effectively avoiding monitoring blind spots caused by single points of failure and ensuring the overall security and continuity of the system.

[0090] Specifically, the core advantages of distributed deployment are: 1. High scalability: When the maintenance base expands to include new work areas, only new equipment management process instances need to be added and connected to the message queue, without requiring downtime to modify existing modules; 2. Fault isolation: A single process (such as the identity collection process crashing due to camera driver anomalies) will not affect the continued operation of other processes, and the status monitoring and early warning modules can still function normally; 3. Regional automatic monitoring: The equipment management process in each region is only responsible for reporting the status of equipment in its own region, significantly reducing the processing load and network bandwidth consumption of a single node; 4. Meeting the high concurrency requirements of large bases: The number of devices in the main operating base can exceed 500, and each process can be distributed across multiple high-performance servers, handling sudden tasks through load balancing; 5. Cross-regional collaboration and clear responsibility: Even if maintenance personnel work across regions, the status monitoring process can still aggregate second messages from different regions to uniformly determine non-returned equipment, and the early warning process is deployed independently, so even if the task management module restarts, it will not affect the push of abnormal messages. This distributed architecture is particularly suitable for the main operating base of a maritime rescue flight team, as well as group-level deployment scenarios that need to manage multiple dispersed sites (such as multiple coastal take-off and landing points) simultaneously.

[0091] For example, in real-world maintenance scenarios, there are maintenance tools and equipment. Maintenance tools are often used on-board, leading to a higher rate of omissions; maintenance equipment is often used on the ground, resulting in a lower probability of omissions. Both can utilize the above techniques for omission management. In rescue helicopter scenarios, multiple helicopters often operate from the same base, such as helicopters A, B, and C. For instance, helicopter A is in maintenance mode, helicopter B is in rescue standby mode, and helicopter C is in training mode. Helicopter A, while in maintenance, needs to retrieve some packaged tools, such as tool kit 1, which is currently out of service. Helicopter C, needing to be deployed for training, has not yet returned all its tools and equipment. However, if tool kit 1 is in a normal retrieved state, and the tools and equipment are verified as being in a legitimate, not-yet-returned state, no multi-process collaborative warning will be issued, but the display screen will show a normal retrieved state.

[0092] In addition, a "three-check" of tools is required during maintenance work. The core of this check is checking tools three times: before work, during transfer, and after work, to prevent loss, omission, and error. This preventative warning system has both early warning and one-keyboard check functionality. At the same work site, a one-keyboard check can quickly check tools to see if any are missing or left behind. During rescue helicopter maintenance operations, a similar inventory of tools and equipment is required before and after each workday, and the one-keyboard check function efficiently meets this requirement. Assuming the flight team has two permanent bases (Base 1 and Base 2) and a third base under temporary management with personnel on long-term assignments; when Base 1 faces relocation, and Base 1 operates simultaneously with the other two bases, Base 1 can utilize a centralized deployment and distributed coexistence deployment model. Even if Base 1 experiences power outages or other malfunctions, it will not affect the operation of Base 1 and other bases, ensuring the deployment and rescue operations of other rescue helicopters.

[0093] Although the invention has been specifically shown and described in conjunction with preferred embodiments, those skilled in the art should understand that various changes in form and detail may be made to the invention without departing from the spirit and scope of the invention as defined in the appended claims, all of which shall be within the scope of protection of the invention.

Claims

1. A multi-process collaborative management system for preventing equipment from being left behind, characterized in that, include: The identity acquisition module acquires the facial image of the maintenance personnel, extracts facial features and compares them with the pre-stored feature library. After the comparison is successful, it generates personnel identity information, current area information and unique identifier of the equipment picked up by the maintenance personnel, and writes the personnel identity information, area information and unique equipment identifier as the first message into the message queue. The device management module obtains the unique identifier, current status, and timestamp of each device within the process area, and writes the unique identifier, current status, and timestamp of each device as a second message into the message queue. The task management module retrieves the first message from the message queue, parses the personnel identity information and the unique identifier of the equipment from the first message, and generates a task order number based on the personnel identity information, the unique identifier of the equipment, the current timestamp, and the task information filled in by the maintenance personnel. This task order number is then written into the message queue as the third message. The status detection module retrieves a second message from the message queue and filters out devices whose current status is outside the specified storage area based on the second message, thus obtaining a list of unreturned devices. For each device in the unreturned device list, the status detection process searches the message queue for a third message associated with the device's unique identifier. If no message is found, the device is skipped. If a message is found, the task number and task status are parsed from the third message. If the task status is "completed," the status detection process generates an abnormal warning message containing the device's unique identifier, task number, borrower information, and current timestamp, and writes it to the message queue as a fourth message. The early warning module extracts the fourth message from the message queue and pushes the early warning messages sequentially according to the preset multi-level receiver order. Each level receiver must return an acknowledgment signal within the timeout threshold. If no acknowledgment is received within the timeout, the message is transferred to the dead letter queue and the frequency increase strategy is triggered to re-push the early warning message to the current level receiver and the previous level receiver.

2. The multi-process collaborative management system for preventing equipment abandonment according to claim 1, characterized in that, In the equipment management module, the current status of each piece of equipment includes being in a designated storage area, being borrowed, under maintenance, and not returned to its original location. Among them, the equipment that has been borrowed for identification purposes has not yet been completed and has been used normally; the equipment that has not been returned to its original location has been completed for identification purposes but has not been returned to its original location.

3. The multi-process collaborative management system for preventing equipment abandonment according to claim 1, characterized in that, In the status detection module, the third message associated with the device's unique identifier is retrieved from the message queue. Specifically, this includes: using the device's unique identifier as the key, retrieving all relevant third messages within a preset time sliding window; the length of the time sliding window is preset to 1.5 times the standard task duration. Based on the device's unique identifier, candidate messages are located within the retrieved third-party messages to obtain a candidate message set; For each third message in the candidate message set, check whether its task state transition path meets the preset state machine rules. If it meets the state machine rules, take the message with the latest timestamp as the associated message. If it does not meet the rules, it is determined to be an abnormal state transition, and a consistency check message including the device's unique identifier, the abnormal state sequence, and the current timestamp is generated and written to the message queue.

4. The multi-process collaborative management system for preventing equipment abandonment according to claim 3, characterized in that, The preset state machine rule is as follows: before the device changes from the borrowed state to the not returned state, there must be a valid path that passes through the maintenance process and the associated task is in progress.

5. The multi-process collaborative management system for preventing equipment abandonment according to claim 3, characterized in that, The length L of the time sliding window can be configured in adaptive mode, and the specific configuration formula is as follows: ； ； Where n is the number of historical time samples of the device from the most recent n times it went from being borrowed to being in the designated storage area; For the first Duration of the second historical return; This represents the average historical repositioning time. This is the scaling factor; and These are the preset minimum window length and maximum window length, respectively; This represents the function that takes the minimum value.

6. The multi-process collaborative management system for preventing equipment abandonment according to claim 1, characterized in that, The identity acquisition process, device management process, task management process, status monitoring process, and early warning management process support centralized deployment, distributed deployment, and centralized and distributed collaborative deployment. In a centralized deployment, all processes run on the same physical server or the same container cluster; In distributed deployment, each process is deployed on different physical servers, virtual machines, or container instances and communicates across the network through message queues; When deploying in a centralized and distributed manner, the process is divided into a core process group and an edge process group. The core process group includes a task management process and a status monitoring process, which are centrally deployed on the central server. The edge process group includes an identity acquisition process, a device management process, and an early warning management process, which are deployed on edge nodes in different physical areas.

7. The multi-process collaborative management system for preventing equipment abandonment according to claim 1, characterized in that, It also includes a deployment controller, which dynamically displays the current system deployment scheme and the running status of each process, and issues dynamic instructions to each target server node through the flow table to add or destroy process instances. The flow table includes target node identifier, process type, expected number of instances, flow table action, startup parameters, and flow table version number. When the deployment controller updates the flow table version, it distributes the new version flow table to each target server node. Each target node compares its current local flow table version with the received flow table version. If the version number increases, it performs a process instance addition or destruction operation based on the difference between the expected number of instances and the current number of running instances, and feeds the execution result back to the deployment controller for update display.

8. The multi-process collaborative management system for preventing equipment abandonment according to claim 1, characterized in that, In the task management module, the task information filled in by maintenance personnel includes the task description, planned start time, and planned end time; the task order number generated by the task management process is composed of the department code, date serial number, and the last four digits of the equipment's unique identifier.

9. The multi-process collaborative management system for preventing equipment abandonment according to claim 1, characterized in that, In the early warning module, the preset multi-level receiving end order is as follows: the first level is the maintenance personnel themselves, the second level is the maintenance personnel's direct supervisor, and the third level is the regional safety officer; the frequency increase strategy is as follows: the interval between re-pushing the early warning message to the current level and the previous level is shortened to half of the original interval, and the number of pushes is increased by one.

10. The multi-process collaborative management system for preventing equipment abandonment according to claim 1, characterized in that, It also includes a dead-letter queue processing module, which is used to periodically scan the warning messages in the dead-letter queue. For each warning message, it records the duration of its stay in the dead-letter queue. If the duration exceeds the preset delay retry threshold, the message is removed from the dead-letter queue and resubmitted to the message queue entry of the warning module. If the same warning message is removed from the dead-letter queue and resubmitted a specified number of times without receiving an acknowledgment signal from any level of receiver, the message is written to the persistent alarm database and a system email notification to the administrator is triggered.

11. The multi-process collaborative management system for preventing equipment abandonment according to claim 1, characterized in that, In the device management module, the unique identifier of the device is determined collaboratively by both the RFID identification channel and the visual identification channel: The RFID identification channel reads the electronic tags of the equipment in the work area through the RFID reader to obtain the RFID identification mark and the tag signal quality; After acquiring images from the device via image acquisition, the visual recognition channel obtains visual recognition labels and visual confidence levels through AI target recognition and OCR text recognition. The device management process performs a double consistency comparison between the RFID identification tag and the visual identification tag of the same device. Only when the two are consistent and the overall identification confidence is not lower than the preset acceptance threshold is it determined to be a double consistency confirmation. The device's unique identifier, current status and timestamp are written as the second message to the message queue. Otherwise, generate a consistency check message, including conflict types, and write it to the message queue.

Images