A distributed shelter remote management and control method

Abstract

The application discloses a kind of distributed shelter remote management and control methods, specifically related to distributed shelter remote management and control technical field, for solving the problem that existing distributed shelter is prone to control mismatch, repeated execution and multi-cabin state inconsistency in link exception and recovery process. By establishing a control session with session identifier, version identifier, time-to-live identifier and linkage identifier for the target shelter group, and combining cabin side context summary, link portrait, execution semantic portrait, constrained control token, local execution record, constrained agent execution and recovery decision, a unified constraint closed loop is formed throughout the link exception, thereby achieving consistent control caliber, clear control boundary, recoverable process under weak network, broken link, autonomous switching and link recovery scenarios, avoiding the problems of incorrect control, repeated control, loss of control and cross-cabin state bifurcation after recovery caused by link fluctuations in the prior art.

Description

Technical Field

[0001] This invention relates to the field of distributed modular hospital remote control technology, specifically a distributed modular hospital remote control method. Background Technology

[0002] With the increasing adoption of modular deployment for emergency communications, medical support, edge computing, and mobile command, the connection of multiple remote modular units to a central control node via private networks, cellular networks, satellite links, or wired backhaul links has become a common remote collaborative operation method. Existing distributed modular unit systems typically enable remote start-up and shutdown, link switching, load adjustment, service delivery, and status feedback, and centrally manage each unit through heartbeats, receipts, and operational monitoring information. Under conditions of stable links, controllable latency, and minimal changes in the status of each unit, this approach can meet general remote scheduling needs and therefore has a certain application foundation in emergency support and mobile deployment scenarios.

[0003] However, in actual missions, the deployment environment of mobile shelters is often complex. Communication links are prone to short-term jitter, interruptions, restricted handover, and reconnection. The local operating status, power supply status, service maintenance status, and autonomous status of different shelters also change dynamically with site conditions. In existing technologies, the control issued by the central side and the execution, receipt, abnormal proxy, and reconciliation after recovery are often handled separately in different control links, lacking a consistent constraint benchmark around the same control task. Especially during and after link anomalies, existing solutions focus more on whether a single command was successfully sent or whether a single shelter has returned to online status, while lacking a unified connection between the control boundaries, execution boundaries, and recovery boundaries before and after the anomaly. This can easily lead to inconsistent interpretations of the same task across different shelters.

[0004] In the process of link anomaly and recovery in distributed modular shelter systems, existing technologies are prone to control mismatch, duplicate execution, and difficulty in achieving consistent convergence of multiple shelter states due to the lack of unified control constraints and reconciliation mechanisms that run through the pre-anomaly, during-anomaly, and post-recovery stages. This affects the stability and continuity of collaborative management and control of multiple modular shelters. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a distributed remote control method for mobile shelters, thereby resolving the problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for remote control of a distributed mobile shelter, comprising:

[0007] S1. Establish a control session for the target modular unit group, generate session identifier, version identifier, timeliness identifier and linkage identifier, and generate the corresponding modular unit context summary based on the current operating status of each target modular unit;

[0008] S2. Collect the link status, receipt continuity status, local autonomy status and recently effective command status of each target cabin, and generate link profile and execution semantic profile;

[0009] S3. Generate the corresponding constrained control token for the target container based on the session identifier, version identifier, timeliness identifier, container-side context summary, link profile, and execution semantic profile.

[0010] S4. Send the constrained control token to the corresponding target module, which performs condition verification based on the module-side context summary and generates a local execution record based on the condition verification result.

[0011] S5. During a link anomaly, the target container executes a constrained proxy based on the current effective control session and generates a local evidence fragment containing the reason for the proxy execution and the scope of alternatives.

[0012] S6. After the link is restored, receive the restoration reconciliation receipt returned by the target container, execute the restoration decision based on the restoration reconciliation receipt, and execute cross-containment convergence control based on the restoration decision result.

[0013] Furthermore, S1 includes:

[0014] The members of the target mobile cabin team were determined based on the task scheduling ledger, asset registration form, and online heartbeat records.

[0015] The version identifier is locked based on the rule repository, parameter repository, and interface configuration repository;

[0016] Time alignment is performed on the acquisition and transmission times in the cabin-side messages based on a unified time reference.

[0017] Generate a cabin-side context summary based on the current operational status after time alignment, and write it into the cabin-side context summary table using the session identifier and cabin number as unique keys.

[0018] Furthermore, S2 includes:

[0019] A continuous receipt status is formed based on the control token sending record, receipt receiving record, and timeout retry record;

[0020] The link status is obtained based on link monitoring messages, heartbeat messages, and link switching records;

[0021] The local autonomous status is obtained based on the autonomous policy status register and the autonomous switching record;

[0022] Obtain the status of the most recently effective command based on the command activation register and valid receipt records;

[0023] Generate a link profile based on link status and receipt continuity status;

[0024] Generate an execution semantic profile based on the local autonomy status and the status of the most recently effective command.

[0025] Furthermore, S3 includes:

[0026] Alignment is performed based on the current session master record, cabin-side context summary, link profile, execution semantic profile, and pending control content record, using the sampling time as a unified time benchmark.

[0027] The control scope is formed by comparing the set of control objects in the control content to be executed with the business instance list, resource list and power supply list item by item;

[0028] Execution priority is determined based on task level, linkage indicator, and remaining time.

[0029] Write the sending method flag based on the execution semantic profile and link profile.

[0030] Furthermore, when the semantic profile is ready to be directly accepted, the primary link status code in the link profile is available, and there are no high latency, high jitter, heavy packet loss, or frequent switching issues in the link profile, the write is sent immediately.

[0031] In other cases where a restricted control token can be generated, write restricted transmission;

[0032] When writing the transmission mode flag, retry boundaries and failure conditions are written simultaneously.

[0033] Furthermore, S4 includes:

[0034] The constrained control token is validated and deduplicated in the order of session identifier, version identifier, target container number, and token number.

[0035] Using the target container's reception time as the current baseline, and based on the container-side context summary and real-time status, condition checks are performed according to timeliness boundaries, version boundaries, object boundaries, autonomy boundaries, and duplication boundaries.

[0036] The execution boundary is determined based on the condition verification results, and a local execution record is generated.

[0037] Furthermore, S5 includes:

[0038] Link anomalies are determined based on local link status records, receipt transmission results, number of consecutive timeout periods, number of consecutive failed session periods, and the arrival time of the most recent valid token.

[0039] Based on the current effective control session, the most recent effective local execution record, the local autonomy level, and the real-time status of the cabin side, an alternative range is generated with the trimmed control range of the most recent effective local execution record as the upper limit.

[0040] Perform constrained proxy execution based on the scope of substitution, and generate local evidence fragments containing the reason for proxy execution and the scope of substitution.

[0041] Furthermore, S6 includes:

[0042] The reconciliation receipts are verified and deduplicated in sequence according to the session identifier, version identifier, target shelter number, and record time, and the adjudication base is determined based on the record time.

[0043] Perform recovery decisions based on session boundaries, version boundaries, execution boundaries, proxy execution boundaries, and object boundaries;

[0044] A single-cabin-level recovery decision record is generated based on the recovery decision.

[0045] Furthermore, based on the linkage identifiers, the single-module-level recovery decision records of each target module are summarized to form a cross-module convergence view;

[0046] Perform cross-compartment comparisons based on the recovery decision results, final agent execution scope, object removal records, and receipt missing flags in the cross-compartment convergence view;

[0047] Based on the cross-module comparison results, determine the cross-module convergence control results and generate a linkage group-level cross-module convergence control record.

[0048] Compared with the prior art, the present invention has the following beneficial effects:

[0049] 1. By establishing a control session with session identifier, version identifier, timeliness identifier and linkage identifier for the target modular unit group, and combining the modular unit context summary, link profile, execution semantic profile, constrained control token, local execution record, constrained proxy execution and recovery adjudication to form a unified constraint closed loop that runs through the link anomaly before, during and after. This achieves the goal of maintaining consistent remote control standards, clear control boundaries and adjudicable recovery process for multiple modular units in scenarios such as weak network, link loss, autonomous switching and link recovery. This avoids the problems of miscontrol, repeated control, loss of control and cross-unit state fork after recovery caused by link fluctuations in the existing technology.

[0050] 2. By introducing a constrained agent execution mechanism based on the current effective management session on the target container side, and combining the recovery reconciliation receipt with the recovery decision and cross-containment convergence control after the link is restored, the necessary business continuity can be maintained during the communication interruption, and the unified convergence of the status of each target container and the re-convergence of the linkage relationship can be achieved after the communication is restored. This improves the continuous operation capability and collaborative management stability of the distributed container system under complex field conditions. Attached Figure Description

[0051] Figure 1This is a flowchart illustrating a distributed remote control method for mobile shelters according to the present invention. Detailed Implementation

[0052] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0053] Example: Figure 1 A flowchart illustrating a distributed remote control method for a mobile shelter is provided. The distributed remote control method for a mobile shelter includes:

[0054] S1. Establish a control session for the target modular unit group, generate session identifier, version identifier, timeliness identifier, and linkage identifier, and generate a corresponding modular context summary based on the current operating status of each target modular unit. The specific implementation is as follows:

[0055] This procedure can be deployed in a distributed modular system consisting of emergency communication modular units, medical support modular units, edge computing modular units, and mobile command modular units. It is suitable for scenarios where a central control node remotely coordinates the start-up and shutdown, load switching, link switching, resource control, service migration, and status maintenance of multiple remote modular units within the same mission cycle. In the field, each target modular unit is connected to its in-unit controller, network equipment, power supply unit, service host, and environmental monitoring unit. The central control node communicates with each target modular unit through a private network, cellular network, satellite link, or wired backhaul link.

[0056] Upon initial appearance, the target modular unit group is a collection of modular units that need to accept unified constraints under the same coordinated task. Its member information is jointly determined by the task scheduling ledger, asset registry, and online heartbeat records. The task scheduling ledger serves as the primary determination source, the asset registry as the identity verification source, and the online heartbeat records as the reachability verification source. When the task scheduling ledger exists, the asset registry matches, and the online heartbeat record arrives within the last three collection cycles, the modular unit is included in the target modular unit group. When the task scheduling ledger exists, the asset registry matches, but the online heartbeat record is missing, the modular unit is recorded as a candidate member and does not participate in the generation of the current coordinated identifier. When the asset registry does not match, the modular unit number is duplicated, the business role conflicts, or the member number is added, deleted, or replaced within the session creation window, the modular unit is directly removed and a record is left. The verification period can be set from 500 milliseconds to 2 seconds.

[0057] A control session is a time-series continuous control context established around a single remote control task, created by the central control node within the first acquisition cycle after receiving a scheduling instruction. A unified time reference is provided by the time source bound to the central control node. Cabin-side messages carry both acquisition and transmission times; the acquisition time is prioritized for alignment. Alignment is directly performed when the acquisition time deviates from the central control node's current time by no more than 200 milliseconds; if the deviation exceeds 200 milliseconds but is less than 1 second, the transmission time is used for correction; and if the deviation exceeds 1 second, it is considered a time alignment failure. During creation, the task number and latest execution time are obtained from the task management service, the target cabin group members from the asset registration service, the currently available communication links and estimated round-trip time from the link management service, and the online status and most recent response time from the cabin-side heartbeat message. Fields that have not been updated for more than two collection cycles are marked as old values. Reference fields that have been missing for no more than three consecutive collection cycles are filled with the most recent valid value. Critical fields that have been missing for more than three consecutive collection cycles are marked as unavailable. Critical fields are fixed as online status, primary link status, most recently effective command version, and power supply status. Reference fields are fixed as cabin temperature, access control status, and resource usage. Both old and filled values ​​are written to the record with status flags. When a critical field is an old value, only control sessions in the observation state are allowed to be established. When a critical field is unavailable, the session establishment is terminated. Control sessions in the observation state are only allowed to continue to perform status collection, logging, and session maintenance. They are not allowed to generate constrained control tokens or enter subsequent control sending stages. The session creation completion time is fixed as the timestamp corresponding to the completion of member verification, version locking, time alignment, and successful writing of the session master record.

[0058] The session identifier is a unique identifier string that corresponds to this management session within the entire system. It is formed by combining the task number, the central management node number, the creation timestamp, and the sequence count when the current scheduling task is created. It remains unchanged within the same management session and serves as the main index for subsequent message routing, log collection, deduplication determination, and retry reconciliation.

[0059] The version identifier is the locking identifier for the set of parameter rules used in this control session. It is retrieved from the rule repository, parameter repository, and interface configuration repository during session establishment and formed by combining the rule version number, parameter version number, and interface version number in a fixed order. If any version is in a gray-scale release, not yet issued, or fails to be retrieved, the current session is terminated, and no version rollback is used. The validity period identifier is the allowed effective time boundary for this control session. Its start time is fixed at the session creation completion time, and its end time is obtained by subtracting the estimated round-trip latency and default retry time from the latest execution time, in milliseconds. The default value can be set to 5 to 120 seconds. During retry periods, the original validity period identifier is inherited and does not restart. The linkage identifier is a constraint identifier for multiple target modules participating in the same group linkage under the same control session. It is fixed and includes the linkage group number, member set, master / slave roles, synchronization error boundary, and local failure propagation range. The synchronization error boundary can be set from 200 milliseconds to 2 seconds, and the local failure propagation range is fixed to one of the following: full group blocking, master / slave blocking, or local isolation. If any master module is not included in the target module group, no linkage identifier is established. After the above identifier is formed, it is written to the version lock record and session master record in a fixed field order, and is directly called by the subsequent control token generation process.

[0060] The current operational status is a set of on-site statuses for each target container that directly reflects its readiness to receive and undertake the current control actions within the session establishment observation window. The observation window is a continuous period of 3 to 10 seconds before session creation. During this period, the system obtains the operating mode from the container-side controller, the primary link status and the most recent link switchover time from the network equipment, the service instance liveness status and resource occupancy status from the service host, the power supply status and remaining backup time from the power supply unit, and the container temperature and access control status from the environmental monitoring unit.

[0061] The valid values ​​for the operating mode are fixed as standby, running, degraded, and maintenance; the valid values ​​for the primary link status are fixed as available, limited, and interrupted; the valid values ​​for the service instance liveness status are fixed as live, restarting, and stopped; the valid values ​​for the power supply status are fixed as mains power, backup power, and low power protection; and the valid values ​​for the access control status are fixed as closed and open. Fields exceeding the valid value set are recorded as illegal values ​​and removed. Temperature is in degrees Celsius, resource usage is in percentage, remaining backup time is in seconds, and the sampling rate can be set to 200 milliseconds, 500 milliseconds, or 1 second.

[0062] For the collected current operating status, it is first aligned to the same sampling plane according to a unified time base, and then short-window smoothing is performed on the continuous jitter field. The short window length can be set to 3 to 5 consecutive sampling points. Each time a new sampling point is received, it is updated forward once. The middle value after sorting the valid sampling points in the window by numerical value is used as the smoothing result. When the number of valid sampling points is even, the first of the two middle values ​​is taken as the smoothing result. When there are missing points in the window but there are no less than 3 valid sampling points, only the valid sampling points are sorted and values ​​are taken. When there are fewer than 3 valid sampling points, short-window smoothing is not enabled, the original value is retained and a sampling insufficiency mark is attached. For discrete state fields, instantaneous jitter is removed by confirming after two consecutive consistent values. Consistency means that the field code values ​​of two adjacent sampling points are exactly the same. Zero missing measurements are allowed between two sampling points. If one or more missing measurements occur, the count is reset. Out-of-bounds values ​​are removed according to the dual boundaries of the device nameplate upper limit and the interface protocol upper limit.

[0063] The cabin-side context summary is a compressed record of the status of a single target cabin under the current session. Its field list is locked by a version identifier. In the main implementation, it fixedly includes cabin number, current operating mode, most recently effective command version, primary link status, most recently switched link time, service instance liveness status, power supply status, data collection completion time, and status flags for each field. The above fields are encapsulated into a fixed-length text record in a fixed order. The time field uniformly uses a millisecond-level timestamp, the status field uniformly uses a registered code value, and missing fields are uniformly filled with empty codes. The placeholder length remains unchanged. A single cabin-side context summary is written to the cabin-side context summary table, session trace log, and audit log database using the session identifier and cabin number as unique keys.

[0064] The session log is written synchronously upon successful summary writing, recording the summary text, field status flags, and write time. The audit log is written separately upon successful session creation, failed session creation, successful session submission, and failed session submission, recording the caller, version identifier, summary unique key, result code, and record time. The cabin-side context summary table stores the currently effective summary records. The retention period for both the session log and the audit log is fixed at no less than 180 days, and the three together constitute a chain of evidence. The purpose of forming the cabin-side context summary is to fix the criteria for subsequent steps to determine whether the target cabin can receive the current session control based on the same time base, the same version boundary, and the same field list.

[0065] In terms of upstream and downstream connectivity, after the central control node generates the session identifier, version identifier, timeliness identifier, linkage identifier, and cabin-side context summary, it submits them as the same session record to the control token generation stage. The submission method can be local inter-process messaging or asynchronous delivery based on message queues. The delivery semantics are fixed at at least one arrival. The consumer uses the combination of session identifier, version identifier, linkage identifier, and member set as the deduplication key. The maximum latency for a single submission can be set to 100 milliseconds, and the number of concurrent sessions can be set to 100 to 1000. When the concurrency limit is exceeded, sessions are queued according to task level and creation time. The number of retries can be set to 3, and the retry interval can be set to 200 milliseconds. If no consumption confirmation is received after exceeding the number of retries, the session submission is considered a failure.

[0066] The session creation interface, status collection interface, and session query interface constitute a fixed set of interfaces. The request content is fixed, including the caller ID, request timestamp, session identifier, and signature digest. The returned content is fixed, including the result code, result description, record time, and session identifier. The result codes are fixed and include: session creation failure, version locking failure, missing status collection, time alignment failure, member set change, session submission failure, and access denied. Specifically, session creation failure corresponds to a failure to write the session master record; version locking failure corresponds to any version of the rule repository, parameter repository, or interface configuration repository being locked; missing status collection corresponds to key fields being missing for more than three consecutive collection cycles; time alignment failure corresponds to a collection time deviating from the current time of the central control node by more than one second; member set change corresponds to a member ID being added, deleted, or replaced within the session creation window; session submission failure corresponds to more than three retries without receiving consumption confirmation; and access denied corresponds to permission verification failure. These result codes are not further subdivided and are all synchronously written to the audit log database.

[0067] If, during session establishment, it is found that the target container has no heartbeat for three consecutive collection cycles, the primary link is interrupted, the most recently effective command version is missing, the rule repository version is not locked, the member set has been changed during creation, or time alignment has failed, then the current session establishment will be terminated, and the original message, alignment result, field status flag, and version snapshot will be retained to form a chain of evidence.

[0068] To ensure order, idempotency, and deduplication, only one effective record is allowed per session identifier during the session establishment phase. When the central control node resubmits the same task number due to a retry, it first compares the session identifier, version identifier, linkage identifier, and member set. If they are completely identical, the existing record is returned directly; if they are partially identical, the old candidate record is discarded and a reason for discarding is added. Regarding security and compliance, session establishment messages and status collection messages use a registered encrypted channel on the transmission link. Geographic deployment locations and personnel association fields are anonymized in persistent logs, and access permissions are granted according to the least privilege level.

[0069] During on-site testing, with a sample size of no less than 30 control sessions and no less than 3 target cabins per session, the session establishment success rate, version lock consistency rate, context digest integrity rate, time alignment success rate, and session submission latency can be checked. Preferably, the session establishment success rate is no less than 99%, the version lock consistency rate is 100%, the context digest integrity rate is no less than 98%, the time alignment success rate is no less than 99%, and the session submission latency is no more than 100 milliseconds.

[0070] For example, in a preferred embodiment, one central control node manages four target shelters simultaneously. The sampling rhythm is set to 500 milliseconds, the observation window to 6 seconds, the short window length to 3 sampling points, the time deviation threshold to 200 milliseconds, the timeliness identifier to 30 seconds, and the linkage synchronization error boundary to 500 milliseconds. After a single session is created, member verification, time alignment, and version locking are completed within 82 milliseconds, generating four shelter-side context summaries. One target shelter undergoes a primary / backup link switch 1.5 seconds before creation, and this switchover time is written into the corresponding shelter-side context summary. All four summaries are stored in the shelter-side context summary table using a unique key formed by the session identifier and shelter number. Subsequent control tokens are only effective for target shelters that have not exceeded the 30-second timeliness boundary and have the same version of the most recently effective command. Alternatively, session identifiers can be centrally allocated by a dedicated serial number service, and cabin-side context summaries can be stored in a real-time database or an attached segment of the industrial message bus using fixed byte segment encoding. As long as version locking, time alignment, fixed field list, traceability, and direct access to the next step can be maintained within the same session, these are all feasible alternatives for this step.

[0071] S2. Collect the link status, receipt continuity status, local autonomy status, and recently effective command status of each target module to generate a link profile and execution semantic profile. The specific implementation is as follows:

[0072] This step can be deployed between the central control node of the aforementioned distributed modular shelter system and each target modular shelter. It is applicable to the continuous control phase after the establishment of the control session, version locking, and generation of the shelter-side context summary have been completed. It is used to further determine whether the current communication carrying conditions and execution acceptance conditions of each target modular shelter meet the subsequent constraints of the same control session before the control token is generated. In the field, the link status, local autonomy status, and the status of the most recently effective command are collected and uploaded by the target modular shelter side, and the continuous status of the receipt is formed by the central control node in combination with historical issuance records and receipt records. The sampling period is consistent with the previous step and can be set to 200 milliseconds, 500 milliseconds, or 1 second; the control period is used for control token issuance and receipt statistics, and the sampling period is used for status collection and time alignment. In this embodiment, the control period and the sampling period use the same period length, and the same version identifier is used to lock the status field list, field legal value set, observation window length, segment boundary, judgment order, and result code set in this step.

[0073] Link status refers to the reachability and transmission stability of the current primary communication link in the target container within the observation window. This is obtained from link monitoring messages, heartbeat messages, and the most recent link handover record reported by network devices. Within the most recent 3-10 second observation window, the primary link status code, round-trip time, latency jitter, packet loss count, number of link handovers, and most recent successful response time are read. Round-trip time is in milliseconds, latency jitter is in milliseconds, packet loss count is in units, and the number of link handovers is in times. The primary link status code is fixed as Available, Limited, and Interrupted.

[0074] The most recent successful response time is included in the original link status record and is used to retain the time position of the most recent normal link response. It is not included in the subsequent link profile field combination. The receipt continuity status is the degree of continuity of valid receipts received by the central control node within a fixed statistical window for the current target container. It is obtained from the control token sending record, receipt receiving record, and timeout retry record.

[0075] The statistics window is fixed at the most recent 10 control cycles, or it can be locked to a fixed value between 5 and 20 control cycles by the version identifier. Within this statistics window, the target container is checked in chronological order for each cycle to see if it has returned a valid receipt within the corresponding time limit. This yields the consecutive receipt count, the number of interrupted cycles, the number of timeout cycles, and the most recent interrupted cycle number. The consecutive receipt count includes the current cycle. If there is no valid receipt in the current cycle, the consecutive receipt count is directly recorded as 0. The consecutive receipt count is the number of cycles with consecutive valid receipts from the current cycle forward. The number of interrupted cycles is the number of cycles in the statistics window that did not receive a valid receipt and did not receive a valid receipt before the time limit expired. The number of timeout cycles is the number of cycles in the statistics window that received a receipt after the time limit expired or never received a receipt. The most recent interrupted cycle number is the sequence number of the most recent interrupted cycle in the statistics window.

[0076] A maximum of one valid receipt can be confirmed within one control cycle. When multiple receipts are received within the same control cycle, they are first filtered by complete matching of session identifier, version identifier, and target container number. Then, the receipt that arrives first and whose result code does not belong to no receipt, timeout receipt, or wrong session receipt is selected as the only valid receipt for that cycle. Other receipts are only recorded and do not participate in continuous counting.

[0077] A valid receipt is a receipt record returned by the target container provided that the session identifier, version identifier, target container number, and linkage identifier all match, and the deviation between the receiving time and the end time of the corresponding control cycle does not exceed one sampling cycle. Among them, an effective receipt is a receipt record in which the result code indicates that the command has met the effective conditions; a partially effective receipt is a receipt record in which the result code indicates that the command has met some of the effective conditions; and a failure receipt is a receipt record returned within the time limit, with correct session matching, and a result code indicating that the command has not met the effective conditions. Failure receipts, partially effective receipts, and effective receipts can all be used as valid receipts for continuity statistics, but only effective receipts and partially effective receipts can be used for subsequent verification of the status of the most recently effective command. In this step, valid receipts are only used for receipt continuity statistics and verification of the status of the most recently effective command, and do not necessarily indicate that the target container has entered a state where it can be directly accepted.

[0078] The local autonomy status refers to the current control state of the target module, maintaining its business and equipment operation without immediate intervention from the central control node. This status is obtained from the module's controller mode register, autonomy policy status register, and the most recent autonomy switchover record. Within the most recent 3-10 second observation window, the autonomy activation flag, autonomy duration, autonomy reason code, and autonomy level are read. The autonomy activation flag is always enabled or disabled; the autonomy duration is in seconds; the autonomy reason code is always link interruption, center unreachable, service maintenance, and security protection; and the autonomy level is always maintenance, restriction, and blockade. The only triggering condition for autonomy activation is that the primary link status is interrupted for two consecutive sampling cycles, or the central control node does not receive a valid response from the target module for two consecutive control cycles, or the module controller detects a security protection trigger signal.

[0079] The sole condition for autonomous exit is that the primary link status recovers to available status for two consecutive sampling cycles, the central control node receives a valid acknowledgment from the target container for two consecutive control cycles, and the security protection trigger signal disappears. The duration of autonomy is accumulated from the sampling moment when the autonomy activation flag first switches from disabled to enabled, and terminates at the sampling moment when the autonomy activation flag switches from enabled to disabled. When the autonomy level is "maintain," only the current service instance and current power supply configuration are allowed to remain unchanged; when the autonomy level is "restricted," only core service instances locked by the version identifier are allowed to be retained, and non-core service instances are stopped. Core service instances are determined by the service list locked by the version identifier, and the remaining service instances are non-core service instances; when the autonomy level is "blocked," only communication monitoring and security protection functions are allowed to be retained, and service migration, resource switching, and new control token acceptance are stopped. When the autonomy status changes multiple times within the observation window, the autonomy status closest to the current sampling surface and confirmed by two consecutive successful confirmations is taken as the current valid autonomy status.

[0080] The status of the most recently effective command refers to the status of the command that was actually effective and recorded locally in the target container the most recently. It is obtained from the command execution log, command effectiveness register, and the record of the most recently valid acknowledgment, which is either an effective acknowledgment or a partially effective acknowledgment. Within the most recent 1 to 5 control cycles, the version of the most recently effective command, the time of the most recently effective command, the result code of the most recently effective command, and the source of the most recently effective command are read. The version of the most recently effective command uses the same encoding length as the current version identifier. The time of the most recently effective command is in milliseconds. The result code of the most recently effective command is always effective, partially effective, or ineffective. The source of the most recently effective command is always either issued by the center or locally autonomous.

[0081] The most recently effective command is selected based on the principle that the effective time recorded in the command effective register is closest to the current sampling surface; when there is a conflict between the command execution log and the command effective register, the record in the command effective register shall prevail; when the command effective register is missing but there is an effective receipt or a partial effective receipt in the valid receipt record, the command corresponding to the valid receipt shall be used as the replacement record and a replacement flag shall be attached.

[0082] Effective means that after the target container receives the command, the corresponding execution position of the controller inside the container is set and the status of the controlled object meets the command requirements within one control cycle; partially effective means that at least one of the multiple controlled objects corresponding to the command meets the command requirements and at least one does not meet the command requirements, or a single controlled object enters a downgraded execution state with version identifier locked; when the command corresponds to only one controlled object, the stable state of the controlled object at the end of the control cycle is used as the criterion for judgment. Being in the command requirement state is recorded as effective, being in the downgraded execution state with version identifier locked is recorded as partially effective, and other situations are recorded as ineffective; ineffective means that the control position is not set or the controlled object does not enter the required state within one control cycle.

[0083] When the aforementioned status fields enter this step, they are first aligned to the same sampling plane according to the unified time base of the previous step. Fields that have not been updated for more than two sampling periods are marked as old values. Reference fields that have been missing for no more than three consecutive sampling periods are filled with the most recent valid value. Critical fields that have been missing for more than three consecutive sampling periods are marked as unavailable. The critical fields in this step are fixed as the primary link status code, round-trip time, consecutive receipt count, autonomy enable flag, and most recently effective command version. The reference fields are fixed as latency jitter, packet loss count, autonomy duration, most recent interruption period number, and most recently effective command time difference. Among continuously changing numerical fields, only round-trip time, latency jitter, packet loss count, autonomy duration, and most recently effective command time difference are allowed to use the same short-window smoothing rule as the previous step; smoothing is prohibited for other fields. Discrete status fields are confirmed by a rule after two consecutive confirmations. Fields that exceed the set of legal values ​​or the range of the device protocol are marked as illegal values ​​and discarded.

[0084] After processing, link profiles and execution semantic profiles are generated according to the field order locked by the version identifier. The link profile is a record of the communication bearer status of a single target shelter within the current observation window. It is formed by combining the primary link status code, round-trip delay segmentation results, delay jitter segmentation results, packet loss count segmentation results, link switching count segmentation results, continuous receipt count, interruption cycle count, and timeout cycle count on the same sampling plane.

[0085] Segmentation is performed after smoothing is completed, and segment boundaries remain fixed within the same management session; round-trip latency below 50 milliseconds is considered low latency, 50 to 200 milliseconds is considered medium latency, and above 200 milliseconds is considered high latency; latency jitter below 20 milliseconds is considered low jitter, 20 to 80 milliseconds is considered medium jitter, and above 80 milliseconds is considered high jitter; packet loss count of 0 is considered no packet loss, 1 to 3 is considered light packet loss, and above 3 is considered heavy packet loss; link handover count of 0 is considered stable, 1 is considered a single handover, and above 1 is considered frequent handover.

[0086] Within each boundary, segments falling on the lower boundary are taken as the current segment, and segments falling on the upper boundary are also taken as the current segment; cross-segment merging is not performed. The link profile only stores records with the above fixed field combinations. Subsequent control token generation processes directly read each field without secondary classification. Each field is encapsulated into a fixed-length text record in a fixed order and is fixedly written to the link profile table, session trace log, and audit log database, using the session identifier, target shelter number, sampling time, and version identifier as a combined unique key.

[0087] Semantic profiling involves recording the local acceptance conditions of a single target container within the current observation window. On the same sampling surface, this is achieved by combining the autonomy activation flag, segmented autonomy duration results, autonomy reason code, autonomy level, most recently effective command version, most recently effective command result code, most recently effective command source, and the most recently effective command time difference. Autonomy durations less than 5 seconds are classified as short-term autonomy, 5 to 30 seconds as medium-term autonomy, and more than 30 seconds as long-term autonomy. The most recently effective command time difference is obtained by subtracting the most recently effective command time from the current sampling surface; less than one control cycle is considered near-term effectiveness, one to three control cycles as medium-term effectiveness, and more than three control cycles as far-term effectiveness.

[0088] The result set of semantic profiling is fixed as follows: directly acceptable, restricted acceptable, and unacceptable. The following order is used for judgment: if the autonomy level is blocked, or the most recently effective command result code is ineffective, or the most recently effective command version is inconsistent with the current version identifier and the source of the most recently effective command is local autonomy, it is determined to be unacceptable; if it is not determined to be unacceptable, if the autonomy activation flag is enabled, or the autonomy level is restricted, or the most recently effective command result code is partially effective, it is determined to be restricted acceptable; if none of the above conditions are met, and the most recently effective command version is consistent with the current version identifier, the most recently effective command result code is effective, and the autonomy activation flag is not enabled, it is determined to be directly acceptable.

[0089] Once determined to be eligible for restricted access, the subsequent control token generation process is only allowed to generate status maintenance controls, core business maintenance controls, and restricted recovery controls. It is prohibited to generate business migration controls, resource switching controls, and new bearer controls.

[0090] The execution semantic profile is encapsulated into fixed-length text records in a fixed field order. These records are synchronously written to the execution semantic profile table, session log, and audit log database, using the same composite unique key as the session profile. The execution semantic profile records the current acceptance status during the continuous management phase, while the cabin-side context summary records the basic status during the session establishment phase. The two records differ in their generation time, field list, and purpose.

[0091] The purpose of generating link profiles and execution semantic profiles is to fix the selection of delivery methods and constraint fields for the target cabin in the subsequent control token generation process to the same time base, the same field list, the same segment boundary, and the same judgment order. It is suitable for distributed cabin systems with multiple link access, short-term link loss, and autonomous switching, but not for simplified single cabin control scenarios that do not retain historical receipt records or provide logs of the most recently effective commands.

[0092] During upstream and downstream integration, after the central control node completes the generation of link profiles and execution semantic profiles within the current sampling period, it submits the two types of profile records to the control token generation stage. The submission method uses the same interface set and encrypted channel as the previous step, and the delivery semantics are fixed to at least one arrival. The consumer uses the session identifier, target cabin number, sampling time, and version identifier as deduplication keys. The total latency limit for a single generation and submission can be set to 150 milliseconds, the number of concurrent target cabins can be set to 100 to 1000, the number of retries can be set to 3, and the retry interval can be set to 200 milliseconds.

[0093] In this step, the recording time is divided into sampling time, generation time, and writing time. The combined unique key and deduplication key both use the sampling time, the generation time is the moment the profile record is formed, and the writing time is the moment the profile record is written to the database. The three times are written to the corresponding record fields respectively.

[0094] If, during the profile generation process, key fields become unavailable, receipt records and distribution records cannot be associated, the most recently effective command version is missing, the link status is interrupted and the continuous receipt count is 0, or the target cabin number in the current sampling message is inconsistent with the target cabin number written to the session master record when the current session is established, then the profile generation of the current target cabin will be terminated, the result code will be written, and the original status record, smooth activation flag, original value before segmentation, code value after segmentation, receipt association details, field status flag, observation window start and end time, and version snapshot will be retained to form an evidence chain.

[0095] The minimum set of result codes corresponding to this step is fixed and includes missing link status, failed receipt association, missing autonomous status, missing command status, failed profile generation, and successful profile generation, and each result code is mutually exclusive; when multiple anomalies occur at the same time, the codes are assigned in the order of missing link status, failed receipt association, missing autonomous status, missing command status, and failed profile generation.

[0096] A missing link status corresponds to an unavailable primary link status code or unavailable round-trip latency; a failed receipt association corresponds to a situation where the session identifier, version identifier, target shelter number, and linkage identifier cannot be matched simultaneously; a missing autonomy status corresponds to an unavailable autonomy activation flag; a missing command status corresponds to an unavailable recently effective command version; a profile generation failure is recorded only when none of the aforementioned missing link status, failed receipt association, missing autonomy status, and missing command status are triggered, and both types of profile records fail to be successfully submitted within 3 retries; a profile generation success is recorded when both types of profile records are successfully written.

[0097] To ensure order, idempotency, and deduplication, only one set of valid link profiles and execution semantic profiles are allowed to be retained under the same session identifier, target cabin number, sampling time, and version identifier. When generating duplicates, the version identifier, field status flags, and sampling time are compared first. If they are completely consistent, the existing record is returned directly. If they are partially inconsistent, the old candidate record is discarded and a reason for discarding is added.

[0098] In terms of security and compliance, the link profile table, execution semantic profile table, session trace log, and audit log library all follow the least privilege access and de-identification rules of the previous step. Fields involving caller number and link address in the receipt record are stored in a de-identified format. When the permission verification fails, it returns no permission access and is synchronously written to the audit log library.

[0099] During on-site testing, with a sample size of no less than 30 control sessions, no less than 3 target cabins per session, and no less than 50 control cycles per target cabin, the success rate of link profile generation, the success rate of execution semantic profile generation, the accuracy of receipt association, the profile writing latency, and the duplicate profile removal rate can be checked. Preferably, the success rate of link profile generation is no less than 99%, the success rate of execution semantic profile generation is no less than 99%, the accuracy of receipt association is no less than 99%, the profile writing latency is no more than 150 milliseconds, and the duplicate profile removal rate is 100%.

[0100] For example, in a preferred embodiment, one central control node manages four target shelters simultaneously. The sampling rhythm is set to 500 milliseconds, the observation window is set to 6 seconds, the continuous status statistics window for receipts is set to 10 control cycles, the round-trip delay segment boundaries are set to 50 milliseconds and 200 milliseconds, the delay jitter segment boundaries are set to 20 milliseconds and 80 milliseconds, and the autonomy duration segment boundaries are set to 5 seconds and 30 seconds. One target shelter maintains an available primary link status within the last 6 seconds, with a round-trip delay of 42 to 57 milliseconds, a continuous receipt count of 9, and an autonomy activation flag that is not enabled. The most recently effective command version matches the current version identifier and becomes effective within one control cycle. Finally, one link profile and one execution semantic profile are generated and written to the corresponding record table and log database within 93 milliseconds. The execution semantic profile result determines that the shelter can be directly accepted, and the subsequent control token generation stage includes this target shelter as a direct delivery target. Alternatively, link profiling and execution semantic profiling can also be written to the real-time database cache using fixed byte segment encoding, or the central control node can first generate temporary records and then batch write them to the database. As long as the field list, segment boundaries, judgment order, record unique key, evidence chain traceability, and direct call to the next link can be maintained under the same version identifier, they are all feasible alternative forms of this step.

[0101] S3. Based on the session identifier, version identifier, timeliness identifier, cabin-side context summary, link profile, and execution semantic profile, generate the corresponding constrained control token for the target cabin. The specific implementation is as follows:

[0102] This step can be deployed in the central control node of the aforementioned distributed control system. It is applicable to the continuous control phase after the establishment of control sessions, generation of link profiles, and generation of execution semantic profiles have been completed. Before the control content is officially sent, it is used to fix the control boundaries, time limits, acceptance boundaries, and record boundaries for a single target control unit under the same control session as transmittable, verifiable, and traceable token records. This is to avoid the central control node directly issuing raw control content, which could lead to inconsistent acceptance interfaces, time limit mismatches, or duplicate executions in different target control units under conditions of weak network, short-term link loss, autonomous switching, and version changes.

[0103] In practice, the session identifier, version identifier, and timeliness identifier are obtained from the current session master record; the cabin-side context summary is obtained from the cabin-side context summary table; the link profile is obtained from the link profile table; the execution semantic profile is obtained from the execution semantic profile table; and the control content to be executed is obtained from the control content record table corresponding to the current session. Each record in the control content record table includes the target cabin number, control object set, task level, generation time, and version identifier. The task level is fixed as high, medium, and low. Each item in the control object set corresponds to one business instance, one resource unit, or one power supply configuration requirement. When there are multiple records in the same target cabin and at the same sampling time, they are sorted from high to low task level and from early to late generation time, and constrained control tokens are generated one by one without merging.

[0104] Within the current sampling period, the central control node reads the latest session master record, the latest cabin-side context summary, the latest link profile, the latest execution semantic profile, and the currently prioritized pending control content records corresponding to the target cabin. The node aligns these records with the sampling time as a unified time benchmark. If the version identifier of any record is inconsistent with the session master record, the generation of the token is terminated and recorded as a version inconsistency. Mixing old versions or rolling back versions is not allowed.

[0105] The constrained control token is a fixed-length control record generated for a single target shelter under the current control session. On the current sampling datum, it consists of session identifier, version identifier, time limit identifier, linkage identifier, target shelter number, token number, control category, control scope, execution priority, sending method flag, retry boundary, failure condition, receipt requirement, sampling time, generation time and field status flag.

[0106] The token number starts from 1 and increments under the same session identifier, the same target container number and the same version identifier. The candidate token is the occupied number and is not recycled after being discarded. When there are multiple records of control content to be executed at the same sampling time, the numbers are assigned in sequence according to the aforementioned sorting order.

[0107] The control categories are fixed as follows: State Preservation Control, Core Business Maintenance Control, Restricted Recovery Control, Business Migration Control, Resource Switching Control, and New Bearer Control. Among them, those that only maintain the current business instance, current link configuration, current resource configuration, current power supply configuration, and current state are classified as State Preservation Control; those that only maintain the continuous operation of core business instances with version identifier locks are classified as Core Business Maintenance Control; those that only restore existing business instances or resource configurations that are allowed to be restored are classified as Restricted Recovery Control; those involving the transfer of business instances across nodes are classified as Business Migration Control; those involving the switching of link, power supply, computing power, or storage resources are classified as Resource Switching Control; and those involving the addition of new business instances, new link bearers, or new resource occupancy are classified as New Bearer Control. When the same control content simultaneously falls into multiple categories, it is classified into the first category in the order of Business Migration Control, Resource Switching Control, New Bearer Control, Restricted Recovery Control, Core Business Maintenance Control, and State Preservation Control.

[0108] The control scope is fixed as a set of control objects, which is formed by comparing the set of control objects in the control content to be executed with the business instance list, resource list and power supply list item by item. First, it is verified that the business instance exists and is in an allowed acceptance state. Then, it is verified that the resources meet the requirements of the current control content. Finally, it is verified that the power supply status allows execution. The allowed acceptance state is fixed as the business instance being alive, recoverable and not blocked. If any object does not meet the previous condition, it is directly removed and does not enter the subsequent verification. When all objects are removed, it is recorded as a scope pruning failure.

[0109] The execution priority is fixed as high, medium, and low, first determined by the task level field in the control content record table. High level corresponds to high priority, medium level corresponds to medium priority, and low level corresponds to low priority. When the task levels are the same, the master cabin in the linkage identifier is higher than the slave cabin. If the above are still the same, the remaining timeliness is less than 2 control cycles and recorded as high, 2 to 5 control cycles and recorded as medium, and more than 5 control cycles and recorded as low.

[0110] The sending method flag is written only when a token is successfully generated, and is fixed as either immediate sending or restricted sending. Immediate sending is written when the semantic profile result indicates direct acceptance, the primary link status code in the link profile is available, and there are no high latency, high jitter, heavy packet loss, or frequent switching issues. Restricted sending is written for all other scenarios where token generation is possible. Immediate sending corresponds to the submission of the basic sending interval locked by the version identifier, while restricted sending corresponds to the submission of the sending interval extended from the basic sending interval by a multiple locked by the version identifier. Both the basic and extended sending intervals are constrained by retry boundaries. The retry boundaries are fixed and include the number of retries and the retry interval. The number of retries can be locked from 1 to 3 times by the version identifier, and the retry interval can be locked from 100 milliseconds to 500 milliseconds by the version identifier.

[0111] The failure conditions are fixed and include expiration of validity period, version inconsistency, link interruption, and autonomous control failure. Expiration of validity period is triggered when the current time exceeds the end time of the validity period indicator before sending or receiving. Version inconsistency failure is triggered when the current version indicator and the token version indicator are inconsistent before sending or when receiving the receipt. Link interruption failure is triggered when the primary link status is interrupted for two consecutive sampling periods. Autonomous control failure is triggered when the autonomous level is controlled after two consecutive consistent confirmations.

[0112] The receipt requirements are fixed and include session identifier, version identifier, target shelter number, token number, result code, record time, and most recently effective command version. During receipt verification, the session identifier and token number are verified first, then the target shelter number and version identifier are verified, and finally the record time and most recently effective command version are verified. If the first two items are inconsistent, it is recorded as an incorrect token. If the record time exceeds the time limit, it is recorded as an overdue receipt. If the most recently effective command version is inconsistent, it is recorded as a version inconsistency receipt. Version inconsistency receipts are only used for receipt verification classification and are not used as the result code for this step.

[0113] Field status flags are written at the field record granularity, with fixed markers for current value, old value, and padding value; if any of the following items are old or padding values: version identifier and expiration identifier in the session master record, current operating mode and most recently effective command version in the cabin-side context summary, primary link status code and continuous acknowledgment count in the link profile, acceptance result in the execution semantic profile, and set of control objects and task level in the record of control content to be executed, no constrained control token is generated.

[0114] When the semantic profile result indicates that the application can be directly accepted, all control categories can be written. When the result indicates that the application can be accepted under limited circumstances, only state maintenance control, core business maintenance control, and limited recovery control can be written. When the result indicates that the application cannot be accepted, no token is generated and the application is recorded as rejected. When the primary link status code in the link profile is interrupted and the continuous acknowledgment count is 0, no token is generated and the link is recorded as rejected. When the current sampling time is less than one control cycle from the end of the time limit identifier, no token is generated and the time limit is recorded as rejected.

[0115] After generation, the token is encapsulated as a fixed-length text record and written to the constrained control token table, session log, and audit log database, using the session identifier, target shelter number, token number, and version identifier as a combined unique key. The session log records the full text of the token, the set of controlled objects before and after pruning, the pruning reason code, field status flags, and the generation time. The pruning reason code is fixed to four categories: business instance does not exist, business instance is not allowed to accept, insufficient resources, and power supply is not allowed. The audit log database records the caller number, token number, result code, sampling time, generation time, and consumption confirmation status of the sending stage. Consumption confirmation in the sending stage refers to the sending stage receiving the token record and successfully writing it to the sending queue. The confirmation timeout boundary is fixed at one control cycle; failure to confirm within the timeout period is recorded as token submission failure.

[0116] The submission method uses the same interface set and encrypted channel as the previous step. The delivery semantics are fixed at at least one arrival. When a duplicate token is received during the sending process, it is compared according to the session identifier, target cabin number, token number, and version identifier. If they are completely consistent, the duplicate record is discarded and an existing consumption confirmation is returned. The minimum result code set corresponding to this step is fixed and includes token generation success, acceptance rejection, link rejection, timeout rejection, range pruning failure, version inconsistency, and token submission failure, and each result code is mutually exclusive.

[0117] During on-site testing, with a sample size of no less than 30 control sessions, no less than 3 target cabins per session, and no less than 50 records to be generated for each target cabin, the token generation success rate, version consistency accuracy, range pruning accuracy, token write latency, and duplicate token removal rate can be checked. Preferably, the token generation success rate is no less than 99%, the version consistency accuracy is 100%, the range pruning accuracy is no less than 99%, the token write latency is no more than 120 milliseconds, and the duplicate token removal rate is 100%.

[0118] For example, in a preferred embodiment, one central control node manages four target shelters simultaneously. The sampling period and control period are both set to 500 milliseconds, and the remaining time of the time-sensitive identifier is 8 seconds. The execution semantic profile result of one target shelter is that it can be restricted to accept. In the link profile, the primary link status code is restricted and the continuous acknowledgment count is 6. The control content to be executed includes one control for business migration, one control for state maintenance, and one control for core business maintenance. The central control node classifies the control by category and removes the control for business migration by the acceptance boundary, retaining only the latter two control contents. It generates two constrained control tokens respectively and completes the writing and sending queue consumption confirmation within 97 milliseconds.

[0119] Alternatively, the constrained control token can also be written to the real-time database cache using fixed byte segment encoding, or the central control node can first generate temporary tokens and then submit them in batches to the sending stage. As long as the field list under the same version identifier is fixed, the control category boundary is fixed, the control scope level is fixed, the execution priority rule is fixed, the joint unique key is fixed, the evidence chain is traceable, and the next stage can directly call it, all of these are feasible alternative forms of this step.

[0120] S4. The constrained control token is sent to the corresponding target module. The target module performs condition verification based on the module-side context digest and generates a local execution record based on the condition verification result. The specific implementation is as follows:

[0121] This step can be deployed between the central control node of the aforementioned distributed modular system and each target modular system. It is applicable to the control transmission and modular acceptance phase after the constrained control token has been generated and written. After the token arrives at the target modular system, it is used to verify the real-time status of the modular system against the context digest of the modular system formed during the session establishment phase to determine whether the token can continue to be accepted in the current modular system. The acceptance result, the reason for the restriction, and the execution boundary are solidified into a traceable local execution record, thereby avoiding the mistaken acceptance of expired, mismatched, or duplicate tokens due to link fluctuations, state drift, autonomous switching, or version drift.

[0122] The real-time status of the cabin side in this step includes the current operating mode, power supply status, service instance liveness status, local autonomy status, and the status of the most recently effective local command. The current operating mode, power supply status, and service instance liveness status are provided by the cabin side context summary stored locally in the target cabin, the local autonomy status is provided by the autonomy policy status register, and the status of the most recently effective local command is provided by the record of the most recently effective local command.

[0123] In the field, the central control node reads the token record that has been consumed and confirmed from the constrained control token table, encapsulates it according to the session identifier, target module number, token number and version identifier, and sends it to the corresponding target module through the aforementioned encrypted channel. The target module receives the token record on the in-module communication controller and reads the locally stored module-side context summary, the status of the most recently effective command, the local autonomy status and the current operating mode at the time of reception. The reception period is consistent with the aforementioned control period and can be set to 200 milliseconds, 500 milliseconds or 1 second.

[0124] The in-cabin communication controller first performs sequential verification and deduplication verification on the received token records according to the order of session identifier, version identifier, target cabin number, and token number. If the same session identifier, target cabin number, token number, and version identifier are completely identical, it is recorded as a duplicate token. Duplicate tokens will not be subject to conditional verification. Only a duplicate arrival flag will be written and a summary of the existing local execution record will be returned. The duplicate arrival flag is a fixed status field written to the local log, which records that the token is a duplicate message that has not entered the acceptance process again.

[0125] A token number less than the most recently accepted token number locally, and with the same session identifier and version identifier, is recorded as an out-of-order token; the most recently accepted token number locally is the token number in the local execution record where the last execution boundary under the same session identifier, the same target container number, and the same version identifier is either fully accepted or limited accepted.

[0126] Out-of-order tokens are not executed directly. They are first written to a wait-for-review flag and entered into the local temporary storage area. The wait-for-review flag is a fixed status field written to the local temporary storage area and the local log. If a missing preceding token is received within one control cycle and the missing preceding token forms a local execution record of full acceptance or limited acceptance, the current out-of-order token is transferred to condition verification. If no preceding missing token is received or acceptance is rejected, the current out-of-order token is converted to out-of-order rejection.

[0127] Condition verification uses the target container's reception time as the current baseline. On this baseline, the version identifier, validity period identifier, control category, control scope, failure condition, and acknowledgment requirement in the token record are compared item by item with the container's real-time status. Condition verification is performed in a fixed order: validity period boundary, version boundary, object boundary, autonomous boundary, and duplicate boundary. Subsequent boundaries are not considered until a preceding boundary is passed. Within the validity period boundary, the target container compares its local reception time with the validity period identifier's end time; if they exceed this, it is directly recorded as validity period rejection. Within the version boundary, if the token version identifier is inconsistent with either the local container-side context digest version identifier or the version of the most recently effective command, it is directly recorded as version rejection. This determination takes precedence over the object boundary, autonomous boundary, and duplicate boundary.

[0128] Object boundaries are executed separately according to the type of controlled object. For business instance objects within the control scope, the existence of the business instance is first verified, and then its liveness or recoverability and non-blocking status are verified. The blocking status of the business instance is taken from the blocking flag field in the local business instance status table. For resource unit objects within the control scope, the existence of the resource unit is first verified, and then its availability status is verified, and the token requirement capacity is not greater than the current allocable capacity of the resource unit. The resource unit status is fixed as available, occupied, and unavailable, and only the available status meets the acceptance conditions. For power supply configuration objects within the control scope, the power supply configuration requirements in the record of the control content to be executed are used as the basis, and they are matched item by item with the local power supply configuration list of the target container. After a successful match, the current power supply status is verified to meet the corresponding power supply configuration requirements. When mains power is required, only the mains power status is met; when backup power is required, only the backup power status is met; when non-low power protection is required, both mains power and backup power status are met.

[0129] If any object does not meet the requirements within the corresponding object boundary, it is removed from the control scope and the reason for the restriction is recorded. If the control scope is empty after removal, it is recorded as a scope rejection. Within the autonomous boundary, when the autonomy level is "blocked," all control categories are rejected and recorded as an autonomous rejection. When the autonomy level is "restricted," only status maintenance controls, core business maintenance controls, and restricted recovery controls are allowed. When the autonomy level is "maintained," acceptance is allowed without changing the current link configuration, current resource configuration, and current power supply configuration. Within the duplicate boundary, if the current token number is the same as the locally most recently accepted token number and the version identifier is consistent, it is recorded as a duplicate acceptance rejection. Duplicate acceptance rejection is different from duplicate tokens. Duplicate tokens are packets that arrive repeatedly without entering condition verification, while duplicate acceptance rejection is when the current token enters condition verification and its acceptance result has been overwritten by a valid local execution record.

[0130] The condition validation results are fixed and categorized into three types: pass, restricted pass, and rejection, each corresponding one-to-one with the execution boundary. Pass corresponds to full acceptance, restricted pass corresponds to restricted acceptance, and rejection corresponds to rejection acceptance; no cross-combination is allowed. A pass is defined as when all boundaries are met and the control scope is not pruned; a restricted pass is defined as when object pruning exists but at least one control object remains and the control category does not exceed the autonomous level's allowed boundaries; all other cases are defined as rejection.

[0131] The target module generates a local execution record based on the condition verification results. The local execution record is a fixed-length text record generated by the target module for a single constrained control token. It includes a fixed session identifier, version identifier, target module number, token number, condition verification result, execution boundary, reception time, acceptance time, recording time, trimmed control scope, restriction reason code, local most recently effective command version, autonomy level, acknowledgment result code, and write time. The reception time is the time when the in-module communication controller receives the token, the acceptance time is the time when the condition verification result is determined, the recording time is the time used to write the acceptance acknowledgment, and the write time is the time when the local execution record is stored in the database.

[0132] The receipt result code corresponds to the result code in the previous receipt requirement. The receipt result codes are fixed and include acceptance success, acceptance limit, time-limited rejection, version rejection, scope rejection, autonomous rejection, duplicate rejection, and out-of-order rejection. When the condition validation result is passed, the receipt result code is recorded as acceptance success. When it is passed with limitations, it is recorded as acceptance limit. When rejected, it is written according to the time-limited rejection, version rejection, scope rejection, autonomous rejection, duplicate rejection, and out-of-order rejection.

[0133] The target module writes local execution records to the local execution record table and the local trace log, using the session identifier, target module number, token number, and version identifier as a combined unique key. The local execution record table retains only one valid record for each combined unique key to store the current valid acceptance result. The local trace log stores all successful, failed, and replaced records, with a fixed retention period of no less than 180 days. If a combined unique key conflict occurs, the original valid record is retained, and the new record does not overwrite the original record; this is recorded as a record write failure and written to the conflict trace. The local trace log synchronously stores the token original digest, the control scope before pruning, the control scope after pruning, the restriction reason code, the condition verification result, the reception time, and the acceptance time, for subsequent receipt generation and direct invocation of the recovery ruling. To ensure idempotency, order, and deduplication, only one valid local execution record is allowed under the same session identifier, target container number, token number, and version identifier. If the same token arrives again, the summary of the existing local execution record will be returned directly. When the session identifier is the same but the version identifier is different, or the token number is the same but the control category is different, it is recorded as a version conflict. Version conflicts are only used for local trace classification and are not used as the minimum error code returned externally in this step.

[0134] During upstream and downstream coordination, after the central control node sends a token, it waits for the target container to return a receipt within one control cycle. Once the target container successfully writes the execution record locally, it immediately generates a receipt according to the token receipt requirements. The receipt includes a fixed set of fields: session identifier, version identifier, target container number, token number, receipt result code, restriction reason code, trimmed control scope, the most recently effective local command version, and the recording time. It is then returned to the central control node through the aforementioned encrypted channel. Among these, the session identifier, version identifier, target container number, token number, receipt result code, recording time, and the most recently effective local command version are fixed receipt fields, while the restriction reason code and the trimmed control scope are extended receipt fields.

[0135] If a missing session identifier, missing version identifier, missing cabin-side context digest, incomplete token field, conflicting unique key, local storage write failure, or failed receipt generation occurs during token reception or condition verification, the current token acceptance process is stopped, and the token is assigned to the minimum error code according to a fixed mapping relationship. Specifically, missing session identifier, missing version identifier, missing cabin-side context digest, and incomplete token field are all classified as version rejection; conflicting unique key and failed local storage write are all classified as record write failure; and failed receipt generation is classified as receipt generation failure. At the same time, the received message, intermediate condition verification record, pruning record, restriction reason code, and error code are retained to form an evidence chain. The intermediate condition verification record includes at least the order of each boundary verification, the time of each boundary verification, the object pruning result, and the code assignment result.

[0136] The minimum set of error codes corresponding to this step is fixed and includes time-sensitive rejection, version rejection, range rejection, autonomous rejection, duplicate rejection, out-of-order rejection, record write failure, and receipt generation failure, and these error codes are mutually exclusive. When multiple exceptions occur simultaneously, they are prioritized in the following order: time-sensitive rejection, version rejection, range rejection, autonomous rejection, duplicate rejection, out-of-order rejection, record write failure, and receipt generation failure. Regarding security and compliance, the constrained control token, local execution record, and acceptance receipt all use a registered encrypted channel on the transmission link. The local execution record table and local trace log follow the aforementioned minimum access and de-identification rules, and the business instance identifier, resource unit number, and caller number are stored in a de-identified format.

[0137] During on-site testing, with a sample size of no less than 30 control sessions, no less than 3 target cabins per session, and no less than 50 token records per target cabin, the token arrival accuracy, condition validation accuracy, local execution record generation success rate, duplicate token rejection rate, and acceptance receipt latency can be checked. Preferably, the token arrival accuracy is no less than 99%, the condition validation accuracy is no less than 99%, the local execution record generation success rate is no less than 99%, the duplicate token rejection rate is 100%, and the acceptance receipt latency is no more than one control cycle.

[0138] For example, in a preferred embodiment, one central control node manages four target cabins simultaneously, with a control cycle set to 500 milliseconds. One target cabin receives a constrained control token, the token control category being core business maintenance control, the control scope including two business instances and one resource unit, and the receiving time having 6 seconds remaining before the expiration time of the validity period. The local cabin-side context summary shows that the current operating mode is running, the most recently effective command version is consistent with the token version identifier, and the local autonomy level is restricted. One business instance is in a live state, another business instance is in a stopped state, and the resource unit is in an available state. After condition verification, the target cabin removes the business instance in the stopped state, retains the remaining two control objects, forming a local execution record. The condition verification result is recorded as restricted pass, the execution boundary is recorded as restricted acceptance, and the local write and acceptance receipt return are completed within 320 milliseconds.

[0139] Alternatively, the constrained control token can be written to the local temporary storage area of ​​the target container before the condition verification is performed, or the local execution record can be stored in the real-time database cache area using fixed byte segment encoding. As long as the field list, condition verification order, joint unique key, restriction reason code, traceable evidence chain, and direct call to the next step can be maintained under the same version identifier, they are all feasible alternative forms of this step.

[0140] S5. During a link anomaly, the target container executes a constrained proxy based on the currently valid control session, and generates a local evidence fragment containing the reason for the proxy execution and the scope of substitution. Specifically, this is implemented as follows:

[0141] In one embodiment, during a link anomaly, the target container executes a constrained proxy based on the current valid control session and generates a local evidence fragment containing the reason for the proxy execution and the scope of alternatives. This fragment can be deployed in the target container-side controller of the aforementioned distributed container system. It is applicable to scenarios where the communication link between the central control node and the target container is interrupted, or there are continuous timeouts or consecutive incorrect sessions, resulting in the constrained control token failing to arrive stably according to the current control cycle.

[0142] The start time of a link anomaly is fixed as the current sampling time when the link anomaly judgment condition is first met, and the end time is fixed as the time when any one of the following conditions is first met: link recovery judgment is established, timeout identifier expires, version identifier drifts, replacement range is empty, or manual termination is completed. Multiple link anomalies switching consecutively are considered as the same link anomaly period.

[0143] Link anomalies are determined by the target container based on local link status records, receipt transmission results, number of consecutive timeout cycles, number of consecutive failed session cycles, and the arrival time of the most recent valid token. The arrival time of the most recent valid token is used to verify whether the current anomaly has spanned at least one control cycle when the number of consecutive timeout cycles reaches a threshold. The control cycle is consistent with the aforementioned steps and can be set to 200 milliseconds, 500 milliseconds, or 1 second.

[0144] The target container reads the primary link status code, consecutive timeout cycles, and consecutive wrong session cycles within the observation window of the most recent 3 to 10 seconds. The primary link status code is fixed as available, restricted, and interrupted. When the primary link status is interrupted for two consecutive sampling cycles, it is recorded as a link interruption. When the number of consecutive timeout cycles reaches 2 and the time of arrival of the most recent valid token is not less than 1 control cycle from the current time, it is recorded as a consecutive timeout. When the number of consecutive wrong session cycles reaches 2, it is recorded as a wrong session. The agent execution reason and the exception type are fixed and correspond one-to-one, and are recorded as link interruption, consecutive timeout, and wrong session, respectively. When multiple concurrent events occur, the first reason is selected in the order of link interruption, consecutive timeout, and wrong session.

[0145] The currently valid control session is the only session record in the local cache of the target container that simultaneously meets the following conditions: the expiration date has not expired, the version ID is consistent with the version of the most recently effective command, and the most recent valid local execution record belongs to this session. When there are multiple candidate sessions, priority is given to the session with the most recent acceptance time. If the acceptance times are the same, priority is given to the session with the latest version ID.

[0146] The constrained agent execution is limited to maintaining the operation of the current business instance, maintaining the current link configuration, maintaining the current resource configuration, maintaining the current power supply configuration, and performing recovery on existing business instances that are marked as recoverable in the business list with version ID locked, within the control scope after pruning the most recent valid local execution record. It may not add new business instances, expand the resource occupation boundary, or change the link and power supply configuration that are not authorized by the current valid management session.

[0147] Before entering the agent execution phase, the target module reads the currently valid control session, the most recent valid local execution record, the local autonomy level, and the module's real-time status. The most recent valid local execution record is the last local execution record under the same session identifier, the same target module number, and the same version identifier, whose execution boundary is either full acceptance or limited acceptance. Constrained agent execution is only allowed to start when the control category of the most recent valid local execution record belongs to status maintenance control, core business maintenance control, or limited recovery control, and the local autonomy level is maintained or restricted.

[0148] The replacement scope is fixed at the maximum control scope of the most recent valid local execution record after pruning. It can only be equal to or less than this scope and cannot be expanded. Business instance objects must remain alive or recoverable and not be blocked. Resource unit objects must remain available and the token requirement capacity must not be greater than the current allocable capacity. Power supply configuration objects must continue to meet the current power supply configuration requirements. Those that do not meet the requirements will be removed from the replacement scope.

[0149] Each control cycle of the target container determines whether to stop agent execution in the following order: link recovery, expiration of validity period, version drift, empty replacement scope, and manual termination. Manual termination is always an authorized termination command from the target container's local maintenance interface, representing a local management action outside the currently valid control session, and takes precedence over link recovery. The target container generates one startup evidence fragment when agent execution starts, adds one continuous evidence fragment each control cycle during agent execution, and generates one stop evidence fragment when agent execution stops. Existing records are not overwritten. Continuous evidence fragments are appended and do not update existing startup or continuous evidence fragments.

[0150] The local evidence fragments are fixed to include session identifier, version identifier, target shelter number, reason for proxy execution, scope of substitution, start time of proxy execution, continuous status of proxy execution, reason for stopping proxy execution, corresponding local execution record number, local autonomy level, record time and field status flag. The continuous status of proxy execution is fixed to start, continue and stop. The reason for stopping proxy execution is fixed to link recovery, expiration of time limit, version drift, empty scope of substitution and manual termination.

[0151] The field status flags retain the current, old, and supplementary values. The key fields in this section are fixed and include the session identifier, version identifier, and expiration identifier of the currently valid management session, the control category and trimmed control scope of the most recent valid local execution record, the local autonomy level, and the primary link status code. If any of these are old or supplementary values, no new constrained agent execution will be initiated; only agent execution actions that have been initiated and have not yet expired are allowed to be maintained. Once the expiration identifier of an initiated agent execution action expires, the version drifts, the replacement scope becomes empty, or manual termination is established, even if the key fields are restored to the current values, the original agent execution action must not be continued.

[0152] The target module writes local evidence fragments into the local evidence fragment table and the local trace log, using the session identifier, target module number, record time, and agent execution persistence status as the joint unique key. The local evidence fragment table stores currently valid agent execution evidence and historical agent execution evidence that has not exceeded the retention period. The currently valid agent execution evidence is the latest local evidence fragment under the same session identifier and the same target module number whose agent execution persistence status is started or ongoing and has not yet stopped. The currently valid agent execution evidence is only used for agent execution maintenance determination during link anomalies and recovery ruling invocation after link recovery. The local trace log stores all success and stop records, with a fixed retention period of no less than 180 days.

[0153] The intermediate record for proxy execution determination includes at least the link exception type, trigger time, current valid control session number, the number of the most recent valid local execution record, the alternative scope pruning result, the local autonomy level, and the stop determination result. If the current valid control session or the most recent valid local execution record is missing, it is uniformly classified as session missing; alternative scope generation failure is classified as scope generation failure; local evidence fragment writing failure is classified as evidence writing failure; and the reason for proxy execution stoppage cannot be determined is classified as stoppage reason missing. The minimum set of error codes corresponding to this step is fixed and includes session missing, scope generation failure, evidence writing failure, and stoppage reason missing, and each error code is mutually exclusive; when multiple exceptions occur simultaneously, they are classified in the order of session missing, scope generation failure, evidence writing failure, and stoppage reason missing.

[0154] During on-site inspection, with no fewer than 30 control sessions, no fewer than 3 target cabins per session, and no fewer than 20 link anomaly samples per target cabin, the link anomaly logs and manual review annotations can be used as comparison benchmarks to check the accuracy of link anomaly judgment, the accuracy of constrained agent execution startup, the success rate of local evidence fragment generation, and the accuracy of evidence retrieval after link recovery. Preferably, the accuracy of link anomaly judgment is no less than 99%, the accuracy of constrained agent execution startup is no less than 99%, the success rate of local evidence fragment generation is no less than 99%, and the accuracy of evidence retrieval after link recovery is no less than 99%.

[0155] For example, in a preferred embodiment, if a target container experiences a primary link status interruption for two consecutive cycles under a 500-millisecond control cycle, and the control category of the most recent valid local execution record is core business maintenance control, the pruned control scope includes one surviving business instance and one available resource unit, the local autonomy level is restricted, and the remaining time of the timeout indicator is 5 seconds, the target container initiates constrained proxy execution accordingly, using the link interruption as the reason for proxy execution, and retains the aforementioned two control objects in the replacement scope. When the link is restored after 2.5 seconds, the proxy execution stops, forming three local evidence fragments, corresponding to start, continue, and stop, respectively.

[0156] S6. After the link is restored, receive the restoration reconciliation receipts from each target module, execute the restoration decision based on the restoration reconciliation receipts, and execute cross-module convergence control based on the restoration decision results. The specific implementation is as follows:

[0157] In one embodiment, after the link is restored, the system receives restoration reconciliation receipts from each target module, executes restoration decisions based on the restoration reconciliation receipts, and performs cross-module convergence control based on the restoration decision results. This system can be deployed in the central control node of the aforementioned distributed module system. It is applicable to the closed-loop recovery phase after the target modules have performed constrained proxy execution and generated local evidence fragments during the link anomaly, and the primary link between the central control node and each target module has been restored to usability. It is used to uniformly pull back the local execution results, proxy execution results, and current status generated by each target module during the anomaly to the same control session and the same version identifier for verification, decision-making, and convergence.

[0158] Link recovery is defined as the primary link status being restored to available status for two consecutive sampling cycles, and the central control node receiving a valid acceptance receipt or recovery reconciliation receipt from the target shelter for two consecutive control cycles. In this step, a valid receipt is one in which the session identifier, version identifier, target shelter number, and record time are all verified, and the result code does not belong to an incorrect session, timeout, or missing field acceptance receipt or recovery reconciliation receipt. The recovery time is taken as the end time of the current control cycle that meets the conditions.

[0159] Within the current control cycle after the link is restored, the central control node sends a recovery reconciliation request to each target container. The recovery reconciliation request includes a fixed session identifier, version identifier, linkage identifier, target container number, request number, request time, and waiting window. The request number is used as a deduplication key.

[0160] The recovery reconciliation receipt is jointly generated from the target module's local execution record table, local evidence fragment table, most recently effective local command status record, and module-side context summary. It consistently includes the session identifier, version identifier, target module number, most recently effective local execution record number, execution boundary of the most recently effective local execution record, trimmed control scope of the most recently effective local execution record, reason for proxy execution of the most recently effective local evidence fragment, substitution scope, reason for proxy execution termination, version of the most recently effective local command, current operating mode, current power supply status, current business instance status summary, record time, and field status flags. The current business instance status summary consistently records the business instance number, liveness status, and containment flag in the order of controlled objects. All source fields in the recovery reconciliation receipt must maintain the same version identifier as the current session master record; mixing older versions is not allowed.

[0161] After receiving the recovery reconciliation receipt, the central control node performs sequential verification and deduplication verification using the session identifier, version identifier, target cabin number, and record time. If they are completely identical, they are recorded as duplicate receipts. If the record time is earlier than the time of the most recent received recovery reconciliation receipt, it enters the waiting review queue. The waiting review queue is a local temporary storage queue of the central control node. If the previous missing receipt is supplemented within one control cycle and the previous missing receipt passes the session boundary and version boundary verification, the current out-of-order receipt is transferred to the recovery adjudication; otherwise, it is transferred to out-of-order discard.

[0162] Recovery decisions are based on records with a time deviation of no more than one control cycle, forming the same decision base. If the deviation exceeds the limit, the newer record time is used as the primary base, and older records are only used for record keeping and are not included in object boundary calculations. The currently valid token record is the last successfully sent and not rolled back constrained control token record under the same session identifier, the same target module number, and the same version identifier. Recovery decisions are executed in a fixed order of session boundary, version boundary, execution boundary, agent execution boundary, and object boundary.

[0163] The object boundary output is fixed and includes the final agent execution scope and object removal record. The object removal record includes at least the object number, object type, and removal reason. The removal reason is fixed and includes five categories: business instance stopped, business instance blocked, resource unavailability, insufficient capacity, and power supply mismatch. The recovery ruling result is fixed and includes: remain valid, partial rollback, full rollback, and reissue, with the priority being full rollback, reissue, partial rollback, and remain valid. Only one recovery ruling result is generated within a single module.

[0164] The central control node generates a recovery decision record based on the recovery decision result. The recovery decision record is a single-cabin-level record. Cross-cabin convergence control is executed under the same linkage identifier. The cross-cabin convergence view is a linkage group-level summary record formed by the central control node after waiting for all recovery reconciliation receipts or waiting for the window to reach 3 control cycles. The cross-cabin convergence view is only used for cross-cabin comparison and convergence control generation within the current recovery cycle and is not used as an input record for subsequent session establishment. It is fixed to include the linkage identifier, member set, recovery decision result of each target cabin, final agent execution scope, object removal record, and receipt missing flag. Target cabins with missing receipts are marked as missing members and participate in convergence comparison without waiting for secondary convergence. Missing members are treated as incomplete recovery reconciliation in cross-cabin convergence. When missing members cause the linkage group to fail to form a valid convergence result, they are preferentially marked as convergence failure.

[0165] The cross-module convergence control results are fixed as follows: full group hold, partial rollback, full group rollback, and reconstruction issuance, with the priority order being reconstruction issuance, full group rollback, partial rollback, and full group hold. If any target module's recovery decision result is reissued, it is recorded as reconstruction issuance; if all target modules are fully rolled back, it is recorded as full group rollback; if there is partial rollback and no reissue, it is recorded as partial rollback; otherwise, it is recorded as full group hold.

[0166] The rollback list is fixed and includes the target module number, the set of rollback objects, the rollback reason, and the execution order. The token candidate list is fixed and includes the target module number, the set of control objects to be issued, the control category, and the version identifier, both generated from the current session master record and the recovery adjudication record. The recovery adjudication record is a single module-level record, while the cross-module convergence control record is a linkage group-level record. If the recovery reconciliation receipt is missing, the session adjudication fails, the version adjudication fails, the object boundary calculation fails, or the cross-module summary is incomplete, it will be categorized as a missing receipt, session failure, version failure, object calculation failure, or convergence failure, respectively.

[0167] During on-site inspection, the original text of the restored reconciliation receipt and the offline replay results were used as the main comparison benchmarks, and manual review and annotation were used as the sampling verification benchmarks. The accuracy rates of restored reconciliation receipt reception, restored decision-making, cross-cabin convergence control, and reconstruction issuance consistency were checked. The reconstruction issuance consistency rate was the proportion of token candidate lists generated by reconstruction that were consistent with the offline replay benchmark lists in four aspects: target cabin number, set of controlled objects, control category, and version identifier. Alternatively, the restored reconciliation receipts could be written to the local cache of the central control node before batch execution of restored decisions, or the cross-cabin convergence control records could be stored in the real-time database cache using fixed byte segment encoding. As long as the field list under the same version identifier is fixed, the order of restored decisions is fixed, the cross-cabin comparison rules are fixed, the joint unique key is fixed, the evidence chain is traceable, and the next stage can directly call upon the data, these are all feasible alternative forms of this step.

[0168] All calculations involved in the embodiments are dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to the actual situation.

[0169] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0170] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired transmission; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0171] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0172] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0173] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0174] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0175] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0176] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0177] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for remote control of a distributed mobile shelter, characterized in that, include: S1. Establish a control session for the target modular unit group, generate session identifier, version identifier, timeliness identifier and linkage identifier, and generate the corresponding modular unit context summary based on the current operating status of each target modular unit; S2. Collect the link status, receipt continuity status, local autonomy status, and most recently effective command status of each target module; form the receipt continuity status based on control token sending records, receipt receiving records, and timeout retry records; obtain the link status based on link monitoring messages, heartbeat messages, and link switching records; obtain the local autonomy status based on the autonomy policy status register and autonomy switching records; obtain the most recently effective command status based on the command effectiveness register and valid receipt records; generate a link profile based on the link status and receipt continuity status; generate an execution semantic profile based on the local autonomy status and most recently effective command status. S3. Generate the corresponding constrained control token for the target container based on the session identifier, version identifier, timeliness identifier, container-side context summary, link profile, and execution semantic profile. S4. Send the constrained control token to the corresponding target module, which performs condition verification based on the module-side context summary and generates a local execution record based on the condition verification result. S5. During a link anomaly, the target container executes a constrained proxy based on the current effective control session and generates a local evidence fragment containing the reason for the proxy execution and the scope of alternatives. S6. After the link is restored, receive the restoration reconciliation receipt returned by the target container, execute the restoration decision based on the restoration reconciliation receipt, and execute cross-containment convergence control based on the restoration decision result.

2. The method for remote control of a distributed modular shelter according to claim 1, characterized in that, S1 includes: The members of the target mobile cabin team were determined based on the task scheduling ledger, asset registration form, and online heartbeat records. The version identifier is locked based on the rule repository, parameter repository, and interface configuration repository; Time alignment is performed on the acquisition and transmission times in the cabin-side messages based on a unified time reference. Generate a cabin-side context summary based on the current operational status after time alignment, and write it into the cabin-side context summary table using the session identifier and cabin number as unique keys.

3. The method for remote control of a distributed modular shelter according to claim 1, characterized in that, S3 includes: Read the current session master record, cabin-side context summary, link profile, execution semantic profile, and pending control content record, and align them using the sampling time as a unified time benchmark; The control scope is formed by comparing the set of control objects in the control content to be executed with the business instance list, resource list and power supply list item by item; Execution priority is determined based on task level, linkage indicator, and remaining time. Write the sending method flag based on the execution semantic profile and link profile.

4. The distributed modular shelter remote control method according to claim 3, characterized in that: When the semantic profile is ready to be directly accepted, the primary link status code in the link profile is available, and there are no high latency, high jitter, heavy packet loss, or frequent switching issues in the link profile, the write is sent immediately. In other cases where a restricted control token can be generated, write restricted transmission; When writing the transmission mode flag, retry boundaries and failure conditions are written simultaneously.

5. The distributed modular shelter remote control method according to claim 1, characterized in that, S4 include: The constrained control token is validated and deduplicated in the order of session identifier, version identifier, target container number, and token number. Using the target container's reception time as the current baseline, and based on the container-side context summary and real-time status, condition checks are performed according to timeliness boundaries, version boundaries, object boundaries, autonomy boundaries, and duplication boundaries. The execution boundary is determined based on the condition verification results, and a local execution record is generated.

6. The distributed modular shelter remote control method according to claim 1, characterized in that, S5 include: Link anomalies are determined based on local link status records, receipt transmission results, number of consecutive timeout periods, number of consecutive failed session periods, and the arrival time of the most recent valid token. Based on the current effective control session, the most recent effective local execution record, the local autonomy level, and the real-time status of the cabin side, an alternative range is generated with the trimmed control range of the most recent effective local execution record as the upper limit. Perform constrained proxy execution based on the scope of substitution, and generate local evidence fragments containing the reason for proxy execution and the scope of substitution.

7. The distributed modular shelter remote control method according to claim 1, characterized in that, S6 include: The reconciliation receipts are verified and deduplicated in sequence according to the session identifier, version identifier, target shelter number, and record time, and the adjudication base is determined based on the record time. Perform recovery decisions based on session boundaries, version boundaries, execution boundaries, proxy execution boundaries, and object boundaries; A single-cabin-level recovery decision record is generated based on the recovery decision.

8. The method for remote control of a distributed modular shelter according to claim 7, characterized in that: Based on the linkage identifiers, the single-module-level recovery decision records of each target module are summarized to form a cross-module convergence view; Perform cross-compartment comparisons based on the recovery decision results, final agent execution scope, object removal records, and receipt missing flags in the cross-compartment convergence view; Based on the cross-module comparison results, determine the cross-module convergence control results and generate a linkage group-level cross-module convergence control record.

Images