Hierarchical alarm handling arrangement method, device and system for nursing homes

Abstract

The application discloses a hierarchical alarm handling arrangement method, device and system for a pension institution; the method acquires standardized alarm events and real-time resource states, determines matched standard operation procedures as task graphs containing atomic tasks, resource role slots, dependency relationships, preemption attributes and safety constraints; automatically generates capability, time sequence, route, resource mutual exclusion and safety hard constraints from the task graphs, and obtains feasible or optimized plans within a limited time; converts the safety constraints into control parameters supported by target terminals, generates task instructions with plan versions, task versions, instruction sequence numbers and expected state versions; implements compensation, manual takeover and incremental re-arrangement according to execution feedback, and activates a new plan after receiving cancellation or update confirmation; and the application improves the safety, consistency and traceability of multi-alarm concurrency and heterogeneous terminal collaborative handling.

Description

Technical Field

[0001] This invention belongs to the fields of smart elderly care information technology, task scheduling and heterogeneous execution terminal collaborative control technology. Specifically, it relates to a method, device and system for converting multi-source alarms, standard operating procedures of elderly care institutions, real-time resource status and security requirements into atomic task graphs, joint constraint models and versioned executable instructions, and completing closed-loop processing through execution status feedback. Background Technology

[0002] Elderly care facilities are gradually deploying smart mattresses, millimeter-wave radar, wearable devices, call buttons, environmental sensors, nurse station terminals, and inspection, delivery, and companion robots. These devices can generate alarms for falls, getting out of bed, abnormal heart rate, abnormal breathing, requests for help, getting lost, and environmental risks. However, the generation of alarm events does not directly lead to a closed-loop response. Actual response still requires combining the elderly person's medical history, individual baseline data, event evidence, on-duty personnel, robot capabilities, spatial distance, task time limits, and safety rules to form a task that can be executed by personnel or equipment and can be continuously tracked.

[0003] Existing technologies typically suffer from the following problems: First, alarm fields, time formats, location codes, and confidence levels differ across brands of equipment, and some systems mix factual fields, risk assessments, and handling strategies within the same data object, making it difficult to distinguish between original facts and system decisions during subsequent audits. Second, standard operating procedures in elderly care institutions are often stored in natural language, flowcharts, or based on human experience, and cannot be directly translated into atomic tasks, resource roles, dependencies, and mathematical constraints. Consequently, manual queuing remains necessary when multiple alarms occur concurrently. Third, the simple approach of "assigning one execution entity to each alarm" is insufficient to cover real-world elderly care scenarios. A fall alarm may simultaneously require a patrol robot to obtain on-site video, a caregiver to arrive, a nurse to assess the situation, a first-aid kit to be delivered, and notification from family members or emergency medical services. Without breaking down an alarm into multiple synchronous and dependent atomic tasks, it is difficult to accurately represent multi-resource collaboration. Fourth, some scheduling models only use static resource quantity constraints, failing to consider resource capabilities, personnel qualifications, shifts, battery power, task execution duration, inter-task travel time, and time exclusivity for the same resource. This can easily lead to mathematically feasible but practically unfeasible solutions. Fifth, the low-level obstacle avoidance commonly used by robots can only guarantee collision-free operation in a general sense, and it is difficult to directly express operational safety requirements such as "maintaining a safe distance around a fallen person," "low speed and quiet operation at night," and "prioritizing emergency tasks but not compromising personnel safety." If low-level safety parameters are directly generated by the language model, unpredictable risks may arise. Sixth, dynamic reprogramming is usually only described as "canceling old instructions and issuing new instructions," but the physical task may already be en route or in progress, leading to problems such as out-of-order old and new instructions, unconfirmed cancellations, irreversible actions, and lack of takeover in the event of a network outage.

[0004] Therefore, a technical solution is needed that can reliably connect alarm facts, auditable handling decisions, standard operating procedures, formal constraints, versioned instructions, and execution status, so that elderly care institutions can still obtain a safe, traceable, and degradeable handling loop under conditions of multiple alarm concurrency, heterogeneous resource collaboration, network fluctuations, and execution failures. Summary of the Invention

[0005] I. Purpose of the Invention The purpose of this invention is to provide a hierarchical alarm handling orchestration method, device, and system for elderly care institutions. This scheme uses deterministic standard operating procedure compilation, joint constraint solving, controlled safety semantic compilation, versioned instructions, and execution status confirmation as its main technical lines, transforming alarm events into executable, verifiable, traceable, and manually manageable handling plans. Constrained intelligent agents can be used as one orchestration control implementation method, but they do not constitute the only way to implement the core technology chain.

[0006] II. Technical Solution To achieve the above objectives, the present invention adopts the following technical solution.

[0007] A tiered alarm handling and orchestration method for elderly care institutions includes the following steps: S1, acquire standardized alarm events generated by sensing devices, risk warning systems or manually triggered terminals and the current resource status, and match a predefined standard operating procedure template according to the alarm type, handling risk level and strategy version of the standardized alarm events; S2, the standard operation program template is compiled into a task graph G=(V,A) by the deterministic standard operation program compiler, where V is a set of atomic task nodes, each atomic task node includes at least one resource role slot, time window, preemptible attribute and controlled safety constraint object, and A is a set of preconditions, synchronization, conditional branches or mutual exclusion relationships between atomic task nodes. S3. Automatically generate a joint constraint model based on the task graph and the current resource status. The joint constraint model includes at least allocation decision constraints between atomic tasks and candidate resources, time window constraints, timing constraints, resource exclusivity and order constraints, and resource capacity constraints. Obtain an execution plan that satisfies the safety hard constraints within a preset solution time. S4. Based on the capability declaration of the candidate execution terminal, the controlled security constraint object is converted into a security control payload that can be recognized by the interface of the candidate execution terminal. After completing the interface-level compatibility verification, a versioned task instruction is generated. The versioned task instruction includes at least the plan version number, task version number, instruction sequence number, idempotency identifier, and expected state version. S5, send the versioned task instruction to the execution terminal and receive the execution status; generate a candidate new plan when a new alarm occurs, execution fails, resource status changes, or environment status changes, activate the candidate new plan only after the affected execution terminal returns a cancellation confirmation or update confirmation, and make the execution terminal reject outdated instructions lower than the current version; maintain the original security action or transfer to manual takeover when no confirmation is received.

[0008] Furthermore, the standard event envelope and the handling context are recorded and associated with the event identifier respectively; the standard event envelope records the original alarm facts, resource system risk output, evidence references and data versions, and the handling context records the handling risk level, resource capacity requirements, time limit strategy, security strategy, compensation and manual takeover strategy, as well as the corresponding rule version, model version, standard operating procedure version and profile version.

[0009] Furthermore, the standard operating procedure template consists of six parts: disposal type, resource roles and quantity requirements, priority rules, time safety and compliance constraints, task execution steps, and failure compensation and degradation takeover strategies; the deterministic standard operating procedure compiler generates corresponding resource role slots for each atomic task node and outputs the template version, compilation version, and task graph version.

[0010] Furthermore, in the joint constraint model, the allocation decision constraint between the atomic task and the candidate resource is that any atomic task can only be allocated to the candidate resource that meets its capability, qualification, accessibility and security compliance requirements, and the number of resources allocated to any atomic task is equal to its preset resource requirement. The time window constraint is as follows: if the atomic task is executed serially by multiple resources, the total execution time of the task is equal to the sum of the execution times of each resource; if the atomic task is executed in parallel by multiple resources, the total execution time of the task is equal to the team's collaborative completion time. The timing constraint stipulates that the start time of the atomic task is no earlier than the preset earliest start time and no later than the sum of the preset latest start time limit and the start time limit slack; at the same time, the completion time of the atomic task is stipulated to be no later than the sum of the preset latest completion time limit and the completion time limit slack. For task pairs with prerequisite dependencies, the start time of the subsequent task is limited to no less than the sum of the completion time of the prerequisite task and the preset minimum interval time. The resource exclusivity and order constraint are as follows: for multiple atomic tasks executed by the same candidate resource, the execution time periods of each atomic task are limited to not overlap, and the travel time from the previous task position to the next task position is required to be included when the execution order is switched. The resource capacity constraint is that the real-time load value of any candidate resource at any given time does not exceed its preset capacity limit.

[0011] Furthermore, the joint constraint model employs a hierarchical multi-objective optimization or multi-objective hierarchical weighted optimization approach, optimizing and solving the following objectives in descending order of priority: (1) First priority: Minimize service level agreement time limit defaults calculated by risk weight; (2) Second priority: Minimize task start time or completion time calculated by risk weight, and ensure that critical handling actions are started and completed as early as possible; (3) Third priority: Minimize overall resource scheduling and travel costs, including fixed costs of resource execution tasks, path travel overhead and load imbalance between resources; (4) Fourth priority: Minimize plan switching costs; that is, when incremental rescheduling occurs, minimize the switching overhead caused by reassigning or canceling tasks in transit, so as to maximize the stability of the physical execution terminal's actions; In the solution implementation, if a large coefficient weighting method is adopted, the weighting coefficients of each level need to be distributed in a decreasing nonlinear manner to ensure that high-priority objectives are absolutely satisfied. The constraint solver outputs the best known feasible solution within a preset finite solution time, without making a commitment to a proven global optimum, in order to meet the strong real-time response requirements of high-concurrency alarms in the elderly care scenario.

[0012] Furthermore, the types of controlled safety constraints include restricted space, minimum safe distance, maximum linear velocity, maximum angular velocity, silent mode, right-of-way level, mandatory manual confirmation, and non-preemptive; the restricted space is generated by coordinate transformation between the mechanism map coordinates and sensor positioning results, and the safety boundary is expanded according to the positioning reliability or positioning error; when the positioning reliability is lower than the threshold or the coordinate transformation fails, the autonomous execution command to approach the human body is stopped and alternative resources or manual takeover is triggered.

[0013] Furthermore, the resource capability matching constraint is verified before solving based on resource type, personnel qualifications, shift, power consumption, access control permissions, spatial accessibility, and abstract functional capabilities; the interface-level compatibility verification is used to confirm whether the target execution terminal supports the corresponding security constraint type, parameter field, and constraint version before the instruction is issued.

[0014] Furthermore, the task lifecycle state machine includes at least the following states: created, issued, confirmed, in transit, arrived, executing, completed, failed, cancelled pending confirmation, cancelled, and manually taken over. Failure handling distinguishes between retryable actions, reassignable actions, compensable actions, irreversible actions, and actions requiring manual confirmation, and triggers corresponding state transitions based on the failure code, confirmation timeout, heartbeat, and state version.

[0015] Furthermore, when the central network is unavailable, edge nodes use locally cached and version-verified alarm classification rules, core standard operating procedures, resource contacts, and manual call policies to perform degradation processing. After the network is restored, the event, instruction, and feedback logs during the network outage are deduplicated and conflict-merged according to the event identifier, plan version, task version, and instruction sequence number.

[0016] Furthermore, the constrained agent, as an orchestration and control component, maintains event states, policy versions, plan states, and feedback states, and invokes the rule engine, standard operating procedure compiler, constraint solver, security constraint compiler, and notification interface under the restrictions of the permission list and audit rules.

[0017] Furthermore, the large language model component only receives structured risk results, evidence summaries, and disposal plans to generate explanatory texts, handover summaries, or candidate communication texts, and has no right to independently modify the disposal risk level, service level agreement time limit, resource allocation, security constraints, compensation strategies, or plan versions.

[0018] A hierarchical alarm handling orchestration system for elderly care institutions includes an event adaptation module, a handling context generation module, a standard operating procedure (SOP) compilation module, a constraint modeling and solving module, a safety constraint compilation module, a version control and state machine module, and a heterogeneous execution terminal, which sequentially interact with each other. Specifically, the event adaptation module outputs standardized alarm events; the handling context generation module outputs handling context based on the standardized alarm events and the current resource status; the SOP compilation module generates an atomic task graph based on the handling context; the constraint modeling and solving module generates an execution plan based on the atomic task graph and the current resource status; the safety constraint compilation module generates a safety control payload based on the execution plan and the execution terminal's capability declaration; and the version control and state machine module generates versioned task instructions and controls the activation of new plans based on cancellation or update confirmations returned by the execution terminal.

[0019] A hierarchical alarm handling and orchestration device for elderly care institutions includes a processor, a memory, and a communication interface. The memory stores a computer program, which, when executed by the processor, interacts with an execution terminal through the communication interface to implement the aforementioned method.

[0020] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method.

[0021] 1. Separation of standard event envelope from handling context The system first performs protocol adaptation on raw events from multi-brand sensing devices, risk warning systems, and human terminals to form standard event envelopes. Each standard event envelope records factual inputs, source system risk outputs, evidence citations, and data versions; the handling context records the handling risk level, resource requirements, time limits, security policies, and compensation strategies. Both are recorded separately and linked through event identifiers, thus ensuring the traceability of original facts, subsequent decisions, and corresponding versions.

[0022] 2. Compilation of standard operating procedures into atomic task diagrams The standard operating procedure template is represented as SOP=<T,R,P,K,Q,F>. Here, T represents the disposal type, R represents the resource roles and quantities, P represents the priority rules, K represents time, safety, and compliance constraints, Q represents steps, dependencies, synchronization, and conditional branches, and F represents failure compensation, degradation, and manual takeover strategies. The deterministic standard operating procedure compiler combines the template with the disposal context to output a task graph G=(V,A). In the task graph, V is the set of atomic task nodes, each atomic task node including one or more resource role slots; A is the set of prerequisite, synchronization, mutual exclusion, or conditional relationships between nodes.

[0023] When a response step requires multiple executors, the system breaks it down into multiple atomic tasks. For example, a fall response can be broken down into nodes such as on-site video verification, caregiver arrival, nurse assessment, emergency supplies delivery, and external notification, and connected by relationships such as "prior to," "start simultaneously," and "triggered after conditions are met."

[0024] 3. Formal Constraint Modeling and Time-Limited Solution The system automatically generates decision variables and constraints based on the atomic task graph. For atomic task i and candidate resource j, allocation variables x_ij are set; start time s_i, completion time f_i, latest start default variable L_i^start, and latest completion default variable L_i^finish are also set. The system simultaneously maintains a resource capability matrix, resource availability time, task-related execution duration, inter-task travel time, personnel qualifications, equipment capabilities, power consumption, spatial accessibility, and security constraint support capabilities.

[0025] In the constraint model, personnel safety, equipment safety, qualifications, accessibility, restricted space, resource time exclusivity, and non-preemptible actions are considered hard constraints that cannot be relaxed. Confirmation, initiation, arrival, or completion deadlines in the service level agreement (SLA) can be set as hard deadlines or soft deadlines with default variables, depending on the risk level. The solution objective is to first reduce deadline defaults for high-risk tasks, secondly reduce weighted start or completion times, and thirdly reduce travel, load imbalance, and schedule changeover costs. The solver outputs the best known feasible solution within a preset time; if no feasible solution satisfies the hard constraints, a downgrade and manual takeover are triggered.

[0026] 4. Controlled security semantic compilation and terminal capability verification Safety constraints are represented using controlled types, fixed fields, and versioning rules. The deterministic safety constraint compiler converts objects such as restricted areas, minimum safe distances, maximum linear velocity, maximum angular velocity, silent mode, right-of-way levels, mandatory manual confirmation, and non-preemption into specific execution terminal interface parameters. Resource capability matching verifies abstract capabilities, qualifications, shifts, power consumption, and accessibility before solving; interface-level compatibility verification verifies whether the specific terminal supports the corresponding safety parameter fields and constraint versions before issuing instructions. If not supported or if environmental location confidence is insufficient, alternative resources are selected or manual intervention is initiated.

[0027] 5. Versioned task instructions and physical execution state machine Each task instruction carries a plan version, task version, instruction sequence number, idempotency flag, desired state version, and validity period. The execution terminal only accepts instructions whose version is compatible with the current state and rejects outdated, duplicate, or unauthorized instructions. The task state machine is used to distinguish between states such as created, issued, confirmed, en route, arrived, executing, completed, failed, canceled pending confirmation, canceled, and manually taken over. For actions in the physical world that cannot be restored to the state before execution, this invention employs retry, reassignment, compensatory actions, safe stop, degradation, and manual takeover, and records the current physical state.

[0028] 6. Incremental Rearrangement and Edge Degradation When new alarms, resource failures, path congestion, or risk escalation occur, the system retains completed and non-preemptible tasks, adds switching costs to tasks that can be preempted, and constructs an incremental problem-solving mechanism. New plans are only activated after the affected execution terminal confirms cancellation or update; otherwise, the original safety actions are maintained or manual takeover is triggered immediately. When the central network is unavailable, edge nodes use locally cached core rules, standard operating procedures, and manual call strategies to complete minimum safety measures, and re-upload logs and merge versions after network recovery.

[0029] IV. Beneficial Effects (1) By separating the standard event envelope from the handling context, this invention can distinguish the original evidence, the source system risk output and subsequent decision-making, which facilitates auditing, review and accountability.

[0030] (2) By compiling the standard operating procedure into an atomic task graph, the present invention can express the real handling process of an alarm that requires the collaboration of multiple robots, caregivers and nurses, thus avoiding the alarm being mistakenly limited to a single resource task.

[0031] (3) The present invention uses resource capability matrix, time non-overlap and travel time constraints to make the mathematical solution consistent with the actual personnel qualifications, equipment capabilities, spatial location and task execution order.

[0032] (4) This invention prioritizes reducing service level agreement defaults in high-risk events through hierarchical objectives and time-limited feasible solutions, and avoids making commitments that are necessarily globally optimal in real-time scenarios.

[0033] (5) The present invention converts the security requirements of elderly care services into verifiable control parameters through controlled security constraint objects and deterministic compilers, and automatically downgrades when the terminal does not support it or the location confidence is insufficient.

[0034] (6) The present invention reduces physical execution conflicts caused by duplicate, out-of-order and obsolete instructions by using plan version, task version, instruction sequence number and expected state version.

[0035] (7) The present invention can maintain minimum safety measures in the event of equipment failure, network disconnection and environmental changes by means of state machine, compensation action, manual takeover and edge degradation.

[0036] (8) This invention preserves the natural language interaction capability by limiting the large language model to only generating explanations, summaries and communication texts, while avoiding its direct modification of risk levels, resource allocation and security parameters. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the overall system architecture and data flow of the present invention.

[0038] Figure 2 This is a schematic diagram of the method flow of the present invention.

[0039] Figure 3 A schematic diagram of compiling standard operating procedures into atomic task graphs and mapping them into constraint models.

[0040] Figure 4 This is a schematic diagram of the task lifecycle state machine.

[0041] Figure 5 This is a schematic diagram of the versioned incremental re-compilation process. Detailed Implementation

[0042] The present invention will be further described below with reference to the accompanying drawings and embodiments. These embodiments are used to illustrate the technical implementation of the present invention, and are not intended to limit the scope of protection to specific device brands, communication protocols, solvers, or parameter values.

[0043] Implementation Method 1: System Overall Architecture like Figure 1As shown, the system includes an event adaptation and standardization module, a constrained agent decision-making module, a standard operating procedure compilation module, a constraint modeling and solving module, a safety constraint compilation and capability verification module, a versioned task instruction module, a state machine and fault tolerance module, an edge degradation module, and a heterogeneous execution terminal. Figure 2 This is a flowchart of the method of the present invention.

[0044] The constrained agent is not a single language model, but rather an orchestration component with the capabilities of event states, policy versions, tool calls, plan states, and feedback observations. It can invoke the rule engine, risk scoring model, standard operating procedure compiler, constraint solver, and notification interface, but its executable actions are limited by the permission list, policy versions, and audit rules. If the language model is enabled, it is only attached as an interpretation component after structured decision-making.

[0045] Implementation Method 2: Standard Event Envelope and Handling Context One data structure for a standard event envelope is shown in the table below.

[0046]

[0047] One data structure for handling context is shown in the table below.

[0048]

[0049] The risk review output simultaneously saves the source system risk, the reviewed risk, the reason code, and the model or rule version. If the confidence level is insufficient, evidence is missing, the profile version is outdated, or there is a rule conflict, the system can mark the risk as "requiring manual review" instead of inferring the missing key facts through a language model. The risk level and priority generated by this invention are only used for alarm task classification, resource scheduling, and execution terminal control; they do not directly output disease diagnosis conclusions, nor do they replace the diagnosis or treatment decisions made by medical personnel.

[0050] Implementation Method 3: Standard Operating Procedure Compilation and Atomic Task Diagram A standard operating procedure template should include at least the task steps, roles, quantity, time window, conditional branches, safety requirements, and failure strategies. For example... Figure 3 As shown, after receiving the template and disposal context, the compiler performs the following processing: (1) Break down complex steps that require multiple execution entities into independent atomic task nodes, and set one or more resource role slots for each node; (2) Determine the start time, latest start time, latest completion time, and execution duration for each atomic task; (3) Convert processes such as “video verification first, then decide whether to deliver the first aid kit” into conditional edges; (4) Convert the requirement of “starting the assessment after both the caregiver and the inspection robot have arrived” into a synchronous relationship; (5) Mark the attributes as preemptible, non-preemptible, retryable, compensable, and requiring manual confirmation; (6) Generate sopVersion, compilerVersion and taskGraphVersion.

[0051] For example, a fall handling template can be compiled into a task graph as shown below.

[0052]

[0053] Implementation Method 4: Resource Capabilities, Time and Space Constraints The resource capability profile includes at least the resource type, skills or qualifications, supported sensing and communication capabilities, reachable area, current location, shift, task status, remaining battery power, maximum load, number of tasks that can be performed concurrently, and supported security constraint types. The system generates a_ij based on the task capability requirements and the resource capability profile.

[0054] When the resource is personnel, capability verification may include nurse qualifications, caregiver training level, whether they are on duty, and whether they have undertaken uninterrupted tasks; when the resource is a robot, capability verification may include navigation, two-way audio and video, load capacity, power consumption, access control, and corresponding safety control interfaces.

[0055] Resource time constraints are expressed using available intervals and non-overlapping relationships. For two tasks executed consecutively on the same resource, the system adds the travel time from the end of the previous task to the start of the next task. Travel time can be provided by the organization map path planner or estimated from historical running data. If a road is blocked, the path planner updates `travel_ikj` and triggers incremental rescheduling.

[0056] Example 1: One way to implement a mathematical model Let I be the set of atomic tasks and J be the set of candidate resources. Indicates whether atomic task i is assigned to resource j; This indicates whether resource j meets the capability, qualification, reachability, and security constraint support requirements of task i. Each atomic task is allocated only to one or more required resources that meet the conditions.

[0057] and . Indicates the amount of resources required for task i. set up For the start time, For completion time, Let i be the estimated execution time. Then:

[0058] If the task is completed serially by multiple resources, then This is the sum of the execution times of all resources. If the task is completed by multiple resources working in parallel, then... It is determined by the time required for the team to complete the task collaboratively.

[0059] set up The start time of the task. The latest start time, The latest completion time; If these are used to measure the latest start time and latest finish time breach that can be relaxed, then: ; .

[0060] For a task in the task graph that has a preceding edge (i,k), let... To minimize the interval, then:

[0061] For tasks i and k that may be executed by the same resource, the model ensures they do not overlap through order variables and mutual exclusion time window constraints, or the NoOverlap constraint in constraint programming, and incorporates the travel time travel_ikj from task i to task k. This constraint avoids static... .

[0062] To ensure that physical safety constraints are not violated while balancing efficiency and operational costs, a hierarchical multi-objective optimization model was constructed. Specifically, the joint constraint model employs hierarchical multi-objective optimization or multi-objective hierarchical weighted optimization, optimizing the following objectives in descending order of priority: (1) First priority (highest priority): Minimize Service Level Agreement (SLA) deadline defaults calculated based on risk weights. That is, based on the risk weight of the task, minimize the weighted sum of the latest start deadline default and the latest finish deadline default, so as to ensure that the safe performance of high-risk and urgent tasks takes precedence over any other efficiency indicators; (2) Second priority: Minimize the task start time or finish time calculated based on risk weights, so as to ensure that critical actions are started and completed as early as possible; (3) Third priority: Minimize overall resource scheduling and travel costs, including the fixed cost of resource execution, path travel overhead, and load imbalance between resources; (4) Fourth priority: Minimize plan switching costs. That is, when incremental rescheduling occurs, minimize the switching overhead caused by reassigning or canceling tasks in transit, so as to maximize the stability of the physical execution terminal's actions.

[0063] In the solution implementation, if a large-coefficient weighting method is used, the weighting coefficients of each level must have a decreasing non-linear distribution to ensure that high-priority objectives are satisfied with absolute priority. The constraint solver outputs the best known feasible solution within a preset finite solution time, without making a commitment to a proven global optimum, in order to meet the strong real-time response requirements of high-concurrency alarms in elderly care scenarios.

[0064] Implementation Method 5: Security Constraints and Deterministic Compilation Security constraint objects are represented using controlled fields. One object structure includes constraintType, scope, geometry, value, precedence, sourceRef, confidence, validFrom, validTo, and fallbackAction. Examples of available types are shown below.

[0065]

[0066] The restricted space is not simply defined by coordinates directly provided in the SOP text. The system first converts the positions generated by millimeter-wave radar, cameras, bedside sensors, or manual annotations to the organization's unified map coordinate system, and then expands the safety boundary by combining positional reliability and human contour estimation. One non-restrictive calculation method is... Where d_0 is the basic safety distance, q is the normalized positioning confidence level, and k is the error expansion coefficient; another approach is to form a confidence ellipse based on the positioning covariance and extend it by a preset safety distance. If the coordinate transformation fails or the confidence level is below the threshold, the robot will not send autonomous execution commands to approach the human body, but will instead maintain a safe distance and call for personnel.

[0067] Right-of-way levels only address the order of passage between robots or equipment and are always subordinate to hard safety constraints such as pedestrian collision avoidance, fire evacuation, and medical personnel access. Therefore, high-priority robots will not be granted "absolute right-of-way" that would compromise pedestrian safety; low-priority robots will only stop, yield, or replan when safety conditions permit.

[0068] Implementation Method Six: Versioning Protocol and Task State Machine The unified interaction protocol can run on top of message queues, HTTP, WebSocket, or other communication mechanisms, and is not limited to a specific protocol. Task messages must contain at least the following fields: taskId, eventId, planVersion, taskVersion, commandSeq, idempotencyKey, expectedStateVersion, issuedAt, expiresAt, target, requiredCapabilities, safetyPayload, actionPayload, and fallbackPolicy.

[0069] The execution terminal maintains `lastPlanVersion`, `lastTaskVersion`, and `lastCommandSeq`. Upon receiving a command, it first verifies the user's identity, signature, or access permissions, then verifies the version, validity period, expected state, and capabilities. Duplicate idempotent flags only return existing results; commands with versions lower than the current version are rejected and `STALE_COMMAND` is returned; commands that cannot satisfy security constraints return `UNSUPPORTED_SAFETY_CONSTRAINT`.

[0070] State machines such as Figure 4 As shown. For confirmation timeouts, a retry or reassignment can be performed; for pathfinding failures, the path can be updated and the solution recalculated; for network disconnections, a local call can be triggered by the edge node; for irreversible action failures, the system records the current physical state and performs compensation or manual takeover, rather than assuming that the state before execution can be restored.

[0071] Example 2: Nighttime Multiple Alarm Concurrency and Multi-Resource Collaboration The scenario time is 3:15 AM. On-duty resources include Nurse A, Nurse B, Caregiver C, Inspection Robot R1, Delivery Robot R2, and Companion Robot R3. The system simultaneously receives the following alarms.

[0072]

[0073] The SOP compiler expands the three events into multiple atomic tasks. E1 generates F1 inspection robot video verification, F2 nurse arrival, F3 nurse assessment, and conditional task F4 first aid kit delivery; E2 generates H1 nurse arrival and H2 nurse station notification preparation; E3 generates C1 companion robot voice verification and conditional task C2 nurse assistance.

[0074] The constraint solver generates the following initial plan based on capacity, location, shift, and time window.

[0075]

[0076] In this embodiment, a fall alarm is compiled into multiple collaborative tasks. Delivery robot R2 participates in constraint solving as a candidate executor in the task graph, rather than being added temporarily outside the solution results. All subsequent executors are derived from the task graph and the solution results, ensuring consistency between plans, instructions, and audit logs.

[0077] Example 3: Security-constrained compilation and capability-inadequate degradation When R1 moves to room A, the sensor fusion module generates the outline region of the fallen person in a unified map coordinate system and extends the boundary outward by 0.6 meters based on the positioning error. The SOP safety configuration generates FORBIDDEN_ZONE, MIN_STANDOFF_DISTANCE=0.8 meters, MAX_LINEAR_SPEED=0.3 meters / second, SILENT_MODE=true, and HUMAN_CONFIRM_REQUIRED=true.

[0078] The safety compiler converts the above objects into dynamic cost maps, speed limits, and audio switch parameters supported by the R1 navigation interface. If the R1 capability declaration does not support dynamic restricted areas, the system does not issue close-range video verification tasks to R1, but instead reassigns the tasks to caregiver C, allowing R1 to remain outside the door for long-distance communication.

[0079] When R1 encounters a regular delivery robot, the regular delivery robot slows down or avoids it according to RIGHT_OF_WAY_LEVEL; however, when there are people, fire evacuation, or medical staff pushing a bed through the corridor, both robots obey the rules of personnel safety and fire priority.

[0080] Example 4: Execution Failure, Compensation, and Edge Degradation If no confirmation is received from R1 within 5 seconds after the task is assigned, the state machine will transition the task from "assigned" to "failed," and the system will check the idempotent retry count and network status. If the network is normal, it can be retried once or other resources can be reassigned; if the network is abnormal, the edge node will directly issue a local audio-visual prompt at the nurse station and send a local network message to nurse C's mobile terminal.

[0081] If R1 reports PATH_BLOCKED en route, the system updates the path travel time and attempts alternative routes; if still unreachable, the task is reassigned to caregiver C. If R1 has already approached the human body and entered an unpreemptible safety stop action, it must not be canceled directly; a safety stop should be completed first, and the status confirmation should be returned.

[0082] Edge nodes cache the most recently valid core SOPs, P0 / P1 alarm classification rules, contacts, and manual call policies. Events, tasks, and feedback during network outages are stored in local immutable logs; after network recovery, they are deduplicated and retransmitted according to eventId, planVersion, taskVersion, and commandSeq.

[0083] Example 5: Versioned Incremental Rearrangement Triggered by New Alarms Figure 5 This is a schematic diagram of the versioned incremental reordering process. In the initial plan V1, R1 is heading to room A to execute F1, and caregiver C is heading to room A to execute F2. At t=30 seconds, a new fall event E4 (P0) is added to room B. The system first reads the current state of V1: R1 is en route and allowed to preempt at a safe point, and caregiver C has approached room A and has been marked as non-preemptible.

[0084] Incremental solution retains the caregiver C task and compares the following candidate options: Option A keeps R1 heading to room A, while nurse B or other available resources head to room B; Option B reassigns R1 to room B after reaching a safe turning point, while nurse A performs video or on-site verification for room A. The objective function simultaneously calculates SLA default, travel time, and reassignment switching costs for both events. The system outputs the best known feasible plan V2 obtained up to the preset solution time based on the objective function, without pre-limiting any candidate option.

[0085] For the affected R1, the system sends planVersion=2, taskVersion update, and expectedStateVersion. If R1 confirms that it is in a preemptible state, it returns UPDATE_ACK, and the system then activates V2; if R1 has entered a non-preemptible area or fails to confirm within the time limit, the system maintains the safety action in V1 and triggers manual takeover, without activating two conflicting sets of instructions at the same time.

[0086] Example 6: Limited Use of Language Interpretation Components After completing risk review and task solving, the system can send the structured results to the language interpretation component to generate a nurse station summary: "A suspected fall in room A, confidence level 0.92; upgraded to P0 due to history of osteoporosis; R1 is conducting video verification, nurse C has departed, and nurse A will assess the situation after receiving on-site information." This component cannot change the P0 level, task assignment, latest arrival time, or safe distance.

[0087] The generated explanatory text is saved in association with the input planVersion, policyVersion, and evidenceRef. When the structured plan changes, the old explanatory text is marked as outdated to prevent caregivers from implementing it based on old texts.

[0088] Implementation Method Seven: Alternative Implementation Constraint solvers can employ mixed integer programming, constraint programming, CP-SAT, heuristic search, or combinations thereof. Regardless of the solution method used, the system should first satisfy hard constraints such as personnel safety, equipment safety, and mandatory compliance, and then optimize SLA, time, and cost within a limited timeframe.

[0089] The execution terminal is not limited to robots, but can also include nurse stations, mobile phones, wearable terminals, broadcasting systems, access control systems, lighting systems, and call systems. For terminals that do not have autonomous execution capabilities, task instructions can be translated into notifications, confirmations, and manual feedback.

[0090] The above embodiments are used to illustrate the technical concept of the present invention and are not intended to limit the scope of protection of the present invention. Any equivalent substitutions made to event fields, task graph structures, constraint solving methods, communication protocols, state names, or execution terminal types without departing from the core technical features of the present invention shall fall within the scope of protection of the present invention.

Claims

1. A hierarchical alarm handling and scheduling method for elderly care institutions, characterized in that, Includes the following steps: S1, acquire standardized alarm events generated by sensing devices, risk warning systems or manually triggered terminals and the current resource status, and match a predefined standard operating procedure template according to the alarm type, handling risk level and strategy version of the standardized alarm events; S2, the standard operation program template is compiled into a task graph G=(V,A) by the deterministic standard operation program compiler, where V is a set of atomic task nodes, each atomic task node includes at least one resource role slot, time window, preemptible attribute and controlled safety constraint object, and A is a set of preconditions, synchronization, conditional branches or mutual exclusion relationships between atomic task nodes. S3. Automatically generate a joint constraint model based on the task graph and the current resource status. The joint constraint model includes at least allocation decision constraints between atomic tasks and candidate resources, time window constraints, timing constraints, resource exclusivity and order constraints, and resource capacity constraints. Obtain an execution plan that satisfies the safety hard constraints within a preset solution time. S4. Based on the capability declaration of the candidate execution terminal, the controlled security constraint object is converted into a security control payload that can be recognized by the interface of the candidate execution terminal. After completing the interface-level compatibility verification, a versioned task instruction is generated. The versioned task instruction includes at least the plan version number, task version number, instruction sequence number, idempotency identifier, and expected state version. S5, send the versioned task instruction to the execution terminal and receive the execution status; generate a candidate new plan when a new alarm occurs, execution fails, resource status changes, or environment status changes, activate the candidate new plan only after the affected execution terminal returns a cancellation confirmation or update confirmation, and make the execution terminal reject outdated instructions lower than the current version; maintain the original security action or transfer to manual takeover when no confirmation is received.

2. The method according to claim 1, characterized in that, The standard event envelope and the handling context are recorded separately and associated with the event identifier; the standard event envelope records the original alarm facts, resource system risk output, evidence references and data version, and the handling context records the handling risk level, resource capacity requirements, time limit strategy, security strategy, compensation and manual takeover strategy, as well as the corresponding rule version, model version, standard operating procedure version and profile version.

3. The method according to claim 1, characterized in that, The standard operating procedure template consists of six parts: disposal type, resource roles and quantity requirements, priority rules, time safety and compliance constraints, task execution steps, and failure compensation and downgrade takeover strategies. The deterministic standard operating procedure compiler generates corresponding resource role slots for each atomic task node and outputs the template version, compilation version, and task graph version.

4. The method according to claim 1, characterized in that, In the joint constraint model, the allocation decision constraint between the atomic task and the candidate resource is that any atomic task can only be allocated to the candidate resource that meets its capability, qualification, accessibility and security compliance requirements, and the number of resources allocated to any atomic task is equal to its preset resource requirement. The time window constraint is as follows: if the atomic task is executed serially by multiple resources, the total execution time of the task is equal to the sum of the execution times of each resource; if the atomic task is executed in parallel by multiple resources, the total execution time of the task is equal to the team's collaborative completion time. The timing constraint stipulates that the start time of the atomic task is no earlier than the preset earliest start time and no later than the sum of the preset latest start time limit and the start time limit slack; at the same time, the completion time of the atomic task is stipulated to be no later than the sum of the preset latest completion time limit and the completion time limit slack. For task pairs with prerequisite dependencies, the start time of the subsequent task is limited to no less than the sum of the completion time of the prerequisite task and the preset minimum interval time. The resource exclusivity and order constraint are as follows: for multiple atomic tasks executed by the same candidate resource, the execution time periods of each atomic task are limited to not overlap, and the travel time from the previous task position to the next task position is required to be included when the execution order is switched. The resource capacity constraint is that the real-time load value of any candidate resource at any given time shall not exceed its preset capacity limit.

5. The method according to claim 4, characterized in that, The joint constraint model employs a hierarchical multi-objective optimization or multi-objective hierarchical weighted optimization approach, optimizing and solving the following objectives in descending order of priority: (1) First priority: Minimize service level agreement time limit defaults calculated by risk weight; (2) Second priority: Minimize task start time or completion time calculated by risk weight, and ensure that critical handling actions are started and completed as early as possible; (3) Third priority: Minimize overall resource scheduling and travel costs, including fixed costs of resource execution tasks, path travel overhead and load imbalance between resources; (4) Fourth priority: Minimize plan switching costs; that is, when incremental rescheduling occurs, minimize the switching overhead caused by reassigning or canceling tasks in transit, so as to maximize the stability of the physical execution terminal's actions; In the solution implementation, if a large coefficient weighting method is adopted, the weighting coefficients of each level need to be distributed in a decreasing nonlinear manner to ensure that high-priority objectives are absolutely satisfied. The constraint solver outputs the best known feasible solution within a preset finite solution time, without making a commitment to a proven global optimum, in order to meet the strong real-time response requirements of high-concurrency alarms in the elderly care scenario.

6. The method according to claim 1, characterized in that, The types of controlled safety constraints include restricted space, minimum safe distance, maximum linear velocity, maximum angular velocity, silent mode, right-of-way level, mandatory manual confirmation, and non-preemptive; the restricted space is generated by coordinate transformation between the mechanism map coordinates and sensor positioning results, and the safety boundary is expanded according to the positioning reliability or positioning error; when the positioning reliability is lower than the threshold or the coordinate transformation fails, the autonomous execution command to approach the human body is stopped and alternative resources or manual takeover is triggered.

7. The method according to claim 1, characterized in that, The resource capability matching constraint is verified before solving based on resource type, personnel qualifications, shift, power consumption, access control permissions, spatial accessibility, and abstract functional capabilities; the interface-level compatibility verification is used to confirm whether the target execution terminal supports the corresponding security constraint type, parameter fields, and constraint version before the instruction is issued.

8. The method according to claim 1, characterized in that, The task lifecycle state machine includes at least the following states: created, issued, confirmed, in transit, arrived, executing, completed, failed, cancelled pending confirmation, cancelled, and manually taken over. Failure handling distinguishes between retryable actions, reassignable actions, compensable actions, irreversible actions, and actions requiring manual confirmation, and triggers corresponding state transitions based on the failure code, confirmation timeout, heartbeat, and state version.

9. The method according to claim 1, characterized in that, When the central network is unavailable, edge nodes use locally cached and version-verified alarm classification rules, core standard operating procedures, resource contacts, and manual call policies to perform degradation processing. After the network is restored, the event, instruction, and feedback logs during the network outage are deduplicated and conflict merged according to the event identifier, plan version, task version, and instruction sequence number.

10. The method according to claim 1, characterized in that, The constrained agent acts as an orchestration and control component, maintaining event states, policy versions, plan states, and feedback states, and invoking the rule engine, standard operating procedure compiler, constraint solver, security constraint compiler, and notification interface under the constraints of the permission list and audit rules.

11. The method according to claim 10, characterized in that, The large language model component only accepts structured risk results, evidence summaries, and disposal plans to generate explanatory texts, handover summaries, or candidate communication texts, and has no right to independently modify the disposal risk level, service level agreement time limit, resource allocation, security constraints, compensation strategy, or plan version.

12. A hierarchical alarm handling and orchestration system for elderly care institutions, characterized in that, The system includes an event adaptation module, a disposal context generation module, a standard operating procedure compilation module, a constraint modeling and solving module, a safety constraint compilation module, a version control and state machine module, and a heterogeneous execution terminal, which sequentially perform data interaction. Specifically, the event adaptation module outputs standardized alarm events; the disposal context generation module outputs a disposal context based on the standardized alarm events and the current resource status; the standard operating procedure compilation module generates an atomic task graph based on the disposal context; the constraint modeling and solving module generates an execution plan based on the atomic task graph and the current resource status; the safety constraint compilation module generates a safety control payload based on the execution plan and the execution terminal's capability declaration; and the version control and state machine module generates versioned task instructions and controls the activation of new plans based on cancellation or update confirmations returned by the execution terminal.

13. A hierarchical alarm handling and orchestration device for elderly care institutions, comprising a processor, a memory, and a communication interface, characterized in that, The memory stores a computer program, which, when executed by the processor, interacts with the execution terminal through the communication interface and implements the method described in any one of claims 1 to 11.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 11.

Images