Formal Verification Method and System for Security Constraints in Deep Space Exploration Mission Planning

Abstract

This invention discloses a formal verification method and system for safety constraints in deep space exploration mission planning, belonging to the field of spacecraft autonomous mission planning and formal verification technology. Through a traceable mapping framework, the formal expression transformation from natural language constraints to PDDL constraint models, structural verifiers, and temporal behavior verifiers is performed according to a mapping rule table, achieving accurate transformation and semantic consistency, as well as traceability of the source. Furthermore, a dual-engine complementary verification approach using structural verification and temporal behavior verification is employed. Structural verification scans for constraint conflicts, while temporal behavior verification locks in temporal safety, achieving blind zone complementarity. Additionally, direct compilation of the formal model to on-board checking functions enables automatic mapping from safety invariants to checking functions, eliminating the need for manual writing of on-board logic and achieving seamless migration from ground verification to on-board verification.

Description

Technical Field

[0001] This invention belongs to the field of spacecraft autonomous mission planning and formal verification technology, specifically relating to a formal verification method and system for safety constraints in deep space exploration mission planning. Background Technology

[0002] Currently, the most common approach to formally verifying the safety constraints of deep space exploration mission planning is for engineers to review the constraint documents line by line, then import the planning scheme into a ground-based simulation system for simulation to verify whether the scheme violates any rules. The problem is that manual review is too inefficient, and constraint conflicts often only surface during mission implementation. Furthermore, simulations can only cover a limited range of scenarios, largely failing to cover the long-latency, multi-constraint coupled situations common in deep space exploration.

[0003] Furthermore, constraint verification methods based on the Constraint Satisfaction Problem (CSP) were previously used on Mars rovers, where task constraints were programmed into constraint satisfaction problems, allowing the solver to verify consistency. However, this method was custom-developed for a specific Mars rover mission and lacks cross-mission versatility. While CSP can solve constraint consistency problems, it cannot verify temporal behavior, such as whether "safety invariants can be maintained throughout the entire state space." In addition, the lack of a mapping between the CSP model and the PDDL (Planning Domain Definition Language) planning model prevents a valid correlation between the verification results and the planning system output.

[0004] In the joint Mercury exploration mission, the MBSE (Model-Based Systems Engineering) approach was used for requirements verification. A system model was constructed using SysML (Systems Modeling Language), and constraint consistency checks were performed at the model level. While MBSE has significant advantages in requirements verification at the system architecture level, it has limitations in verifying temporal safety attributes at the mission planning level. Furthermore, SysML's semantic precision is insufficient for exhaustive formal verification, and it lacks a dedicated verification combination for deep space scenarios. Summary of the Invention

[0005] The purpose of this invention is to provide a formal verification method and system for security constraints in deep space exploration mission planning, so as to solve the technical problems existing in the prior art.

[0006] The first aspect discloses a formal verification method for security constraints in deep space exploration mission planning, the method comprising:

[0007] The natural language constrained text is semantically equivalently mapped and transformed into a formal expression of PDDL constrained model and multiple preset verifiers according to a predefined mapping rule table. The predefined mapping rule table includes at least rule encoding, mapping basis and verification check items, and the multiple preset verifiers include structural verifier and temporal behavior verifier.

[0008] The PDDL constraint model is structurally verified using a Boolean satisfaction solver based on the formal expression of the structural verifier.

[0009] Temporal behavior verification in a finite state space based on the formal expression of a temporal behavior verifier;

[0010] Verify the constraint satisfaction of the planning scheme of the PDDL constraint model within the preset standard domain;

[0011] When the structural verification, temporal behavior verification, and constraint satisfaction verification all pass, the check function compiler will compile the safety invariants into an on-board executable check function for the target language.

[0012] The second aspect discloses a formal verification system for security constraints in deep space exploration mission planning, the system comprising:

[0013] The mapping and transformation unit is used to perform semantic equivalence mapping on natural language constraint text according to a predefined mapping rule table and transform it into a formal expression of PDDL constraint model and multiple preset verifiers. The predefined mapping rule table includes at least rule encoding, mapping basis and verification check items, and the multiple preset verifiers include structural verifier and temporal behavior verifier.

[0014] The structural verifier unit is used to perform structural verification of the PDDL constraint model using a Boolean satisfaction solver based on the formal expression of the structural verifier.

[0015] The temporal behavior verification unit is used to verify the temporal behavior in a finite state space based on the formal expression of the temporal behavior verifier.

[0016] The constraint satisfaction verification unit is used to verify the constraint satisfaction of the planning scheme of the PDDL constraint model within the preset standard domain.

[0017] The on-board executable check function compilation unit is used to compile safety invariants into on-board executable check functions in the target language when the structural verification, timing behavior verification, and constraint satisfaction verification all pass.

[0018] As can be seen from the above technical solutions, the present invention has the following beneficial effects:

[0019] This invention employs a traceable mapping framework, transforming natural language constraints into PDDL constraint models, structural verifiers, and temporal behavior verifiers through a mapping rule table. Encoding task constraints into formal models ensures accurate transformation and traceability of origin. Furthermore, it utilizes a dual-engine complementary verification approach, with structural verification eliminating constraint conflicts and temporal behavior verification locking in temporal safety, achieving complementary blind spots. Moreover, it abandons the model of verifying constraints after planning, directly embedding constraints into the PDDL layer and deeply binding them to the planning problem. This allows the planner to naturally generate compliant solutions, validating the safety of the planning scheme in a simulation environment. Finally, direct compilation of formal models into on-board checking functions enables automatic mapping from safety invariants to checking functions, eliminating the need for manual on-board logic and achieving seamless migration from ground verification to on-board operation. Attached Figure Description

[0020] Figure 1 The overall flowchart of a formal verification method for security constraints in deep space exploration mission planning provided by this invention is shown.

[0021] Figure 2 This invention provides a schematic diagram of a formal verification system architecture for security constraints in deep space exploration mission planning. Detailed Implementation

[0022] To make the objectives, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Several embodiments of the present invention are shown in the drawings. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that the disclosure of the present invention will be thorough and complete.

[0023] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] It should be noted that when an element is referred to as being "fixed to" another element, it can be directly on the other element or there may be an intervening element. When an element is considered to be "connected to" another element, it can be directly connected to the other element or there may be an intervening element. The terms "vertical," "horizontal," "left," "right," "up," "down," and similar expressions used herein are for illustrative purposes only and are not intended to indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as limiting the invention.

[0025] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal communication between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances. The term "and / or" as used herein includes any and all combinations of one or more of the related listed items.

[0026] In one embodiment, the present invention discloses a formal verification method for security constraints in deep space exploration mission planning, such as... Figure 1 As shown, the specific steps include:

[0027] S101. Based on a predefined mapping rule table, the natural language constraint text is semantically equivalently mapped and transformed into a formal expression of a PDDL constraint model and multiple preset verifiers. The predefined mapping rule table includes at least rule encoding, mapping basis and verification check items, and the multiple preset models include a structure verifier and a temporal behavior verifier.

[0028] Specifically, the SemEquiv (Semantic Equivalence) mapping engine transforms natural language constraint text into three formal expressions: a PDDL constraint model and formal expressions for multiple pre-defined validators. The structural validator can be the Alloy structural validator, and the temporal behavior validator can be the TLA+ temporal behavior validator. It's worth noting that Alloy is a lightweight formal modeling and analysis tool, with the underlying solution engine kodkod. It uses a minimalist syntax resembling mathematics and pseudocode to describe system structure, constraints, and rules, automatically traversing the state space to find logical structures and violation scenarios. TLA+ (Temporal Logic of Actions) is a formal specification and verification language used to accurately describe the behavior and logical constraints of concurrent, distributed, and complex systems.

[0029] The structural verifier, besides the Alloy structural verifier, can also be NuSMV (New Symbolic ModelVerifier, an open-source symbolic model checker) or Z3 (SMT solver). The temporal behavior verifier, besides the TLA+ temporal behavior verifier, can also be SPIN (Simple Promela Interpreter, a Promela model detector) or mCRL2. It should be noted that, for a clearer and more complete description of the technical solution of this invention, the following explanation uses the Alloy structural verifier and the TLA+ temporal behavior verifier as examples. The Alloy structural verification is used to statically check whether there are conflicts and contradictions in the logical structure of the PDDL constraint model, while the TLA+ temporal behavior verification is used to detect whether the temporal behavior meets the conditions. By scanning for logical contradictions through Alloy structural verification and locking temporal safety through TLA+ temporal behavior verification, the problem of blind spots in single tools is avoided.

[0030] This invention does not rely on subjective conversion based on experience, but rather performs standardized conversion through a predefined mapping rule table. Each rule includes at least a number, mapping basis, and verification check items.

[0031] For example, the predefined mapping rule table includes a rule number (SEQ-NNN), natural language constraint text, three formal expressions (PDDL constraint model / Alloy / TLA+), mapping basis, and verification check items, thus achieving traceability from beginning to end. Among them, the rule number is a unique identifier used to distinguish different mapping rules.

[0032] Taking the natural language constraint text "the detector attitude angle does not exceed ±30 degrees" as an example, according to the mapping rule SEQ-001, the corresponding formal tool is input to obtain the PDDL constraint model, fact / assert formal encoding, and INVARIANT / timing logic formula, which corresponds to a security invariant.

[0033] The mapping is based on existing attitude control specifications. As a key technology for interplanetary probes, these specifications are built upon Newton's laws of motion and dynamic equations. They acquire probe attitude information through sensors and adjust the attitude using actuators. They also fully consider the extreme conditions of the interplanetary environment, such as microgravity and radiation, to ensure stable operation of the probe in complex space environments. The system architecture encompasses core components such as sensors, controllers, and actuators. Verification checks include specific verification content for the structural verifier and the temporal behavior verifier, such as the assertions of the Alloy structural verifier and the INVARIANT invariants of the TLA+ temporal behavior verifier.

[0034] S102. The PDDL constraint model is structurally verified using a Boolean satisfaction solver based on the formal expression of the structural verifier.

[0035] In one embodiment, this step specifically includes:

[0036] Load the PDDL constraint model and set the bounded validation range;

[0037] The relational logic constraint encoding file of the PDDL constraint model is compiled into an intermediate representation of the Boolean satisfaction solver.

[0038] Assertion verification is performed within a defined bounded verification range, wherein the assertions include state invariant assertions and step invariant assertions. The state invariant assertions are used to check that single-state constraints are valid, and the step invariant assertions are used to check that constraints are maintained during transitions.

[0039] The solution is obtained by a Boolean satisfaction solver, which outputs counterexamples, including sequences of conflicting states.

[0040] The bounded verification scope is the upper limit of the state, for example, scope=10 State. In addition, it also includes the upper limit of the number of transition steps, such as 20 steps, which can cover the key state transition paths. The verification types include assertion verification and predicate verification. The response time is less than 200 milliseconds, which is suitable for rapid iteration.

[0041] First, Alloy's Analyzer compiles the relational logic constraint encoding file (.als file) into a kodkod intermediate representation, which encodes the relational logic constraints into Boolean SAT formulas. For example, PDDL(:constraint) is mapped to Alloy's fact (global enforcement), and (:goal) is mapped to assert (verification of the goal).

[0042] Next, assertion definitions are performed. Assertions are divided into two categories: state invariant assertions and step invariant assertions. State invariant assertions are used to check the validity of single-state constraints (e.g., `assert AttitudeLimit { all s: State |s.attitude_angle <= 30}`), while step invariant assertions are used to check the preservation of constraints during transitions (e.g., `assertPowerMonotonic { all s,s':State | step(s,s') implies s'.energy <= s.energy}`).

[0043] Furthermore, kodkod combines the negation of the assertion with axiom to form a SAT instance, which is solved by the Boolean satisfaction solver (SAT4J). Here, UNSAT means the assertion is true within the scope, and SAT means the violation counterexample is output.

[0044] In addition, conflicts are classified into three categories: timing conflicts, resource conflicts, and logical conflicts. Within the defined bounded verification scope, timing conflicts, resource conflicts, and logical conflicts are verified by assertions. Timing conflicts are captured by step invariant assertions, resource conflicts are captured by state invariant assertions, and logical contradictions are captured by fact consistency checks.

[0045] Finally, counterexamples are identified. In one embodiment, this specifically includes:

[0046] By reverse tracing the conflict state sequence included in the counterexamples, the original constraint is located from the conflict state, and then the corresponding rule number is located through the predefined mapping rule table.

[0047] After repairing the mapping rules based on the located rule numbers, the structure is re-verified within the same bounded verification range;

[0048] After successful verification, the formal expressions of the PDDL constraint model and the temporal behavior verifier are updated synchronously.

[0049] Specifically, counterexamples are presented as a state sequence (State0→State1→...→StateN). The state sequence is traced backward from the conflicting state to the original constraint (i.e., the corresponding natural language constraint text), and then located to the corresponding rule number through a predefined mapping rule table, forming a five-level location chain (counterexample→state→variable→constraint→rule).

[0050] After repairing the mapping rules based on the located rule numbers, they are re-validated within the same bounded validation range. Upon successful validation, the PDDL constraint model and the TLA+ temporal behavior validator validation pipeline are updated synchronously.

[0051] Take the safety invariant "energy consumption does not exceed 80% of battery capacity" as an example. A successful verification indicates that no constraint violation was found in the finite state space; if it fails, Alloy will output specific counterexample scenarios, which can be used to locate the problem.

[0052] S103. Temporal behavior verification in a finite state space based on the formal expression of a temporal behavior verifier;

[0053] In one embodiment, this step specifically includes:

[0054] Extract the key safety state machine of the planning model, and after maximizing the abstraction and simplification of the key safety state machine, perform the first-level safety invariant verification by means of exhaustive reachable states, and check the safety invariant predicates item by item;

[0055] Perform the second-level safety invariant verification by preferentially exploring the transfer paths related to the safety invariant with a preset search depth step by step;

[0056] When there is no counterexample output in both the first-level verification and the second-level verification, the timing behavior verification passes.

[0057] When the first-level verification passes and the second-level verification finds a counterexample, it is determined that the abstract simplified model loses details, backtracks to supplement variables, and marks the shortest path from the initial state to the conflict state when outputting the counterexample;

[0058] When a counterexample is found in the first-level verification but not in the second-level verification, it is determined that the abstract simplification introduces false positives excessively.

[0059] The specific process of the first-level verification is as follows:

[0060] Extract the key safety state machine from the planning model, and retain three types of core variables, including modal variables (operation mode enumeration), physical continuous variables (discretized into a finite range), and task state variables (retaining the full value range). Then perform transfer normalization. Define autonomous transfers (e.g., `Next ∨ ControlStep ∨ EmergencyStep∨ SafeModeEntry`) and response transfers (modeling non-deterministic inputs with env variables) using the ACTION of TLA+, and then check the transfer mutual exclusivity through ENABLED, where ENABLED is a boolean predicate indicating whether an action can be executed in the current state. Encode the safety constraints as INVARIANT, which are divided into three levels: S1 physical safety (such as the attitude angle not exceeding the limit of ±30°), S2 task constraints (such as communication windows, observation timings), and S3 formation cooperation. Distinguish state invariants (INVARIANT declarations) and action invariants (inline assert in ACTION).

[0061] When performing the first-level verification, for the key safety state machine, use the TLC (TLA+ Model Checker, a model checking tool supporting TLA+ for automatically traversing all reachable states of the system to verify whether the invariants and timing properties in the specification hold) tool to perform exhaustive enumeration of all reachable states (≥1.247 million states). Check the INVARIANT item by item, and mark the shortest path from the initial state to the conflict state when outputting the counterexample.

[0062] Furthermore, the specific process of the second-level verification includes:

[0063] The second level of validation, namely a bounded search of the complete model, is performed. All engineering details are preserved, with a preset search depth step size of 20 steps (covering 5-15 decision actions within a single planning window), and a reachable state count ≥ 45 million. Priority is given to exploring transition paths related to safety invariants.

[0064] This invention performs an exhaustive traversal verification of all 1.247 million states for the simplified model, and a bounded search verification of over 45 million states for the complete model. Both layers require that the safety invariants have no counterexamples.

[0065] Then, a difference analysis is performed. If neither the first-level nor the second-level validation outputs any negative examples, the time-series behavior validation passes. If the first-level validation passes but the second-level validation finds a negative example, it is determined that the simplified model has lost details, and variables need to be added back. If the first-level validation finds a negative example but the second-level validation does not, it is determined that excessive abstraction has introduced false positives. Based on the analysis results, corresponding corrections are made. This invention uses a two-level validation process: the first-level validation exhaustively covers the scope, while the second-level validation approximates engineering reality in depth. The two levels combined overcome the blind spots of a single strategy.

[0066] The verification covers three sets of invariants: attitude limit, power safety, and thermal safety. The two layers of verification run independently, with results cross-validated: simplified model traversal verification shows no issues, and full model global search verification shows no issues. Verification is considered successful only if the results from both layers are consistent.

[0067] Furthermore, the execution order of structural verification and temporal behavioral verification is explained. Structural verification and temporal behavioral verification are executed sequentially; that is, structural verification is performed first, followed by temporal behavioral verification. Alternatively, structural verification and temporal behavioral verification are executed in parallel, followed by cross-verification. Cross-verification compensates for the blind spots of a single verification paradigm, ensuring dual confirmation of structural consistency and behavioral safety.

[0068] For serial execution, the advantages are clear dependencies and unidirectional data flow, but the disadvantage is that the total time equals the sum of each stage, resulting in a longer execution time. It is more suitable for rapid iteration during the development phase. The parallel + cross-validation approach, with a total time of max(Alloy, TLA+), is faster than serial execution, but its disadvantages include complex orchestration and the need for both tools to be synchronously mapped from the same PDDL constraint model. It is suitable for final-state verification of key milestones. Before submission, a complete parallel + cross-validation process is performed to ensure no blind spots or omissions. After both layers of time-series behavior verification pass, the results are cross-compared with the Alloy results.

[0069] Furthermore, in one embodiment, the present invention further includes:

[0070] The blind zone coverage domains of structural verification and temporal behavior verification are compared, where the blind zone coverage domain represents the constraint conflicts that cannot be covered by structural verification and temporal behavior verification.

[0071] Because structural inconsistencies discovered by Alloy structural verification are not automatically detected by TLA+ temporal behavior verification (TLA+ assumes the model is correct and only checks behavior), conversely, out-of-bounds temporal violations discovered by TLA+ temporal behavior verification cannot be covered by the bounded verification of Alloy structural verification. Therefore, through verification, the blind zone coverage of structural verification and temporal behavior verification can be compared.

[0072] During the structural verification process, the predicates of the safety invariant are paired one by one with those of the assertion verification process and the temporal behavior verification process to confirm whether the numerical values ​​and the semantics of the triggering conditions are consistent.

[0073] Specifically, during consistency checks, Alloy assert is paired with TLA+ INVARIANT one by one to confirm that the numerical values ​​and triggering conditions are semantically consistent. If there is a discrepancy, the values ​​are backtracked and corrected through a predefined mapping rule table before re-verification.

[0074] Cross-complementary verification is performed on the preset complementary defects, wherein the preset complementary defects include mutually exclusive constraint structural contradictions, out-of-boundary temporal violation conflicts, and cross-constraint coupling conflicts. The mutually exclusive constraint structural contradictions are defined as counterexamples detected by structural verification but not detected by temporal behavior verification. The out-of-boundary temporal violation conflicts are defined as conflicts triggered after a preset search depth step size. The cross-constraint coupling conflicts are defined as counterexamples detected by both structural verification and temporal behavior verification but from different perspectives.

[0075] Specifically, three types of pre-defined complementary defects are constructed: mutually exclusive constraint structural contradictions (mutually exclusive constraints), for which Alloy structural verification detects counterexamples but TLA+ temporal behavior verification does not; out-of-bounds temporal violation conflicts, for which conflicts are triggered after a pre-defined search depth step size (20 steps), for which TLA+ temporal behavior verification detects counterexamples but Alloy structural verification misses them; and cross-constraint coupling conflicts, for which both Alloy structural verification and TLA+ temporal behavior verification detect counterexamples but from different perspectives.

[0076] When Alloy detects a conflict but TLA+ does not report an error, the constraint definition is corrected based on the Alloy counterexample first; when TLA+ detects a violation but Alloy missed it, the transfer logic is corrected based on the TLA+ counterexample first. The correction order is: P0 mutual exclusion constraint structural contradiction → P1 out-of-bounds timing violation conflict → P2 cross-constraint coupling conflict.

[0077] A joint report is generated for re-verification after backtracking and correction based on the joint report and a predefined mapping rule table. The joint report includes at least the independent verification results of each security invariant, the cross-consistency status, and the blind zone coverage comparison results.

[0078] The joint report includes independent verification results for each safety invariant, cross-consistency status (e.g., consistent / inconsistent), blind zone coverage descriptions and comparisons, and a comprehensive conclusion (e.g., double confirmation / needs correction). After successful verification, it is submitted to the lightweight check function compilation pipeline.

[0079] S104. Verify the constraint satisfaction of the planning scheme of the PDDL constraint model within the preset standard domain.

[0080] The preset standard domains are the IPC-2023 standard domains (rover / spacecraft / telescope). The rover domain simulates the rover's movement, sampling, and communication operations; the spacecraft domain simulates the spacecraft's on-orbit maneuvers and attitude maintenance; and the telescope domain simulates pointing control and information acquisition operations for Earth or space. However, after structural verification and temporal behavior verification are passed, the planner, Fast Downward (LM-Cut heuristic), generates planning schemes in each standard domain. The verifier will then check each simulated action one by one to confirm whether it meets the constraints defined in the natural language constraint text.

[0081] This invention abandons the model of verifying constraints after planning is completed, and instead embeds constraints directly into the PDDL level and deeply binds them to the planning problem, so that the planner can naturally generate compliant solutions and ensure the safety of the planning solution in the simulation environment.

[0082] S105. When the structural verification, timing behavior verification, and constraint satisfaction verification all pass, the check function compiler will compile the safety invariants into an on-board executable check function for the target language.

[0083] Once all safety invariants of the Alloy structure verification pass, all temporal properties of the TLA+ temporal behavior verification pass, and constraint satisfaction verification passes, the safety invariants are compiled into an on-board executable check function in the target language. The target language is TypeScript / C++ to adapt to the onboard operating environment.

[0084] Taking attitude angle constraints as an example, the compiler automatically converts the safety invariant (AttitudeLimit = attitude_angle <= 30) into a TypeScript function. As a statically typed superset of JavaScript, TypeScript possesses static type checking capabilities, enabling it to capture type-related errors during development, improving code security and maintainability, making it very suitable for this type of security verification scenario. Furthermore, TypeScript's type checking features can be leveraged to rigorously validate the type and numerical range of attitude angle parameters within the function. For example, after confirming the parameter type compliance through a type predicate function, it can then be determined whether it meets the constraint that the attitude angle does not exceed 30 degrees. The same applies to energy security invariants. The on-board executable checking function should meet the following requirements: single function memory less than 1MB to meet on-board resource constraints; single execution time less than 1ms to meet real-time requirements. The compiled on-board executable checking function is deployed to the on-board security protection module, triggered before each action execution. Before each action, all safety invariants are checked; if any fail, the corresponding action is not executed.

[0085] The formal model is directly compiled into the on-board checking function, realizing the automatic mapping of safety invariants to TypeScript checking functions. No need to manually write the on-board logic, and achieving seamless migration from ground verification to on-board.

[0086] In one embodiment, the method further includes:

[0087] If a security constraint conflict is detected during verification, a verification failure report containing counterexample scenarios is output to check the correctness of the predefined mapping rule table or constraint definition based on the verification failure report.

[0088] Specifically, when a counterexample is found in any of the verification steps of structural verification, temporal behavior verification, or constraint satisfaction verification, a verification failure report containing the specific scenario is generated, and the process reverts to step S101 to check the correctness of the mapping rules or constraint definitions.

[0089] This invention employs a traceable mapping framework, where the conversion from natural language constraints to PDDL / Alloy / TLA+ is performed through a mapping rule table, achieving traceability of the source. Furthermore, it utilizes a complementary Alloy+TLA+ dual-engine verification system: Alloy scans for constraint conflicts, while TLA+ locks for timing safety, achieving complementary blind spots. Moreover, it abandons the model of verifying constraints after planning is complete, embedding constraints directly into the PDDL layer and deeply binding them to the planning problem, enabling the planner to naturally generate compliant solutions. Additionally, the same set of safety invariants runs from the PDDL layer through Alloy, TLA+, and the onboard checking function, maintaining high semantic consistency across layers; verification results at any stage can be used to back-verify other layers. Finally, direct compilation of the formal model to the onboard checking function enables automatic mapping from TLA+ invariants to TypeScript checking functions, eliminating the need for manual onboard logic and achieving seamless migration from ground verification to onboard functionality.

[0090] The same set of safety invariants runs from the PDDL layer through Alloy, TLA+, and the onboard checking function, with the semantics of each layer remaining highly consistent. The verification results of any step can be used to verify other layers in reverse.

[0091] This invention also provides a formal verification system for the security constraints of deep space exploration mission planning, corresponding to the above-described method embodiments. Since the system embodiments are basically similar to the method embodiments, the description is relatively simple. For details of the relevant technical features and the effects of implementation, please refer to the corresponding descriptions of the above-described method embodiments. This invention discloses a formal verification system for the security constraints of deep space exploration mission planning, such as... Figure 2 As shown, the system includes:

[0092] The mapping and transformation unit is used to perform semantic equivalence mapping on natural language constraint text according to a predefined mapping rule table and transform it into a formal expression of PDDL constraint model and multiple preset verifiers. The predefined mapping rule table includes at least rule encoding, mapping basis and verification check items, and the multiple preset verifiers include structural verifier and temporal behavior verifier.

[0093] The structural verifier unit is used to perform structural verification of the PDDL constraint model using a Boolean satisfaction solver based on the formal expression of the structural verifier.

[0094] The temporal behavior verification unit is used to verify the temporal behavior in a finite state space based on the formal expression of the temporal behavior verifier.

[0095] The constraint satisfaction verification unit is used to verify the constraint satisfaction of the planning scheme of the PDDL constraint model within the preset standard domain.

[0096] The on-board executable check function compilation unit is used to compile safety invariants into on-board executable check functions in the target language when the structural verification, timing behavior verification, and constraint satisfaction verification all pass.

[0097] This invention also provides an electronic device, which includes a processor and a memory. The memory stores at least one instruction or at least one program, which is loaded and executed by the processor using the formal verification method for deep space exploration mission planning security constraints provided in the above-described method embodiments.

[0098] Furthermore, the electronic device may participate in or include the apparatus or system provided in the embodiments of the present invention. The electronic device may include one or more processors (processors may include, but are not limited to, processing devices such as microprocessors (MCUs) or programmable logic devices (FPGAs), memory for storing data, and transmission devices for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a power supply, and / or a camera.

[0099] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuit may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the device (or mobile device). As involved in the embodiments of the present invention, the data processing circuit serves as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0100] The memory can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method described in the embodiments of the present invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the above-mentioned data processing method. The memory 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 may further include memory remotely located relative to the processor, and these remote memories can be connected to electronic devices via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0101] The transmission device is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the device's communication provider. In one example, the transmission device 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 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0102] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows users to interact with the user interface of an electronic device (or mobile device).

[0103] This invention also provides a computer storage medium storing at least one instruction or at least one program, which is loaded and executed by a processor to implement the formal verification method for security constraints of deep space exploration mission planning provided in the above-described method embodiments.

[0104] Optionally, in this embodiment, the aforementioned computer storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the aforementioned storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0105] This invention also provides a computer program product or computer program, which includes computer instructions stored in a computer storage medium. The processor of an electronic device reads the computer instructions from the computer storage medium and executes the computer instructions, causing the electronic device to perform the formal verification method for deep space exploration mission planning security constraints provided in the above-described method embodiments.

[0106] It should be noted that the order of the above embodiments of the present invention is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0107] It should be understood that the above description of the preferred embodiments is quite detailed, but it should not be considered as a limitation on the scope of protection of this invention. Those skilled in the art, under the guidance of this invention, can make substitutions or modifications without departing from the scope of protection of the claims of this invention, and all such substitutions or modifications fall within the scope of protection of this invention. The scope of protection of this invention should be determined by the appended claims.

Claims

1. A formal verification method for security constraints in deep space exploration mission planning, characterized in that, The method includes: The natural language constrained text is semantically equivalently mapped and transformed into a formal expression of PDDL constrained model and multiple preset verifiers according to a predefined mapping rule table. The predefined mapping rule table includes at least rule encoding, mapping basis and verification check items, and the multiple preset verifiers include structural verifier and temporal behavior verifier. The PDDL constraint model is structurally verified using a Boolean satisfaction solver based on the formal expression of the structural verifier. Temporal behavior verification in a finite state space based on the formal expression of a temporal behavior verifier; Verify the constraint satisfaction of the planning scheme of the PDDL constraint model within the preset standard domain; When the structural verification, temporal behavior verification, and constraint satisfaction verification all pass, the check function compiler will compile the safety invariants into an on-board executable check function for the target language.

2. The formal verification method for security constraints in deep space exploration mission planning according to claim 1, characterized in that, The method further includes: If any verification detects a security constraint conflict, a verification failure report containing counterexample scenarios is output to check the correctness of the predefined mapping rule table or constraint definition based on the verification failure report.

3. The formal verification method for security constraints in deep space exploration mission planning according to claim 1, characterized in that, The formal expression based on the structure verifier performs structural verification of the PDDL constraint model using a Boolean satisfaction solver, including: Load the PDDL constraint model and set the bounded validation range; The relational logic constraint encoding file of the PDDL constraint model is compiled into an intermediate representation of the Boolean satisfaction solver. Assertion verification is performed within a defined bounded verification range, wherein the assertions include state invariant assertions and step invariant assertions. The state invariant assertions are used to check that single-state constraints are valid, and the step invariant assertions are used to check that constraints are maintained during transitions. The solution is obtained by a Boolean satisfaction solver, which outputs counterexamples, including sequences of conflicting states.

4. The formal verification method for security constraints in deep space exploration mission planning according to claim 3, characterized in that, The assertion verification within the defined bounded verification range includes: Within the defined bounded verification scope, assertion verification is performed on timing conflicts, resource conflicts, and logical conflicts. Timing conflicts are captured by step invariant assertions, resource conflicts are captured by state invariant assertions, and logical contradictions are captured by fact consistency checks.

5. The formal verification method for security constraints in deep space exploration mission planning according to claim 3, characterized in that, The method further includes: By reverse tracing the conflict state sequence included in the counterexamples, the original constraint is located from the conflict state, and then the corresponding rule number is located through the predefined mapping rule table. After repairing the mapping rules based on the located rule numbers, the structure is re-verified within the same bounded verification range; After successful verification, the formal expressions of the PDDL constraint model and the temporal behavior verifier are updated synchronously.

6. The formal verification method for security constraints in deep space exploration mission planning according to claim 1, characterized in that, The formal expression for temporal behavior verification in a finite state space based on a temporal behavior verifier includes: After extracting the key safety state machine of the planning model and abstracting and simplifying it to the greatest extent, the first level of safety invariant verification is performed by exhaustively enumerating reachable states, and the safety invariant predicates are checked one by one. A second-level verification of safety invariants is performed by prioritizing the exploration of transition paths related to safety invariants using a preset search depth step size. If neither the first-level nor the second-level validation outputs a counterexample, then the timing behavior validation passes.

7. The formal verification method for security constraints in deep space exploration mission planning according to claim 6, characterized in that, The method further includes: If the first level of validation passes and the second level of validation finds a counterexample, it is determined that the abstract simplified model has lost details. The variables are then backtracked and supplemented, and the shortest path from the initial state to the conflict state is marked when the counterexample is output. If the first level of validation finds a counterexample but the second level does not, it is determined that the abstract simplification has led to a false positive.

8. The formal verification method for security constraints in deep space exploration mission planning according to claim 6, characterized in that, The method further includes: The blind zone coverage domains of structural verification and temporal behavior verification are compared, where the blind zone coverage domain represents the constraint conflicts that cannot be covered by structural verification and temporal behavior verification. During the structural verification process, the predicates of the safety invariant are paired one by one with those of the assertion verification process and the temporal behavior verification process to confirm whether the numerical values ​​and the semantics of the triggering conditions are consistent. Cross-complementary verification is performed on the preset complementary defects, wherein the preset complementary defects include mutually exclusive constraint structural contradictions, out-of-boundary temporal violation conflicts, and cross-constraint coupling conflicts. The mutually exclusive constraint structural contradictions are defined as counterexamples detected by structural verification but not detected by temporal behavior verification. The out-of-boundary temporal violation conflicts are defined as conflicts triggered after a preset search depth step size. The cross-constraint coupling conflicts are defined as counterexamples detected by both structural verification and temporal behavior verification but from different angles. A joint report is generated for re-verification after backtracking and correction based on the joint report and a predefined mapping rule table. The joint report includes at least the independent verification results of each security invariant, the cross-consistency status, and the blind zone coverage comparison results.

9. The formal verification method for security constraints in deep space exploration mission planning according to claim 1, characterized in that, The constraint satisfaction verification of the planning scheme of the PDDL constraint model within the preset standard domain includes: After the planner generates a planning scheme based on the PDDL constraint model in the preset standard domain, the verifier checks each simulation action one by one to confirm whether it meets the predefined constraints. There are multiple preset standard domains, and different preset standard domains are used to execute different simulation actions.

10. A formal verification system for security constraints in deep space exploration mission planning, characterized in that, The system includes: The mapping and transformation unit is used to perform semantic equivalence mapping on natural language constraint text according to a predefined mapping rule table and transform it into a formal expression of PDDL constraint model and multiple preset verifiers. The predefined mapping rule table includes at least rule encoding, mapping basis and verification check items, and the multiple preset verifiers include structural verifier and temporal behavior verifier. The structural verifier unit is used to perform structural verification of the PDDL constraint model using a Boolean satisfaction solver based on the formal expression of the structural verifier. The temporal behavior verification unit is used to verify the temporal behavior in a finite state space based on the formal expression of the temporal behavior verifier. The constraint satisfaction verification unit is used to verify the constraint satisfaction of the planning scheme of the PDDL constraint model within the preset standard domain. The on-board executable check function compilation unit is used to compile safety invariants into on-board executable check functions in the target language when the structural verification, timing behavior verification, and constraint satisfaction verification all pass.

Images