A safety control method, device and medium for a robot edge device

Abstract

The application relates to a safety control method, device and medium for a robot edge device, and belongs to the technical field of robot control. Before a remote call of a control interface of a robot edge device is enabled, a safety contract of the control interface capable of being remotely called is bound; a set of safety contracts that pass verification is activated by an edge execution module, combined with a remote control instruction of each control interface, and two independent execution units that run in parallel and do not block each other are started to realize safety control of the robot edge device; a task execution thread controls a control interface to execute task logic according to the remote control instruction; a safety execution context carries out TTL timeout monitoring and veto monitoring of the control interface based on the safety contract, when an exception is monitored, a safety degradation action of the corresponding control interface is autonomously controlled by being separated from communication with a management and control end, a task execution thread is notified to interrupt or cancel current task logic, a local safety event log is reserved and cloud reporting is supported.

Description

Technical Field

[0001] This application relates to the field of robot control technology, and in particular to a safety control method, device and medium for robot edge devices. Background Technology

[0002] Existing remote safety control of robot edge devices mostly adopts a centralized handling mode, relying on remote monitoring terminals to detect anomalies, replan, and issue error correction commands. However, in this mode, edge devices usually lack autonomous safety fallback capabilities and rely entirely on network communication for safety handling. When communication between the monitoring module and the edge device becomes unavailable, the issuance and execution of corrective actions become uncertain. The robot will continue to execute the original remote control commands, failing to correct anomalies in a timely manner, posing a safety hazard of operational loss of control. Summary of the Invention

[0003] Therefore, it is necessary to provide a safety control method, device, and medium for robot edge devices to address the aforementioned technical problems.

[0004] A safety control method for a robot edge device, the method comprising: Before the control interface of the robot edge device is allowed to be remotely called, a security contract is bound to each control interface that is allowed to be remotely called and sent to the edge execution module for security verification. The security contract includes a maximum lifespan field and a security degradation action identifier field bound to a single control interface, as well as an edge veto trigger condition field bound to a single control interface or the device's global security domain. The edge execution module activates the verified set of security contracts and, in conjunction with the remote control commands issued by the control terminal to each control interface, starts two independent, parallel, and non-blocking execution units to achieve safe control of the robot's edge device. Each execution unit includes a security execution context and a task execution thread. The task execution thread controls the corresponding control interface to execute task logic according to the remote control commands. The security execution context, based on the maximum lifetime field and edge veto trigger condition field in the security contract, performs TTL timeout monitoring and veto monitoring of the control interface corresponding to the remote control commands. When a TTL timeout is detected or an edge hardware-level veto is triggered, it autonomously controls the corresponding control interface's security degradation action according to the security degradation action identifier field in the security contract, without relying on network communication with the control terminal. Simultaneously, it notifies the task execution thread to interrupt or cancel the current task logic, generates an event record, and writes it to the local security event log and / or reports it through the event channel.

[0005] In one embodiment, before the control interface of the robot edge device is allowed to be remotely invoked, a security contract is bound to each control interface that is allowed to be remotely invoked and sent to the edge execution module for security verification, including: In at least one of the following stages: device registration, device network access, capability list loading, or deployment package activation, a security contract is bound to each control interface that is allowed to be remotely invoked and distributed to the edge execution module. The edge execution module verifies the version number of the security contract, its matching relationship with the control interface, and its signature or digest. If the verification fails, the corresponding control interface is refused activation. Some or all fields of the security contract are configured manually or automatically generated by reading the device capability metadata. When a new model of device is connected, the verified security contract is automatically migrated from the original model of the same type of device as the initial security baseline, and a new security contract is generated. At the same time, during the migration process, parameters in the verified security contract that differ from a preset threshold are marked.

[0006] In one embodiment, TTL timeout monitoring includes: Based on the edge local monotonic clock and the maximum lifetime field in the security contract bound to the control interface corresponding to the remote control command, the local deadline of the remote control command is generated, and the remote control command and its local deadline are stored in the list of commands to be monitored, and the command status is marked as active; wherein, the remote control command carries the command identifier and the control interface identifier, as well as the command sequence number or command epoch value. The security execution context periodically traverses the list of monitored instructions at a higher frequency than the task execution thread. For each remote control instruction in the list that is active, it reads the current edge local monotonic clock value. If the current edge local monotonic clock value does not exceed the local deadline of the remote control instruction, monitoring continues. If the current edge local monotonic clock value exceeds the local deadline of the remote control instruction, and the remote control instruction has not been completed or a valid instruction refresh message has not been received, it autonomously controls the security degradation action of the corresponding control interface according to the security degradation action identifier field in the security contract bound to the control interface corresponding to the remote control instruction, without relying on network communication with the management end. At the same time, it notifies the task execution thread to interrupt the current task logic, generates a security event record containing the instruction ID, control interface identifier, timeout time, and type of triggered security degradation action, writes it to the local security event log that cannot be modified by the task execution thread, and reports it through the event channel.

[0007] In one embodiment, the instruction refresh message carries the instruction identifier of the target instruction and the instruction sequence number or instruction epoch value of the target instruction. After receiving the instruction refresh message, the secure execution context performs a verification: only if the target instruction exists in the list of instructions to be monitored, is in an active state, and the instruction sequence number or instruction epoch value carried in the instruction refresh message is consistent with the current instruction sequence number or instruction epoch value of the target instruction, the local deadline of the target instruction is recalculated based on the current edge local monotonic clock value, and TTL timeout monitoring is performed again; instruction refresh messages for expired instructions are rejected, and expired instructions can only be restored to control by re-issuing new remote control instructions.

[0008] In one embodiment, veto monitoring includes: The robot's edge device's local sensor readings are continuously monitored with the highest priority by the safe execution context. When the real-time readings of the local sensor meet the edge veto trigger condition field bound to a single control interface or the device's global security domain, the edge hardware-level veto is triggered. This means that the security execution context, with higher priority than the remote control commands, vetoes the current remote control command for a single control interface or all relevant remote control commands for the robot's edge device. Furthermore, according to the security degradation action flag field in the security contract bound to the corresponding control interface, the system autonomously controls the corresponding control interface's security degradation action without relying on network communication with the management terminal. Simultaneously, it notifies the task execution thread to initiate a cancellation operation for the currently executing task logic, generating a veto event. The event record is written to the local security event log that cannot be modified by the task execution thread and reported through the event channel. Furthermore, when the task execution thread initiates a cancellation operation on the currently executing task logic and does not receive a cancellation success confirmation within the preset timeout period, the predefined cancellation failure degradation action of the control interface is executed. If multiple cancellation operations on the same control interface time out consecutively, the security execution context marks this control interface as non-cancellable. If the control interface experiences another TTL timeout, the cancellation stage is skipped directly, and the next level of security degradation action is executed. The non-cancellable status mark remains unchanged until the device is restarted or the security contract is updated.

[0009] In one embodiment, the security contract bound to each control interface also includes a hardware veto flag field. When the hardware veto flag field is true, the edge veto trigger condition field in the corresponding security contract can only be modified through the device firmware, trusted underlying security module, or security update process verified by the hardware root of trust. It cannot be overridden by the declarative security policy file. When the configuration in the declarative security policy file attempts to overwrite the edge veto trigger condition field, the overwriting operation is rejected and a policy conflict event is generated to be written to the local security event log that cannot be modified by the task execution thread.

[0010] In one embodiment, when the network link between the robot edge device and the control terminal is completely interrupted, the security execution context continues to run independently based on the set of activated security contracts. When a TTL timeout is detected in the control interface corresponding to the received remote control command, the security degradation action indicated by the security degradation action identifier field in the security contract is triggered. At the same time, relying on the edge veto trigger condition field in the security contract, the hardware-level veto is triggered to ensure physical security and enter the fully autonomous edge mode. The security status of the robot edge device is maintained without relying on any network communication. After communication is restored, the local security event logs accumulated during the interruption are reported in batches.

[0011] In one embodiment, the secure execution context includes at least one of an independent thread, an independent process, a real-time task, or a secure coprocessor task.

[0012] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program performing the following steps: Before the control interface of the robot edge device is allowed to be remotely called, a security contract is bound to each control interface that is allowed to be remotely called and sent to the edge execution module for security verification. The security contract includes a maximum lifespan field and a security degradation action identifier field bound to a single control interface, as well as an edge veto trigger condition field bound to a single control interface or the device's global security domain. The edge execution module activates the verified set of security contracts and, in conjunction with the remote control commands issued by the control terminal to each control interface, starts two independent, parallel, and non-blocking execution units to achieve safe control of the robot's edge device. Each execution unit includes a security execution context and a task execution thread. The task execution thread controls the corresponding control interface to execute task logic according to the remote control commands. The security execution context, based on the maximum lifetime field and edge veto trigger condition field in the security contract, performs TTL timeout monitoring and veto monitoring of the control interface corresponding to the remote control commands. When a TTL timeout is detected or an edge hardware-level veto is triggered, it autonomously controls the corresponding control interface's security degradation action according to the security degradation action identifier field in the security contract, without relying on network communication with the control terminal. Simultaneously, it notifies the task execution thread to interrupt or cancel the current task logic, generates an event record, and writes it to the local security event log and / or reports it through the event channel.

[0013] A computer-readable storage medium having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Before the control interface of the robot edge device is allowed to be remotely called, a security contract is bound to each control interface that is allowed to be remotely called and sent to the edge execution module for security verification. The security contract includes a maximum lifespan field and a security degradation action identifier field bound to a single control interface, as well as an edge veto trigger condition field bound to a single control interface or the device's global security domain. The edge execution module activates the verified set of security contracts and, in conjunction with the remote control commands issued by the control terminal to each control interface, starts two independent, parallel, and non-blocking execution units to achieve safe control of the robot's edge device. Each execution unit includes a security execution context and a task execution thread. The task execution thread controls the corresponding control interface to execute task logic according to the remote control commands. The security execution context, based on the maximum lifetime field and edge veto trigger condition field in the security contract, performs TTL timeout monitoring and veto monitoring of the control interface corresponding to the remote control commands. When a TTL timeout is detected or an edge hardware-level veto is triggered, it autonomously controls the corresponding control interface's security degradation action according to the security degradation action identifier field in the security contract, without relying on network communication with the control terminal. Simultaneously, it notifies the task execution thread to interrupt or cancel the current task logic, generates an event record, and writes it to the local security event log and / or reports it through the event channel.

[0014] The aforementioned safety control method, device, and medium for robot edge devices pre-bind a safety contract containing a maximum lifespan, a safety degradation action identifier, and an edge veto trigger condition to all remotely callable control interfaces before the control interfaces of the robot edge devices are allowed to be remotely invoked. This makes the safety contract an intrinsic attribute of the control interface, effectively adapting to the safety control requirements of different control interfaces under task logic. Furthermore, by setting up independent, parallel, and non-blocking safety execution contexts and task execution threads on the edge execution side for division of labor, business task execution and safety monitoring are completely decoupled, preventing abnormal business logic from blocking safety monitoring. The testing process allows for independent monitoring of instruction timeouts and determination of hardware status rejection within the secure execution context. In scenarios involving network disconnection or loss of connection with upper-layer control nodes, it can locally perform interface security degradation operations and promptly halt business tasks. Furthermore, it forms a dual-layer offline security barrier based on instruction lifecycle timeliness control and local sensor hardware status hard rejection, effectively mitigating the risks of robot malfunctions caused by network latency, disconnection, reuse of outdated instructions, and abnormal equipment conditions. Simultaneously, it retains structured event logs and supports cloud reporting, enabling full traceability and auditing of abnormal security behaviors. Overall, it enhances the operational stability, emergency response capabilities, and comprehensive security management level of the robot's remote edge control. Attached Figure Description

[0015] Figure 1This is a flowchart illustrating a safety control method for a robot edge device in one embodiment; Figure 2 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0017] In one embodiment, such as Figure 1 As shown, a safety control method for robot edge devices is provided, including the following steps: 1. Initialization: Upon initial deployment or reconfiguration of the edge device, before remote invocation of the robot's edge device control interface is permitted, a safety contract is bound to each remotely invoked control interface and sent to the edge execution module for security verification. Each safety contract includes a maximum lifespan field (TTL, in milliseconds) bound to a single control interface and a safety degradation action identifier field (indicating the specific degradation action to be executed upon timeout or veto), and an edge veto trigger condition field bound to a single control interface or the device's global security domain (which local sensor reading triggers veto, such as LiDAR detecting an obstacle at a distance of <50cm).

[0018] In this embodiment, the binding of the control interface and the security contract occurs at least once during the device registration phase, the device network access phase, the capability list loading phase, or the deployment package activation phase. After binding the security contract, the security contract set is sent to the edge execution module along with the device's runtime configuration data. The sending method is not limited; it can be sent along with the deployment package or through a separate configuration sending channel. Before loading, the edge execution module performs an integrity check on the security contract set, including checking the version number of the security contract, its matching relationship with the control interface, and its signature or digest. If the check fails, the corresponding control interface is not activated, and the device does not enter the ready state. Some or all fields of the security contract are automatically generated by a preset calculation model through manual configuration or by reading the device's capability metadata (braking distance or braking time, maximum speed, communication delay distribution). When a new model of device is connected, the verified security contract is automatically migrated from the original model of the same category of device as the initial security baseline, and a new security contract is generated. At the same time, during the migration process, parameters in the verified security contract that differ from a preset threshold are marked.

[0019] It should be understood that the security contract is bound before the control interface is allowed to be remotely called, rather than being dynamically issued at runtime. This solidifies the security contract into an inherent attribute of the control interface, forming a permanent binding association with it. Even if the robot's business task logic is iterated and updated, the program version changes, or the functional process is adjusted, the security contract continues to be effective along with its respective control interface without the need for repeated issuance and reconfiguration. This fundamentally avoids the problems that are prone to occur when dynamically distributing security contracts at runtime, such as network packet loss, issuance delay, mismatch between old and new version configurations, omission of interface security rule loading, and contract invalidation and unbinding. It achieves deep coupling and binding between security constraints and control interfaces, ensuring the long-term stability and effectiveness of timeliness management, hardware veto, and security degradation rules for each remote control interface. It also avoids the absence of security protection mechanisms due to business iteration changes, and continuously maintains the integrity and consistency of security constraints in the robot's edge remote control system. Furthermore, by supporting the inheritance of safety contracts across different models of the same product category, reuse and derivation can be completed based on the safety baseline template of the control interface shared by robots of the same product category. For different product models, only the maximum life cycle, edge rejection trigger threshold, and safety degradation action parameters need to be adjusted to quickly generate a dedicated safety contract adapted to the model, without having to repeat the full configuration of safety rules from scratch. In scenarios of equipment iteration and batch deployment of multiple models on production lines, it can not only uniformly inherit standardized basic safety constraints to ensure the consistency of the safety management baseline of robots in the same series, but also allow the retention of differentiated safety strategies for each model to adapt to its own hardware structure and motion performance. This significantly shortens the development and verification cycle of safety contracts for new models, while avoiding the problems of inconsistent standards and oversights in setting safety thresholds caused by independent customization of rules for multiple models. It achieves a balance between efficient reuse of safety configurations, unified management and control and model-differentiated adaptation.

[0020] For example, generating the maximum survival period field in the safety contract based on equipment capability metadata includes: when the equipment capability metadata includes braking time, braking time is preferentially used as the recommended value for the maximum survival period field; when the equipment capability metadata only includes braking distance and maximum speed, braking time is estimated based on a preset kinematic model, and then the estimated braking time is used as the recommended value for the maximum survival period field; the automatically generated safety contract includes a confidence score, and parameters with low confidence are marked as requiring manual confirmation. Specifically, braking time... Estimation example: (Uniformly decelerated model); ; in, Braking distance, For maximum speed, For the amplitude limiting function, Due to sensor acquisition delay, Due to the delay in remote control command transmission, For safety margin, The minimum value preset for the maximum lifespan field. The maximum value preset for the maximum lifetime field. Furthermore, it can be further adjusted based on network quality metrics such as round-trip delay, latency jitter, and packet loss rate. and The TTL value is dynamically adjusted within the specified range, and the adjustment operation has hysteresis logic; the adjustment record is written to the safe drift log.

[0021] It should be understood that by reading device capability metadata, including braking distance, braking time, maximum speed, and communication latency distribution, and automatically generating the maximum lifespan field of the safety contract based on a preset calculation model, the robot's hardware braking performance, motion limits, and network transmission fluctuation characteristics can be quantified and integrated into the timeliness threshold calculation. This abandons the crude mode of manually configuring TTL parameters statically based on experience. On the one hand, it ensures that the maximum lifespan is accurately matched with the device's actual physical braking capability and network latency characteristics. This avoids the risk of overtravel collisions caused by remote expired instructions due to excessively long timeliness settings, and also avoids the impact of frequent false interceptions of legitimate remote instructions due to excessively short thresholds, which would affect the continuity of operations. On the other hand, it achieves standardized and automated generation of safety parameters, significantly reducing the workload of manual calculation, verification, and debugging, and avoiding parameter omissions, overly conservative or aggressive over-limit issues caused by manual configuration. At the same time, it is compatible with batch deployment scenarios of multiple robot models and batches. Combined with the aforementioned cross-model safety contract inheritance mechanism, it can quickly complete the adaptive generation of timeliness parameters for new models, ensuring a unified timeliness safety baseline for the entire series of devices and full compatibility of the differentiated hardware characteristics of each model. This improves the accuracy of the TTL timeout protection mechanism, the efficiency of engineering implementation, and the safety consistency of all models from the source.

[0022] In this embodiment, each control interface is bound to a security contract that also includes a hardware veto flag field. When the hardware veto flag field is true, the edge veto trigger condition field in the corresponding security contract can only be modified through the device firmware, trusted underlying security module or security update process verified by the hardware root of trust. It cannot be overridden by the declarative security policy file. When the configuration in the declarative security policy file attempts to overwrite the edge veto trigger condition field, the overwriting operation is rejected and a policy conflict event is generated to be written to the local security event log that cannot be modified by the task execution thread.

[0023] It should be understood that the edge veto right trigger condition field marked by the hardware veto flag field has a hardware-level unwriteable protection mechanism, which does not allow various declarative security policy files to overwrite its parameters and judgment logic. It rigidly isolates the physical security bottom line of the device from the upper-layer dynamically adjustable business security policy, completely eliminating the risk of tampering with the veto threshold or canceling the hardware braking condition by issuing and updating policy files. It avoids the failure of the local hardware bottom-line security defense line due to malicious configuration tampering, version update omissions, and operation and maintenance errors. Once the underlying veto rule is bound, it becomes fixed and effective, and is not affected by the iteration of upper-layer business policies or remote configuration issuance. Even if the management end or the cloud pushes new declarative security policy files, it cannot erase or change the emergency veto judgment standard based on the sensor working condition on the edge side. It always maintains the highest priority protection capability of prioritizing the interception of remote commands due to abnormal hardware working conditions. It builds a physical security bottom-line barrier for robot edge remote control that is not subject to upper-layer software policy intervention and cannot be bypassed. It blocks the security vulnerability of the underlying security constraints being tampered with by humans or programs at the configuration permission level.

[0024] 2. Safety Control: The edge execution module activates the verified set of security contracts and, in conjunction with the remote control commands issued by the control terminal for each control interface, starts two independent and parallel execution units that do not block each other, in order to achieve safety control of the robot's edge device; among them, the execution unit includes a security execution context and a task execution thread.

[0025] In this embodiment, the task execution thread runs at a frequency of ≥100Hz to consume data from the communication bus and control the corresponding control interface to execute task logic according to remote control instructions.

[0026] It should be understood that, based on the design of two execution units running independently and in parallel without blocking each other, the running state of the task execution thread will not directly interfere with the scheduling, computation, and hardware calling logic of the secure execution context. Even if the task execution thread experiences various failure scenarios such as blocking, infinite loop, program crash, or abnormal exit, the secure execution context can still continuously and periodically perform TTL timeout monitoring and edge hardware condition rejection monitoring without interference, fully retain the operation permissions of each control interface, and can independently call the corresponding control interface at any time to autonomously trigger preset local security degradation actions. It will not lose the underlying security fallback capability due to business process failure, and eliminates the single point of failure of security protection caused by business thread failure from the perspective of the operation scheduling architecture. It ensures that the robot edge device still has uninterrupted offline emergency braking capability when the business logic is abnormal, and effectively avoids the loss of control safety accidents caused by business thread failure combined with remote dangerous commands and abnormal equipment conditions.

[0027] In this embodiment, the secure execution context is implemented independently of the task execution thread. It can be an independent thread, an independent process, a real-time task of an RTOS (Real-Time Operating System), or a secure coprocessor task, running at a frequency of ≥200Hz. It uses the device's edge local monotonic clock as its time base, and this edge local monotonic clock is monotonically increasing, unaffected by system time adjustments, NTP (Network Time Protocol), or leap seconds. This ensures that the deadline calculated based on this clock cannot be bypassed by external time modification or replay attacks. The secure execution context is responsible for two core tasks: based on the maximum lifetime field and the edge veto trigger condition field in the security contract, it performs TTL timeout monitoring and veto monitoring of the control interface corresponding to the remote control command. When a TTL timeout is detected and the edge hardware-level veto is triggered, it autonomously controls the security degradation action of the corresponding control interface according to the security degradation action identifier field in the security contract, without relying on network communication with the management terminal. At the same time, it notifies the task execution thread to interrupt or cancel the current task logic, generates an event record and writes it to the local security event log and / or reports it through the event channel.

[0028] In this embodiment, TTL timeout monitoring includes: Based on the edge local monotonic clock and the maximum lifetime field in the security contract bound to the control interface corresponding to the remote control command, the local deadline of the remote control command is generated (local deadline = edge local monotonic clock + maximum lifetime field), and the remote control command and its local deadline are stored in the list of commands to be monitored, and the command status is marked as active; wherein, the remote control command carries the command identifier (command_id) and the control interface identifier (capability_id), as well as the command sequence number (sequence_number) or the command epoch value (command_epoch).

[0029] The security execution context periodically traverses the list of monitored instructions at a frequency higher than that of the task execution thread (e.g., ≥200Hz). For each remote control instruction in the list that is active, it reads the current edge local monotonic clock value. If the current edge local monotonic clock value does not exceed the local deadline of the remote control instruction, monitoring continues. If the current edge local monotonic clock value exceeds the local deadline of the remote control instruction, and the remote control instruction has not been completed or a valid instruction refresh message has not been received, it autonomously controls the security degradation action of the corresponding control interface (including sending a zero-speed instruction to stop the device, triggering an emergency stop to cut off power output, maintaining the current state of hovering, or returning to the preset safety origin) without relying on network communication with the management end (which can also be the monitoring end or the cloud). At the same time, it notifies the task execution thread to interrupt the current task logic, generates a security event record containing the instruction ID, control interface identifier, timeout time, and type of triggered security degradation action, writes it to the local security event log that cannot be modified by the task execution thread, and reports it through the event channel.

[0030] The instruction refresh message carries the instruction identifier of the target instruction and its sequence number or epoch value. Upon receiving the instruction refresh message, the secure execution context performs a verification: only if the target instruction exists in the list of monitored instructions, is in an active state, and the sequence number or epoch value carried in the instruction refresh message matches the current sequence number or epoch value of the target instruction, will the local deadline of the target instruction be recalculated based on the current edge local monotonic clock value, and TTL timeout monitoring be performed again. Instruction refresh messages for expired instructions are rejected, and expired instructions can only regain control by re-issuing new remote control instructions. It is important to note that the refresh operation does not use a remote timestamp.

[0031] In this embodiment, veto monitoring includes: The robot's edge device's local sensor readings are continuously monitored with the highest priority by the safety execution context.

[0032] When the real-time readings of local sensors meet the edge veto trigger condition fields bound to a single control interface or the device's global security domain (e.g., the distance of the LiDAR to the obstacle in front is <50cm, the torque sensor reading is >120% of the rated value, and the anti-fall sensor detects a suspended edge), the edge hardware-level veto is triggered. That is, the security execution context, with a higher priority than the remote control command, vetoes the current remote control command of a single control interface or all relevant remote control commands of the robot's edge device. According to the security degradation action identifier field in the security contract bound to the corresponding control interface, the robot autonomously controls the security degradation action of the corresponding control interface without relying on network communication with the management terminal. At the same time, the task execution thread is notified to initiate the cancellation operation of the currently executing task logic, a veto event record is generated and written to the local security event log that cannot be modified by the task execution thread, and reported through the event channel. Furthermore, when a task execution thread initiates a cancellation operation on the currently executing task logic and does not receive a successful cancellation confirmation within the preset timeout period, it executes the predefined cancellation failure degradation action of the control interface (such as downgrading from normal cancellation to switching to hold mode → if hold mode still fails, it upgrades to emergency stop). If multiple (e.g., ≥3 times) cancellation operations on the same control interface time out, the security execution context marks this control interface as non-cancellable. If the control interface experiences another TTL timeout, the cancellation phase is skipped, and the next level of security degradation action is executed. The non-cancellable status mark remains unchanged until the device is restarted or the security contract is updated.

[0033] It should be understood that a single cancellation timeout first undergoes a tiered, flexible degradation process (maintaining a fallback mode in normal operation, and directly shutting down the system if the fallback fails), avoiding unnecessary equipment disturbances caused by a hard shutdown due to a single communication / command lag. If the same interface experiences multiple cancellation timeouts, the interface is directly marked as a permanent, non-cancellable fault. Subsequent timeouts will skip the invalid cancellation process and proceed directly to a higher-level safety shutdown action, preventing thread blocking, resource waste, and fault oscillations caused by repeatedly issuing invalid cancellation commands. Furthermore, the non-cancellable interface flag has persistent locking characteristics, and the fault flag can only be cleared by restarting the entire machine or updating the security contract version to restore the interface's normal cancellation capability. This achieves static isolation of faulty interfaces, comprehensively considering smooth fault tolerance for regular anomalies, rigid safety fallback for persistent faults, and manageable recovery of fault states, thus enhancing the stability of security control.

[0034] It is important to note that hardware-level veto power has the highest priority and can only be modified through device firmware, trusted underlying security modules, or security update processes verified by the hardware root of trust. It cannot be overridden by any declarative configuration. TTL timeout degradation triggered by the TTL field of the security contract has the next highest priority, and both hardware-level veto power and TTL timeout degradation take precedence over declarative security policies (configurable policies issued with configuration have the lowest priority). This hierarchical priority mechanism forms a layered security defense system. When multiple security risks are triggered simultaneously by the device, hardware-level veto power caused by abnormal hardware sensor conditions is responded to first, followed by TTL timeout degradation caused by expired remote commands. These actions will not be intercepted, delayed, or overridden by low-priority declarative security policies, preventing situations where business configuration policies restrict the execution of underlying emergency security actions. From a scheduling priority perspective, this ensures that device physical security and command timing security always take precedence over business optimization configuration policies, completely avoiding the problem of upper-layer business policies crowding out lower-layer emergency protection resources and masking the risks of dangerous device conditions and expired commands.

[0035] Furthermore, when the network link between the robot edge device and the control terminal is completely interrupted (no new instructions can be received, and no events can be reported), the security execution context proposed in this application continues to run independently based on the set of activated security contracts. When a TTL timeout is detected in the control interface corresponding to the received remote control instructions, the security degradation action indicated by the security degradation action identifier field in the security contract is triggered. At the same time, relying on the edge veto right trigger condition field in the security contract, the hardware-level veto right is triggered to ensure physical security and enter the fully autonomous edge mode. The security status of the robot edge device is maintained without relying on any network communication. After communication is restored, the local security event logs accumulated during the interruption are reported in batches.

[0036] It should be understood that the secure execution context constructs a dual-layer parallel security protection system consisting of TTL timeout monitoring and edge hardware condition veto. On the one hand, it relies on the local monotonic clock at the edge to calculate the deadline of remote control commands and independently inspect and intercept timeout commands. On the other hand, it triggers edge hardware-level veto based on local sensor conditions. Both risks can be autonomously triggered offline to reduce security, fully covering the two core risks of remote control: command timing failure and abnormal physical conditions of equipment. Moreover, the security reduction is executed at the edge. Even if the upper-layer network is completely disconnected, the remote control link fails, or the business task thread is stuck or crashes, the independently isolated secure execution context can still continue to run for monitoring and emergency response. It can also proactively notify the task execution thread to immediately interrupt the existing dangerous task logic and generate a complete structured event record to be stored in the local log or reported to the upper layer. This forms a complete security closed loop of pre-event time constraints, in-event hardware backup, and post-event traceability and auditing. This significantly reduces the risk of robot misoperation and equipment damage caused by network fluctuations, disconnections, sensor anomalies, and command delays, and significantly improves the offline survivability and functional safety level of the edge remote control system.

[0037] In summary, the aforementioned safety control method for robot edge devices pre-binds a safety contract containing maximum lifespan, safety degradation action identifiers, and edge veto trigger conditions to all remotely callable control interfaces before remote calls are permitted. This makes the safety contract an intrinsic attribute of the control interface, effectively adapting to the safety control requirements of different control interfaces under task logic. Furthermore, by setting independent, parallel, and non-blocking safety execution contexts and task execution threads on the edge execution side, business task execution and safety monitoring are completely decoupled, preventing abnormal business logic from blocking safety monitoring. The process ensures that the secure execution context independently performs instruction timeout monitoring and hardware status rejection. In scenarios where the network is disconnected or the upper-layer control node is out of contact, it can locally perform interface security degradation operations and promptly stop business tasks. It also forms a dual-layer offline security barrier by relying on instruction lifecycle timeliness control and local sensor hardware status hard rejection, effectively avoiding the risks of robot malfunctions caused by network latency, disconnection, reuse of old instructions, and abnormal equipment conditions. At the same time, it simultaneously retains structured event logs and supports cloud reporting, realizing full traceability and auditing of abnormal security behaviors. Overall, it enhances the operational stability of remote edge control of robots, fault emergency handling capabilities, and the level of overall security control.

[0038] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 2As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a safety control method for robotic edge devices. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0039] Those skilled in the art will understand that Figure 2 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0040] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform the following steps: Before the control interface of the robot edge device is allowed to be remotely called, a security contract is bound to each control interface that is allowed to be remotely called and sent to the edge execution module for security verification. The security contract includes a maximum lifespan field and a security degradation action identifier field bound to a single control interface, as well as an edge veto trigger condition field bound to a single control interface or the device's global security domain. The edge execution module activates the verified set of security contracts and, in conjunction with the remote control commands issued by the control terminal to each control interface, starts two independent, parallel, and non-blocking execution units to achieve safe control of the robot's edge device. Each execution unit includes a security execution context and a task execution thread. The task execution thread controls the corresponding control interface to execute task logic according to the remote control commands. The security execution context, based on the maximum lifetime field and edge veto trigger condition field in the security contract, performs TTL timeout monitoring and veto monitoring of the control interface corresponding to the remote control commands. When a TTL timeout is detected or an edge hardware-level veto is triggered, it autonomously controls the corresponding control interface's security degradation action according to the security degradation action identifier field in the security contract, without relying on network communication with the control terminal. Simultaneously, it notifies the task execution thread to interrupt or cancel the current task logic, generates an event record, and writes it to the local security event log and / or reports it through the event channel.

[0041] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Before the control interface of the robot edge device is allowed to be remotely called, a security contract is bound to each control interface that is allowed to be remotely called and sent to the edge execution module for security verification. The security contract includes a maximum lifespan field and a security degradation action identifier field bound to a single control interface, as well as an edge veto trigger condition field bound to a single control interface or the device's global security domain. The edge execution module activates the verified set of security contracts and, in conjunction with the remote control commands issued by the control terminal to each control interface, starts two independent, parallel, and non-blocking execution units to achieve safe control of the robot's edge device. Each execution unit includes a security execution context and a task execution thread. The task execution thread controls the corresponding control interface to execute task logic according to the remote control commands. The security execution context, based on the maximum lifetime field and edge veto trigger condition field in the security contract, performs TTL timeout monitoring and veto monitoring of the control interface corresponding to the remote control commands. When a TTL timeout is detected or an edge hardware-level veto is triggered, it autonomously controls the corresponding control interface's security degradation action according to the security degradation action identifier field in the security contract, without relying on network communication with the control terminal. Simultaneously, it notifies the task execution thread to interrupt or cancel the current task logic, generates an event record, and writes it to the local security event log and / or reports it through the event channel.

[0042] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0043] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0044] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application.

Claims

1. A safety control method for robot edge devices, characterized in that, The method includes: Before the control interface of the robot edge device is allowed to be remotely invoked, a security contract is bound to each control interface that is allowed to be remotely invoked and sent to the edge execution module for security verification. The security contract includes a maximum lifespan field and a security degradation action identifier field bound to a single control interface, as well as an edge veto right trigger condition field bound to a single control interface or the device's global security domain. The edge execution module activates the verified set of security contracts and, in conjunction with the remote control commands issued by the control terminal to each control interface, initiates two independent, parallel, and non-blocking execution units to achieve safe control of the robot's edge device. Each execution unit includes a security execution context and a task execution thread. The task execution thread controls the corresponding control interface to execute task logic according to the remote control commands. The security execution context, based on the maximum lifetime field and the edge veto trigger condition field in the security contract, performs TTL timeout monitoring and veto monitoring of the control interface corresponding to the remote control command. Upon detecting TTL timeout and triggering edge hardware-level veto, it autonomously controls the corresponding control interface's security degradation action according to the security degradation action identifier field in the security contract, without relying on network communication with the control terminal. Simultaneously, it notifies the task execution thread to interrupt or cancel the current task logic, generates an event record, and writes it to the local security event log and / or reports it through the event channel.

2. The safety control method for a robot edge device according to claim 1, characterized in that, Before remote calls are allowed to the control interfaces of the robot's edge devices, a security contract is bound to each control interface that is allowed to be remotely called and sent to the edge execution module for security verification, including: In at least one of the following stages: device registration, device network access, capability list loading, or deployment package activation, a security contract is bound to each control interface that is allowed to be remotely invoked and distributed to the edge execution module. The edge execution module verifies the version number of the security contract, its matching relationship with the control interface, and its signature or digest. If the verification fails, the corresponding control interface is refused activation. Some or all fields of the security contract are configured manually or automatically generated by reading device capability metadata. When a new model of device is connected, the verified security contract is automatically migrated from the original model of the same type of device as the initial security baseline, and a new security contract is generated. At the same time, during the migration process, parameters in the verified security contract that differ from a preset threshold are marked.

3. The safety control method for a robot edge device according to claim 1, characterized in that, The TTL timeout monitoring includes: Based on the edge local monotonic clock and the maximum lifetime field in the security contract bound to the control interface corresponding to the remote control command, the local deadline of the remote control command is generated, and the remote control command and its local deadline are stored in the list of commands to be monitored, and the command status is marked as active; wherein, the remote control command carries a command identifier and a control interface identifier, as well as a command sequence number or command epoch value. The security execution context periodically traverses the list of monitored instructions at a higher frequency than the task execution thread. For each remote control instruction in the list that is active, the current edge local monotonic clock value is read. If the current edge local monotonic clock value does not exceed the local deadline of the remote control instruction, monitoring continues. If the current edge local monotonic clock value exceeds the local deadline of the remote control instruction, and the remote control instruction has not been completed or a valid instruction refresh message has not been received, the security degradation action identifier field in the security contract bound to the control interface corresponding to the remote control instruction is used to autonomously control the security degradation action of the corresponding control interface without relying on network communication with the management and control end. At the same time, the task execution thread is notified to interrupt the current task logic, and a security event record containing the instruction ID, control interface identifier, timeout time, and type of triggered security degradation action is generated. This record is written to the local security event log that cannot be modified by the task execution thread and reported through the event channel.

4. A safety control method for a robot edge device according to claim 3, characterized in that, The instruction refresh message carries the instruction identifier of the target instruction and the instruction sequence number or instruction epoch value of the target instruction. After receiving the instruction refresh message, the secure execution context performs a verification: only if the target instruction exists in the list of instructions to be monitored, is in an active state, and the instruction sequence number or instruction epoch value carried in the instruction refresh message is consistent with the current instruction sequence number or instruction epoch value of the target instruction, the local deadline of the target instruction is recalculated based on the current edge local monotonic clock value, and TTL timeout monitoring is performed again; instruction refresh messages for expired instructions are rejected, and expired instructions can only be restored to control by re-issuing new remote control instructions.

5. A safety control method for a robot edge device according to claim 1, characterized in that, The veto power monitoring includes: The robot's edge device's local sensor readings are continuously monitored with the highest priority by the safe execution context. When the real-time readings of the local sensor meet the edge veto trigger condition field bound to a single control interface or the device's global security domain, the edge hardware-level veto is triggered. This means that the security execution context, with higher priority than the remote control commands, vetoes the current remote control command for a single control interface or all relevant remote control commands for the robot's edge device. Furthermore, according to the security degradation action flag field in the security contract bound to the corresponding control interface, the system autonomously controls the corresponding control interface's security degradation action without relying on network communication with the management terminal. Simultaneously, it notifies the task execution thread to cancel the currently executing task logic, generating a veto event. Records are written to a local security event log that cannot be modified by the task execution thread and reported through an event channel. Furthermore, when the task execution thread initiates a cancellation operation on the currently executing task logic and does not receive a successful cancellation confirmation within a preset timeout period, a predefined cancellation failure degradation action is executed on the control interface. If multiple consecutive cancellation operations on the same control interface time out, the security execution context marks this control interface as non-cancellable. If a subsequent TTL timeout occurs on the control interface, the cancellation phase is skipped, and the next level of security degradation action is executed. The non-cancellable status mark remains unchanged until the device is restarted or the security contract is updated.

6. A safety control method for a robot edge device according to claim 1, characterized in that, Each control interface is bound to a security contract that also includes a hardware veto flag field. When the hardware veto flag field is true, the edge veto trigger condition field in the corresponding security contract can only be modified through the device firmware, trusted underlying security module, or security update process verified by the hardware root of trust. It cannot be overridden by the declarative security policy file. When the configuration in the declarative security policy file attempts to overwrite the edge veto trigger condition field, the overwriting operation is rejected and a policy conflict event is generated to be written to the local security event log that cannot be modified by the task execution thread.

7. A safety control method for a robot edge device according to claim 1, characterized in that, When the network link between the robot edge device and the control terminal is completely interrupted, the security execution context continues to run independently based on the set of activated security contracts. When a TTL timeout is detected in the control interface corresponding to the received remote control command, the security degradation action indicated by the security degradation action identifier field in the security contract is triggered. At the same time, relying on the edge veto right trigger condition field in the security contract, the hardware-level veto right is triggered to ensure physical security and enter the fully autonomous edge mode. The security status of the robot edge device is maintained without relying on any network communication. After communication is restored, the local security event logs accumulated during the interruption are reported in batches.

8. A safety control method for a robot edge device according to claim 1, 3, 4, 5, or 7, characterized in that, The secure execution context includes at least one of an independent thread, an independent process, a real-time task, or a secure coprocessor task.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

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

Images