Safety control method, system and storage medium for unmanned device

Abstract

This application relates to a security control method, system, and storage medium for unmanned equipment. The security control method for unmanned equipment includes: responding to a received target execution instruction by performing semantic compliance verification on the target execution instruction and obtaining a verification result; if the verification result indicates that the target execution instruction is semantically compliant, real-time hardware behavior characteristics of the unmanned equipment's central processing unit (CPU) during the processing of the target execution instruction are collected; based on the instruction type of the target execution instruction and the execution state of the unmanned equipment, hardware behavior baseline characteristics corresponding to the instruction type and execution state are read from a preset baseline database; the deviation of the real-time hardware behavior characteristics from the hardware behavior baseline characteristics is determined; and based on the deviation, a security strategy for the unmanned equipment is determined. This constructs a dual security verification mechanism of semantic verification and hardware behavior verification, forming cross-layer security protection for the unmanned equipment, thereby improving the comprehensiveness of security detection for the unmanned equipment.

Description

Technical Field

[0001] This application relates to the field of unmanned aerial vehicles (UAVs), and in particular to safety control methods, systems and storage media for unmanned equipment. Background Technology

[0002] Currently, drones are widely used in infrastructure inspection, logistics delivery, emergency rescue, and air traffic management. However, the safety issues of drone operation have also become increasingly prominent. For example, attacks on drones can manipulate them to perform dangerous maneuvers such as deviating from their intended flight paths, entering no-fly zones, and exceeding flight limits, which can lead to property damage, destruction of critical infrastructure, and even personal injury or death.

[0003] In response, related technologies for drone security protection mainly revolve around dimensions such as communication link security, flight command authentication, semantic verification, and redundancy design. For example, at the communication link security level, technologies such as Transport Layer Security (TLS) or Advanced Encryption Standard (AES) are used to encrypt the transmission of communication data between the ground control station and the drone. At the flight command authentication level, cryptographic mechanisms such as digital signatures and Message Authentication Codes (MACs) are used to verify the authenticity and integrity of the command source. At the command semantic compliance verification level, logical and security checks are performed on flight commands based on preset security policies (such as geofencing, airspace restrictions, speed and acceleration thresholds, etc.). At the system redundancy and fault-tolerant design level, methods such as multi-sensor information fusion and dual-redundant flight control systems are used to improve the system's reliability and robustness. These protection mechanisms typically assume that the drone itself is trustworthy, making it difficult to identify and protect against attacks targeting the drone's underlying hardware and software execution processes. For example, it is difficult to identify firmware layer attacks, code injection attacks, hardware interface attacks, and code reuse attacks.

[0004] Therefore, the relevant technologies still have the problem of insufficient comprehensiveness in safety detection for the safety protection of unmanned equipment, which needs to be addressed. Summary of the Invention

[0005] This embodiment provides a safety control method, system, and storage medium for unmanned equipment to address the problem that the safety protection of unmanned equipment still suffers from insufficient comprehensiveness of safety detection in related technologies.

[0006] Firstly, this embodiment provides a safety control method for unmanned equipment, including:

[0007] In response to receiving a target execution instruction, semantic compliance verification is performed on the target execution instruction to obtain a verification result;

[0008] If the verification result indicates that the target execution instruction is semantically compliant, real-time hardware behavior characteristics of the unmanned device's central processing unit are collected when it processes the target execution instruction.

[0009] Based on the instruction type of the target execution instruction and the execution state of the unmanned device, read the hardware behavior baseline features corresponding to the instruction type and the execution state from the preset baseline database;

[0010] Determine the deviation of the real-time characteristics of the hardware behavior from the baseline characteristics of the hardware behavior, and determine a safety strategy for the unmanned device based on the deviation.

[0011] In some embodiments, when the verification result indicates that the target execution instruction is semantically compliant, real-time hardware behavior characteristics of the unmanned device's central processing unit (CPU) are collected when processing the target execution instruction, including:

[0012] Real-time detection of hardware events generated by the central processing unit when processing the target execution instructions;

[0013] Extract the real-time features of the hardware behavior from the hardware events.

[0014] In some embodiments, the process of building the baseline database includes:

[0015] The execution instructions of each instruction type are combined with each execution state of the unmanned device to obtain multiple test combinations;

[0016] In a test environment to verify safety, multiple hardware behavior sample features of the central processing unit of the unmanned device were collected under each of the test combinations.

[0017] Statistical processing is performed on the hardware behavior sample features of multiple test combinations to obtain the hardware behavior baseline features of each test combination.

[0018] In some embodiments, based on the instruction type of the target execution instruction and the execution state of the unmanned device, hardware behavior baseline features corresponding to the instruction type and the execution state are read from a preset baseline database, including:

[0019] Based on the current hardware status of the unmanned device and the current environmental status of the unmanned device, determine the target execution environment in which the unmanned device is currently located;

[0020] Read the hardware behavior baseline features corresponding to the instruction type and the execution state from the baseline database corresponding to the target execution environment; wherein different execution environments have a pre-established correspondence with different baseline databases.

[0021] In some embodiments, the method further includes:

[0022] If the real-time hardware behavior characteristics of the central processing unit during multiple processing of the target execution instructions meet the preset update conditions, the hardware behavior baseline characteristics in the baseline database are updated based on the real-time hardware behavior characteristics.

[0023] In some embodiments, determining the deviation of the real-time hardware behavior characteristics from the baseline hardware behavior characteristics, and determining a safety policy for the unmanned device based on the deviation, includes:

[0024] Determine the target deviation range to which the deviation belongs, and execute the security policy corresponding to the target deviation range; wherein, different deviation ranges are pre-established with corresponding security policies.

[0025] In some embodiments, when the target deviation range is a preset first deviation range, the safety strategy is to record the execution log of the target execution instruction and control the unmanned device to execute the target execution instruction;

[0026] When the target deviation range is a preset second deviation range, the safety strategy is to reduce the execution speed of the unmanned device and continuously collect real-time features of the hardware behavior to perform the deviation calculation.

[0027] When the target deviation range is a preset third deviation range, the safety strategy is: trigger a fault response; the value of the first deviation range is less than the value of the second deviation range; the value of the second deviation range is less than the value of the third deviation range.

[0028] Secondly, this embodiment provides a safety control system for unmanned equipment, including: an instruction verification module, a hardware behavior monitoring module, a baseline database, and a cross-validation arbitrator; wherein:

[0029] The instruction verification module is used to perform semantic compliance verification on the target execution instruction in response to receiving the target execution instruction, and obtain the verification result;

[0030] The hardware behavior monitoring module is used to collect real-time hardware behavior characteristics of the central processing unit of the unmanned device when it processes the target execution instruction, provided that the verification result indicates that the target execution instruction is semantically compliant.

[0031] The baseline database is used to store the hardware behavior baseline characteristics corresponding to different combinations of instruction types and different execution states.

[0032] The cross-validation arbitrator is used to read hardware behavior baseline features corresponding to the instruction type and execution state from the baseline database based on the instruction type of the target execution instruction and the execution state of the unmanned device; determine the deviation of the real-time hardware behavior features from the hardware behavior baseline features; and determine a security policy for the unmanned device based on the deviation.

[0033] In some embodiments, the hardware behavior monitoring module is configured with a double buffering mechanism to asynchronously execute the task of collecting real-time features of the hardware behavior.

[0034] Thirdly, this embodiment provides a storage medium on which a computer program is stored, which, when executed by a processor, implements the security control method described in the first aspect above.

[0035] Compared with related technologies, this embodiment provides a security control method, system, and storage medium for unmanned equipment. The security control method for unmanned equipment, in response to receiving a target execution instruction, performs semantic compliance verification on the target execution instruction and obtains a verification result. If the verification result indicates that the target execution instruction is semantically compliant, it collects real-time hardware behavior characteristics of the unmanned equipment's central processing unit (CPU) when processing the target execution instruction. Based on the instruction type of the target execution instruction and the execution state of the unmanned equipment, it reads the hardware behavior baseline characteristics corresponding to the instruction type and execution state from a preset baseline database. It determines the deviation of the real-time hardware behavior characteristics from the hardware behavior baseline characteristics and determines a security strategy for the unmanned equipment based on the deviation. This constructs a dual security verification mechanism of semantic verification and hardware behavior verification, forming cross-layer security protection for the unmanned equipment, thereby improving the comprehensiveness of security detection for the unmanned equipment.

[0036] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0037] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0038] Figure 1 This is a hardware structure block diagram of the terminal of the safety control method for unmanned equipment according to an embodiment of this application;

[0039] Figure 2 This is a flowchart of a safety control method for unmanned equipment according to an embodiment of this application;

[0040] Figure 3 This is a schematic diagram of the structure of a safety control system for an unmanned device according to an embodiment of this application;

[0041] Figure 4 This is a data flow diagram of a safety control system in a drone application scenario;

[0042] Figure 5 This is a flowchart of a flight safety control method for a drone according to some embodiments of this application. Detailed Implementation

[0043] To better understand the purpose, technical solution, and advantages of this application, the application is described and illustrated below in conjunction with the accompanying drawings and embodiments.

[0044] Unless otherwise defined, the technical or scientific terms used in this application shall have the general meaning understood by one of ordinary skill in the art to which this application pertains. Words such as “a,” “an,” “an,” “the,” “the,” and “these” used in this application do not indicate quantitative limitation and may be singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that comprises a series of steps or modules (units) is not limited to the listed steps or modules (units) but may include steps or modules (units) not listed, or may include other steps or modules (units) inherent to these processes, methods, products, or devices. Words such as “connected,” “linked,” and “coupled” used in this application are not limited to physical or mechanical connections but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. Normally, the character " / " indicates that the objects before and after it are in an "or" relationship. The terms "first," "second," "third," etc., used in this application are merely to distinguish similar objects and do not represent a specific order of objects.

[0045] First, it should be noted that the safety control method for unmanned equipment provided in this embodiment can be applied to scenarios such as flight safety protection for drones, operational safety protection for industrial robots, and infrastructure control systems. For ease of description, the following explanation will primarily focus on flight safety protection for drones.

[0046] Control commands are digital command sets sent by operators or autonomous control systems to unmanned equipment (such as drones) to precisely control their execution state and actions. Control command security and execution integrity ensure that the transmission, reception, parsing, and execution of control commands during drone operation are free from interference, tampering, or hijacking, and that the commands are executed accurately and reliably according to the operator's or autonomous system's intentions. Currently, in the field of drone security protection, drone security technology systems mainly revolve around communication link security, flight command authentication, semantic verification, and redundancy design. These protection mechanisms typically assume the drone itself is trustworthy, making it difficult to identify and protect against attacks targeting the drone's underlying hardware and software execution processes. For example, it is difficult to identify firmware layer attacks, code attacks, hardware interface attacks, and code reuse attacks.

[0047] In addition, in the field of software security, Control Flow Integrity (CFI) technology is used to defend against code reuse attacks by verifying the legitimacy of the program execution path. Specifically, CFI solutions can include shadow stacks, binary instrumentation, and tagged pointers. Shadow stacks are hardware-assisted return address protection based on technologies such as Intel CET (Intel Control Flow Enforcement) and ARM Pointer Authentication. Binary instrumentation inserts control flow checking code during compilation or runtime.

[0048] After careful analysis, the inventors discovered that the aforementioned CFI technology in the field of software security still has the following limitations: it requires source code recompilation or binary rewriting, making it difficult to apply to closed-source firmware; it is mainly designed for computing platforms and does not consider the strict latency requirements of real-time systems; it lacks association with application layer semantics, making it difficult to detect attacks that comply with code-level execution paths; and it is difficult to cover attacks at the firmware and hardware layers.

[0049] Alternatively, hardware-assisted security monitoring solutions typically utilize processor performance monitoring units (PMUs) to detect anomalous software and behaviors. For example, branch prediction and cache access patterns can be used to identify anomalous software characteristics; instruction execution statistics can be used to detect ransomware; and embedded trace macrocells (ETMs) can be used for hardware debugging and performance analysis.

[0050] In response, the inventors discovered that current hardware-assisted safety monitoring technologies are often used for offline analysis or post-event auditing on general-purpose computer platforms, and are not optimized for drone flight safety scenarios. For example, drone flight control systems typically require millisecond-level response times, while the aforementioned hardware-assisted safety monitoring technologies have excessive computational overhead and slow response times, making it difficult to meet the real-time requirements of the drone industry. Furthermore, the computing power and storage space of drone systems-on-chips (SoCs) are relatively limited, which is also incompatible with the hardware environment required by the aforementioned hardware-assisted safety monitoring technologies. Moreover, these hardware-assisted safety monitoring technologies also lack a mechanism to correlate and verify high-level instruction semantics with low-level hardware behavior.

[0051] In the field of avionics, software development standards such as "DO-178C" ensure system security through rigorous development processes and verification testing, while the "ARINC 653" standard isolates tasks of different safety levels through time and space partitioning. However, these standards mainly focus on quality assurance during the development phase and lack the ability to dynamically monitor and detect anomalies during UAV operation.

[0052] To address this, this embodiment provides a safety control method for unmanned equipment. The method provided in this embodiment can be executed on a terminal, computer, or similar computing device. For example, it can run on a terminal. Figure 1 This is a hardware structure block diagram of the terminal of the safety control method for unmanned equipment in this embodiment. For example... Figure 1 As shown, a terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 and a memory 104 for storing data are also included. The processor 102 may be, but is not limited to, a microprocessor (MCU) or a programmable logic device (FPGA). The terminal may also include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that… Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the terminal described above. For example, the terminal may also include components that are larger than... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown are illustrated.

[0053] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the safety control method for unmanned equipment in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the aforementioned method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0054] The transmission device 106 is used to receive or send data via a network. This network includes a wireless network provided by the terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 can be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0055] This embodiment provides a safety control method for unmanned equipment. Figure 2 This is a flowchart of the safety control method for unmanned equipment in this embodiment, such as... Figure 2 As shown, the process includes the following steps:

[0056] Step S210: In response to receiving the target execution instruction, perform semantic compliance verification on the target execution instruction and obtain the verification result.

[0057] Specifically, the target execution command can be a structured command generated by the operator, control station, or autonomous mission system, transmitted to the unmanned device via a wireless data link, and understood and executed by its control system. The purpose of sending the target execution command is to control the execution state and mission actions of the unmanned device. For example, the target execution command can be a flight command that controls the UAV's flight state and mission actions, instructing the UAV to fly at a set attitude and speed, take off to a certain waypoint, and activate the camera for fixed-distance shooting, etc.

[0058] Semantic compliance verification of target execution instructions can be a security check performed after receiving the instruction but before its execution. Specifically, semantic compliance verification involves a deep analysis and verification of whether the intent and content of the instruction are safe, valid, and executable in the current context. Taking drones as an example, semantic compliance verification can include verification of geofence constraints, verification of drone flight speed or acceleration limits, verification of drone flight altitude limits, detection of no-fly zones, verification of the rationality of the sequence of target execution instructions, and state machine consistency verification. State machine consistency verification can verify the safety and rationality of the target execution instructions based on the drone's current flight state. By performing semantic compliance verification on the target execution instructions, a verification result indicating whether the semantics of the target execution instructions are compliant can be obtained. Furthermore, the instruction type to which the target execution instructions belong can also be obtained, for example, it could be GOTO, HOVER, LAND, TAKEOFF, or ROTATE.

[0059] Specifically, after receiving and parsing the target execution command, semantic compliance verification of the target execution command can be performed based on various constructed rule engines or validators. In particular, in this embodiment, a high-level command verification module can be constructed. This module contains different semantic compliance verification rules and logic. Inputting the target execution command into this module allows for the performance of semantic compliance verifications such as geofence constraints, speed / acceleration limits, altitude limits, no-fly zone detection, command sequence rationality, and state machine consistency, yielding the aforementioned verification results.

[0060] Step S220: If the verification result indicates that the target execution instruction is semantically compliant, collect real-time hardware behavior characteristics of the unmanned device's central processing unit when processing the target execution instruction.

[0061] After the target execution instructions pass semantic compliance verification, the collection of hardware behavioral characteristics generated by the central processing unit (CPU) during the processing of the target execution instructions can be initiated, thereby obtaining the aforementioned real-time hardware behavioral characteristics. Specifically, these real-time hardware behavioral characteristics can be a set of quantifiable low-level performance events and statistical metrics that characterize the CPU's microarchitectural state changes during the processing of the target execution instructions. These real-time hardware behavioral characteristics reflect the micro-interaction patterns between the execution of the target execution instructions and the CPU hardware (including pipelines, caches, branch predictors, etc.), constituting the physical fingerprint of the target execution instructions running on a specific hardware platform.

[0062] For example, the real-time hardware behavior characteristics may include branch prediction-related characteristics, cache access-related characteristics, translation lookaside buffer (TLB)-related characteristics, or memory access-related characteristics, etc. Among them, branch prediction refers to a hardware optimization technique adopted by the CPU to overcome control hazards. When the CPU encounters a branch instruction (such as "if-else", loop, function call), it predicts the execution path in advance and obtains and executes the path in advance based on the prediction result.

[0063] For example, the hardware performance counter (HPC) within the drone's SoC or a dedicated monitoring circuit can be used to start real-time acquisition of the hardware behavior characteristics of the CPU during the processing of the target execution instruction after the target execution instruction passes semantic compliance verification, until the target execution instruction is completed or the execution times out, thereby obtaining the real-time characteristics of the hardware behavior.

[0064] Step S230: Based on the instruction type of the target execution instruction and the execution state of the unmanned device, read the hardware behavior baseline features corresponding to the instruction type and execution state from the preset baseline database.

[0065] The execution state of an unmanned device (UAV) represents the operation it is currently performing. For example, it could be the core control mode currently being executed by the UAV flight control system, describing the operation the UAV is currently performing. The execution state can be managed and switched by the UAV's control software based on execution commands, sensor data, and internal logic. This baseline database can be pre-built. Specifically, it can be pre-established in a controlled testing environment through a combination of offline training and online adaptive updates. This baseline database stores the standard hardware behavior corresponding to each type of execution command conforming to the execution specifications under different execution states. The data stored in the baseline database can be structured as a statistical distribution of multi-dimensional feature vectors of hardware behavior, such as including mean, standard deviation, and confidence intervals. Hardware behavior baseline features can specifically be quantitative reference features extracted from historical hardware events collected by the CPU under normal, controlled, and anomaly-free conditions using statistical modeling methods. These hardware behavior baseline features describe the observable standard behavior patterns and reasonable fluctuation ranges of the CPU's hardware behavior under baseline conditions, serving as a benchmark for future state comparisons and anomaly detection. The feature dimensions of the baseline hardware behavior features are consistent with those of the aforementioned real-time hardware behavior features. For example, these dimensions may include, but are not limited to, the following:

[0066] Branch prediction dimensions: branch prediction failure rate, number of indirect jumps, and return address stack (RAS) hit rate;

[0067] Cache access dimensions: L1 instruction cache miss rate, L1 data cache miss rate, L2 cache miss rate, and cache refresh count; where L1 is the first-level cache and L2 is the second-level cache.

[0068] TLB dimensions: Instruction TLB miss rate, Data TLB miss rate;

[0069] Instruction statistics dimensions: total number of instructions, load / store instruction ratio, floating-point instruction ratio, and jump instruction density;

[0070] Execution efficiency dimensions: Instructions Per Cycle (IPC), total execution cycles, pipeline pause cycles;

[0071] Memory access pattern dimensions: memory access sequence entropy, page access dispersion;

[0072] Privilege level switching dimensions: number of system calls and number of exception / interrupt triggers.

[0073] In particular, different baseline databases can be established for different execution environments (such as the flight environment of drones), such as high-temperature environments (temperature greater than 35°C) and high-altitude environments (altitude greater than 2000 meters).

[0074] The command type of the target execution instruction, along with the current execution state of the unmanned device, can be used as an index to retrieve the corresponding hardware behavior baseline features from the baseline database. For example, for a drone, the command type and execution state can be combined as follows: command type "GOTO," execution state "cruise"; command type "HOVER," execution state "hover"; command type "LAND," execution state "landing preparation." Different combinations of execution states and command types will correspond to different hardware behavior baseline features in the baseline database. Therefore, based on the combination of command type and execution state, the corresponding hardware behavior baseline features can be retrieved from the baseline database.

[0075] Step S240: Determine the deviation of the real-time hardware behavior characteristics from the hardware behavior baseline characteristics, and determine the safety strategy for the unmanned equipment based on the deviation.

[0076] According to step S230 above, after extracting the hardware behavior baseline features, the real-time hardware behavior features obtained in step S220 can be compared with the hardware behavior baseline features. Specifically, the deviation of the real-time hardware behavior features from the hardware behavior baseline features can be calculated based on weighted Euclidean distance, cosine similarity, Mahalanobis distance, etc.

[0077] For example, the deviation can be calculated using a weighted Euclidean distance. :

[0078] ;

[0079] Among them, f i For the real-time hardware behavior feature of the i-th dimension, μ i For the baseline feature of hardware behavior in the i-th dimension, w i Let w be the weight of the feature in the i-th dimension. i Adaptive adjustments can be made based on the discriminative power and stability of features in each dimension.

[0080] The aforementioned security strategy can be a series of pre-defined, tiered, condition-triggered automated response rules for unmanned equipment during operation to address internal faults, external anomalies, or environmental threats. Understandably, the deviation quantifies the degree to which hardware events / behaviors generated by the CPU during the processing of target instructions in the current execution state of the unmanned equipment deviate from normal hardware events / behaviors. Therefore, the security strategy for the unmanned equipment can be determined based on the magnitude of this deviation. For example, a higher deviation indicates a higher probability of execution anomalies, requiring a higher level of security control.

[0081] Compared to related technologies, security mechanisms for drones struggle to identify firmware layer attacks, code injection attacks, hardware interface attacks, and code reuse attacks, resulting in insufficient comprehensiveness in security detection. This embodiment employs dual verification—semantic verification and hardware behavior verification—to form cross-layer security protection, making it difficult for attacks to bypass protection at a single level. Furthermore, it can identify covert attacks where the instructions themselves are semantically normal but the underlying execution path has been tampered with, such as return-oriented programming (ROP) attacks and firmware backdoors. In addition, this embodiment can be implemented based on the standard hardware features (PMU / ETM) of existing SoCs, eliminating the need for custom chips and thus making it suitable for resource-constrained unmanned equipment platforms.

[0082] Therefore, in this embodiment, through the aforementioned steps S210 to S240, in response to receiving a target execution instruction, semantic compliance verification is performed on the target execution instruction to obtain a verification result. If the verification result indicates that the target execution instruction is semantically compliant, real-time hardware behavior characteristics of the unmanned device's central processing unit (CPU) are collected during the processing of the target execution instruction. Based on the instruction type of the target execution instruction and the execution state of the unmanned device, baseline hardware behavior characteristics corresponding to the instruction type and execution state are read from a preset baseline database. The deviation of the real-time hardware behavior characteristics from the baseline hardware behavior characteristics is determined, and a security strategy for the unmanned device is determined based on the deviation. This constructs a dual security verification mechanism of semantic verification and hardware behavior verification, forming cross-layer security protection for the unmanned device, thereby improving the comprehensiveness of security detection for the unmanned device.

[0083] In one embodiment, based on step S220 above, if the verification result indicates that the target execution instruction is semantically compliant, real-time hardware behavior features of the unmanned device's central processing unit (CPU) when processing the target execution instruction are collected in real time. Specifically, this may include: real-time detection of hardware events generated by the CPU when processing the target execution instruction; and extraction of real-time hardware behavior features from the hardware events.

[0084] These hardware events can be atomic operational states or activity signals directly defined and generated by the processor microarchitecture. Specifically, CPU hardware events can be read through performance monitoring unit (PMU) counting, precise event sampling (PEBS), or pre-configured monitoring logic. Then, by performing statistical and feature processing on the read hardware events, real-time characteristics of hardware behavior can be extracted.

[0085] In this embodiment, by using non-intrusive monitoring sources such as hardware performance counters to read hardware events, the impact on the real-time performance of unmanned equipment can be reduced.

[0086] In another embodiment, the process of building the baseline database may specifically include:

[0087] The execution instructions of each instruction type are combined with each execution state of the unmanned device to obtain multiple test combinations. In a test environment for verifying safety, multiple hardware behavior sample features of the central processing unit of the unmanned device are collected under each test combination. The multiple hardware behavior sample features under each test combination are statistically processed to obtain the hardware behavior baseline features under each test combination.

[0088] For example, for drones, each type of flight command ("GOTO", "HOVER", "LAND", "TAKEOFF", "ROTATE", etc.) can be combined with different flight states of the drone (hovering, cruising, sharp turn, ascent, descent, etc.) to obtain several test combinations. For instance, such test combinations could take the following forms: command type "GOTO", execution state is cruising; command type "HOVER", execution state is hovering; command type "LAND", execution state is landing preparation.

[0089] In a closed testing environment, using verified and safe flight control software and firmware, at least N valid hardware behavior sample features (exemplarily, N can be greater than or equal to 100) can be collected for each of the above test combinations. Then, outlier removal can be performed on the multiple hardware behavior sample features under each test combination. Specifically, statistical methods such as the 3σ criterion and box plots can be used to remove outlier sample features. Feature distribution modeling is then performed on the hardware behavior sample features with outliers removed. Specifically, the mean μ and standard deviation σ of each hardware behavior sample feature are calculated, and a confidence interval is established (e.g., μ+3σ), or a fitted probability distribution model (e.g., Gaussian distribution, Gaussian mixture model, etc.) is established. Then, based on the results of feature distribution modeling, the confidence region boundaries of the baseline features of hardware behavior in different dimensions are determined, thereby forming the above-mentioned hardware behavior baseline features. This embodiment uses statistical methods to establish confidence intervals, which can improve the accuracy of hardware behavior baseline feature construction, thereby reducing the false alarm rate.

[0090] Furthermore, in one embodiment, based on the instruction type of the target execution instruction and the execution state of the unmanned device, hardware behavior baseline features corresponding to the instruction type and execution state are read from a preset baseline database. Specifically, this may include:

[0091] Based on the current hardware status of the unmanned equipment and the current environmental status of the unmanned equipment, the target execution environment in which the unmanned equipment is currently located is determined; the hardware behavior baseline features corresponding to the instruction type and execution status are read from the baseline database corresponding to the target execution environment; among them, different execution environments have a pre-established correspondence with different baseline databases.

[0092] In this embodiment, a baseline database can be specifically constructed for the execution environment. The execution environment is a combination of the current hardware state of the unmanned device and the physical environment it is in, such as the flight environment of a drone. Taking a drone as an example, the environmental state can include temperature and altitude; the hardware state can include load level and battery status. Temperature can include low temperature (below 0°C), normal temperature (between 0°C and 35°C), and high temperature (above 35°C); altitude can include low altitude (below 500 meters), medium altitude (between 500 meters and 2000 meters), and high altitude (above 2000 meters); load level can include no load, standard load, and full load; battery status can include fully charged (above 80%), normal (between 30% and 80%), and low battery (below 30%).

[0093] By using real-time inputs from various sensors installed on unmanned equipment, such as temperature sensors, barometers, battery management systems, and load sensors, the current target execution environment of the unmanned equipment can be identified, thereby selecting a baseline database corresponding to that target execution environment.

[0094] This embodiment can adapt to the environment and build a baseline database specifically for the execution environment, thereby improving the accuracy of anomaly detection.

[0095] In another embodiment, the above-described security control method may further include:

[0096] If the real-time hardware behavior characteristics of the central processing unit during multiple processing of target execution instructions meet the preset update conditions, the hardware behavior baseline characteristics in the baseline database are updated based on the real-time hardware behavior characteristics.

[0097] Specifically, the baseline database can be calibrated online during the execution of unmanned equipment to adapt to the effects of hardware aging, environmental changes, and other factors, thereby improving the accuracy of identifying abnormal events. Specifically, the update condition can be whether the real-time hardware behavior characteristics corresponding to a certain execution instruction deviate from the corresponding hardware behavior baseline characteristics for K consecutive times (e.g., K can be 10) within a preset slight deviation range, and whether the execution result of the target execution instruction is normal. If so, the baseline database can be updated based on the real-time hardware behavior characteristics of the target execution instruction. Specifically, a sliding window and exponentially weighted moving average (EWMA) algorithm can be used to update the baseline database.

[0098] μ_new=α×μ_old+(1-α)×f_recent;

[0099] Where μ_new represents the updated hardware behavior baseline features in the baseline database; μ_old represents the unupdated hardware behavior baseline features in the baseline database; f_recent represents the real-time hardware behavior features; and α is the smoothing coefficient, which can take values ​​of [0.9, 0.99] to ensure smooth and slow updates to the baseline database.

[0100] Specifically, safety constraints can be imposed on updates to the baseline database. For example, the gradient of the update can be limited, restricting the magnitude of a single update to no more than ±5%; alternatively, the behavioral patterns of the updated hardware behavior baseline features must be stably observed across L tasks (e.g., 5); and if the false positive rate rises above a certain threshold after the update, the system automatically reverts to the previous version of the hardware behavior baseline features. Furthermore, an anti-pollution mechanism can be set up, ensuring that updates to the baseline database only occur when all of the following conditions are met:

[0101] The Control and Vehicle Unit (CVU) has passed verification; there are no records of manual takeover; the flight log is normal; and the ground station has not issued any safety warnings.

[0102] In this embodiment, online calibration of the baseline database can adapt to hardware aging and environmental changes. Furthermore, by setting multiple security constraints, the baseline database can be prevented from being contaminated.

[0103] Furthermore, in one embodiment, the deviation of real-time hardware behavior characteristics from baseline hardware behavior characteristics is determined, and a safety policy for the unmanned device is determined based on the deviation, which may specifically include:

[0104] Determine the target deviation range to which the deviation belongs, and execute the security policy corresponding to the target deviation range; different deviation ranges are pre-established with corresponding security policies.

[0105] In this embodiment, a multi-level security policy determination mechanism can be constructed to achieve graded security responses based on the degree of deviation. Multiple different deviation ranges can be pre-set, and the corresponding security policy is determined based on the target deviation range to which the currently calculated deviation belongs. This allows for a flexible balance between security and availability in the protection of unmanned equipment.

[0106] Specifically, in one embodiment, when the target deviation range is a preset first deviation range, the safety strategy is to record the execution log of the target execution instruction and control the unmanned device to execute the target execution instruction; when the target deviation range is a preset second deviation range, the safety strategy is to reduce the execution speed of the unmanned device and continuously collect real-time hardware behavior features for deviation calculation; when the target deviation range is a preset third deviation range, the safety strategy is to trigger a fault response; the value of the first deviation range is less than the value of the second deviation range; the value of the second deviation range is less than the value of the third deviation range.

[0107] Here, deviation thresholds T1 and T2 can be set. When the deviation... When T1 < T1, the target deviation range is confirmed as the first deviation range, indicating a slight deviation; when T1 ≤ T1 When <T2, the target deviation range is confirmed to be the second deviation range, which belongs to the moderate deviation; when When the deviation is ≥T2, the target deviation range is confirmed to be the third deviation range, which is a serious deviation.

[0108] When the target deviation range is within the first deviation range, the execution log is recorded but execution is not blocked. If the deviation of the real-time hardware behavior characteristics corresponding to the target execution command falls within the first deviation range for N1 consecutive times (e.g., 5 times), the observation mode is entered, and the deviation threshold is lowered to avoid false alarms due to environmental fluctuations. When the target deviation range is within the second deviation range, the UAV's flight speed can be reduced to a safe speed (e.g., 50% of the maximum speed) and continuous monitoring is performed. If the target execution command is executed normally for M consecutive times (e.g., 3 times), the original flight speed is restored to enhance monitoring while maintaining flight capability. When the target deviation range is within the third deviation range, a fault response can be triggered. Based on the current flight stage and risk level, the following fault-safe strategies can be selected for execution: reject command execution and maintain the current state; trigger UAV hovering and wait for manual takeover; initiate an automatic return-to-home procedure; execute the nearest safe landing; or switch to a degraded safety mode (responding only to basic control commands).

[0109] Understandably, the aforementioned thresholds T1 and T2, as well as counters N1 and M, can all be calibration values ​​for security configuration at the ground station and can be sent to the UAV through an encrypted channel. This embodiment, based on a multi-level decision mechanism and configurable thresholds, can flexibly balance security and availability. In addition, through continuous anomaly counting and environmental classification matching, the false alarm rate can be effectively reduced.

[0110] Specifically, in some embodiments, in emergency situations (such as collision avoidance), a fast track can be set up for high-priority target execution instructions, performing only simplified verification or post-audit to ensure real-time response capabilities. For example, this fast track may include: performing a preset minimum semantic check; monitoring only a preset subset of core behavioral features; employing simplified distance calculations and increasing the decision threshold; executing instructions immediately, with full verification completed asynchronously in the background.

[0111] Furthermore, for drones, if the target deviation range is the third deviation range, the fail-safe strategy can be selected according to the flight phase as follows: if the flight phase is the takeoff phase, it can immediately land at the takeoff point; if the flight phase is the cruise phase, it can initiate automatic return; if the flight phase is the approach landing phase, it can continue the landing process but switch to degraded mode; if the flight phase is the hovering phase, it can remain hovering and wait for manual takeover.

[0112] Figure 3 This is a schematic diagram of the structure of a safety control system 30 for an unmanned device according to this embodiment, as shown below. Figure 3 As shown, the security control system 30 may specifically include: an instruction verification module 32, a hardware behavior monitoring module 34, a baseline database 36, and a cross-validation arbitrator 38; wherein:

[0113] The instruction verification module 32 is used to perform semantic compliance verification on the received target execution instruction and obtain the verification result. The hardware behavior monitoring module 34 is used to collect real-time hardware behavior characteristics of the unmanned device's central processing unit when processing the target execution instruction, provided that the verification result indicates that the target execution instruction is semantically compliant. The baseline database 36 is used to store the hardware behavior baseline characteristics corresponding to different combinations of instruction types and execution states. The cross-validation arbitrator 38 is used to read the hardware behavior baseline characteristics corresponding to the instruction type and execution state from the baseline database according to the instruction type of the target execution instruction and the execution state of the unmanned device; determine the deviation of the real-time hardware behavior characteristics from the hardware behavior baseline characteristics; and determine the security strategy for the unmanned device based on the deviation. Each module in this security control system 30 can be implemented as a hardware circuit, firmware program, embedded software, or a combination thereof. Specific examples in this embodiment can be found in the examples described in the above embodiments and optional implementations, and will not be repeated in this embodiment.

[0114] In one embodiment, the hardware behavior monitoring module 34 is configured with a double-buffering mechanism to asynchronously execute the acquisition task of real-time hardware behavior features. Specifically, the hardware behavior monitoring module 34 can asynchronously acquire and process hardware performance counter data in the background, avoiding blocking the main flight control process. Additionally, the cross-validation arbitrator 38 can employ incremental feature extraction and decision algorithms to avoid fully calculating all real-time hardware behavior features each time. For critical operations such as deviation calculation and threshold comparison, FPGA or dedicated accelerators can be used to keep the computation latency within 100 microseconds (the specific value depends on the SoC's clock speed and hardware configuration).

[0115] Furthermore, the verification process can be differentiated for execution commands based on different priorities. For example, a simplified verification process can be used for high-priority commands (such as collision avoidance and emergency landing), while a complete verification process can be performed for low-priority commands (such as aerial photography parameter adjustments). In addition, hardware behavior baseline characteristics of commonly used execution commands can be preloaded into the cache according to the flight mission to reduce the access latency of the baseline database.

[0116] The performance overhead estimate of the security control method described in the above embodiments, verified on a typical "ARM Cortex-A53@1.2GHz" hardware platform, is as follows:

[0117] Hardware event data acquisition accounts for less than 5% of CPU usage; real-time hardware behavior feature generation takes less than 10 microseconds per instruction; cross-validation arbitrator decision speed is less than 50 microseconds per instruction; overall latency increase is less than 200 microseconds (for a flight control system with a control cycle of 10 milliseconds, latency accounts for less than 2%).

[0118] Figure 4 This is a data flow diagram of a safety control system 30 in a drone application scenario, such as... Figure 4 As shown, the safety control system 30 receives a target flight command; this target flight command can be sent from the ground station to the UAV via a communication link. The command verification module 32 performs semantic compliance verification on the target flight command, combined with speed verification, to obtain a verification result. It then determines whether the verification result passes. If yes, the target flight command is added to the execution queue, and the hardware behavior monitoring module 34 is notified to collect hardware events and extract real-time hardware behavior features; otherwise, the target flight command is rejected. The cross-validation arbitrator 38 extracts baseline hardware behavior features from the baseline database 36 and compares them with the real-time hardware behavior features to obtain the deviation. It then determines whether the deviation falls within the high deviation range; if yes, a fail-safe policy is executed; otherwise, the target flight command continues to be executed.

[0119] Figure 5This is a flowchart of a flight safety control method for a drone according to some embodiments. This flight safety control method can be applied to the aforementioned safety control system 30, such as... Figure 5 As shown, the flight safety control method may include the following steps:

[0120] Step S501: Collect hardware events in real time through hardware performance counters; for example, these may include IPC events, branch prediction events, L1 / L2 cache events, and TLB events.

[0121] Step S502: Extract real-time hardware behavior features from hardware events; execute step S504; specifically, the data related to hardware events can be vectorized to obtain real-time hardware behavior features. For example, real-time hardware behavior features may include the following features f1 to f8, where: f1: branch prediction failure rate = 3.2%; f2: L1 cache miss rate = 1.8%; f3: L2 cache miss rate = 0.5%; f4: TLB miss rate = 0.3%; f5: instruction execution cycle = 1250; f6: jump instruction density = 8.5%; f7: load / store ratio = 0.42; f8: IPC = 1.85.

[0122] Step S503: Based on the command type and flight status, query the hardware behavior baseline features from the baseline database. For example, the queried hardware behavior baseline features are B_ref=[μ1±σ1,…,μ2±σ2]. Step S503 can be performed simultaneously with steps S501 and S502.

[0123] Step S504: Calculate the deviation of the real-time hardware behavior features from the hardware behavior baseline features; specifically, this can be calculated... .

[0124] Step S505, perform multi-level decision; wherein, the target deviation range is a preset first deviation range ( When T1 < T1, the safety strategy is as follows: record the execution log of the target execution command and control the unmanned equipment to execute the target execution command; when the target deviation range is within the preset second deviation range (T1 ≤ T1), ... When <T2), the safety strategy is to reduce the execution speed of the unmanned equipment and continuously collect real-time characteristics of hardware behavior for deviation calculation; when the target deviation range is the preset third deviation range ( When ≥T2), the safety policy is: trigger a fault response; the value of the first deviation interval is less than the value of the second deviation interval; the value of the second deviation interval is less than the value of the third deviation interval.

[0125] Step S506: Determine whether the deviation is less than the preset safety threshold; if yes, proceed to step S507; otherwise, proceed to step S509; the safety threshold can be T2 as described above.

[0126] Step S507 allows the execution of the target flight command.

[0127] Step S508: Execute the target flight command normally.

[0128] Step S509: Execute the fail-safe strategy. This strategy can correspond to different flight phases and includes measures such as preventative execution, hovering, automatic return to home, and safe landing.

[0129] It should be noted that the steps shown in the above process or in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions.

[0130] The above steps S501 to S509 form a cross-layer security protection through dual verification of semantic verification and hardware behavior verification, making it difficult for attack behaviors to bypass the protection at a single layer; in addition, it can also identify those covert attack behaviors where the instruction itself has no semantic abnormality but the underlying execution path is tampered with, such as return-oriented programming attacks, firmware backdoors, etc.; furthermore, this embodiment can be implemented based on the standard hardware characteristics of existing SoCs without the need for customized chips, thus making it applicable to resource-constrained unmanned equipment platforms.

[0131] Furthermore, in conjunction with the security control methods provided in the above embodiments, this embodiment can also provide a storage medium for implementation. This storage medium stores a computer program; when executed by a processor, the computer program implements any of the security control methods described in the above embodiments.

[0132] It should be understood that the specific embodiments described herein are merely illustrative of the application and not intended to limit it. All other embodiments derived by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0133] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0134] Obviously, the accompanying drawings are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar situations based on these drawings without any creative effort. Furthermore, it is understood that although the work done in this development process may be complex and lengthy, for those skilled in the art, certain design, manufacturing, or production modifications made based on the technical content disclosed in this application are merely conventional technical means and should not be considered as insufficient disclosure of this application.

[0135] The term "embodiment" in this application refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily imply the same embodiment, nor does it imply that it is mutually exclusive with or independent of other embodiments. It will be clearly or implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0136] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of patent protection. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the appended claims.

Claims

1. A safety control method for unmanned equipment, characterized in that, include: In response to receiving a target execution instruction, semantic compliance verification is performed on the target execution instruction to obtain a verification result; When the verification result indicates that the target execution instruction is semantically compliant, the real-time hardware behavior characteristics of the central processing unit of the unmanned device are collected in real time when it processes the target execution instruction; the real-time hardware behavior characteristics characterize the set of quantifiable low-level performance events and statistical indicators generated by the microarchitecture state changes of the central processing unit during the processing of the target execution instruction. Based on the instruction type of the target execution instruction and the execution state of the unmanned device, read the hardware behavior baseline features corresponding to the instruction type and the execution state from the preset baseline database; Determine the deviation of the real-time characteristics of the hardware behavior from the baseline characteristics of the hardware behavior, and determine a safety strategy for the unmanned device based on the deviation.

2. The safety control method according to claim 1, characterized in that, If the verification result indicates that the target execution instruction is semantically compliant, real-time hardware behavior characteristics of the unmanned device's central processing unit when processing the target execution instruction are collected, including: Real-time detection of hardware events generated by the central processing unit when processing the target execution instructions; Extract the real-time features of the hardware behavior from the hardware events.

3. The safety control method according to claim 1, characterized in that, The process of building the baseline database includes: The execution instructions of each instruction type are combined with each execution state of the unmanned device to obtain multiple test combinations; In a test environment to verify safety, multiple hardware behavior sample features of the central processing unit of the unmanned device were collected under each of the test combinations. Statistical processing is performed on the hardware behavior sample features of multiple test combinations to obtain the hardware behavior baseline features of each test combination.

4. The security control method according to claim 1 or claim 3, characterized in that, Based on the instruction type of the target execution instruction and the execution state of the unmanned device, hardware behavior baseline features corresponding to the instruction type and the execution state are read from a preset baseline database, including: Based on the current hardware status of the unmanned device and the current environmental status of the unmanned device, determine the target execution environment in which the unmanned device is currently located; Read the hardware behavior baseline features corresponding to the instruction type and the execution state from the baseline database corresponding to the target execution environment; wherein different execution environments have a pre-established correspondence with different baseline databases.

5. The security control method according to claim 1 or claim 3, characterized in that, The method further includes: If the real-time hardware behavior characteristics of the central processing unit during multiple processing of the target execution instructions meet the preset update conditions, the hardware behavior baseline characteristics in the baseline database are updated based on the real-time hardware behavior characteristics.

6. The safety control method according to claim 1, characterized in that, Determine the deviation of the real-time hardware behavior characteristics from the baseline hardware behavior characteristics, and determine a safety policy for the unmanned device based on the deviation, including: Determine the target deviation range to which the deviation belongs, and execute the security policy corresponding to the target deviation range; wherein, different deviation ranges are pre-established with corresponding security policies.

7. The safety control method according to claim 6, characterized in that: When the target deviation range is within a preset first deviation range, the safety strategy is to record the execution log of the target execution instruction and control the unmanned device to execute the target execution instruction; When the target deviation range is a preset second deviation range, the safety strategy is to reduce the execution speed of the unmanned device and continuously collect real-time features of the hardware behavior to perform the deviation calculation. When the target deviation range is a preset third deviation range, the safety strategy is: trigger a fault response; the value of the first deviation range is less than the value of the second deviation range; the value of the second deviation range is less than the value of the third deviation range.

8. A safety control system for unmanned equipment, characterized in that, include: The system comprises an instruction verification module, a hardware behavior monitoring module, a baseline database, and a cross-validation arbitrator; among which: The instruction verification module is used to perform semantic compliance verification on the target execution instruction in response to receiving the target execution instruction, and obtain the verification result; The hardware behavior monitoring module is used to collect real-time hardware behavior features of the central processing unit of the unmanned device when processing the target execution instruction, provided that the verification result indicates that the target execution instruction is semantically compliant. The real-time hardware behavior features characterize the set of quantifiable underlying performance events and statistical indicators generated by microarchitecture state changes during the processing of the target execution instruction by the central processing unit. The baseline database is used to store the hardware behavior baseline characteristics corresponding to different combinations of instruction types and different execution states. The cross-validation arbitrator is used to read hardware behavior baseline features corresponding to the instruction type and execution state from the baseline database based on the instruction type of the target execution instruction and the execution state of the unmanned device; determine the deviation of the real-time hardware behavior features from the hardware behavior baseline features; and determine a security policy for the unmanned device based on the deviation.

9. The safety control system according to claim 8, characterized in that, The hardware behavior monitoring module is configured with a double buffering mechanism to asynchronously execute the task of collecting real-time features of the hardware behavior.

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

Images