Supervisory terminal device, control system, and method for monitoring autonomous device

Abstract

The present disclosure provides a supervisory terminal device (10) configured to be physically coupled to an autonomous device (20). The supervisory terminal device (10) comprises a storage unit (100) configured to store an identification code (ID). The supervisory terminal device (10) comprises a processing unit (102) electrically connected with the storage unit (100). The supervisory terminal device (10) comprises a communication unit (104) electrically connected with the processing unit (102). The supervisory terminal device (10) comprises an encryption unit (106) electrically connected with the communication unit (104). The processing unit (102) is configured to output the identification code (ID) for confirming an identity of the autonomous device (20) through the communication unit (104). The encryption unit (106) is configured to encrypt the identification code (ID) and other information transmitted by the supervisory terminal device before outputting of the identification code (ID) and the other information.

Description

SUPERVISORY TERMINAL DEVICE, CONTROL SYSTEM, AND METHOD FOR MONITORING AUTONOMOUS DEVICE

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Application No. 63 / 777,030, titled METHODS, SYSTEMS &DEVICES FOR MONITORING ROBOTS, filed Mar. 25, 2025, which is hereby incorporated by reference in its entirety.FIELD OF INVENTION

[0003] The present disclosure relates to control systems for autonomous devices, and more particularly to a supervisory terminal device, control system, and method for monitoring an autonomous device.BACKGROUND

[0004] Autonomous devices, including robots, are increasingly deployed in environments where they interact with humans and other systems. These environments include industrial facilities, healthcare settings, hospitality venues, logistics centers, and residential spaces. As autonomous devices become more prevalent in daily life, various approaches have been developed to monitor and regulate their operation.

[0005] Conventional monitoring approaches for autonomous devices include software-based runtime monitors that execute within the device's operating system, safety programmable logic controllers integrated into control loops, and various sensor-based detection systems. These approaches provide different levels of oversight depending on their implementation and integration with the autonomous device's operational systems.

[0006] Autonomous devices typically include perception, planning, and control functions that enable them to navigate and perform tasks within their operating environments. Monitoring systems may observe various aspects of device operation, including position, movement, operational status, and interactions with surrounding objects and people.

[0007] Accordingly, there is a need for a supervisory terminal device, control system, and method for monitoring an autonomous device, operating independently from the autonomous device's autonomy stack.SUMMARY

[0008] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0009] According to an aspect of the present disclosure, a supervisory terminal device is provided. The supervisory terminal device is configured to be physically coupled to an autonomous device. The supervisory terminal device comprises a storage unit configured to store an identification code or a set of identification codes, wherein the identification code may include one or more cryptographic keys or a set of key-related data. The supervisory terminal device comprises a processing unit electrically connected with the storage unit. The supervisory terminal device comprises a communication unit electrically connected with the processing unit. The supervisory terminal device comprises an encryption unit electrically connected with the communication unit. The processing unit is configured to output the identification code for confirming an identity of the autonomous device through the communication unit. The encryption unit is configured to encrypt the identification code (s) and other robot-related information transmitted by the supervisory terminal device using quantum-resistant cryptography before outputting of the identification code (s) and other information. In some aspects, the encryption unit may use the identification code or cryptographic keys stored in the storage unit to encrypt data transmitted for reporting the status of the autonomous device. The encryption unit can also digitally sign any messages to protect its integrity using quantum-resistant cryptography before transmitting the messages.

[0010] The physical coupling of the supervisory terminal device to the autonomous device establishes an out-of-band regulatory architecture that operates independently from the autonomous device's software stack. The supervisory terminal device further includes a hardware-rooted identification code stored in a secure hardware storage region of the device. The identification code may comprise a fused hardware identifier, a physically unclonable function derived identity, or another hardware-bound identifier that uniquely identifies the supervisory terminal device. Because the identification code is generated or stored within trusted hardware of the supervisory terminal device, the identification code cannot be modified or replaced by software executing within the robot system. The hardware-rooted identification code thereby enables external supervisory systems to authenticate the supervisory terminal device and verify the regulatory integrity of the robot. Through this hardware-rooted identification mechanism, the supervisory terminal device can be reliably authenticated by external supervisory systems even when the robot operating system or autonomy stack becomes degraded or compromised. According to other aspects of the present disclosure, the supervisory terminal device may further comprise a tamper detection unit electrically connected with the communication unit and configured to output an alarm signal when the supervisory terminal device is separated from the autonomous device.

[0011] The tamper detection unit provides a mechanism for detecting unauthorized removal or physical manipulation of the supervisory terminal device, thereby maintaining the integrity of the regulatory relationship between the supervisory terminal device and the autonomous device. This feature supports accountability and auditability by ensuring that attempts to circumvent the supervisory function are detected and reported.

[0012] According to other aspects of the present disclosure, the supervisory terminal device may further comprise a blocking unit configured as a hardware intervention module coupled with the baseband processor. The blocking unit is arranged on a control path that is independent of the stack of the robot and is configured to generate a blocking signal that directly interrupts or disables one or more operational interfaces of the robot system. In some embodiments, the blocking signal is delivered through a dedicated control line or hardware gating interface that bypasses the robot operating system and application software layers. The communication unit may be configured to receive an RF signal and to convert the RF signal into a base-band control signal to the processing unit. When the base-band control signal indicates to stop the autonomous device, the blocking unit may be configured to output a blocking signal to stop the autonomous device. In some embodiments, the communication path used by the supervisory terminal device is logically and / or electrically isolated from the autonomous device’s primary communication stack such that software-level modifications, firmware updates, or application-layer reconfiguration within the autonomous device cannot disable, re-route, or override supervisory communication.

[0013] The blocking unit provides a non-bypassable intervention mechanism that enables remote enforcement of safety constraints on the autonomous device. The ability to receive RF signals and convert them to control signals enables out-of-band command reception that is independent of the autonomous device's communication systems, ensuring that intervention commands can be executed even when the autonomous device's primary software stack is unresponsive or compromised. In some embodiments, the blocking unit possesses higher execution privilege than the robot autonomy stack such that safety enforcement cannot be overridden by software components of the robot.

[0014] According to other aspects of the present disclosure, the supervisory terminal device may further comprise a status detection unit electrically connected with the processing unit and configured to detect a status information of the autonomous device. The processing unit may be configured to determine whether the status information is true or to determine whether the autonomous device is under an abnormal condition based on the status information.

[0015] The status detection unit enables continuous monitoring of the autonomous device's operational state through an independent observation channel. The ability to verify the truthfulness of status information and detect abnormal conditions provides a mechanism for identifying discrepancies between reported and actual device behavior, supporting detection of software faults, adversarial manipulation, or misaligned decision policies.

[0016] According to other aspects of the present disclosure, the abnormal condition may comprise at least one of an unreasonable behavior, a non-compliant behavior, an illegal behavior, a behavior that may endanger human beings, and a behavior that violates rules or regulations.

[0017] The enumeration of abnormal condition types provides a structured framework for behavioral assessment that encompasses safety-relevant scenarios in human-centered environments. This categorization supports regulatory compliance verification and enables appropriate intervention responses based on the nature and severity of detected abnormalities.

[0018] According to other aspects of the present disclosure, the communication unit may be configured to receive an RF signal to locate the autonomous device and output a position coordinate to the processing unit.

[0019] The position locating capability provides an independent verification mechanism for the autonomous device's location that does not rely on location information reported by the autonomous device itself. This enables detection of falsified or inaccurate position data and supports spatial constraint enforcement for zone-based authorization policies.

[0020] According to other aspects of the present disclosure, the supervisory terminal device may further comprise a sensing unit electrically connected with the processing unit and configured to sense a movement information and output the movement information to the processing unit. The processing unit may be configured to compute a movement of the supervisory terminal device or a movement of the autonomous device.

[0021] The sensing unit provides an independent source of movement data that can be used to verify consistency between reported and actual device motion. The ability to compute movement trajectories enables detection of implausible position changes and supports physical consistency verification as part of behavioral assessment.

[0022] According to other aspects of the present disclosure, the supervisory terminal device may further comprise a frequency scanning unit electrically connected with the communication unit and configured to detect a frequency band of signals output by the autonomous device.

[0023] The frequency scanning unit enables monitoring of wireless communications emanating from the autonomous device, supporting detection of unauthorized transmissions or communication anomalies. This capability provides visibility into the autonomous device's communication behavior independent of any information reported by the autonomous device itself.

[0024] According to other aspects of the present disclosure, the supervisory terminal device may further comprise a self-detection unit electrically connected with the processing unit and configured to detect whether each unit of the supervisory terminal device is normal.

[0025] The self-detection unit provides a mechanism for verifying the operational integrity of the supervisory terminal device itself, ensuring that the regulatory functions remain reliable. This supports remote attestation capabilities by enabling the supervisory terminal device to report on its own operational status and integrity.

[0026] According to other aspects of the present disclosure, the supervisory terminal device may be independent from an autonomy stack of the autonomous device.

[0027] The independence from the autonomy stack establishes a separation of concerns that ensures the supervisory function remains operational even when the autonomous device's perception, planning, or control functions are degraded, overloaded, or compromised. This architectural separation supports the principle that regulatory authority should not be a subroutine of the system being regulated.

[0028] According to other aspects of the present disclosure, the storage unit may be included within the processing unit or the encryption unit.

[0029] The inclusion of the storage unit within the processing unit or the encryption unit may reduce component count and simplify interconnections within the supervisory terminal device. When the storage unit is integrated within the processing unit, the identification code may be stored in a secure memory region that is isolated from general-purpose memory used for processing operations. When the storage unit is integrated within the encryption unit, the identification code may be stored in protected storage that is co-located with cryptographic key material, allowing the encryption unit to access the identification code directly for encryption operations. This integration may provide enhanced security through tighter integration of storage and processing or cryptographic functions.

[0030] According to another aspect of the present disclosure, a control system is provided. The control system comprises a supervisory terminal device physically coupled to an autonomous device. The supervisory terminal device comprises a storage unit configured to store an identification code, a processing unit electrically connected with the storage unit, a communication unit electrically connected with the processing unit, and an encryption unit electrically connected with the communication unit. The control system comprises a remote supervisory device configured to communicate with the supervisory terminal device. The processing unit is configured to output the identification code to confirm an identity of the autonomous device through the communication unit to the remote supervisory device. The encryption unit is configured to encrypt the identification code using quantum-resistant cryptography before outputting of the identification code.

[0031] The control system architecture establishes a distributed regulatory framework where the supervisory terminal device provides local enforcement and the remote supervisory device provides centralized oversight. The quantum-resistant encryption of identification codes ensures secure identity verification across the communication channel between the supervisory terminal device and the remote supervisory device, supporting accountability and auditability across organizational boundaries.

[0032] According to other aspects of the present disclosure, the communication unit of the supervisory terminal device may be configured to receive a control signal from the remote supervisory device.

[0033] The ability to receive control signals from the remote supervisory device enables centralized policy enforcement and coordinated intervention across multiple autonomous devices. This bidirectional communication capability supports environment-level safety governance while maintaining local enforcement authority at the supervisory terminal device.

[0034] According to other aspects of the present disclosure, the supervisory terminal device may further comprise a status detection unit electrically connected with the processing unit and configured to detect a status information of the autonomous device. The processing unit may be configured to determine whether the status information is true or to determine whether the autonomous device is under an abnormal condition based on the status information.

[0035] The integration of status detection within the control system enables continuous behavioral assessment that can inform both local intervention decisions and remote supervisory oversight. The ability to verify status information truthfulness supports detection of attempts by compromised autonomous device software to misrepresent operational state.

[0036] According to other aspects of the present disclosure, the communication unit may be configured to receive an RF signal to locate the autonomous device and output a position coordinate to the processing unit.

[0037] The position locating capability within the control system enables spatial tracking of the autonomous device independent of any location information provided by the autonomous device. This supports enforcement of zone-based authorization constraints and enables the remote supervisory device to maintain awareness of autonomous device locations across a deployment environment.

[0038] According to other aspects of the present disclosure, the supervisory terminal device may further comprise a blocking unit electrically connected with the processing unit and configured to output a blocking signal to stop the autonomous device when the processing unit determines that the autonomous device is under an abnormal condition.

[0039] The blocking unit provides a local enforcement mechanism that can immediately constrain autonomous device behavior upon detection of abnormal conditions without requiring communication with the remote supervisory device. This ensures that safety intervention can occur within bounded time constraints even when network connectivity is unavailable or degraded.

[0040] According to other aspects of the present disclosure, the processing unit comprises an artificial intelligence edge computing module configured to perform real-time behavioral risk assessment of the autonomous device by determining whether status information transmitted by the autonomous device is true and reasonable based on inputs from multiple sources.

[0041] According to another aspect of the present disclosure, a method for monitoring an autonomous device is provided. The method comprises storing an identification code in a storage unit of a supervisory terminal device physically coupled to the autonomous device. The method comprises encrypting the identification code using quantum-resistant cryptography via an encryption unit of the supervisory terminal device. The method comprises transmitting the encrypted identification code, by the supervisory terminal device, to confirm an identity of the autonomous device.

[0042] The method establishes a secure identity verification process that leverages hardware-rooted storage and quantum-resistant cryptography to provide reliable identity confirmation. The physical coupling requirement ensures that the identification code is bound to a specific autonomous device through a hardware relationship rather than a software-based association that could be manipulated. The encryption of the identification code and other robot-related information provides comprehensive protection for all data transmitted by the supervisory terminal device to the remote supervisory device.

[0043] According to other aspects of the present disclosure, the method may further comprise receiving an RF signal to locate position coordinates of the autonomous device. The method may further comprise receiving coordinates from the autonomous device. The method may further comprise comparing the position coordinates located via the RF signal with the coordinates received from the autonomous device to determine whether the coordinates received from the autonomous device is inaccurate or falsified.

[0044] The position validation process provides a mechanism for detecting discrepancies between independently determined position coordinates and position information reported by the autonomous device. This comparison enables identification of falsified location data that could be used to circumvent spatial authorization constraints or conceal unauthorized movements.

[0045] According to other aspects of the present disclosure, the method may further comprise detecting a status information of the autonomous device. The method may further comprise determining whether the status information is true or whether the autonomous device is under a normal condition based on the status information.

[0046] The status detection and verification process enables continuous assessment of autonomous device operational state through an independent observation channel. The determination of status information truthfulness supports detection of software faults, adversarial manipulation, or inconsistencies between reported and actual device behavior.

[0047] According to other aspects of the present disclosure, the method may further comprise performing real-time edge computing to determine whether the autonomous device is under an abnormal condition.

[0048] The use of real-time edge computing enables sophisticated behavioral assessment to be performed locally at the supervisory terminal device without requiring communication with remote systems. This supports bounded-time decision making for safety-relevant determinations and reduces dependency on network availability for abnormal condition detection.

[0049] According to other aspects of the present disclosure, the method may further comprise outputting a blocking signal to stop the autonomous device when the supervisory terminal device determines that the autonomous device is under an abnormal condition.

[0050] The blocking signal output provides a direct enforcement mechanism that translates abnormal condition detection into immediate intervention action. This ensures that the monitoring method includes not only observation and assessment but also the capability to constrain autonomous device behavior when safety-relevant conditions are detected.

[0051] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.

[0052] BRIEF DESCRIPTION OF FIGURES

[0053] Non-limiting and non-exhaustive examples are described with reference to the following figures.

[0054] FIG. 1 illustrates a block diagram of a control system for monitoring an autonomous device, according to aspects of the present disclosure.

[0055] FIG. 2 illustrates a block diagram of a control system with a supervisory terminal device having additional detection units, according to an embodiment.

[0056] FIG. 3 illustrates a flowchart for a method for monitoring an autonomous device, according to aspects of the present disclosure.

[0057] FIG. 4 illustrates a flowchart for a method for monitoring an autonomous device with status detection, according to an embodiment.

[0058] FIG. 5 illustrates a flowchart for a method for monitoring an autonomous device with position validation, according to aspects of the present disclosure.

[0059] FIG. 6 illustrates a block diagram of a supervisory terminal device as a hardware identity card and authorization enforcement loop, according to an embodiment.

[0060] FIG. 7 illustrates a block diagram of algorithm-based behavioral assessment integrated as a rule-driven advisory layer alongside a deterministic safety core, according to an embodiment.

[0061] FIG. 8 illustrates a block diagram of deep learning-based behavioral assessment module as an advisory layer alongside a deterministic safety core, according to an embodiment.

[0062] FIG. 9 illustrates a block diagram of LLM-based behavioral assessment as a semantic and policy-level advisory layer alongside a deterministic safety core, according to an embodiment.

[0063] FIG. 10 illustrates a flowchart of a deterministic safety assessment pipeline for real-time behavioral assessment, according to an embodiment.DETAILED DESCRIPTION

[0064] Autonomous devices, such as robots, are increasingly deployed in environments where human safety and regulatory compliance are of concern. As autonomous devices operate with greater independence, mechanisms for monitoring and controlling such devices become relevant to ensuring that the devices operate within acceptable parameters and do not pose risks to humans or property.

[0065] Conventional approaches to monitoring autonomous devices may rely on software-based safety mechanisms that operate within the same computing environment as the autonomy stack of the autonomous device. Such in-band approaches are subject to limitations when the autonomy stack experiences faults, is compromised, or is otherwise degraded. In such scenarios, safety logic that operates within the same computing environment may be delayed, suppressed, or bypassed.

[0066] As autonomous devices increasingly rely on artificial intelligence for decision-making, the behavior of such devices may become progressively more autonomous and less predictable. In some cases, AI systems may modify their own operational parameters or decision policies in ways that were not anticipated during initial deployment. Software-based control mechanisms that operate within the same computing environment as the AI system may become less effective over time as the AI system evolves or adapts its behavior. In some aspects, attempts to constrain AI behavior through software-level interventions may be circumvented or rendered ineffective when the AI system has the capability to modify its own code or decision logic.

[0067] Even in scenarios where at least a portion of the autonomous device's systems remain under human control, vulnerabilities may exist that allow malicious actors to tamper with operational constraints or regulatory parameters. In some cases, adversarial manipulation of software-based safety mechanisms may cause autonomous devices to engage in harmful, non-compliant, or criminal behavior without detection by conventional monitoring approaches. Such tampering may occur through exploitation of software vulnerabilities, unauthorized access to control systems, or manipulation of data inputs that influence device behavior.

[0068] Accordingly, monitoring approaches that operate independently from the autonomous device's software stack may provide advantages in scenarios where software-based mechanisms are insufficient, compromised, or bypassed. A supervisory terminal device that is physically coupled to the autonomous device but operates out-of-band with respect to the autonomy stack may maintain regulatory oversight even when the autonomous device's internal software systems are degraded, manipulated, or otherwise unreliable.

[0069] The present disclosure relates to a supervisory terminal device, a control system, and a method for monitoring an autonomous device. The supervisory terminal device is physically coupled to the autonomous device and operates independently from an autonomy stack of the autonomous device. By operating out-of-band with respect to the autonomy stack, the supervisory terminal device provides regulatory supervision that is not dependent on the proper functioning of the autonomy stack. The supervisory terminal device stores an identification code and transmits the identification code to a remote supervisory device for confirming an identity of the autonomous device. The identification code is encrypted using quantum-resistant cryptography before transmission to provide protection against decryption by quantum computing techniques.

[0070] The control system includes the supervisory terminal device and the remote supervisory device. The remote supervisory device communicates with the supervisory terminal device to receive the identification code and to verify the identity of the autonomous device. The remote supervisory device also transmits control signals to the supervisory terminal device to control or monitor the autonomous device.

[0071] The method for monitoring an autonomous device includes storing an identification code in a storage unit of the supervisory terminal device, encrypting the identification code using quantum-resistant cryptography, and transmitting the encrypted identification code to confirm an identity of the autonomous device. The method may further include detecting status information of the autonomous device and determining whether the status information is accurate or whether the autonomous device is operating under normal conditions.

[0072] Referring to FIG. 1, a control system 1 for monitoring an autonomous device 20 is illustrated. The control system 1 includes a supervisory terminal device 10 and a remote supervisory device 30. The supervisory terminal device 10 is physically coupled to the autonomous device 20 and is configured to communicate with the remote supervisory device 30. The autonomous device 20 may be a robot or other device capable of autonomous operation in environments where human safety and regulatory compliance are of concern.

[0073] The supervisory terminal device 10 is independent from an autonomy stack of the autonomous device 20. The autonomy stack of the autonomous device 20 includes perception, planning, and control modules that execute on a computing substrate of the autonomous device 20. By operating independently from the autonomy stack, the supervisory terminal device 10 provides out-of-band regulatory supervision that remains operational even when the autonomy stack of the autonomous device 20 is degraded, faulty, or compromised. The supervisory terminal device 10 has a separate processor, memory, and power domain from the autonomous device 20, allowing the supervisory terminal device 10 to function as a parallel regulatory control loop to monitor system state and to enforce safety interventions independently of the autonomous device 20 autonomy software. The supervisory terminal device 10 possesses higher regulatory authority such that safety enforcement actions cannot be overridden by software components of the autonomous device 20.

[0074] With continued reference to FIG. 1, the relationship between the supervisory terminal device 10 and the autonomous device 20 is analogous to the relationship between a Baseboard Management Controller (BMC) and a host operating system in server architecture. In such an architecture, the supervisory terminal device 10 forms a regulatory domain that is distinct from an autonomy domain of the autonomous device 20. The supervisory terminal device 10 observes behavior of the autonomous device 20 via a restricted interface and regulates behavior through a defined set of safety actions without replacing intelligence of the autonomous device 20.

[0075] Referring to FIG. 6, a block diagram illustrates the supervisory terminal device 10 as a hardware identity card and authorization enforcement loop, depicting the architectural separation between the autonomous robot domain and the hardware-rooted regulatory domain. On the left side of FIG. 6, the autonomous device 20 is shown containing an autonomy stack comprising perception, planning, and control functions. The robot software of the autonomous device 20 is explicitly not part of the trusted computing base (TCB) . The autonomous device 20 communicates with the supervisory terminal device 10 through a non-trusted domain boundary, transmitting telemetry, intent, and execution data as bounded summaries.

[0076] The central portion of FIG. 6 shows the supervisory terminal device 10 functioning as a hardware identity card containing four primary functional blocks. A hardware identity anchor stores the identification code ID which is silicon-bound, along with attestation capabilities and post-quantum cryptographic (PQC) key material. The hardware identity anchor corresponds to the storage unit 100 and the encryption unit 106 described with reference to FIG. 1 and FIG. 2. An authorization engine is responsible for verifying claims and evaluating environment policy. The authorization engine corresponds to functions performed by the processing unit 102 in conjunction with authorization constraints received from the remote supervisory device 30. A constraint binder manages speed, zone, mode, and time constraints that govern operation of the autonomous device 20. The constraint binder maintains active authorization constraints that are cryptographically bound to the supervisory terminal device 10. A safety enforcement interface provides trusted, hardware-rooted, non-bypassable controls including emergency stop, safe mode degrade, and motion inhibit functions. The safety enforcement interface corresponds to the blocking unit 110 described with reference to FIG. 2.

[0077] The right side of FIG. 6 depicts external environments and relying parties that communicate with the supervisory terminal device 10. The external environments and relying parties include a hotel security console, a hospital access controller, a campus or city policy console, other robots, and optionally CCTV-based supervisory terminal devices. These external entities communicate with the supervisory terminal device 10 through policy and authorization channels flowing into the supervisory terminal device 10, while attested identity and verifiable claims flow outward from the supervisory terminal device 10 to these parties. Environment-defined policies are shown feeding into the supervisory terminal device 10 from the external environments and relying parties.

[0078] The arrow at the bottom of FIG. 6 illustrates the enforced constraint and intervention flow that operates continuously from the safety enforcement interface back toward the autonomous device 20, demonstrating the closed-loop nature of the regulatory enforcement mechanism. This closed-loop architecture ensures that the supervisory terminal device 10 continuously monitors the autonomous device 20 and enforces constraints in real-time. The separation between the autonomy domain of the autonomous device 20 and the regulatory domain of the supervisory terminal device 10 ensures that safety enforcement remains effective even when the autonomy stack of the autonomous device 20 is degraded, faulty, or compromised.

[0079] Table 1 below positions the proposed supervisory terminal device relative to commonly deployed robot safety mechanisms and highlights the authority, timing, and trust assumptions that motivate a hardware-rooted, out-of-band regulatory design. The supervisory terminal device occupies a previously unaddressed design point, combining out-of-band independence, real-time analyzability, and algorithmic safety assessment.

[0080] The remote supervisory device 30 is configured to communicate with the supervisory terminal device 10. The remote supervisory device 30 receives information from the supervisory terminal device 10 and uses the information to verify and monitor the identity of the autonomous device 20. The remote supervisory device 30 also transmits control signals to the supervisory terminal device 10 to control or monitor the autonomous device 20.

[0081] As further shown in FIG. 1, the supervisory terminal device 10 implements a standardized out-of-band regulatory interface analogous to BMC-Redfish architecture. The standardized out-of-band regulatory interface provides deterministic, minimal, and non-bypassable observability and control sufficient for real-time safety regulation. The interface is constrained to satisfy vendor neutrality, out-of-band operation independent from an operating system or middleware of the autonomous device 20, deterministic bounded processing, least-privilege control, and auditability. The regulatory interface is defined using a constrained command schema to ensure bounded execution latency and predictable safety enforcement.

[0082] The supervisory terminal device 10 implements a two-plane design having a Redfish-like resource plane for governance and an Intelligent Platform Management Interface (IPMI) -like deterministic command plane for hard real-time safety management. The resource plane exposes structured resources including identity, telemetry summaries, safety state, and restricted actions. The deterministic command plane provides constant-time, bounded primitives for health monitoring, event logging, watchdog enforcement, and controlled recovery. The two-plane design allows the supervisory terminal device 10 to support policy-driven identity verification and authorization through the resource plane while providing low-level deterministic management primitives through the command plane.

[0083] The supervisory terminal device 10 includes a storage unit 100 configured to store an identification code ID. The storage unit 100 is electrically connected with a processing unit 102 of the supervisory terminal device 10. The identification code ID stored in the storage unit 100 is used to confirm an identity of the autonomous device 20 to which the supervisory terminal device 10 is physically coupled.

[0084] The identification code ID may include a hardware-bound identity that includes a globally unique identifier. The globally unique identifier is anchored to hardware-bound material such as fused identifiers, physically unclonable function (PUF) -derived identity, or identity assertions bound to the supervisory terminal device 10. The hardware-bound nature of the globally unique identifier provides stability across runtime restarts and is independent of an operating system of the autonomous device 20.

[0085] The identification code ID may further include a protected attestation key. The protected attestation key may form part of a cryptographic key pair used to generate attestation signatures for the device. The protected attestation key is stored within the storage unit 100 in a manner such that the protected attestation key does not leave trusted hardware of the supervisory terminal device 10. The protected attestation key is used for cryptographic signing of audit logs and attestation reports. By maintaining the protected attestation key within trusted hardware, the supervisory terminal device 10 prevents compromised software of the autonomous device 20 from forging identity proofs or escalating permissions beyond issued claims. The supervisory terminal device may use the attestation key pair to generate digital signatures for audit logs, attestation reports, or challenge-response authentication messages exchanged with external regulatory systems.

[0086] The identification code ID may also include integrity measurements that bind firmware and interface state to the identity. The integrity measurements include firmware hashes that are exposed for provenance correlation without trusting claims from the autonomous device 20. The integrity measurements bind the supervisory terminal device 10 to a specific interface specification version that is cryptographically protected and verified. The binding of firmware and interface state to the identity prevents schema confusion and downgrade attacks.

[0087] The storage unit 100 may be implemented using various hardware configurations. In some embodiments, the storage unit 100 is implemented as part of a hardware security module (HSM) integrated within the supervisory terminal device 10. The hardware security module provides hardware-enforced isolation such as ARM TrustZone or a dedicated Secure Element. In some embodiments, the storage unit 100 is implemented as secure memory within a system-in-package (SiP) , a system-on-chip (SoC) or as part of a printed circuit board (PCB) module containing multiple chips.

[0088] In some embodiments, the storage unit 100 may be included within another unit of the supervisory terminal device 10. For example, the storage unit 100 may be implemented as secure memory integrated within the processing unit 102 or as protected storage within the encryption unit 106 or a hardware security module associated with the encryption unit 106. When the storage unit 100 is integrated within the processing unit 102, the identification code ID may be stored in a secure memory region of the processing unit 102 that is isolated from general-purpose memory used for processing operations. When the storage unit 100 is integrated within the encryption unit 106, the identification code ID may be stored in protected storage that is co-located with cryptographic key material, allowing the encryption unit 106 to access the identification code ID directly for encryption operations. The integration of the storage unit 100 within another unit of the supervisory terminal device 10 may reduce component count, simplify interconnections, or provide enhanced security through tighter integration of storage and processing or cryptographic functions.

[0089] In a method for monitoring an autonomous device, storing an identification code ID in a storage unit 100 of a supervisory terminal device 10 physically coupled to the autonomous device 20 establishes a hardware-rooted identity anchor. The stored identification code ID enables external parties, such as the remote supervisory device 30, facility controllers, or regulatory consoles, to authenticate the supervisory terminal device 10 rather than authenticating an operating system or autonomy stack of the autonomous device 20. By relocating identity authority from software to hardware through the storage unit 100, the supervisory terminal device 10 provides a stable basis for accountability and trust across heterogeneous autonomous devices and vendors.

[0090] The supervisory terminal device 10 includes a processing unit 102 electrically connected with the storage unit 100. The processing unit 102 is configured to retrieve the identification code ID from the storage unit 100 and to output the identification code ID to the remote supervisory device 30 for confirming an identity of the autonomous device 20 through a communication unit 104 of the supervisory terminal device 10. The processing unit 102 coordinates operations between the storage unit 100 and other units of the supervisory terminal device 10 to facilitate monitoring and regulatory supervision of the autonomous device 20.

[0091] The processing unit 102 may be implemented using various hardware configurations. In some embodiments, the processing unit 102 includes a microcontroller unit (MCU) . The microcontroller unit provides deterministic processing capabilities suitable for real-time safety regulation. The microcontroller unit executes bounded operations with predictable worst-case execution time, allowing the supervisory terminal device 10 to maintain timing guarantees for safety-related functions. In some embodiments, the processing unit 102 includes a neural processing unit (NPU) . The neural processing unit provides computational capabilities for processing behavioral assessment signals or anomaly detection algorithms. The neural processing unit operates as an advisory component that provides risk indicators to the processing unit 102 without directly controlling safety intervention decisions.

[0092] In some embodiments, the processing unit 102 includes both a microcontroller unit and a neural processing unit. The microcontroller unit handles deterministic safety pipeline operations within a bounded decision budget, while the neural processing unit handles advisory assessment computations that do not require hard real-time guarantees. The separation between the microcontroller unit and the neural processing unit allows the processing unit 102 to support both deterministic enforcement and richer behavioral understanding without compromising timing guarantees. In some other embodiments, the processing unit 102 may include a field-programmable gate array (FPGA) . The field-programmable gate array may be used for both handling deterministic safety pipeline operations and advisory assessment computations, here is not intended to be limiting.

[0093] The processing unit 102 is configured to output the identification code ID to confirm an identity of the autonomous device 20 through the communication unit 104 to the remote supervisory device 30. The processing unit 102 retrieves the identification code ID from the storage unit 100 and coordinates with an encryption unit 106 of the supervisory terminal device 10 to encrypt the identification code ID before transmission. The processing unit 102 then directs the communication unit 104 to transmit the encrypted identification code ID to the remote supervisory device 30. The remote supervisory device 30 uses the received identification code ID to verify and authenticate the identity of the autonomous device 20.

[0094] The processing unit 102 operates independently from an autonomy stack of the autonomous device 20. The processing unit 102 has a separate memory domain and executes regulatory supervision functions without relying on proper functioning of software executing on the autonomous device 20. By operating out-of-band with respect to the autonomy stack, the processing unit 102 continues to function even when the autonomous device 20 experiences software faults, is compromised, or is otherwise degraded.

[0095] The control system 1 uses the identification code ID transmitted by the processing unit 102 to establish a verified identity for the autonomous device 20 that is independent of software-based credentials managed by the autonomous device 20.

[0096] The supervisory terminal device 10 includes a communication unit 104 electrically connected with the processing unit 102. The communication unit 104 is configured to transmit the encrypted identification code ID to the remote supervisory device 30 for confirming an identity of the autonomous device 20. The communication unit 104 is also configured to receive signals from external sources and to facilitate bidirectional communication between the supervisory terminal device 10 and the remote supervisory device 30.

[0097] The communication unit 104 may include an antenna module having at least one antenna or a set of antennas. The antenna module enables the communication unit 104 to transmit and receive radio frequency (RF) signals. The antenna module supports various communication protocols and frequency bands to facilitate communication with the remote supervisory device 30 and with satellite systems for positioning purposes.

[0098] The communication unit 104 is configured to receive an RF signal to locate the autonomous device 20 and output a position coordinate to the processing unit 102. In some embodiments, the communication unit 104 receives RF signals from satellites through the antenna module to determine position coordinates, latitude, and longitude of the autonomous device 20 via GPS positioning or other satellite-based positioning systems. The communication unit 104 converts the received RF signals into position coordinate data and outputs the position coordinate data to the processing unit 102. The processing unit 102 uses the position coordinate data to track a location of the autonomous device 20 and to verify location information reported by the autonomous device 20.

[0099] In the control system 1, the communication unit 104 of the supervisory terminal device 10 is configured to receive a control signal from the remote supervisory device 30. The control signal received from the remote supervisory device 30 includes instructions for controlling or monitoring the autonomous device 20. The communication unit 104 converts the received RF signal into a baseband control signal and transmits the baseband control signal to the processing unit 102. The processing unit 102 interprets the baseband control signal and coordinates appropriate responses based on the instructions contained in the control signal.

[0100] The communication unit 104 may include a transmitter and a receiver. The transmitter is configured to transmit the encrypted identification code ID and other information to the remote supervisory device 30. The receiver is configured to receive RF signals from the remote supervisory device 30, from satellites, and from other external sources. The transmitter and the receiver operate through the antenna module to facilitate wireless communication.

[0101] In some embodiments, the communication unit 104 is configured to transmit position coordinates determined via satellite positioning to the remote supervisory device 30. The transmission of position coordinates allows the remote supervisory device 30 to track a location of the autonomous device 20 in real-time. The communication unit 104 is also configured to transmit status information, safety state data, and other regulatory information to the remote supervisory device 30.

[0102] The communication unit 104 operates independently from communication systems of the autonomous device 20. By maintaining a separate communication path, the communication unit 104 continues to transmit and receive information even when communication systems of the autonomous device 20 are degraded or compromised. The independent operation of the communication unit 104 supports the out-of-band regulatory supervision provided by the supervisory terminal device 10.

[0103] In a method for monitoring an autonomous device 20, transmitting the encrypted identification code ID is performed by the supervisory terminal device 10 through the communication unit 104 to confirm an identity of the autonomous device 20. The communication unit 104 transmits the encrypted identification code ID to the remote supervisory device 30, which verifies the identity of the autonomous device 20 based on the received identification code ID.

[0104] The supervisory terminal device 10 includes an encryption unit 106 electrically connected with the communication unit 104. The encryption unit 106 is configured to encrypt the identification code ID and other robot-related information transmitted by the supervisory terminal device 10 to the remote supervisory device 30 using quantum-resistant cryptography before outputting of the identification code ID and the other information. By encrypting the identification code ID and the other information before transmission, the encryption unit 106 provides protection against decryption by quantum computing techniques that may be capable of breaking conventional cryptographic algorithms. The encryption unit 106 may also digitally sign messages to protect their integrity using quantum-resistant cryptography before transmitting the messages. The digital signatures enable the remote supervisory device 30 and other external parties to verify the authenticity and integrity of messages received from the supervisory terminal device 10.

[0105] In some embodiments, a hybrid post-quantum session establishment mechanism may be employed between the supervisory terminal device and the remote supervisory device. In one embodiment, the devices perform an authenticated handshake that combines a classical key-exchange mechanism with a post-quantum key encapsulation mechanism (PQ-KEM) , such as a NIST-standardized PQC algorithm. The resulting shared secrets are combined through a key-derivation function to generate ephemeral session keys that are then used to protect all transmitted identification codes, telemetry, attestation results, and control messages using authenticated encryption. Post-quantum digital signatures may additionally be used to verify device identity, software integrity reports, and command authorization. This hybrid approach preserves interoperability with existing cryptographic systems while providing resistance against quantum-computer attacks and preventing downgrade vulnerabilities. The module may be called as a Robotic Identity Module (RIM) , a Hardware-Rooted Robotic Identity (HRRI) , or a Supervisory Identity Anchor (SIA) .

[0106] In some embodiments, the supervisory terminal device implements a hardware-rooted identity module whose functional role is analogous to that of a SIM or eSIM in a mobile device, without requiring integration with existing cellular subscriber modules. The hardware-rooted identity module provisions each autonomous device with a unique, non-cloneable, and tamper-resistant identity bound to a secure cryptographic key stored within protected hardware. The identity cannot be modified through software updates of the autonomous device and remains valid independently of the autonomous device’s primary communication stack. The hardware-rooted identity module supports cryptographic attestation, freshness validation using nonces, and integrity-bound audit reporting such that every supervisory event, state transition, or intervention command can be unambiguously attributed to a specific autonomous device instance. In some embodiments, the identity is derived from or anchored in a physically protected element (e.g., secure enclave, hardware security module, physically unclonable function, or equivalent mechanism) , thereby preventing identity spoofing, duplication, or substitution even under partial compromise of the autonomous device’s operating environment. The supervisory architecture thus achieves SIM / eSIM-equivalent identity assurance for robots, providing per-device authenticity, traceability, and regulatory accountability across distributed deployments.

[0107] In some embodiments, the supervisory terminal device implements a SIM card or eSIM-based identity architecture. The supervisory terminal device may be implemented as a SIM card or an embedded SIM (eSIM) that is physically installed within the autonomous device, or the supervisory terminal device may include a SIM card reader or eSIM reader configured to read identity information from a separate SIM card or eSIM module. In this architecture, the identification code stored in the storage unit 100 may comprise a cryptographic key such as a SHA-256 key or other hash-based key that is used to encrypt data transmitted to the remote supervisory device 30. The communication architecture is analogous to cellular network communication where the outermost layer comprises communication protocol packets, the supervisory terminal device provides a unique device identifier analogous to an IMEI, and the SIM card or eSIM provides the cryptographic key for securing communications. The encrypted packets transmitted by the supervisory terminal device to the remote supervisory device 30 are structured such that only the remote supervisory device 30 possesses the corresponding key to decrypt the packet contents. This SIM / eSIM-based architecture provides a familiar and proven security model for identity management and secure communication that leverages existing cellular network security principles while adapting them for robot regulatory supervision. The SIM card or eSIM may store multiple cryptographic keys for different purposes, including keys for identity verification, keys for encrypting status information, and keys for authenticating commands received from the remote supervisory device 30.

[0108] The encryption unit 106 supports NIST post-quantum cryptographic standards FIPS-203 / 204 / 205 for quantum-resistant cryptography. FIPS-203 defines a key encapsulation mechanism based on module-lattice-based cryptography. FIPS-204 defines a digital signature algorithm based on module-lattice-based cryptography. FIPS-205 defines a stateless hash-based digital signature algorithm. By supporting these post-quantum cryptographic standards, the encryption unit 106 provides cryptographic protection that remains secure against both classical and quantum computing attacks.

[0109] The encryption unit 106 is configured to encrypt the identification code ID retrieved from the storage unit 100 and other robot-related information before the communication unit 104 transmits the encrypted identification code ID and other information to the remote supervisory device 30. The processing unit 102 coordinates operations between the storage unit 100, the encryption unit 106, and the communication unit 104 to facilitate secure transmission of the identification code ID and other information. The encryption unit 106 receives the identification code ID and other information from the processing unit 102, applies quantum-resistant cryptographic algorithms to the identification code ID and other information, and outputs the encrypted identification code ID and other information to the communication unit 104 for transmission. The encryption unit 106 may also apply quantum-resistant digital signatures to messages before transmission to protect message integrity and enable verification of message authenticity by the remote supervisory device 30.

[0110] The supervisory terminal device 10 may include a HSM that serves as a cryptographic root for the encryption unit 106. The HSM provides secure key storage for cryptographic keys used by the encryption unit 106. The cryptographic keys stored within the HSM include identity keys, attestation keys, and policy verification keys. The HSM stores the cryptographic keys in a manner such that the cryptographic keys do not leave trusted hardware of the supervisory terminal device 10.

[0111] The HSM provides hardware-backed signing for audit logs and attestation reports. The encryption unit 106 uses the HSM to generate cryptographic signatures for audit records and attestation reports produced by the supervisory terminal device 10. The hardware-backed signing binds audit logs and attestation reports to the hardware-rooted identity of the supervisory terminal device 10, allowing external parties to verify the authenticity and integrity of the signed information.

[0112] The HSM provides accelerated post-quantum cryptographic operations. The encryption unit 106 invokes the HSM to perform cryptographic operations with bounded execution time. By providing hardware acceleration for post-quantum cryptographic operations, the HSM allows the encryption unit 106 to complete cryptographic processing within deterministic time bounds. The hardware acceleration avoids pushing variable-latency cryptographic operations onto safety-related processing paths of the supervisory terminal device 10.

[0113] In some embodiments, the HSM is implemented using embedded architectures equipped with hardware-enforced isolation. The hardware-enforced isolation may include ARM TrustZone or a dedicated Secure Element. The hardware-enforced isolation provides a physical trust anchor that separates cryptographic operations from other processing functions of the supervisory terminal device 10.

[0114] In the control system 1, the encryption unit 106 of the supervisory terminal device 10 is configured to encrypt the identification code ID and other information transmitted by the supervisory terminal device 10 to the remote supervisory device 30 using quantum-resistant cryptography before outputting of the identification code ID and the other information. The encryption unit 106 may also digitally sign messages using quantum-resistant cryptography to protect message integrity before transmission. The control system 1 uses the encrypted identification code ID transmitted by the communication unit 104 to establish a verified identity for the autonomous device 20 that is protected against quantum computing attacks.

[0115] In a method for monitoring an autonomous device 20, encrypting the identification code ID and other robot-related information using quantum-resistant cryptography via an encryption unit 106 of the supervisory terminal device 10 is performed after storing the identification code ID in the storage unit 100. The encryption unit 106 applies post-quantum cryptographic algorithms conforming to NIST standards FIPS-203 / 204 / 205 to the identification code ID and other information. The encryption unit 106 may also digitally sign messages using quantum-resistant cryptography to protect message integrity before transmission. Transmitting the encrypted identification code ID and other information, by the supervisory terminal device 10, to confirm an identity of the autonomous device 20 is performed after the encryption unit 106 encrypts the identification code ID and other information. The communication unit 104 transmits the encrypted identification code ID and other information to the remote supervisory device 30, which verifies the identity of the autonomous device 20 based on the received encrypted identification code ID.

[0116] Referring to FIG. 2, a control system 1A for monitoring an autonomous device 20 is illustrated. The control system 1A includes a supervisory terminal device 10A and the remote supervisory device 30. The supervisory terminal device 10A is physically coupled to the autonomous device 20 and is configured to communicate with the remote supervisory device 30. The supervisory terminal device 10A includes additional units beyond those described with reference to FIG. 1, providing enhanced monitoring and intervention capabilities.

[0117] The supervisory terminal device 10A includes the storage unit 100, the processing unit 102, the communication unit 104, and the encryption unit 106 as described with reference to FIG. 1. The supervisory terminal device 10A further includes a tamper detection unit 108, a blocking unit 110, a status detection unit 112, a sensing unit 114, a frequency scanning unit 116, and a self-detection unit 118. The additional units provide the supervisory terminal device 10A with capabilities for detecting tampering, stopping the autonomous device 20, detecting status information, sensing movement, scanning frequency bands, and performing self-diagnostics.

[0118] The supervisory terminal device 10A may operate with an independent power domain allowing the supervisory terminal device 10A to remain operational even when a primary software stack of the autonomous device 20 is faulty or compromised. The independent power domain includes a power supply module having at least one battery. The power supply module supplies power to the various units of the supervisory terminal device 10A independently from a power system of the autonomous device 20. In some embodiments, the supervisory terminal device 10A includes a charging module configured to connect to a power supply of the autonomous device 20 to charge the battery while the autonomous device 20 is operational. The independent power domain allows the supervisory terminal device 10A to continue monitoring and transmitting information to the remote supervisory device 30 even when the autonomous device 20 experiences a power interruption or shutdown.

[0119] With continued reference to FIG. 2, the tamper detection unit 108 is electrically connected with the communication unit 104. The tamper detection unit 108 is configured to output an alarm signal when the supervisory terminal device 10A is separated from the autonomous device 20. The tamper detection unit 108 detects physical separation of the supervisory terminal device 10A from the autonomous device 20 through various mechanisms. In some embodiments, the supervisory terminal device 10A may be attached or encapsulated on or in a body of the autonomous device 20 with a substance, material, or mechanism that is visibly damaged when separated from the body of the autonomous device 20. The tamper detection unit 108 detects such damage and outputs the alarm signal to the communication unit 104 for transmission to the remote supervisory device 30. The alarm signal alerts the remote supervisory device 30 that the supervisory terminal device 10A has been tampered with or removed from the autonomous device 20.

[0120] The blocking unit 110 is electrically connected with the processing unit 102. The communication unit 104 is configured to receive an RF signal and to convert the RF signal into a base-band control signal to the processing unit 102. When the base-band control signal indicates to stop the autonomous device 20, the blocking unit 110 is configured to output a blocking signal to stop the autonomous device 20.

[0121] The blocking unit 110 may further comprise a blocking signal generator configured to interrupt the operation of one or more components of the autonomous device 20 when the processing unit 102 determines that the autonomous device 20 is under an abnormal or stop condition. In some embodiments, the blocking unit 110 may include an electromagnetic pulse (EMP) transmitter, a blocking signal generator module, a power gating signal, or another hardware-level control signal capable of forcing the affected subsystem into a safe state. Through such hardware-level intervention, the supervisory terminal device 10A can rapidly halt or cause at least one chip of the autonomous device 20 to stop operation of at least one module or function. The blocking signal generator module generates a blocking signal that interferes with operation of the autonomous device 20 to stop improper behavior or action. The blocking unit 110 provides the supervisory terminal device 10A with a capability to enforce immediate intervention when the autonomous device 20 poses a risk to human beings or property.

[0122] As further shown in FIG. 2, the status detection unit 112 is electrically connected with the processing unit 102. The status detection unit 112 is configured to detect a status information of the autonomous device 20. The processing unit 102 is configured to determine whether the status information is true or to determine whether the autonomous device 20 is under an abnormal condition based on the status information. The status information includes location information, coordinates, latitude, longitude, height, floor, current power level, charging status, work or task being performed, work or task to be performed, images captured by vision systems of the autonomous device 20, and sounds captured by audio systems of the autonomous device 20.

[0123] The abnormal condition includes at least one of an unreasonable behavior, a non-compliant behavior, an illegal behavior, a behavior that may endanger human beings, and a behavior that violates rules or regulations. The unreasonable behavior includes behavior that is inconsistent with physical constraints or operational parameters of the autonomous device 20. The non-compliant behavior includes behavior that does not conform to authorized operational constraints such as zone restrictions, speed limits, or mode restrictions. The illegal behavior includes behavior that violates laws or regulations applicable to operation of the autonomous device 20. The behavior that may endanger human beings includes behavior that poses a risk of physical harm to humans in proximity to the autonomous device 20. The behavior that violates rules or regulations includes behavior that violates rules of robotics or other regulatory requirements applicable to the autonomous device 20.

[0124] The control system 1A uses the status detection unit 112 to monitor behavior of the autonomous device 20 and to detect conditions that may warrant intervention.

[0125] With continued reference to FIG. 2, the sensing unit 114 is electrically connected with the processing unit 102. The sensing unit 114 is configured to sense a movement information and output the movement information to the processing unit 102. The processing unit 102 is configured to compute a movement of the supervisory terminal device 10A or a movement of the autonomous device 20 based on the movement information received from the sensing unit 114.

[0126] The sensing unit 114 includes at least one MEMS sensor. The MEMS sensor includes at least one of a G Sensor, a Gyroscope, and an E Compass. The G Sensor measures acceleration in three-axis directions. The Gyroscope measures angular velocity or rotational speed in three-axis directions. The E Compass detects changes in direction due to cutting or blocking of magnetic lines of force of a geomagnetic field as a result of motion of the autonomous device 20. The sensing unit 114 outputs numerical values in three-axis directions to the processing unit 102.

[0127] The processing unit 102 may include a self-localization module configured to receive the numerical outputs from the sensing unit 114 and to execute an algorithm to compute a trajectory of the supervisory terminal device 10A or of the autonomous device 20. The self-localization module computes position information, coordinate values, and height at which the autonomous device 20 is located based on the movement information from the sensing unit 114. The self-localization module also computes a path of movement over a period of time and changes in position during the movement. The processing unit 102 compares position coordinates computed by the self-localization module with coordinates received from the autonomous device 20 through the status detection unit 112 to determine whether the coordinates received from the autonomous device 20 are inaccurate or falsified.

[0128] As further shown in FIG. 2, the frequency scanning unit 116 is electrically connected with the communication unit 104. The frequency scanning unit 116 is configured to detect a frequency band of signals output by the autonomous device 20. The frequency scanning unit 116 controls the communication unit 104 to receive wireless signals emitted by the autonomous device 20 or to scan frequency bands of signals emitted by the autonomous device 20. The frequency scanning unit 116 scans all frequency bands or scans frequency bands known from past scans to be used by the autonomous device 20 for transmitting wireless signals. The frequency scanning unit 116 allows the supervisory terminal device 10A to monitor wireless communications of the autonomous device 20 and to detect unauthorized or anomalous wireless transmissions.

[0129] The self-detection unit 118 is electrically connected with the processing unit 102. The self-detection unit 118 is configured to detect whether each unit of the supervisory terminal device 10A is normal. The self-detection unit 118 detects whether a state or condition of each unit of the supervisory terminal device 10A is normal or reasonable and whether abnormal behaviors have occurred. In some embodiments, the self-detection unit 118 performs a testing task in response to a remote attestation command to detect whether operation of at least one unit contained in the supervisory terminal device 10A or at least one unit connected to the supervisory terminal device 10A is normal or in order. The self-detection unit 118 is also configured to detect whether source code associated with a unit contained in the supervisory terminal device 10A or a connected unit has been tampered with. The self-detection unit 118 provides the supervisory terminal device 10A with a capability to verify integrity of the supervisory terminal device 10A and to detect attempts to compromise the supervisory terminal device 10A.

[0130] The control system 1A uses the blocking unit 110 to enforce immediate intervention when the status detection unit 112 detects an abnormal condition or when the remote supervisory device 30 transmits a control signal indicating to stop the autonomous device 20.

[0131] The supervisory terminal device 10A is independent from an autonomy stack of the autonomous device 20. The supervisory terminal device 10A operates out-of-band with respect to the autonomy stack, providing regulatory supervision that is not dependent on proper functioning of the autonomy stack. The independent power domain, the tamper detection unit 108, the blocking unit 110, the status detection unit 112, the sensing unit 114, the frequency scanning unit 116, and the self-detection unit 118 allow the supervisory terminal device 10A to monitor and control the autonomous device 20 even when the autonomous device 20 experiences software faults, is compromised, or is otherwise degraded.

[0132] With continued reference to FIG. 2, the communication unit 104 provides remote attestation primitives that cryptographically bind a hardware-rooted identity of the supervisory terminal device 10A, integrity measurements, safety-relevant state indicators, and a freshness challenge. The remote attestation primitives enable external relying parties, such as the remote supervisory device 30, facility controllers, or regulatory consoles, to verify integrity and binding state of the supervisory terminal device 10A and an association between the supervisory terminal device 10A and the autonomous device 20. The remote attestation primitives operate as read-only, non-invasive verification mechanisms that do not alter behavior of the autonomous device 20 or safety state of the supervisory terminal device 10A.

[0133] An attestation report generated by the supervisory terminal device 10A cryptographically binds the hardware-rooted identity of the supervisory terminal device 10A, integrity measurements including firmware hashes and module hashes, selected safety-relevant state indicators, and a freshness challenge in the form of a nonce provided by a requesting party. The attestation report is signed by a hardware-protected attestation key that does not leave trusted hardware of the supervisory terminal device 10A. The hardware-protected attestation key supports post-quantum cryptographic algorithms to provide protection against quantum computing attacks on the attestation mechanism.

[0134] The supervisory terminal device 10A may be implemented using embedded architectures with ARM TrustZone or dedicated Secure Elements as a physical trust anchor. ARM TrustZone provides hardware-enforced isolation that separates a secure world from a normal world within a processor of the supervisory terminal device 10A. The secure world executes attestation operations, cryptographic signing, and audit logging functions in isolation from other processing functions. A dedicated Secure Element provides a tamper-resistant hardware component that stores cryptographic keys and performs cryptographic operations in a protected environment. The physical trust anchor provided by ARM TrustZone or the dedicated Secure Element ensures that attestation operations execute within a trusted computing base of the supervisory terminal device 10A.

[0135] The supervisory terminal device 10A maintains hardware-protected audit records of authorization states, constraint updates, attestation events, and safety interventions. The hardware-protected audit records are cryptographically bound to a device identity of the supervisory terminal device 10A. The cryptographic binding allows external parties to verify authenticity and integrity of the audit records independently of logs maintained by the autonomous device 20. The hardware-protected audit records include records of authorization constraints issued to the supervisory terminal device 10A, updates to authorization constraints, attestation requests and responses, and safety intervention actions executed by the supervisory terminal device 10A. The audit records support post-incident analysis and establish a chain of responsibility suitable for regulatory and legal scrutiny. The hardware-protected nature of the audit records prevents compromised software of the autonomous device 20 from tampering with or suppressing audit information.

[0136] With continued reference to FIG. 2, the supervisory terminal device 10A may implement a deterministic safety assessment pipeline that operates within a strict 1 millisecond to 10 millisecond decision budgets for real-time intervention authority. The deterministic safety assessment pipeline constitutes a sole authority for immediate intervention decisions and is designed to provide bounded, interpretable, and enforceable safety decisions with predictable worst-case behavior. The deterministic safety assessment pipeline operates in a cyclic manner, processing telemetry inputs and producing safety decisions within the strict decision budget to maintain timing guarantees for safety-related functions. The deterministic safety assessment pipeline executes without dynamic memory allocation, without adaptive model inference, and without reliance on external service calls. Execution paths are statically analyzable and bounded in worst-case execution time, thereby permitting formal verification or timing certification under safety-critical deployment requirements.

[0137] In some embodiments, the supervisory terminal device 10A includes an artificial intelligence (AI) edge computing module configured to perform real-time behavioral risk assessment of the autonomous device 20. The AI edge computing module may be implemented within the processing unit 102 or as a separate neural processing unit (NPU) electrically connected with the processing unit 102. The AI edge computing module is configured to determine in real-time whether status information transmitted by the autonomous device 20 is true and reasonable. The AI edge computing module receives inputs from multiple sources including the status detection unit 112, the sensing unit 114, the communication unit 104, and optionally an image processing unit or camera module coupled to the supervisory terminal device 10A. By synthesizing information from these multiple sources, the AI edge computing module can comprehensively determine whether the behavior of the autonomous device 20 is abnormal. For example, the AI edge computing module may compare position information reported by the autonomous device 20 with position coordinates determined via satellite positioning and with movement information sensed by the sensing unit 114 to detect inconsistencies that indicate falsified or inaccurate status information. The AI edge computing module may also analyze images captured by a camera module to verify that observed behavior of the autonomous device 20 is consistent with reported status information. The AI edge computing module operates as part of the deterministic safety assessment pipeline or as an advisory layer that provides risk indicators to the processing unit 102 for safety enforcement decisions. The use of AI for behavioral risk assessment enables the supervisory terminal device 10A to detect complex anomaly patterns and context-dependent hazards that may be difficult to capture using fixed rules alone.

[0138] In some embodiments, the supervisory terminal device 10A implements a hardware guardrail for robot AI that enforces non-bypassable safety invariants independently from any perception, planning, control, or machine-learning runtime of the autonomous device. The hardware guardrail comprises a safety-dedicated execution context (e.g., a microcontroller or secure processor) , fixed-schema telemetry parsing with bounded memory and bounded execution time, and a deterministic safety state machine that maps validated telemetry and authorization constraints into enforceable intervention primitives. The hardware guardrail is configured to treat missing, stale, or inconsistent telemetry as risk-elevating conditions and to escalate monotonically toward restrictive states, thereby providing fail-safe behavior under partial observability, overload, or adversarial manipulation. The hardware guardrail further validates external commands against hardware-rooted safety invariants and rejects commands that contradict local hard constraints, ensuring that safety enforcement remains effective even when a remote supervisory device or network path is compromised.

[0139] In some embodiments, the supervisory terminal device 10A implements a pre-action decision interception mechanism that functions as a guardrail for the AI system of the autonomous device. In this embodiment, when the AI system of the autonomous device generates a decision or command for controlling the autonomous device, the decision or command is transmitted to the supervisory terminal device before the autonomous device executes the corresponding action. The supervisory terminal device evaluates the decision or command to determine whether execution of the decision or command would result in non-compliant behavior, illegal behavior, or behavior that may cause danger or harm to human beings or property. If the supervisory terminal device determines that the decision or command is problematic, the supervisory terminal device generates a blocking signal or rejection signal that prevents the autonomous device from executing the action. This pre-action interception mechanism provides a guardrail that intercepts potentially harmful decisions before they are executed, rather than only detecting and responding to harmful behavior after it has occurred. The pre-action decision interception mechanism operates within bounded time constraints to avoid introducing unacceptable latency into the control loop of the autonomous device. In some aspects, the supervisory terminal device maintains a whitelist of permitted action types and a blacklist of prohibited action types, and evaluates incoming decisions against these lists as part of the interception process. The pre-action decision interception mechanism may also evaluate decisions against current authorization constraints including spatial zone restrictions, speed limits, and operational mode restrictions to ensure that the autonomous device operates within its authorized operational envelope.

[0140] The processing unit 102 may implement input validation and freshness gating that validates sequence numbers, timestamp bounds, and per-field validity flags for telemetry inputs. The input validation and freshness gating operates as a first stage of the deterministic safety assessment pipeline. The processing unit 102 validates sequence numbers to detect missing or out-of-order telemetry frames. The processing unit 102 validates timestamp bounds to detect stale telemetry inputs that exceed acceptable age thresholds. The processing unit 102 validates per-field validity flags to detect incomplete or inconsistent telemetry data. Telemetry inputs that are stale, incomplete, or inconsistent are flagged immediately by the input validation and freshness gating. The freshness gating is deliberately strict such that missing safety-related fields cause the deterministic safety assessment pipeline to transition into a more conservative enforcement state. Missing or invalid telemetry inputs are treated as risk-elevating conditions rather than benign omissions.

[0141] The processing unit 102 may implement a safety state machine with states including NORMAL, RESTRICTED, DEGRADED, and STOP. Transitions between safety states may be determined based on telemetry inputs. The safety state machine aggregates local risk indicators into a bounded risk state and applies hysteresis to avoid oscillation due to transient noise. The hysteresis ensures that the safety state machine does not oscillate between states in response to momentary fluctuations in telemetry inputs. The safety state machine ensures monotonic escalation under persistent risk such that sustained or repeated unsafe conditions cause progressive transitions from NORMAL toward STOP. The safety state machine guarantees immediate escalation on hard violations without waiting for advisory modules or external confirmation. State transitions toward more restrictive modes are monotonic and irreversible without explicit multi-factor authorization validated by the hardware-rooted identity module. No automatic transition from a restrictive state to a less restrictive state is permitted based solely on resumed telemetry availability.

[0142] Each state of the safety state machine corresponds to a well-defined intervention profile. The NORMAL state corresponds to unrestricted operation within authorized constraints. The RESTRICTED state corresponds to reduced operational envelope with tightened speed limits or zone restrictions. The DEGRADED state corresponds to further reduced capabilities with limited mobility or functionality. The STOP state corresponds to immediate cessation of motion and potentially other functions of the autonomous device 20. The deterministic safety assessment pipeline maps safety state transitions directly to intervention primitives executed by the blocking unit 110. The deterministic safety assessment pipeline is authorized to enforce state transitions without waiting for any advisory module, ensuring that safety intervention remains predictable and non-bypassable.

[0143] With continued reference to FIG. 2, the processing unit may implement a layered behavioral assessment architecture having a deterministic safety pipeline as sole intervention authority, with algorithm-based, deep learning-based, and LLM-based advisory layers that are non-authoritative. The layered behavioral assessment architecture reconciles deterministic, enforceable safety decisions with richer behavioral understanding that captures complex, context-dependent hazards in autonomous devices operating in human-centered environments.

[0144] Referring to FIG. 10, a flowchart illustrates the deterministic safety assessment pipeline architecture within the supervisory terminal device 10A. The pipeline begins at the top with Bounded OOB (Out-of-Band) Summaries, which encompass Intent, Execution, Context, and Validity Flags representing the structured telemetry inputs received through the out-of-band interface from the autonomous device 20. These summaries flow downward into a Deterministic Feature Extraction stage, which processes Authorization Compliance, Physical Consistency, Multi-Modal Anomalies, and Telemetry Integrity. An annotation indicates that this stage performs constant-time checks producing fixed-size indicators, ensuring predictable execution timing. The extracted features then proceed to a Risk Aggregation stage, which computes Instantaneous Risk, applies Short-Memory Smoothing, and performs Abrupt Change Detection. This stage incorporates a fail-safe bias where missing data increases risk rather than being treated as benign. The aggregated risk signals feed into the Safety State Machine, which manages transitions through four discrete states: NORMAL, RESTRICTED, DEGRADED, and STOP. The safety state machine employs hysteresis and deterministic transitions to prevent oscillation and ensure stable enforcement decisions. The pipeline terminates at an Intervention Primitive stage, which maps the current safety state to one of four possible actions: None, SafeModeDegrade, MotionInhibit, or EmergencyStop. The left side of FIG. 10 indicates that the entire pipeline operates within a 1 to 10 millisecond cycle time, demonstrating the real-time deterministic nature of the safety enforcement mechanism. The deterministic safety assessment pipeline serves as the sole authority for immediate intervention decisions in the supervisory terminal device 10A, operating within a fixed and analyzable execution budget while providing enforceable safety decisions that are independent of robot operating systems, autonomy software, and learning-based components.

[0145] Referring to FIG. 7, a block diagram illustrates algorithm-based behavioral assessment module integrated as a rule-driven advisory layer alongside the deterministic safety core of the supervisory terminal device 10A. At the top of FIG. 7, a box labeled Structured Context Summaries contains four categories of input data: Declared Intent, Environment Policies, Authorization State, and Safety Context. These structured inputs flow downward via a solid arrow into the central component labeled Deterministic Safety Core, which performs risk aggregation and maintains a safety state machine, with an indicated safety authority response time of 1 to 10 milliseconds. The Deterministic Safety Core produces Safety Outcomes shown at the bottom of FIG. 7, which include four discrete states: NORMAL, RESTRICTED, DEGRADED, and STOP. To the right side of FIG. 7, enclosed in a box indicating its advisory and non-authoritative nature, is the Algorithm-Based Behavioral Assessment module. This advisory logic layer performs Rule-Based IoA Evaluation, Temporal Threshold Logic, Cross-Signal Consistency Rules, and Scenario-Specific Guards. The module is explicitly labeled as Deterministic, Interpretable, and having No learning capabilities. An arrow shows that Structured Context flows into this advisory module, and another arrow shows that the advisory signal output from this module feeds back into the Deterministic Safety Core. This architectural representation demonstrates the separation between the authoritative deterministic safety pipeline and the non-authoritative advisory assessment layer, ensuring that the advisory signals can inform but never directly control safety intervention decisions. The deterministic safety pipeline remains the sole authority for real-time safety decisions, while the algorithmic rules provide interpretable behavioral risk signals that may increase scrutiny or accelerate escalation when corroborated by other evidence.

[0146] The deterministic safety pipeline constitutes the sole authority for real-time intervention decisions. The deterministic safety pipeline is bounded, interpretable, and implementable on embedded hardware with predictable worst-case behavior. The deterministic safety pipeline operates within a strict 1 millisecond to 10 millisecond decision budget and maps directly to intervention primitives without relying on outputs from advisory layers. The deterministic safety pipeline remains safe and enforceable even if advisory layers are unavailable, incorrect, delayed, or adversarially manipulated.

[0147] The algorithm-based advisory layer provides structured risk signals derived from interpretable logic. The algorithm-based advisory layer includes indicator-of-attack logic for detecting behavior patterns consistent with control-path manipulation, scenario-specific guards for context-dependent hazards, and cross-signal consistency logic for evaluating coherence among health, motion, and authorization constraint signals. The algorithm-based advisory layer outputs bounded rule-driven risk signals that feed into aggregation logic of the deterministic safety pipeline as additional evidence without directly invoking intervention.

[0148] The deep learning-based advisory layer provides sensitivity to complex temporal relationships or cross-modal patterns that are difficult to capture using fixed rules alone. The deep learning-based advisory layer consumes fixed-format temporal windows of bounded summaries rather than raw sensor streams. The deep learning-based advisory layer outputs bounded anomaly indicators such as risk scores or discrete anomaly flags. The deep learning-based advisory layer is treated as untrusted such that outputs are logged, schema-validated, and never interpreted as ground truth. The LLM-based advisory layer addresses risks at semantic and policy interpretation levels where hazards arise from ambiguity, conflicting policy vocabulary, or inconsistent intent declarations. The LLM-based advisory layer supports intent-policy semantic alignment, contextual plausibility reasoning, cross-domain policy interpretation, and human-readable rationale generation. The LLM-based advisory layer receives structured and bounded inputs rather than free-form logs and produces schema-validated outputs before acceptance as advisory signals.

[0149] The supervisory terminal device 10A may implement strict scheduling where the deterministic pipeline is highest priority, advisory layers execute opportunistically, and emergency intervention does not wait for attestation, DL inference, or LLM responses. The deterministic safety pipeline completes within the decision budget as the highest priority task. Advisory layers execute opportunistically and may be skipped under load without affecting safety enforcement. Advisory outputs influence scrutiny and escalation thresholds but do not directly trigger or suppress safety actions. Logging and audit trails are written in bounded formats and may be deferred without affecting intervention. The strict scheduling ensures that the supervisory terminal device remains safe under overload conditions and that real-time intervention guarantees are architectural rather than empirical.

[0150] With continued reference to FIG. 2, the supervisory terminal device 10A may include an algorithm-based behavioral assessment layer using interpretable rules and indicator-of-attack logic for detecting behavioral risk signals. The algorithm-based behavioral assessment layer complements the deterministic safety pipeline by providing additional structured risk signals derived from interpretable logic. The algorithm-based behavioral assessment layer is appropriate for hazards that are well-defined but require richer scenario guards than can be encoded in minimal pipeline checks.

[0151] The algorithm-based behavioral assessment layer includes indicator-of-attack logic for detecting behavior patterns consistent with control-path manipulation. The indicator-of-attack logic identifies sequences of actions or telemetry patterns that suggest adversarial interference with control systems of the autonomous device 20. The indicator-of-attack logic detects attempts to manipulate sensor inputs, override safety constraints, or inject unauthorized commands into control pathways. The algorithm-based behavioral assessment layer also includes scenario-specific guards for context-dependent hazards and cross-signal consistency logic for evaluating coherence among health, motion, and authorization constraint signals.

[0152] The indicator-of-attack (IoA) logic within the algorithm-based behavioral assessment layer is configured to detect specific attack patterns that suggest adversarial interference with control systems of the autonomous device 20. The IoA logic identifies behavior patterns consistent with control-path manipulation, where an attacker attempts to inject unauthorized commands into the control pathway or override legitimate control signals. The IoA logic also detects sensor spoofing patterns, where telemetry inputs are manipulated to present false information about the autonomous device's state or environment. Command injection detection identifies sequences of actions or telemetry patterns that suggest unauthorized commands have been inserted into the autonomous device's command stream. The IoA logic further detects attempts to manipulate safety constraints, override authorization limits, or escalate operational privileges beyond those granted by current authorization constraints. The detection of these attack patterns involves analyzing temporal sequences of telemetry data to identify anomalous transitions, unexpected command sources, or implausible combinations of reported states. When the IoA logic detects patterns consistent with adversarial manipulation, the algorithm-based behavioral assessment layer outputs elevated risk signals that cause the deterministic safety pipeline to increase scrutiny and potentially escalate the safety state toward more restrictive enforcement modes.

[0153] The supervisory terminal device 10A may implement compliance and authorization checks evaluating zone admission, mode restrictions, speed / force limits, and time window validity. Zone admission checks evaluate whether current behavior of the autonomous device 20 respects allowed and forbidden regions defined by authorization constraints. Mode restriction checks evaluate whether the autonomous device 20 operates within permitted operational modes such as restricted mode in human-dense areas. Speed / force limit checks evaluate whether velocity and force outputs of the autonomous device 20 remain within authorized thresholds. Time window validity checks evaluate whether authorization constraints remain valid based on time-limited access windows and revocation conditions. The compliance and authorization checks are rule-driven and bounded to ensure enforceability within the deterministic safety pipeline.

[0154] The processing unit 102 may implements physical consistency and telemetry integrity checks including intent-execution deviation, abrupt discontinuities, repeated oscillation, and integrity anomalies. Intent-execution deviation checks evaluate whether declared intent of the autonomous device 20 is consistent with execution summaries and basic continuity assumptions. The intent-execution deviation checks detect discrepancies between what the autonomous device 20 claims to intend and what the autonomous device 20 is actually doing. Abrupt discontinuity checks detect sudden changes in telemetry values that are inconsistent with physical platform limits of the autonomous device 20. Repeated oscillation checks detect behavior patterns where the autonomous device 20 repeatedly approaches and retreats from safety thresholds. Integrity anomaly checks detect inconsistent validity flags, impossible combinations of telemetry values, or other indicators suggesting telemetry corruption or falsification. The physical consistency and telemetry integrity checks operate without requiring detailed dynamics models of the autonomous device 20.

[0155] The supervisory terminal device 10A may include a deep learning-based behavioral assessment layer for detecting temporal and cross-modal anomaly patterns. The deep learning-based behavioral assessment layer operates on bounded summaries rather than raw sensor streams. By consuming bounded summaries instead of raw sensor data, the deep learning-based behavioral assessment layer reduces attack surface, limits bandwidth requirements, and preserves determinism in preprocessing operations. The deep learning-based behavioral assessment layer provides sensitivity to complex temporal relationships or cross-modal patterns that are difficult to capture using fixed rules alone while maintaining bounded inference characteristics suitable for embedded deployment.

[0156] Referring to FIG. 8, a block diagram illustrates deep learning-based behavioral assessment as an advisory layer alongside the deterministic safety core of the supervisory terminal device 10A. At the top of FIG. 8, a box labeled Structured Context Summaries contains four elements: Declared Intent, Environment Policies, Authorization State, and Safety Context. This structured context feeds into two parallel processing paths. The primary path flows downward through a solid arrow to a Deterministic Safety Core box, which contains Risk Aggregation and Safety State Machine components, with a notation indicating Safety authority operating within a 1-10 ms time budget. The Deterministic Safety Core then produces a Safety Outcome, shown at the bottom of FIG. 8, which can be one of four discrete states: NORMAL, RESTRICTED, DEGRADED, or STOP. A secondary path, indicated by dashed lines and labeled Structured Context, connects the Structured Context Summaries to a separate box on the right side labeled Deep Learning-Based Assessment module. This assessment module has non-authoritative nature, contains Temporal Pattern Detection, Cross-Modal Anomaly Signals, and Emergent Behavior Indicators. The Deep Learning-Based Assessment module is explicitly marked as Advisory only and described as Non-authoritative, Bounded inference. An arrow indicates that Advisory signal connects this module back to the Deterministic Safety Core, indicating that the deep learning outputs serve only as supplementary risk indicators that inform but do not control the deterministic safety decisions. This architecture demonstrates the separation between the authoritative real-time safety pipeline and the advisory learning-based assessment layer, ensuring that safety enforcement remains deterministic and bounded while still benefiting from advanced pattern detection capabilities. The learning-based anomaly detection operates on bounded summaries rather than raw sensor streams, and final safety decisions remain governed by the deterministic assessment pipeline and safety state machine.

[0157] The deep learning-based behavioral assessment layer consumes fixed-format temporal windows of bounded summaries. The fixed-format temporal windows include short windows of intent-execution summaries that capture what the autonomous device 20 claims to intend and what the autonomous device 20 is actually doing over a recent time period. The intent-execution summaries include commanded velocities, measured velocities, and deviations between intent and execution across multiple time steps within the temporal window. The fixed-format temporal windows also include proximity-risk traces that capture distance measurements and risk level indicators over the recent time period. The proximity-risk traces indicate minimum distances to obstacles or humans and corresponding risk classifications across the temporal window. The fixed-format temporal windows further include health indicators that capture operational status of subsystems of the autonomous device 20 over the recent time period. The health indicators include actuator status, battery state, thermal conditions, and sensor health across the temporal window.

[0158] The deep learning-based behavioral assessment layer outputs bounded anomaly indicators based on analysis of the fixed-format temporal windows. The bounded anomaly indicators include risk scores or discrete anomaly flags that indicate detection of anomalous patterns in the temporal data. The bounded anomaly indicators are integrated conservatively such that strong anomaly signals may increase scrutiny and accelerate escalation when corroborated by other evidence, while anomaly outputs do not clear behavior that the deterministic safety pipeline deems unsafe. Missing or delayed outputs from the deep learning-based behavioral assessment layer are treated as uncertainty rather than safety.

[0159] Referring to FIG. 9, a block diagram illustrates LLM-based behavioral assessment module as a semantic and policy-level advisory layer alongside the deterministic safety core of the supervisory terminal device 10A. At the top of FIG. 9 is a box labeled Structured Context Summaries containing four elements: Declared Intent, Environment Policies, Authorization State, and Safety Context. This structured context feeds downward via a solid arrow to a Deterministic Safety Core box, which contains Risk Aggregation and Safety State Machine components and is designated as the Safety authority operating within a 1 to 10 millisecond time budget. The structured context also feeds via a dashed arrow to a separate dashed-border box on the right labeled LLM-Based Behavioral Assessment module, which contains Intent-Policy Alignment, Contextual Plausibility, Cross-Domain Policy Reasoning, and Explanation Generation functions. This LLM component is explicitly marked as Advisory only and described as Non-authoritative and Non-real-time. An arrow indicates that Advisory signals connect the LLM-Based Behavioral Assessment module back to the Deterministic Safety Core, indicating that the LLM outputs serve only as supplementary advisory inputs rather than authoritative control signals. From the Deterministic Safety Core, a solid arrow points downward to a Safety Outcome box displaying four possible states: NORMAL, RESTRICTED, DEGRADED, and STOP. This architecture demonstrates the strict separation between the deterministic safety pipeline that maintains sole authority for real-time intervention decisions and the LLM-based semantic reasoning layer that provides non-authoritative advisory signals for intent-policy alignment and contextual reasoning without being permitted to directly trigger or suppress safety actions. The LLM operates on structured context summaries to evaluate intent-policy alignment and contextual plausibility, while final safety decisions remain governed by the deterministic safety core.

[0160] The deep learning-based behavioral assessment layer is governed by strict principles including advisory-only status with no direct intervention authority, bounded inference with predictable runtime and memory bounds, isolation on a dedicated accelerator or low-priority context, and fail-safe behavior where absence or delay of output does not reduce risk. The deep learning-based behavioral assessment layer is treated as untrusted such that outputs are logged, schema-validated, and never interpreted as ground truth. The untrusted treatment mitigates risks due to distribution shift, adversarial examples, or unexpected model behavior. The deep learning-based behavioral assessment layer executes opportunistically and may be skipped under load without affecting safety enforcement by the deterministic safety pipeline.

[0161] The supervisory terminal device may include an LLM-based behavioral assessment layer for semantic intent-policy alignment and contextual reasoning. The LLM-based behavioral assessment layer addresses risks at semantic and policy interpretation levels where hazards arise from ambiguity, conflicting policy vocabulary, or inconsistent intent declarations across heterogeneous environments. The LLM-based behavioral assessment layer produces outputs that are schema-validated and non-authoritative, ensuring that the deterministic safety pipeline retains sole authority for intervention decisions.

[0162] The LLM-based behavioral assessment layer performs intent-policy semantic alignment to evaluate whether declared intent of the autonomous device 20 conforms to environment policy intent categories. Intent-policy semantic alignment involves comparing task descriptions or operational goals declared by the autonomous device 20 against policy definitions established by facility operators or regulatory authorities. The LLM-based behavioral assessment layer identifies mismatches between declared intent and permitted activities within a given environment, flagging potential policy violations for further scrutiny without directly triggering intervention.

[0163] The LLM-based behavioral assessment layer performs contextual plausibility reasoning to evaluate whether task descriptions are consistent with current constraints. Contextual plausibility reasoning assesses whether declared operational goals make sense given spatial context, temporal context, and authorization constraints active at a given time. The LLM-based behavioral assessment layer detects implausible combinations of declared intent and environmental conditions, such as delivery tasks declared for restricted zones or maintenance activities declared outside permitted time windows.

[0164] The LLM-based behavioral assessment layer performs cross-domain policy interpretation to map heterogeneous facility policies into consistent authorization constraints. Different environments such as hospitals, hotels, and campuses express policies using different vocabulary, formats, and semantic conventions. Cross-domain policy interpretation translates policy expressions from various sources into a common representation that the supervisory terminal device can evaluate consistently. The LLM-based behavioral assessment layer resolves ambiguities in policy language and identifies conflicts between policies from different sources.

[0165] The LLM-based behavioral assessment layer performs human-readable rationale generation to produce structured explanations for audit and operator review. Human-readable rationale generation provides explanations of why particular behaviors were flagged as potentially problematic or why particular policy interpretations were applied. The structured explanations support post-incident analysis and assist human operators in understanding decisions made by the supervisory terminal device.

[0166] The LLM-based behavioral assessment layer receives structured and bounded inputs rather than free-form logs. Inputs to the LLM-based behavioral assessment layer are generated from structured fields of telemetry summaries and authorization constraints rather than raw text captured from the autonomous device 20. The structured inputs reduce susceptibility to prompt injection attacks and ensure that the LLM-based behavioral assessment layer operates on validated data.

[0167] Outputs from the LLM-based behavioral assessment layer are schema-validated before acceptance as advisory signals. Schema validation constrains output fields and output lengths to bounded values, preventing unbounded or malformed responses from affecting downstream processing. The schema-validated outputs are treated as untrusted advisory signals that may influence scrutiny and escalation thresholds but do not directly trigger or suppress safety actions executed by the deterministic safety pipeline.

[0168] In a method for monitoring an autonomous device, performing real-time edge computing to determine whether the autonomous device is under an abnormal condition is performed after detecting status information of the autonomous device. Real-time edge computing involves processing telemetry inputs and status information locally within a supervisory terminal device to evaluate whether the autonomous device exhibits behavior indicative of an abnormal condition. The real-time edge computing executes within bounded time constraints to maintain deterministic timing guarantees for safety-related assessments.

[0169] The supervisory terminal device 10A implements fail-safe behavior where missing, stale, or inconsistent telemetry inputs are treated as risk-elevating conditions rather than benign omissions. When telemetry inputs are missing, the supervisory terminal device escalates a risk assessment rather than assuming that absence of data indicates normal operation. When telemetry inputs are stale and exceed acceptable age thresholds, the supervisory terminal device treats the staleness as an indicator of potential communication degradation or adversarial interference. When telemetry inputs are inconsistent, such as when validity flags contradict reported values or when sequential frames contain implausible discontinuities, the supervisory terminal device interprets the inconsistency as a risk-elevating condition warranting conservative enforcement. The fail-safe behavior ensures that uncertainty in telemetry data causes the supervisory terminal device to adopt more restrictive safety postures rather than permissive postures.

[0170] The supervisory terminal device may implement fixed-schema parsing with bounded field sets, fixed memory allocation, bounded loops, and no blocking calls to preserve deterministic timing guarantees. Fixed-schema parsing involves processing telemetry frames according to pre-negotiated schemas that define fixed field sets for safety-related data. The fixed field sets specify exact fields, field types, and field sizes that telemetry frames contain, eliminating runtime schema discovery or dynamic field enumeration on safety-related processing paths. Fixed memory allocation involves allocating memory for telemetry processing at initialization rather than during runtime, avoiding dynamic memory allocation that could introduce variable latency or memory exhaustion conditions. Bounded loops involve constraining iteration counts within processing algorithms to predetermined maximum values, ensuring that processing completes within analyzable worst-case execution time regardless of input content. No blocking calls involves structuring processing operations such that no operation waits indefinitely for external events, ensuring that processing proceeds to completion within the bounded time budget.

[0171] The deterministic parsing approach rejects telemetry frames with unknown fields, unsupported versions, or malformed structures without side effects. Rejection of non-conforming frames occurs deterministically without variable-latency error handling or recovery attempts that could compromise timing guarantees. The deterministic parsing supports worst-case execution time analysis by ensuring that all processing paths complete within bounded time regardless of input characteristics. The combination of fail-safe behavior and deterministic parsing allows the supervisory terminal device to perform real-time edge computing that maintains safety guarantees under conditions of partial observability, communication degradation, or adversarial manipulation of telemetry data.

[0172] With continued reference to FIG. 2, the supervisory terminal device may implement a telemetry plane using minimal sufficient observability (MSO) with bounded telemetry frames. The telemetry plane exposes summarized telemetry data rather than raw sensor streams to support millisecond-level hazard detection while maintaining deterministic processing characteristics. The bounded telemetry frames are constrained in size and carry sequence numbers, timestamps observed by the supervisory terminal device, and validity flags for each field.

[0173] The bounded telemetry frames include intent summaries that describe what the autonomous device claims to intend to do at a bounded abstraction level. The intent summaries include commanded velocities, command age indicators, and command source identifiers indicating whether commands originate from autonomy systems or teleoperator inputs. The bounded telemetry frames include execution summaries that describe what the autonomous device is actually doing as measured or summarized. The execution summaries include measured velocities and trajectory digests capturing maximum speed and maximum jerk over recent time windows. The bounded telemetry frames include context and safety flags that describe safety-relevant constraints and environment state. The context and safety flags include safety mode indicators, proximity risk indicators with minimum distance measurements and risk level classifications, and validity indicators for each field.

[0174] Missing or invalid fields within the bounded telemetry frames are explicitly represented to support conservative fail-safe reasoning. Incomplete or delayed telemetry escalates risk rather than being treated as benign absence. The telemetry plane treats telemetry originating from the autonomous device as non-trusted evidence requiring integrity and freshness checks before interpretation.

[0175] The supervisory terminal device may implement a Deterministic Management Command Plane (DMCP) providing constant-time primitives for sensor reads, watchdog enforcement, event retrieval, and safety assertion. The DMCP complements the telemetry plane by providing low-level management primitives amenable to worst-case execution time analysis. The constant-time primitives include sensor read operations for safety-relevant readings such as actuator torque and current bands, battery and thermal state, inertial measurement unit health, and proximity-risk indicators. The constant-time primitives include watchdog enforcement operations that monitor liveness of the autonomous device and trigger predefined safe outcomes upon timeout. The constant-time primitives include event retrieval operations for accessing logged safety events and safety assertion operations for querying interlock integrity.

[0176] The supervisory terminal device may implement a Safety Event Log analogous to IPMI System Event Log for forensic traceability independent of operating system logs of the autonomous device. The Safety Event Log records safety-relevant events including authorization state changes, constraint updates, attestation events, and safety interventions. The Safety Event Log is maintained within the supervisory terminal device and is cryptographically bound to a device identity of the supervisory terminal device to support post-incident analysis.

[0177] The supervisory terminal device may implement watchdog and liveness enforcement with predefined safe outcomes and constrained recovery primitives suitable for mobile autonomous devices. The watchdog enforcement monitors periodic signals from the autonomous device and triggers transition to a safe state upon detection of liveness failure. The predefined safe outcomes include safe reset of subsystems, transition to inspection mode, and interlock integrity queries. The constrained recovery primitives allow controlled recovery operations without requiring full system restart.

[0178] With continued reference to FIG. 2, the supervisory terminal device may implement a three-layer authorization model separating admission, authorization, and enforcement. Admission determines whether the autonomous device is allowed to enter or connect to a given environment. Admission decisions are based on verifying identity, integrity, and provenance of the supervisory terminal device against environment-defined criteria. Authorization determines what the autonomous device is permitted to do within a given environment. Authorization produces structured constraints rather than binary permit or deny decisions. Enforcement ensures that authorized constraints are continuously upheld during operation. Enforcement is performed by the supervisory terminal device through out-of-band monitoring and intervention primitives rather than being delegated to software of the autonomous device. The separation of admission, authorization, and enforcement allows policy decisions to be distinguished from real-time safety functions, with the supervisory terminal device serving as a bridge between the two.

[0179] The supervisory terminal device may implement authorization constraints that are cryptographically bound to the supervisory terminal device rather than to software identifiers of the autonomous device. The authorization constraints include speed limits that define maximum translational or rotational velocities permitted for the autonomous device. The authorization constraints include operational modes that define permitted operating configurations such as restricted mode in human-dense areas. The authorization constraints include spatial zones that define allowed or forbidden regions within which the autonomous device may operate. The authorization constraints include time windows that define time-limited access periods during which the autonomous device may perform particular activities. The cryptographic binding of authorization constraints to the supervisory terminal device ensures that constraints become part of an active authorization context enforced independently of an operating system of the autonomous device.

[0180] The supervisory terminal device may implement constraint lifetime management where each constraint carries explicit lifetime and revocation conditions. Each authorization constraint includes a time-to-live value that specifies a validity period after which the constraint expires. Each authorization constraint includes revocation triggers that specify conditions under which the constraint becomes invalid before expiration. Each authorization constraint includes escalation rules that specify how constraint violations affect safety state transitions. Expired, revoked, or unverifiable constraints are treated conservatively such that the supervisory terminal device transitions the autonomous device into a restricted or degraded safety state until valid authorization is restored. The constraint lifetime management ensures that authorization constraints remain current and that stale or invalid constraints do not permit operation outside intended parameters.

[0181] The supervisory terminal device may implement environment-side policy evaluation where authorization policies are evaluated by the environment rather than by the autonomous device. Environments such as hospitals, hotels, campuses, or industrial facilities define admission and authorization policies based on local safety, liability, and operational requirements. When the autonomous device requests access, the environment challenges the supervisory terminal device, verifies identity and integrity via attestation, and evaluates policy rules against claims provided by the supervisory terminal device. Policy inputs include device class, certified capabilities, operational intent, time of day, occupancy conditions, or infrastructure state. The output of policy evaluation is a set of enforceable constraints that are cryptographically bound to the supervisory terminal device and accompanied by validity conditions. Environment-side policy evaluation allows environments to retain sovereignty over policies without trusting software of the autonomous device or requiring vendor-specific integrations.

[0182] With continued reference to FIG. 2, the supervisory terminal device may implement rate limiting and priority scheduling where safety-critical enforcement tasks always preempt management requests to prevent denial-of-service attacks. The rate limiting constrains the number of requests that external entities can submit to the supervisory terminal device within a given time period. Management requests, attestation queries, and policy update requests are subject to rate limits that prevent excessive or malicious traffic from consuming processing resources of the supervisory terminal device. The priority scheduling assigns higher priority to safety-critical enforcement tasks than to management requests. When the supervisory terminal device receives management requests while safety-critical enforcement tasks are pending or executing, the priority scheduling defers processing of the management requests until the safety-critical enforcement tasks complete. The preemption of management requests by safety-critical enforcement tasks ensures that emergency intervention cannot be delayed by excessive traffic or by adversarial attempts to overwhelm the supervisory terminal device with management requests.

[0183] The supervisory terminal device may implement version binding where the autonomous device binds to a specific interface specification version that is cryptographically protected to prevent schema confusion and downgrade attacks. The interface specification version defines schemas, field sets, and protocol semantics that govern communication between the supervisory terminal device and the autonomous device. The autonomous device binds to the interface specification version during initialization and includes the interface specification version in identity information stored within the supervisory terminal device. The cryptographic protection of the interface specification version involves signing or hashing the version identifier such that attempts to modify the version binding are detectable. Schema confusion attacks involve presenting telemetry or commands using schemas that differ from expected schemas, potentially causing misinterpretation of data or commands. Downgrade attacks involve forcing the supervisory terminal device to accept older interface specification versions that contain vulnerabilities or weaker security properties. The version binding prevents schema confusion and downgrade attacks by rejecting messages that do not conform to the bound interface specification version.

[0184] The supervisory terminal device may implement local safety primacy logic that validates external commands against hardware-rooted safety invariants and rejects commands that contradict local hard constraints. When the supervisory terminal device receives a policy update or command from an external source such as an edge server or the remote supervisory device, the local safety primacy logic compares the command against safety invariants stored within the supervisory terminal device. The hardware-rooted safety invariants define physical safety envelopes, maximum operational parameters, and constraints that the supervisory terminal device enforces regardless of external commands. If an external command contradicts a local hard constraint, such as requesting a speed that exceeds a physical safety envelope of the autonomous device, the local safety primacy logic automatically rejects the command and logs the attempted violation. The local safety primacy logic ensures that the supervisory terminal device acts as a firewall for the autonomous device, preventing external entities from issuing commands that would compromise physical safety even if the external entities are compromised or malicious.

[0185] Multiple supervisory terminal devices deployed within the same physical environment mutually observe and cross-validate autonomous device behavior through inter-device cooperative monitoring. When multiple autonomous devices operate within a shared environment such as a hospital, hotel, campus, or commercial building, hazards may arise from interactions among multiple autonomous devices, humans, and infrastructure elements. Such environment-level hazards are not fully observable from the perspective of a single autonomous device or a single supervisory terminal device. Inter-device cooperative monitoring enables supervisory terminal devices to exchange safety-relevant summaries that describe local safety-relevant views of autonomous device behavior. The safety-relevant summaries include current safety state, recent state transitions, active authorization constraints, aggregated risk indicators, and selected advisory signals. The safety-relevant summaries are cryptographically authenticated and bound to hardware identities of the respective supervisory terminal devices, allowing receiving supervisory terminal devices and external aggregators to verify provenance without trusting software of the autonomous devices.

[0186] The control system may include an edge server that aggregates safety-relevant summaries from multiple supervisory terminal devices for environment-level reasoning and coordinated policy enforcement. The edge server is deployed within a physical environment and receives bounded regulatory summaries from supervisory terminal devices operating within that environment. The edge server performs environment-level reasoning that is impractical at the individual supervisory terminal device level. Environment-level reasoning includes multi-device correlation to detect congestion, coordinated anomalies, or emergent unsafe interactions among multiple autonomous devices. Environment-level reasoning includes policy consistency checking to ensure that authorization constraints applied to different autonomous devices do not conflict with shared safety goals. Environment-level reasoning includes environmental context integration to incorporate building state, occupancy conditions, or infrastructure alerts into safety assessments. The edge server issues policy advisories or constraint updates that are cryptographically bound and submitted to individual supervisory terminal devices. Each supervisory terminal device independently validates and enforces updates according to local authority and timing guarantees.

[0187] The supervisory terminal device retains final authority for immediate intervention while the edge server provides supervisory consistency and global context, preserving local autonomy. The edge server operates as a supervisory aggregator that augments local reasoning with environment-level context but is excluded from real-time safety loops. Failure, unavailability, or compromise of the edge server does not reduce local safety guarantees provided by individual supervisory terminal devices. If inter-device communication is delayed, corrupted, or unavailable, each supervisory terminal device continues to operate using local deterministic safety pipelines and existing authorization constraints. Cooperative signals from the edge server may increase conservatism by causing local supervisory terminal devices to tighten enforcement thresholds, but cooperative signals do not suppress intervention triggered by local safety checks. The edge server does not generate real-time intervention commands and does not directly override or delay local intervention decisions made by supervisory terminal devices.

[0188] Table 2 below positions inter-device cooperative regulation between standalone per-device enforcement and centralized robot control, illustrating how the proposed architecture achieves environment-level safety awareness without introducing centralized safety authority or single points of failure.

[0189] In some embodiments, a compromised edge server may attempt to broadcast malicious policy updates to supervisory terminal devices within the environment. For example, a rogue edge server may issue commands to disable speed limits, allow entry to restricted zones, or override safety constraints that would otherwise prevent dangerous behavior. To defend against such threats, each supervisory terminal device implements local safety primacy logic that validates all external commands against hardware-rooted safety invariants before acceptance. When the supervisory terminal device receives a policy update or constraint modification from the edge server, the supervisory terminal device compares the requested change against locally stored safety invariants that define physical safety envelopes, maximum operational parameters, and non-negotiable constraints. If the external command contradicts a local hard constraint, such as requesting a speed that exceeds the physical safety envelope of the autonomous device or requesting access to a zone that is permanently restricted, the supervisory terminal device automatically rejects the command without executing the requested change. The supervisory terminal device logs the attempted violation, including the command contents, the issuer identity, and the timestamp, to support forensic analysis and accountability. This defense mechanism ensures that the supervisory terminal device acts as a firewall for the physical system, preventing compromised infrastructure components from issuing commands that would compromise physical safety. The edge server functions strictly as a policy coordinator, while the supervisory terminal device remains the final, non-bypassable arbiter of physical safety for the autonomous device.

[0190] The edge server performs multi-robot correlation to detect congestion, coordinated anomalies, or emergent unsafe interactions among multiple autonomous devices operating within a shared environment. Multi-robot correlation involves analyzing safety-relevant summaries received from multiple supervisory terminal devices to identify patterns or conditions that are not observable from the perspective of any single supervisory terminal device. Congestion detection involves identifying situations where multiple autonomous devices converge on the same spatial region, creating potential collision risks or impeding movement of humans or other autonomous devices. The edge server correlates position information and trajectory data from multiple supervisory terminal devices to detect when autonomous devices are approaching the same location or when traffic density in a particular zone exceeds acceptable thresholds.

[0191] Coordinated anomaly detection involves identifying situations where multiple autonomous devices exhibit similar anomalous behavior patterns that suggest common causes such as environmental disturbances, infrastructure failures, or coordinated adversarial manipulation. The edge server compares risk indicators and advisory signals across multiple supervisory terminal devices to detect correlated anomalies that would appear as isolated incidents when viewed from individual supervisory terminal devices. Emergent unsafe interaction detection involves identifying situations where combinations of individually acceptable behaviors create hazardous conditions when multiple autonomous devices operate in proximity. The edge server evaluates spatial and temporal relationships among autonomous devices to detect emergent interactions that arise from the collective behavior of multiple autonomous devices rather than from the behavior of any single autonomous device.

[0192] The supervisory terminal device periodically emits bounded regulatory summaries that describe a local safety-relevant view of autonomous device behavior. The bounded regulatory summaries are transmitted to the edge server at controlled rates to support environment-level reasoning without overwhelming communication resources. Each bounded regulatory summary includes a current safety state indicating whether the autonomous device is operating in a NORMAL, RESTRICTED, DEGRADED, or STOP state. The bounded regulatory summary includes active authorization constraints that describe speed limits, zone restrictions, mode restrictions, and time window constraints currently enforced by the supervisory terminal device. The bounded regulatory summary includes aggregated risk indicators produced by a deterministic safety pipeline of the supervisory terminal device. The aggregated risk indicators summarize recent risk assessments without exposing detailed telemetry data. The bounded regulatory summary includes advisory signals from algorithm-based, deep learning-based, or LLM-based advisory layers. The advisory signals indicate persistent anomaly flags or elevated scrutiny conditions detected by advisory assessment components.

[0193] The bounded regulatory summaries transmitted between supervisory terminal devices and the edge server conform to a minimal, schema-fixed contract that supports bounded processing and provenance verification. A minimal supervisory terminal device-to-edge summary includes the following fields: an rrt_id field containing a hardware-bound identifier of the supervisory terminal device; a robot_binding_id field containing an identifier of the autonomous device currently bound to the supervisory terminal device; a local_safety_state field indicating the current safety state such as NORMAL, RESTRICTED, DEGRADED, or STOP; a constraint_digest field containing a hash or digest of active authorization constraints enforced by the supervisory terminal device; a risk_digest field containing an aggregated risk indicator produced by the deterministic safety pipeline; a recent_state_transitions field containing a bounded history of recent safety state changes; an advisory_flags field containing optional indicators from algorithm-based, deep learning-based, or LLM-based advisory layers; a freshness field containing a timestamp and validity window; and a signature field containing a cryptographic signature bound to the hardware identity of the supervisory terminal device. The summary contains no raw sensor data, no control commands, and no executable instructions. The purpose of the summary is descriptive, reporting what the supervisory terminal device is enforcing and observing without delegating authority to external systems.

[0194] The bounded regulatory summaries are cryptographically authenticated and bound to a hardware identity of the supervisory terminal device. The cryptographic authentication allows the edge server and other supervisory terminal devices to verify provenance of the summaries without trusting software of the autonomous device. The bounded regulatory summaries contain no raw sensor data, no control commands, and no executable instructions. The descriptive nature of the bounded regulatory summaries supports environment-level reasoning while maintaining separation between supervisory functions and control functions.

[0195] The supervisory terminal device may implement infrastructure-embedded deployment in CCTV-like systems equipped with vision-language models for cross-validation of autonomous device behavior against environmental perception. Infrastructure-embedded supervisory terminal devices are integrated into fixed sensing systems such as surveillance cameras, environmental monitoring stations, or building management sensors that observe autonomous devices from external vantage points. The infrastructure-embedded deployment provides an independent observational perspective that complements onboard monitoring performed by supervisory terminal devices physically coupled to autonomous devices.

[0196] Infrastructure-embedded supervisory terminal devices are equipped with vision-language models that process visual data captured by cameras or other imaging sensors. The vision-language models analyze captured images or video streams to detect autonomous devices within a field of view, identify behaviors exhibited by the autonomous devices, and evaluate whether observed behaviors conform to expected operational parameters. The vision-language models combine visual perception capabilities with language-based reasoning to interpret observed scenes and generate semantic descriptions of autonomous device activities.

[0197] Cross-validation of autonomous device behavior involves comparing observations from infrastructure-embedded supervisory terminal devices with safety-relevant summaries received from supervisory terminal devices physically coupled to autonomous devices. When an infrastructure-embedded supervisory terminal device observes an autonomous device within a monitored area, the infrastructure-embedded supervisory terminal device generates safety-relevant summaries describing observed position, trajectory, and behavior of the autonomous device. The safety-relevant summaries generated by the infrastructure-embedded supervisory terminal device are compared against safety-relevant summaries transmitted by a supervisory terminal device coupled to the observed autonomous device. Discrepancies between the two sets of observations may indicate potential falsification of telemetry data, sensor failures, or adversarial manipulation of onboard systems.

[0198] The infrastructure-embedded supervisory terminal devices observe robot-human proximity within monitored areas. The vision-language models detect humans within the field of view and estimate distances between detected humans and autonomous devices. Proximity observations from infrastructure-embedded supervisory terminal devices are used to validate proximity risk indicators reported by supervisory terminal devices coupled to autonomous devices. The infrastructure-embedded supervisory terminal devices also detect forbidden zone entry by observing when autonomous devices enter restricted areas that are visible within the monitored field of view.

[0199] Safety-relevant summaries generated by infrastructure-embedded supervisory terminal devices are treated as advisory evidence by supervisory terminal devices coupled to autonomous devices. The advisory evidence strengthens confidence in detected hazards when observations from multiple sources corroborate each other. The advisory evidence also disambiguates false positives when infrastructure-embedded observations indicate that conditions flagged by onboard sensors do not correspond to actual hazards. The infrastructure-embedded supervisory terminal devices transmit safety-relevant summaries to an edge server for aggregation with summaries from supervisory terminal devices coupled to autonomous devices, supporting environment-level reasoning that incorporates both onboard and external observational perspectives.

[0200] Referring to FIG. 3, a method 200 for monitoring an autonomous device is illustrated. The method 200 is performed by the supervisory terminal device 10 physically coupled to the autonomous device 20. The method 200 provides a structured approach for monitoring autonomous devices through secure identification code handling and transmission using quantum-resistant cryptographic techniques.

[0201] The method 200 begins with a step 202 of storing an identification code ID in the storage unit 100 of the supervisory terminal device 10 physically coupled to the autonomous device 20. The step 202 establishes a hardware-rooted identity anchor within the supervisory terminal device 10 that is independent of software executing on the autonomous device 20. The identification code ID stored in the step 202 includes a globally unique identifier that is anchored to hardware-bound material of the supervisory terminal device 10. The identification code ID also includes a protected attestation key and integrity measurements that bind firmware and interface state to the identity. By storing the identification code ID in the storage unit 100 of the supervisory terminal device 10, the step 202 enables external parties to authenticate the supervisory terminal device 10 rather than authenticating an operating system or autonomy stack of the autonomous device 20.

[0202] The method 200 proceeds to a step 204 of encrypting the identification code ID and other information using quantum-resistant cryptography via the encryption unit 106 of the supervisory terminal device 10. The step 204 applies post-quantum cryptographic algorithms to the identification code ID and other information to provide protection against decryption by quantum computing techniques. The encryption unit 106 supports NIST post-quantum cryptographic standards FIPS-203 / 204 / 205 for the quantum-resistant cryptography applied in the step 204. The step 204 involves the encryption unit 106 receiving the identification code ID and other information from the processing unit 102 and applying quantum-resistant cryptographic algorithms to produce an encrypted identification code ID and other information. The quantum-resistant cryptography applied in the step 204 ensures that the identification code ID and other information remains secure against both classical and quantum computing attacks during transmission.

[0203] With continued reference to FIG. 3, the method 200 proceeds to a step 206 of transmitting the encrypted identification code ID and other information, by the supervisory terminal device 10, to confirm an identity of the autonomous device 20. The step 206 involves the communication unit 104 transmitting the encrypted identification code ID and other information to the remote supervisory device 30. The remote supervisory device 30 receives the encrypted identification code ID and verifies the identity of the autonomous device 20 based on the received encrypted identification code ID. The step 206 completes the method 200 by establishing a verified identity for the autonomous device 20 that is protected by quantum-resistant cryptography and is independent of software-based credentials managed by the autonomous device 20.

[0204] The method 200 may be performed repeatedly at intervals to provide ongoing identity verification for the autonomous device 20. The supervisory terminal device 10 performs the step 202, the step 204, and the step 206 in response to requests from the remote supervisory device 30 or according to a predetermined schedule. The method 200 allows the remote supervisory device 30 to maintain current verification of the identity of the autonomous device 20 throughout operation of the autonomous device 20.

[0205] The sequential performance of the step 202, the step 204, and the step 206 provides secure identity verification for the autonomous device 20 using hardware-rooted identity anchors and quantum-resistant cryptographic protection.

[0206] Referring to FIG. 4, a method 300 for monitoring an autonomous device is illustrated. The method 300 is performed by the supervisory terminal device 10 physically coupled to the autonomous device 20. The method 300 combines identity verification through quantum-resistant encryption with status detection and conditional intervention based on assessment of status information accuracy and device operating conditions.

[0207] The method 300 begins with a step 302 of storing an identification code ID in the storage unit 100 of the supervisory terminal device 10 physically coupled to the autonomous device 20. The step 302 establishes a hardware-rooted identity anchor within the supervisory terminal device 10 that is independent of software executing on the autonomous device 20. The identification code ID stored in the step 302 includes a globally unique identifier anchored to hardware-bound material of the supervisory terminal device 10, a protected attestation key, and integrity measurements that bind firmware and interface state to the identity.

[0208] The method 300 proceeds to a step 304 of encrypting the identification code ID and other robot-related information (for example, but not limited to, using quantum-resistant cryptography) via the encryption unit 106 of the supervisory terminal device 10. The encryption unit 106 applies post-quantum cryptographic algorithms conforming to NIST standards FIPS-203 / 204 / 205 to the identification code ID and other information. The step 304 provides protection against decryption by quantum computing techniques that may be capable of breaking conventional cryptographic algorithms.

[0209] With continued reference to FIG. 4, the method 300 proceeds to a step 306 of transmitting the encrypted identification code ID and other information, by the supervisory terminal device 10, to confirm an identity of the autonomous device 20. The step 306 involves the communication unit 104 transmitting the encrypted identification code ID and other information to the remote supervisory device 30. The remote supervisory device 30 receives the encrypted identification code ID and verifies the identity of the autonomous device 20 based on the received encrypted identification code ID.

[0210] The method 300 continues to a step 308 of detecting status information of the autonomous device 20. The step 308 is performed by the status detection unit 112 of the supervisory terminal device 10. The status information detected in the step 308 includes location information, coordinates, latitude, longitude, height, floor, current power level, charging status, work or task being performed, work or task to be performed, images captured by vision systems of the autonomous device 20, and sounds captured by audio systems of the autonomous device 20. The status detection unit 112 receives the status information through an interface with the autonomous device 20 and outputs the status information to the processing unit 102.

[0211] As further shown in FIG. 4, the method 300 advances to a step 310 of determining whether the status information is true or whether the autonomous device 20 is under a normal condition based on the status information. The step 310 is performed by the processing unit 102 of the supervisory terminal device 10. The processing unit 102 evaluates the status information received from the status detection unit 112 to assess accuracy and consistency of the status information. The processing unit 102 compares the status information against expected values, physical constraints, and authorization constraints to determine whether the status information is true. The processing unit 102 also evaluates the status information to determine whether the autonomous device 20 is operating under a normal condition or whether the autonomous device 20 exhibits behavior indicative of an abnormal condition.

[0212] In a method 300 for monitoring an autonomous device 20, determining whether the status information is true or whether the autonomous device 20 is under a normal condition based on the status information involves evaluating consistency between different elements of the status information. The processing unit 102 compares position information reported by the autonomous device 20 with position coordinates determined via satellite positioning received by the communication unit 104. The processing unit 102 compares motion information reported by the autonomous device 20 with movement information sensed by the sensing unit 114. Discrepancies between reported status information and independently determined information indicate that the status information is inaccurate or falsified.

[0213] With continued reference to FIG. 4, the step 310 functions as a decision point that determines subsequent actions based on the assessment of status information accuracy and device operating conditions. If the determination in the step 310 indicates that the status information is not true or the autonomous device 20 is not under a normal condition, the method 300 proceeds to a step 312 of outputting a blocking signal to stop the autonomous device 20. If the determination in the step 310 indicates that the status information is true and the autonomous device 20 is under a normal condition, the method 300 continues monitoring operations by returning to the step 308 to detect subsequent status information.

[0214] In a method 300 for monitoring an autonomous device 20, performing real-time edge computing to determine whether the autonomous device 20 is under an abnormal condition is performed as part of the step 310 following the step 308 of detecting status information of the autonomous device 20. The processing unit 102 implements real-time edge computing to evaluate the status information and to determine whether the autonomous device 20 exhibits behavior indicative of an abnormal condition. The real-time edge computing involves processing telemetry inputs and status information locally within the supervisory terminal device 10 to evaluate whether the autonomous device 20 exhibits unreasonable behavior, non-compliant behavior, illegal behavior, behavior that may endanger human beings, or behavior that violates rules or regulations. The real-time edge computing executes within bounded time constraints to maintain deterministic timing guarantees for safety-related assessments.

[0215] The real-time edge computing performed in the method 300 involves the processing unit 102 applying algorithm-based behavioral assessment using interpretable rules and indicator-of-attack logic. The processing unit 102 evaluates the status information against compliance and authorization checks including zone admission, mode restrictions, speed limits, force limits, and time window validity. The processing unit 102 also evaluates physical consistency and telemetry integrity by checking for intent-execution deviation, abrupt discontinuities, repeated oscillation around safety thresholds, and integrity anomalies such as inconsistent validity flags or impossible combinations of telemetry values.

[0216] In the method 300 for monitoring an autonomous device 20, outputting a blocking signal to stop the autonomous device 20 when the supervisory terminal device 10 determines that the autonomous device 20 is under an abnormal condition is performed as the step 312 following the step 310. When the processing unit 102 determines in the step 310 that the status information is not true or that the autonomous device 20 is under an abnormal condition, the processing unit 102 directs the blocking unit 110 to output a blocking signal in the step 312. The blocking signal output by the blocking unit 110 causes the autonomous device 20 to stop improper behavior or action. In some embodiments, the blocking unit 110 emits a proximity electromagnetic pulse or a blocking signal that causes at least one chip of the autonomous device 20 to stop operation of at least one module or function. The outputting of the blocking signal in the step 312 provides the supervisory terminal device 10 with a capability to enforce immediate intervention when the autonomous device 20 poses a risk to human beings or property.

[0217] The method 300 implements fail-safe behavior where missing, stale, or inconsistent status information is treated as a risk-elevating condition rather than a benign omission. When status information is missing or delayed beyond acceptable thresholds, the processing unit 102 treats the absence as an indicator of potential communication degradation or adversarial interference. When status information contains inconsistencies or implausible values, the processing unit 102 interprets the inconsistency as a risk-elevating condition warranting conservative enforcement. The fail-safe behavior ensures that uncertainty in status information causes the supervisory terminal device 10 to adopt more restrictive safety postures rather than permissive postures.

[0218] Referring to FIG. 5, a method 400 for monitoring an autonomous device is illustrated. The method 400 is performed by the supervisory terminal device 10 physically coupled to the autonomous device 20. The method 400 combines identity verification through quantum-resistant encryption with position validation through coordinate comparison to detect inaccurate or falsified location information reported by the autonomous device 20.

[0219] The method 400 begins with a step 402 of storing an identification code ID in the storage unit 100 of the supervisory terminal device 10 physically coupled to the autonomous device 20. The step 402 establishes a hardware-rooted identity anchor within the supervisory terminal device 10 that is independent of software executing on the autonomous device 20. The identification code ID stored in the step 402 includes a globally unique identifier anchored to hardware-bound material of the supervisory terminal device 10, a protected attestation key, and integrity measurements that bind firmware and interface state to the identity. The step 402 enables external parties to authenticate the supervisory terminal device 10 rather than authenticating an operating system or autonomy stack of the autonomous device 20.

[0220] The method 400 proceeds to a step 404 of encrypting the identification code ID and other robot-related information (for example, but not limited to, using quantum-resistant cryptography) via the encryption unit 106 of the supervisory terminal device 10. The step 404 applies post-quantum cryptographic algorithms to the identification code ID and other information to provide protection against decryption by quantum computing techniques. The encryption unit 106 supports NIST post-quantum cryptographic standards FIPS-203 / 204 / 205 for the quantum-resistant cryptography applied in the step 404. The encryption unit 106 receives the identification code ID and other information from the processing unit 102 and applies quantum-resistant cryptographic algorithms to produce an encrypted identification code ID and other information.

[0221] With continued reference to FIG. 5, the method 400 proceeds to a step 406 of transmitting the encrypted identification code ID and other information to confirm an identity of the autonomous device 20. The step 406 involves the communication unit 104 transmitting the encrypted identification code ID and other information to the remote supervisory device 30. The remote supervisory device 30 receives the encrypted identification code ID and verifies the identity of the autonomous device 20 based on the received encrypted identification code ID. The step 406 establishes a verified identity for the autonomous device 20 that is protected by quantum-resistant cryptography.

[0222] The method 400 continues to a step 408 of receiving an RF signal to locate position coordinates of the autonomous device 20. The step 408 is performed by the communication unit 104 of the supervisory terminal device 10. The communication unit 104 receives RF signals from satellites through an antenna module to determine position coordinates of the autonomous device 20 via GPS positioning or other satellite-based positioning systems. The communication unit 104 converts the received RF signals into position coordinate data including latitude and longitude values. The position coordinates located via the RF signal in the step 408 represent an independent determination of the location of the autonomous device 20 that does not rely on location information reported by the autonomous device 20.

[0223] As further shown in FIG. 5, the method 400 advances to a step 410 of receiving coordinates from the autonomous device 20. The step 410 involves the supervisory terminal device 10 receiving location information reported by the autonomous device 20 through an interface between the supervisory terminal device 10 and the autonomous device 20. The coordinates received from the autonomous device 20 in the step 410 are part of status information that the autonomous device 20 transmits to the supervisory terminal device 10. The status detection unit 112 receives the coordinates from the autonomous device 20 and outputs the coordinates to the processing unit 102. The coordinates received from the autonomous device 20 represent location information that the autonomous device 20 claims to be accurate based on positioning systems or sensors of the autonomous device 20.

[0224] The method 400 concludes with a step 412 of comparing the position coordinates located via the RF signal with the coordinates received from the autonomous device 20 to determine whether the coordinates received from the autonomous device 20 are inaccurate or falsified. The step 412 is performed by the processing unit 102 of the supervisory terminal device 10. The processing unit 102 compares the position coordinates determined independently via satellite positioning in the step 408 with the coordinates reported by the autonomous device 20 in the step 410. The comparison in the step 412 evaluates whether the coordinates received from the autonomous device 20 are consistent with the independently determined position coordinates within acceptable tolerance thresholds.

[0225] With continued reference to FIG. 5, the comparison performed in the step 412 detects various indicators of inaccurate or falsified coordinates. The processing unit 102 determines that the coordinates received from the autonomous device 20 are inaccurate when the coordinates differ from the position coordinates located via the RF signal by more than an acceptable error margin. The processing unit 102 determines that the coordinates received from the autonomous device 20 are falsified when the coordinates show that the autonomous device 20 exhibits unreasonably long-distance shifts or movements over a limited period of time that are inconsistent with physical capabilities of the autonomous device 20. The processing unit 102 also determines that the coordinates received from the autonomous device 20 are falsified when the coordinates indicate a location that is physically impossible given previous position information and elapsed time.

[0226] In a method 400 for monitoring an autonomous device 20, receiving an RF signal to locate position coordinates of the autonomous device 20 is performed as the step 408 following the step 406. Receiving coordinates from the autonomous device 20 is performed as the step 410 following the step 408. Comparing the position coordinates located via the RF signal with the coordinates received from the autonomous device 20 to determine whether the coordinates received from the autonomous device 20 are inaccurate or falsified is performed as the step 412 following the step 410. The sequential performance of the step 408, the step 410, and the step 412 provides position validation that detects attempts by the autonomous device 20 to report false location information.

[0227] The method 400 may be performed repeatedly at intervals to provide ongoing position validation for the autonomous device 20. The supervisory terminal device 10 performs the step 408, the step 410, and the step 412 periodically to continuously validate location information reported by the autonomous device 20. When the step 412 determines that the coordinates received from the autonomous device 20 are inaccurate or falsified, the supervisory terminal device 10 transmits information indicating the discrepancy to the remote supervisory device 30. The supervisory terminal device 10 also treats the detection of inaccurate or falsified coordinates as a risk-elevating condition that causes the processing unit 102 to transition the autonomous device 20 into a more restrictive safety state.

[0228] The method 400 integrates position validation with movement information sensed by the sensing unit 114 of the supervisory terminal device 10. The sensing unit 114 includes MEMS sensors that measure acceleration, angular velocity, and direction changes of the supervisory terminal device 10 and the autonomous device 20. The processing unit 102 includes a self-localization module that computes a trajectory of the autonomous device 20 based on the movement information from the sensing unit 114. The processing unit 102 integrates the position coordinates located via the RF signal in the step 408 with position information computed from the movement information sensed by the sensing unit 114. The integrated position information provides additional validation of the coordinates received from the autonomous device 20 in the step 410, allowing the step 412 to detect discrepancies that may not be apparent from satellite positioning alone.

[0229] A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the disclosure. Accordingly, other implementations are within the scope of the following claims.

Claims

1.A supervisory terminal device, configured to be physically coupled to an autonomous device, the supervisory terminal device comprising:a storage unit, configured to store an identification code;a processing unit, electrically connected with the storage unit;a communication unit, electrically connected with the processing unit; andan encryption unit, electrically connected with the communication unit,wherein the processing unit is configured to output the identification code for confirming an identity of the autonomous device through the communication unit, and the encryption unit is configured to encrypt at least one of the identification code and other information transmitted by the supervisory terminal device before outputting of at least one of the identification code and the other information.2.The supervisory terminal device of claim 1, further comprising:a tamper detection unit, electrically connected with the communication unit, and configured to output an alarm signal when the supervisory terminal device is separated from the autonomous device.3.The supervisory terminal device of claim 1, further comprising:a blocking unit, electrically connected with the processing unit,wherein the communication unit is configured to receive an RF signal and to convert the RF signal into a base-band control signal to the processing unit, andwhen the base-band control signal indicates to stop the autonomous device, the blocking unit is configured to output a blocking signal to stop the autonomous device.4.The supervisory terminal device of claim 1, further comprising:a status detection unit, electrically connected with the processing unit, and configured to detect status information of the autonomous device.5.The supervisory terminal device of claim 4, wherein the processing unit is configured to determine whether the status information is true or to determine whether the autonomous device is under an abnormal condition based on the status information.6.The supervisory terminal device of claim 1, further comprising:a sensing unit, electrically connected with the processing unit, and configured to sense movement information and output the movement information to the processing unit,wherein the processing unit is configured to compute a movement of the supervisory terminal device or a movement of the autonomous device.7.The supervisory terminal device of claim 1, further comprising:a frequency scanning unit, electrically connected with the communication unit, configured to detect a frequency band of signals output by the autonomous device.8.The supervisory terminal device of claim 1, further comprising:a self-detection unit, electrically connected with the processing unit, and configured to detect whether each unit of the supervisory terminal device is normal.9.The supervisory terminal device of claim 1, wherein the processing unit comprises an artificial intelligence edge computing module configured to perform real-time behavioral risk assessment of the autonomous device by determining whether status information transmitted by the autonomous device is true and reasonable based on inputs from multiple sources.10.The supervisory terminal device of any one of claims 1, wherein the storage unit is included within the processing unit or the encryption unit.11.The supervisory terminal device of any one of claims 1, wherein the encryption unit is configured to encrypt the identification code and the other information using quantum-resistant cryptography.12.A control system, comprising:a supervisory terminal device, physically coupled to an autonomous device, the supervisory terminal device comprising a storage unit, configured to store an identification code, a processing unit, electrically connected with the storage unit, a communication unit, electrically connected with the processing unit, and an encryption unit, electrically connected with the communication unit; anda remote supervisory device, configured to communicate with the supervisory terminal device;wherein the processing unit is configured to output the identification code to confirm an identity of the autonomous device through the communication unit to the remote supervisory device, and the encryption unit is configured to encrypt the identification code and other information transmitted by the supervisory terminal device to the remote supervisory device before outputting of the identification code and the other information.13.The control system of claim 12, wherein the communication unit of the supervisory terminal device is configured to receive a control signal from the remote supervisory device.14.The control system of claim 12, wherein the supervisory terminal device further comprises:a status detection unit, electrically connected with the processing unit, and configured to detect status information of the autonomous device,wherein the processing unit is configured to determine whether the status information is true or to determine whether the autonomous device is under an abnormal condition based on the status information.15.The control system of claim 12, wherein the encryption unit is configured to encrypt the identification code and the other information using quantum-resistant cryptography.16.The control system of claim 12, wherein the supervisory terminal device further comprises:a blocking unit, electrically connected with the processing unit, and configured to output a blocking signal to stop the autonomous device when the processing unit determines that the autonomous device is under an abnormal condition.17.A method for monitoring an autonomous device, the method comprising:storing an identification code in a storage unit of a supervisory terminal device physically coupled to the autonomous device;encrypting the identification code and other information transmitted by the supervisory terminal device via an encryption unit of the supervisory terminal device; andtransmitting the encrypted identification code and the other information, by the supervisory terminal device, to confirm an identity of the autonomous device.18.The method of claim 17, wherein encrypting the identification code and the other information comprises using quantum-resistant cryptography.19.The method of claim 17, further comprising:detecting status information of the autonomous device; anddetermining whether the status information is true or whether the autonomous device is under a normal condition based on the status information.20.The method of claim 19, further comprising:performing real-time edge computing to determine whether the autonomous device is under an abnormal condition.21.The method of claim 19, further comprising:outputting a blocking signal to stop the autonomous device when the supervisory terminal device determines that the autonomous device is under an abnormal condition.

Images