A human-less conditional autonomous navigation ship expected function safety control logic verification method

Abstract

The application discloses a kind of few people have conditional autonomous navigation ship expected function safety control logic verification method, it is related to intelligent ship safety verification field.The following steps are included: define target few people have conditional autonomous navigation ship target operating scene, determine the verification range as the control logic safety verification in scene;With system theory process analysis method, the target operating scene of target few people have conditional autonomous navigation ship is analyzed in system level safety, and standardization mapping rule of establishing positive fine safety constraint to formalized model;Based on the standardization mapping rule of formalized model, three-layer gradually refined strategy is used to construct formalized model;The effectiveness of safety mechanism under dynamic scene is verified by formalized model simulation, and the expected function safety verification of control logic is completed, the reliability of control logic under different operating conditions is verified by dynamic parameter modeling, and it is verified that ship can still meet safety requirements in complex dynamic environment.

Description

Technical Field

[0001] This invention relates to the field of intelligent ship safety verification technology, and to a method for verifying the expected functional safety control logic of a conditionally autonomous ship with minimal human intervention. Background Technology

[0002] The global shipping industry is transforming towards smart shipping, with conditionally autonomous vessels (CAVs) moving from conceptual design to real-ship testing. Remote control and autonomous execution have become the focus of technological competition. However, despite increasing technological maturity, the large-scale commercial application of CAVs remains limited by the core challenge of safety verification. Under the guidance of the International Maritime Organization (IMO), the regulatory framework for CAVs is continuously improving. However, with the increasing complexity and autonomy of CAV systems, traditional safety assessment methods based on experience and regulatory compliance are no longer sufficient to fully capture potential risks, necessitating a more systematic and structured approach to risk analysis.

[0003] From the perspective of intended functional safety, current practices lack a rigorous formalized method for verifying control logic and its potential unsafe interactions during the design phase. Existing maritime regulations mainly stipulate high-level functional and performance objectives, without specifying detailed logical-level standards required for design-phase verification, thus making it impossible to translate regulatory requirements into verifiable safety constraints.

[0004] In various operational scenarios of conditionally autonomous vessels with reduced manpower, autonomous berthing, as the "last mile" of intelligent shipping, is characterized by high dynamic coupling and low fault tolerance. Its remote control mode relies on a layered architecture of "shore-based support - shipboard control - crew supervision," transforming berthing operations from a single-entity task into a complex distributed control problem. Under this architecture, the correctness of the control logic is crucial, but the spatiotemporal separation between shore-based operators and the vessel can introduce logical anomalies such as inconsistent command transmission, chaotic authority status, and emergency takeover conflicts. Existing methods cannot eliminate these risks in advance during the design phase.

[0005] While traditional physical simulations and experiments can verify the ship's performance, they cannot cover the vast state space of logical interactions, making it difficult to verify critical edge scenarios such as communication timeouts and human error. Therefore, they fail to meet the logical safety verification requirements for expected functional safety. Thus, there is an urgent need for a system design-phase verification method that can both transform high-level regulatory requirements into formally defined and verifiable safety constraints and rigorously address the logical safety issues related to expected functional safety in the complex control architecture of conditionally autonomous ships with minimal human involvement. Summary of the Invention

[0006] To address the technical problems of insufficient verification of the expected functional safety of control logic in unmanned conditionally autonomous (FIA) vessels and the inability to eliminate control logic risks during the design phase in existing technologies, this invention provides a method for verifying the expected functional safety of control logic in unmanned FIA vessels. This method achieves rigorous verification of the control logic of unmanned FIA vessels, ensuring operational safety. The technical solution adopted by this invention is: a method for verifying the expected functional safety of control logic in unmanned FIA vessels, comprising the following steps: S1. Define the target operational scenario of conditionally autonomous navigation vessels with fewer personnel, clarify the scenario boundary conditions, core entities and physical constraints, and determine the verification scope as the control logic security verification within the scenario. S2. Using system theory process analysis methods, conduct system-level safety analysis on the target operation scenario of conditionally autonomous navigation vessels with fewer personnel, identify system-level losses and dangers, derive system-level safety constraints, construct a hierarchical control structure, identify unsafe control behaviors and transform them into verifiable positive refined safety constraints. S3. Establish standardized mapping rules from positive refined security constraints to formal models; S4. Based on the standardized mapping rules of the formal model, a three-layer progressive refinement strategy is adopted to construct the formal model, as follows: the basic boundary of ship kinematics is established through the physical context layer, the functional control layer introduces control authority and actuator safety interlock, and the collaborative interaction layer introduces shore-based communication and dynamic authority transfer logic. S5. Generate and resolve the proof obligations for each layer of formal model, and mathematically verify the invariant preservation and refinement correctness; verify the effectiveness of the security mechanism in dynamic scenarios through formal model simulation, and complete the expected functional safety verification of the control logic.

[0007] Furthermore, in step S1: The target operational scenarios include autonomous docking scenarios; The boundary conditions include the dimensions of the vessel and the range of maneuvering parameters for berthing without tugboat assistance. The core entities include a shore-based control center, a shipboard intelligent control system, onboard crew members, and actuators. The physical constraints include threshold values ​​for ship physical parameters such as ship speed, propulsion power, and rudder angle.

[0008] Furthermore, the system-level security analysis described in step S2 specifically includes: System-level analysis: Identify system-level losses that need to be avoided in the ship operation system, including ship damage, personal injury and infrastructure damage, deduce the system-level hazards that lead to the losses, and generate system-level safety constraints based on the hazards; Construct a hierarchical control structure: Construct a hierarchical feedback control structure that includes a shore-based control center, a shipboard intelligent control system, shipboard crew members and actuators, and clarify the control flow, feedback path and allocation of authority and responsibility at each level; Identifying unsafe control behaviors: Based on the process analysis method of system theory, four categories of unsafe control behaviors are identified: failure to provide control behavior leads to danger, provision of control behavior leads to danger, incorrect timing of control behavior, and incorrect duration of control behavior. All control actions are traversed to identify unsafe control behaviors. Deriving security constraints: Transform each unsafe control behavior into verifiable, refined security constraints.

[0009] Furthermore, the standardized mapping rule mentioned in step S3 is specifically as follows: Static mapping: Abstracts the physical entities in the control structure of the system's theoretical process analysis method into a set in the formal model context, defines the threshold of ship physical parameters as constants, and defines inviolable physical laws as axioms; Dynamic mapping: Mapping the ship's motion state, control authority state, and system operation mode into state variables in the formal model machine, and modeling control command sending, authority transfer, and state update operations as events that trigger state transitions; Security rule mapping: Maps global system-level security constraints to invariants of a formal model machine, ensuring that all reachable states of the system satisfy the constraint, and maps the preconditions for event execution to guards of the event.

[0010] Furthermore: the three-layer progressive refinement strategy described in step S4 is specifically as follows: Through the physical context layer, the basic kinematic variables of the ship and their physical value ranges are defined, and abstract environmental evolution and actuator setting events are established. Only the rationality of the physical variables is guaranteed, and no control logic is introduced. By introducing control source variables on the basis of the physical context layer through the functional control layer, the system autonomous control and crew manual control are distinguished; the abstract actuator events are refined into two independent events: system control and crew control, and dynamic safety constraints are added to the actuator output. Through the collaborative interaction layer, permission mode variables and communication status variables are introduced on the basis of the functional control layer. Events such as shore-based remote control permission application, communication timeout handling, and emergency takeover are added to verify the permission transfer logic and fault safety mechanism in the distributed human-machine collaboration scenario.

[0011] Furthermore: In the functional control layer: Adding invariants ensures that when the control source is the system, the thrust, rudder angle, and lateral thrust do not exceed the dynamic safety limits calculated in real time based on the current speed and distance from the target; Adding an event guard ensures that the current ship status meets all safety conditions for autonomous control before permissions are transferred from the crew to the system, and prohibits the transfer of unsafe states to the autonomous system.

[0012] Furthermore: In the collaborative interaction layer: Add invariants to ensure that the control source in remote mode must be the system and that the ship's speed does not exceed the operating threshold set on shore. Add an event guard to ensure that remote control permission requests can only be executed when communication is normal, the ship is in a safe state, and the current mode is local. Add an emergency takeover event triggered by communication timeout to ensure that the system automatically degrades to crew local control mode after communication is interrupted.

[0013] Furthermore, the verification of the proof obligation mentioned in step S5 specifically includes: The formal modeling platform is used to automatically generate proof obligations for each refinement layer, including proofs of invariant preservation, proofs of refinement correctness, and proofs of event feasibility. For proof obligations that cannot be resolved by the automatic prover, logical derivation is completed by manually instantiating axioms and assumptions, ensuring that all proof obligations are resolved. This mathematically guarantees that the system will not violate the safety constraints of the derivation under all possible state transitions.

[0014] Furthermore, the model simulation verification described in step S5 specifically includes: An executable simulation environment is built using a formal modeling platform, which instantiates abstract constants into specific ship physical parameters. Three progressive verification scenarios are designed: shore-based constraint and physical interlock verification, security degradation verification under communication failure, and human-computer interaction and permission boundary verification. By interactively triggering event sequences, observe the system state transition trajectory to verify the effectiveness of the system's safety mechanisms under normal operation, fault conditions, and emergency situations.

[0015] Furthermore, the target operating scenarios include, but are not limited to, autonomous berthing, autonomous unberthing, obstacle avoidance, and navigation in open water. The method can be extended to different unmanned conditionally autonomous navigation vessel operating scenarios by adjusting the scenario boundary conditions and extracting safety constraints in a targeted manner.

[0016] The controlled architecture of the conditionally autonomous vessel with reduced manpower consists of a three-tiered control system: a shore-based control center, a shipboard intelligent control system, and a crew member on board. It supports three operating modes: local manual, local autonomous, and remote autonomous.

[0017] This invention provides a method for verifying the expected functional safety control logic of a conditionally autonomous navigation vessel with minimal human intervention. Compared with existing technologies, this invention has the following advantages: 1. A customized expected functional safety verification mechanism for the field of maritime safety assessment was established. By integrating system theoretical process analysis methods with formal methods, a bridge was built between qualitative maritime safety constraints and mathematical models. This enabled rigorous verification of the functional control logic of the distributed architecture during the design phase and improved the research paradigm for expected functional safety verification of control logic applicable to conditionally autonomous vessels with fewer personnel.

[0018] 2. A practical design-stage verification tool was developed. Through empirical verification in a highly coupled scenario of autonomous berthing of a conditionally autonomous vessel with minimal human intervention, it was demonstrated that the method can effectively expose the defects of complex human-computer interaction logic, verify the consistency of functional logic, and provide clear guidance for the design optimization of control logic for conditionally autonomous vessels with minimal human intervention.

[0019] 3. This invention enables the verification of the reliability of functional logic under dynamic conditions. Unlike traditional static analysis methods, this invention uses dynamic parameter modeling to verify the reliability of the designed control logic under different operating conditions and to verify that the ship can still meet safety requirements in complex dynamic environments.

[0020] 4. It has good versatility and scalability. Although it was verified in the autonomous berthing scenario, the method can be extended to other complex operating scenarios such as obstacle avoidance and autonomous departure of conditionally autonomous navigation vessels. Only by adjusting the scenario boundary conditions and safety constraints can the expected functional safety verification of the control logic in different scenarios be achieved. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a schematic diagram of the core entity architecture for the autonomous docking scenario of this invention; Figure 3 This is a schematic diagram of the hierarchical control structure of the unmanned conditionally autonomous navigation vessel berthing control system of the present invention. Figure 4 This is a schematic diagram of the state transition in the shore-based constraint and physical interlocking verification scenario of the present invention; Figure 5 This is a schematic diagram of the state transition in the communication failure security degradation verification scenario of the present invention; Figure 6This is a schematic diagram of the state transition in the human-computer interaction and permission boundary verification scenario of the present invention. Detailed Implementation

[0023] It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of the present invention can be combined with each other. The present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the present invention or its application or use. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] A method for verifying the expected functional safety control logic of a conditionally autonomous, minimally staffed vessel includes the following steps: S1. Define the target operational scenario of conditionally autonomous navigation vessels with fewer personnel, clarify the scenario boundary conditions, core entities and physical constraints, and determine the verification scope as the control logic security verification within the scenario. S2. Using system theory process analysis methods, conduct system-level safety analysis on the target operation scenario of conditionally autonomous navigation vessels with fewer personnel, identify system-level losses and dangers, derive system-level safety constraints, construct a hierarchical control structure, identify unsafe control behaviors and transform them into verifiable positive refined safety constraints. S3. Establish standardized mapping rules from positive refined security constraints to formal models; map static physical entities and constraints to sets, constants and axioms in the context of formal models, map dynamic system properties and operations to state variables and events in formal model machines, and map security constraints to invariants and event guards. S4. Based on the standardized mapping rules of the formal model, a three-layer progressive refinement strategy is adopted to construct the formal model, as follows: the basic boundary of ship kinematics is established through the physical context layer, the functional control layer introduces control authority and actuator safety interlock, and the collaborative interaction layer introduces shore-based communication and dynamic authority transfer logic. S5. Generate and resolve the proof obligations for each layer of formal model, and mathematically verify the invariant preservation and refinement correctness; verify the effectiveness of the security mechanism in dynamic scenarios through formal model simulation, and complete the expected functional safety verification of the control logic.

[0026] Furthermore, in step S1: Identify the specific type of the target operating scenario and determine the boundary conditions of the scenario, including the size of the vessel and the range of maneuvering parameters.

[0027] Identify the core entities in the scenario and clarify the functional positioning of each entity; define the limit values ​​of physical parameters such as ship speed, propulsion power, and rudder angle, and establish a physical constraint basis for verification.

[0028] The verification scope is clearly defined to focus only on the security of control logic within the operational scenario, and does not involve verification of other aspects such as ship motion performance.

[0029] The target operational scenarios include autonomous docking scenarios; The core entities include a shore-based control center, a shipboard intelligent control system, onboard crew members, and actuators. Furthermore, the system-level security analysis described in step S2 specifically includes: System-level analysis: Identify system-level losses that need to be avoided in ship operation systems, including ship damage, personal injury, and infrastructure damage; deduce system-level hazards that lead to these losses; and generate system-level safety constraints based on these hazards; focus on emergent behaviors rather than isolated component failures; and generate system-level safety constraints by logically reversing system-level hazards to clarify the behavioral boundaries that the system must always meet in order to prevent accidents from occurring.

[0030] Construct a hierarchical control structure: Construct a hierarchical feedback control structure that includes a shore-based control center, a shipboard intelligent control system, shipboard crew members and actuators, and clarify the control flow, feedback path and allocation of authority and responsibility at each level; Identifying Unsafe Control Behaviors: Based on the system theory process analysis method, four categories of unsafe control behaviors are identified: failure to provide control behavior leading to danger, provision of control behavior leading to danger, incorrect timing of control behavior, and incorrect duration of control behavior. All control actions are reviewed to identify unsafe control behaviors. Core elements such as high-level controllers, mid-level controllers, actuators, sensors, and controlled processes are clearly defined. The shore-based control center serves as the high-level controller, responsible for issuing and monitoring mission-level commands. The shipborne intelligent control system serves as the mid-level controller, responsible for translating mission-level commands into specific manipulation algorithms. The onboard crew serves as a supervisory and redundant control layer. Actuators serve as the physical layer, executing control commands and driving ship movement. Sensors capture the ship's real-time physical state and transmit it as feedback to each controller, clarifying the control logic and responsibility allocation among various entities.

[0031] Derivation of safety constraints: Each unsafe control behavior is transformed into a verifiable, refined safety constraint. Based on the constructed hierarchical control structure, the control actions of each controller are identified one by one. According to four criteria—"failure to provide leads to danger, providing itself leads to danger, providing too early / too late / incorrect sequence, stopping too early / applying for too long"—the unsafe situations of each control action in different operating scenarios are analyzed to determine unsafe control behaviors. The source of each identified unsafe control behavior is traced to establish a correlation with system-level hazards, thus transforming unsafe control behaviors into verifiable, refined safety constraints.

[0032] Furthermore, the standardized mapping rule mentioned in step S3 is specifically as follows: Static mapping: Abstracts the physical entities in the control structure of the system's theoretical process analysis method into a set in the formal model context, defines the threshold of ship physical parameters as constants, and defines inviolable physical laws as axioms; Dynamic mapping: Mapping the ship's motion state, control authority state, and system operation mode into state variables in the formal model machine, and modeling control command sending, authority transfer, and state update operations as events that trigger state transitions; Security rule mapping: Maps global system-level security constraints to invariants of the formal model machine, ensuring that all reachable states of the system satisfy the constraint, and maps the preconditions for event execution to guards of the event, so that the event can only be executed when the guard condition is met; Furthermore: the three-layer progressive refinement strategy described in step S4 is specifically as follows: Through the physical context layer, the basic kinematic variables of the ship and their physical value ranges are defined, and abstract environmental evolution and actuator setting events are established. Only the rationality of the physical variables is guaranteed, and no control logic is introduced. By introducing control source variables on the basis of the physical context layer through the functional control layer, the system autonomous control and crew manual control are distinguished; the abstract actuator events are refined into two independent events: system control and crew control, and dynamic safety constraints are added to the actuator output. Through the collaborative interaction layer, permission mode variables and communication status variables are introduced on the basis of the functional control layer. Events such as shore-based remote control permission application, communication timeout handling, and emergency takeover are added to verify the permission transfer logic and fault safety mechanism in the distributed human-machine collaboration scenario.

[0033] Furthermore: In the functional control layer: Adding invariants ensures that when the control source is the system, the thrust, rudder angle, and lateral thrust do not exceed the dynamic safety limits calculated in real time based on the current speed and distance from the target; Adding an event guard ensures that the current ship status meets all safety conditions for autonomous control before permissions are transferred from the crew to the system, and prohibits the transfer of unsafe states to the autonomous system.

[0034] Furthermore: In the collaborative interaction layer: Add invariants to ensure that the control source in remote mode must be the system and that the ship's speed does not exceed the operating threshold set on shore. Add an event guard to ensure that remote control permission requests can only be executed when communication is normal, the ship is in a safe state, and the current mode is local. Add an emergency takeover event triggered by communication timeout to ensure that the system automatically degrades to crew local control mode after communication is interrupted.

[0035] Furthermore, the verification of the proof obligation mentioned in step S5 specifically includes: The formal modeling platform is used to automatically generate proof obligations for each refinement layer, including proofs of invariant preservation, proofs of refinement correctness, and proofs of event feasibility. For proof obligations that cannot be resolved by the automatic prover, logical derivation is completed by manually instantiating axioms and assumptions, ensuring that all proof obligations are resolved. This mathematically guarantees that the system will not violate the safety constraints of the derivation under all possible state transitions.

[0036] Furthermore, the model simulation verification described in step S5 specifically includes: An executable simulation environment is built using a formal modeling platform, which instantiates abstract constants into specific ship physical parameters. Three progressive verification scenarios are designed: shore-based constraint and physical interlock verification, security degradation verification under communication failure, and human-computer interaction and permission boundary verification. By interactively triggering event sequences, observe the system state transition trajectory to verify the effectiveness of the system's safety mechanisms under normal operation, fault conditions, and emergency situations.

[0037] Furthermore, the target operating scenarios include, but are not limited to, autonomous berthing, autonomous unberthing, obstacle avoidance, and navigation in open water. The method can be extended to different unmanned conditionally autonomous navigation vessel operating scenarios by adjusting the scenario boundary conditions and extracting safety constraints in a targeted manner.

[0038] The controlled architecture of the conditionally autonomous vessel with reduced manpower consists of a three-tiered control system: a shore-based control center, a shipboard intelligent control system, and a crew member on board. It supports three operating modes: local manual, local autonomous, and remote autonomous.

[0039] Verification of the proof obligation.

[0040] The formal modeling platform is used to automatically generate proof obligations for each layer of the model. These proof obligations are logical theorems that need to be proven to be true, mainly including invariant preservation and refined correctness. Through automatic proof and necessary manual auxiliary proof, it is ensured that all proof obligations can be resolved, and mathematically it is guaranteed that the system will not violate the safety constraints of the derivation in all possible state transitions.

[0041] Dynamic simulation verification.

[0042] Using a formal modeling platform, simulation is performed. Based on the scenario parameters defined in step S1, an executable simulation environment is constructed. By triggering different event sequences, the migration trajectory of state variables is observed to verify the effectiveness of the system's security mechanism under complex temporal conditions, ensuring that the system can strictly reject identified unsafe actions and activate the protection mechanism.

[0043] Example 1: This example specifically includes the following steps: S1. Define the target operation scenario of conditionally autonomous navigation vessels with fewer personnel, clarify the scenario boundary conditions, core entities and physical constraints, and determine the verification scope as the control logic security verification within the scenario.

[0044] Define the ship's parameters. The target vessel is based on the "Zhifei" autonomous container ship and has the ability to berth autonomously without tugboat assistance.

[0045] Define the scene environment. A fixed dock, calm waters, constant wind / water flow, and no dynamic obstacles provide a stable physical environment for verification.

[0046] Define the core entities: the shore-based control center (ROC), the shipboard intelligent control system (ICS), the shipboard crew, and the actuators (propellers, rudders, and thrusters). The functional roles of each entity are as follows: the shore-based control center serves as a remote strategic command and mission monitoring node; the shipboard intelligent control system, as the core of autonomous control, translates high-level commands into maneuvering actions through control algorithms; the shipboard crew, as the "human-in-the-loop" safety layer, possesses supervisory and emergency takeover authority; and the actuators, as the physical layer, execute control commands under kinematic constraints.

[0047] Define physical constraints. Clearly define threshold values ​​for physical parameters such as propulsion power, rudder angle, and ship speed, which will serve as physical benchmarks for subsequent verification.

[0048] S2. Using system theory process analysis methods, conduct system-level safety analysis on the target operation scenario of conditionally autonomous ships with reduced manpower, identify system-level losses and hazards, derive system-level safety constraints, construct a hierarchical control structure, identify unsafe control behaviors and transform them into verifiable positive refined safety constraints.

[0049] In this embodiment, the specific steps are as follows: Step 1: The system-level losses identified in the autonomous docking scenario of this embodiment specifically include: L1: Damage to the vessel (damage to the hull, propulsion system, steering and navigation equipment); L2: Personnel injuries (injuries to crew members on watch, port workers, and shore-based control center operators); L3: Damage to infrastructure (berth fenders, mooring bollards, wharf walls, and shore-based navigation equipment).

[0050] Based on the above losses, the system-level hazards are deduced, specifically including: H1: Collision between vessel and berth; H2: The vessel deviated from the designated channel and ran aground; H3: Ship out of control.

[0051] Corresponding system-level security constraints are generated, specifically including: SC1: Vessels must not collide with the berth during berthing; SC2: Vessels must not deviate from the designated channel during berthing; SC3: The vessel must not lose control during berthing.

[0052] Step Two: The ship operation system is abstracted into a hierarchical control structure containing feedback control loops, clearly defining core elements such as high-level controllers, mid-level controllers, actuators, sensors, and controlled processes. The shore-based control center serves as the high-level controller, responsible for issuing and monitoring mission-level commands. The shipborne intelligent control system serves as the mid-level controller, responsible for translating mission-level commands into specific manipulation algorithms. The onboard crew serves as the supervisory and backup redundant control layer. Actuators serve as the physical layer, executing control commands and driving ship movement. Sensors capture the ship's real-time physical state and transmit it as feedback to each controller, clearly defining the control logic and allocation of responsibilities among the entities.

[0053] Step 3: Based on the constructed hierarchical control structure, the control actions of each controller are identified one by one. According to four criteria, namely "failure to provide leads to danger, provision itself leads to danger, provision is too early / too late / incorrect sequence, and stopping is too early / application is too long", the unsafe situations of each control action in different operating scenarios are analyzed to determine unsafe control behaviors. The source of each identified unsafe control behavior is traced to establish the correlation with system-level hazards, and the unsafe control behavior is transformed into verifiable and refined safety constraints.

[0054] Focusing on the propulsion system (the core of this embodiment), and combining the four unsafe control behavior judgment criteria of the system theoretical process analysis method, the unsafe control behaviors (UCA) of the propulsion system are identified, and the corresponding refined safety constraints (RSC) are derived, as follows: (1) Identification of unsafe control behaviors UCA1: No propeller speed command was provided when acceleration or deceleration was required (resulting in loss of vessel control, associated hazard H3). UCA2: The propeller speed is too high, resulting in excessive speed and excessive braking distance (leading to a collision between the ship and the berth, associated with hazards H1 and H3). UCA3: The propeller speed is too low, causing the ship to stop prematurely before reaching the target (leading to loss of ship control, associated with hazard H3). UCA4: When forward movement is required, provide a reverse direction propulsion command (which may cause the vessel to deviate from its course or collide, associated with hazards H1 and H2). UCA5: Deceleration command applied too late, vessel leaves safe area (causing collision between vessel and berth, associated hazard H1); UCA6: Deceleration command applied too early, vessel stops before reaching the target (causing loss of vessel control, associated hazard H3); UCA7: The propulsion system stops prematurely before reaching the target speed or coming to a complete stop (leading to loss of vessel control, associated hazard H3).

[0055] (2) Derivation of refined safety constraints RSC1: Propulsion power must not exceed the dynamic safety limit calculated based on real-time ship speed and berth distance; RSC2: The propulsion output status must strictly comply with the system's speed requirements or the crew's maneuvering intentions; RSC3: Propulsion power must decrease monotonically as the berthing distance decreases to ensure that the vessel stops before reaching the minimum safe distance.

[0056] Meanwhile, for other control links such as the steering system, side thrust system, and authority transfer, the same method is used to identify UCAs and derive RSCs, establishing a complete hierarchical safety constraint system.

[0057] S3. Establish standardized mapping rules from security constraints to formal models, mapping static physical entities and constraints to sets, constants and axioms in the formal model context, mapping dynamic system properties and operations to state variables and events in the formal model machine, and mapping security constraints to invariants and event guards.

[0058] In this embodiment, the specific steps are as follows: Step 1: Static Mapping Construct a formal model context and define the core set and constants: (1) Set definition: including ship status set (SHIP_STATE), control source set (CONTROL_SOURCE), authority attribution set (PERMISSION_MODE), etc.; (2) Constant definition: including physical parameter constants such as minimum propulsion power (min_propulsion_power), maximum propulsion power (max_propulsion_power), emergency maximum power (emergency_max_power), and minimum safe distance (min_safe_distance); (3) Axiom definition: Define axioms such as axm_calculated_safe_power (axm) to ensure that the safe power calculated based on real-time speed and distance is always within the physical output limit of the propulsion system.

[0059] axm_calculated_safe_powe r : sp, dist · sp dist calculated_ safe_power(sp dist)≥ min_propulsion_power calculated_safe_power(sp dist) max_propulsion_power Step 2: Dynamic Mapping Define the state variables of the formal model machine, focusing on: (1) Propulsion system related variables: propulsion_power, speed_demand, etc.; (2) Ship state variables: ship_speed, distance_to_berth, control_source (distinguishing between system control and crew control), etc. (3) Event definition: For example, the control operation of the propulsion system is modeled as two events: System_Control_Propulsion and Crew_Control_Propulsion. The ship state update is modeled as the Update_Ship_State event. The triggering conditions and state update actions of each event are clearly defined.

[0060] Step 3: Security Rule Mapping The refined safety constraints of the propulsion system are mapped to invariants (inv) and event guard conditions (grd) of the formal model: For example, security constraint RSC1 is mapped to an invariant: inv:control_source=SYSTEM propulsion_power calculated_safe_power (ship_speed distance_to_berth) And the guard conditions for the System_Control_Propulsion event: p calculated_safe_power(ship_speed distance_to_berth) The security constraint RSC2 is mapped to an invariant: inv:control_source=SYSTEM (propulsion_power>0 speed_demand>0) inv:control_source=CREW (propulsion_power>0 intended_direction {FORWARD, ASTERN}) S4. A three-layer progressive refinement strategy is adopted to construct a formal verification model: the physical context layer establishes the basic boundaries of ship kinematics, the functional control layer introduces control authority and actuator safety interlocking, and the collaborative interaction layer introduces shore-based communication and dynamic authority transfer logic.

[0061] In this embodiment, the specific steps are as follows: Step 1: Physical Context Layer.

[0062] Define the basic kinematic variables of the ship and their physical value ranges, establish abstract environmental evolution and actuator setting events, and only ensure the rationality of the physical variables without introducing any control logic.

[0063] As the most abstract model layer, it focuses on the physical properties of the propulsion system and the ship, defining invariants inv1-inv7 to clarify the physical limits of parameters such as propulsion power and ship speed: inv1:propulsion_power min_propulsion_power‥max_propulsion_power inv2:rudder_angle min_rudder_angle‥max_rudder_angle inv3:thruster_force min_thruster_force‥max_thruster_force inv4:ship_speed 0‥absolute_max_speed inv5:ship_heading

[0064] inv6:lateral_position

[0065] inv7:distance_to_berth

[0066] Define the Set_Propulsion event to objectively describe the physical state of a ship's motion under propulsion power: EVENT Set_Propulsion ANY p WHERE grd1: p min_propulsion_power‥max_propulsion_power THEN act1: propulsion_power p END The Update_Ship_State event is introduced to simulate updates to physical parameters such as ship speed and berth distance, providing a physical environment foundation for subsequent control logic verification. EVENT Update_Ship_State ANY sp, hd, pos, dist WHERE grd1: sp 0‥absolute_max_speed grd2: hd

[0067] grd3: pos

[0068] grd4: dist

[0069] grd5: sp absolute_max_speed THEN act1: ship_speed sp act2: ship_heading hd act3: lateral_position pos act4: distance_to_berth dist END Step 2: Functional Control Layer.

[0070] Based on the physical context layer, control source variables are introduced to distinguish between autonomous system control and manual crew control; abstract actuator events are refined into two independent events: system control and crew control, and dynamic safety constraints are added to the actuator output.

[0071] Based on the physical context M0 layer, the control logic of the propulsion system is introduced, distinguishing between system control and crew control modes, and refining the safety constraints of the propulsion system: (1) State variable expansion: Add variables such as control_source to clarify the control mode; (2) Invariant refinement: In addition to inheriting the physical constraints of the physical context layer, a refined safety constraint invariant for the corresponding propulsion system is added to ensure that the propulsion power under both system control and crew control meets the safety requirements; inv:speed_demand 0‥absolute_max_speed inv:control_source=SYSTEM propulsion_power calculated_safe_power (ship_speed distance_to _berth) inv:control_source=CREW propulsion_power emergency_max_power (3) Event refinement: The abstract Set_Propulsion event of the physical context layer is subdivided into two specific events, System_Control_Propulsion and Crew_Control_Propulsion, and the guard conditions for the two control modes are defined respectively: System_Control_Propulsion event: EVENT System_Control_Propulsion REFINES Set_Propulsion ANY p WHERE grd1:p min_propulsion_power‥max_propulsion_power grd2:control_source=SYSTEM grd3:p calculated_safe_power(ship_speed distance_to_berth) grd4:p>0 speed_demand>0 grd5:ship_speed absolute_max_speed THEN act1:propulsion_power p END Crew_Control_Propulsion event: EVENT Crew_Control_Propulsion REFINES Set_Propulsion ANY p WHERE grd1:p min_propulsion_power‥max_propulsion_power grd2:control_source=CREW grd3:p emergency_max_power grd4:p>0 intended_direction {FORWARD, ASTERN} THEN act1:propulsion_power p END In addition, the Switch_To_System_Control event is introduced to define the preconditions for switching the control source from crew control to system control, ensuring that parameters such as propulsion power meet the safety requirements of system control during the switch, and preventing the inheritance of dangerous states. EVENT Switch_To_System_Control WHERE grd1: control_source=CREW grd2: propulsion_power calculated_safe_power(ship_speed distance_ to_berth) grd3: propulsion_power>0 speed_demand>0 grd4: rudder_angle safe_rudder_limit_at_speed(ship_speed)‥safe_ rudder_limit_at_speed(ship _speed) grd5: thruster_force 0 (ship_state=DOCKING ship_speed docking_ speed_limit) THEN act1: control_source SYSTEM END Step 3: Collaborative Interaction Layer.

[0072] Based on the functional control layer, permission mode variables and communication status variables are introduced, and events such as shore-based remote control permission application, communication timeout handling, and emergency takeover are added to verify the permission transfer logic and fault safety mechanism in a distributed human-machine collaboration scenario.

[0073] Building upon the functional control layer, the shore-based-shipboard collaborative interaction logic of the propulsion system is extended by introducing variables such as communication status and time parameters to ensure that the control logic of the propulsion system coordinates with shore-based commands and communication status. (1) State variable expansion: Add variables such as shore_connected (shore-based connection status), commu_time (current time), and last_commu_time (last communication time).

[0074] (2) Invariant extension: The addition of an invariant ensures that the communication timeout triggers a safety mechanism; ensures that the ship speed meets the threshold set by the shore in remote control mode, indirectly constraining the propulsion power: inv:shore_connected=TRUE current_time last_communication_time communication_timeout inv:shore_connected=TRUE speed_threshold absolute_max_speed distance_threshold min_safe _distance inv:permission_mode=REMOTE shore_connected=TRUE ship_speed speed_ threshold distance _to_berth distance_threshold (3) Event details: The Shore_Send_Parameters event has been refined, and guard conditions have been added to verify that parameters such as the speed threshold for shore-based transmissions meet the physical limits of the ship. EVENT Shore_Send_Parameters ANY s_thresh, h_thresh, d_thresh WHERE grd1:permission_mode=REMOTE grd2:shore_connected=TRUE grd3:s_thresh s_thresh absolute_max_speed grd4:h_thresh h_thresh max_heading_deviation grd5:d_thresh d_thresh ≥ min_safe_distance d_thresh max_ detectable_distance grd6:current_time last_communication_time max_latency grd7:ship_speed s_thresh grd8:ship_heading h_thresh ship_heading h_thresh grd9:distance_to_berth d_thresh THEN act1:speed_threshold s_thresh act2:heading_threshold h_thresh act3:distance_threshold d_thresh act4:last_communication_time current_time END The Crew_Takeover_Emergency event has been refined to include propulsion power exceeding limits and communication timeouts as triggering conditions for emergency takeover, ensuring that the propulsion system can be switched to manual control by the crew in a timely manner under dangerous conditions. EVENT Crew_Takeover_Emergency REFINES Switch_To_Crew_Control WHERE grd1:control_source=SYSTEM grd2:ship_state EMERGENCY grd3:propulsion_power emergency_max_power grd4:propulsion_power>0 intended_direction {FORWARD, ASTERN} grd5:permission_mode=REMOTE grd6:ship_speed>speed_threshold distance_to_berth<min_safe_distance current_time last _communication_time>communication_timeout THEN act1:control_source CREW act2:permission_mode LOCAL END S5. Generate and resolve the proof obligations for each layer of formal model, and mathematically verify the invariant preservation and refinement correctness; verify the effectiveness of the security mechanism in dynamic scenarios through model simulation, and complete the expected functional safety verification of the control logic.

[0075] In this embodiment, the specific steps are as follows: Step 1: Verification of the proof obligation.

[0076] The formal modeling platform automatically generated 105 proof obligations for each layer of the model. Of these, 103 were automatically proven, while 2 required manual instantiation of axiom conditions to aid in the derivation due to limitations of the platform's automatic prover in handling complex physical constraints and arithmetic logic. All proof obligations were successfully passed, demonstrating the invariant preservation and refinement correctness of each model layer. This mathematically guarantees that the propulsion system and the entire berthing control logic do not violate the safety constraints derived by STPA during all state transitions, ensuring that parameters such as propulsion power and speed remain within safe limits.

[0077] Step 2: Dynamic simulation verification.

[0078] Using a formal modeling platform, simulations were performed. Based on the scenario parameters defined in step S1, three executable simulation scenarios were constructed. By triggering different event sequences, the migration trajectory of state variables was observed to verify the effectiveness of the system's security mechanism under complex temporal conditions, ensuring that the system can strictly reject identified unsafe actions and activate the protection mechanism.

[0079] Scenario 1: Verification of shore-based constraints and physical interlocking like Figure 4 As shown, the constraints of shore-based parameters on the propulsion system and the physical interlocking logic of the propulsion system are verified. In the simulation, ROC defines a speed threshold. When the injected speed demand exceeds this threshold, the model intercepts the propulsion command through guard conditions, preventing the propulsion power from exceeding the limit. When the ship speed is higher than the berthing speed limit, the side thruster command is disabled, and the deceleration command of the propulsion system is executed first, ensuring that the ship speed meets the physical constraints and verifying the effectiveness of the safety constraints.

[0080] Scenario 2: Security Degradation Verification for Communication Failures like Figure 5 As shown, in a simulated communication interruption scenario, when the system time exceeds the communication timeout threshold, the model intercepts the time advance command, triggers the Shore_Lose_Connection event, and then activates the Crew_Takeover_Emergency event. The control source of the propulsion system switches from system control to crew control, prohibiting the execution of propulsion commands under remote control, ensuring that the propulsion system can safely degrade in the event of a communication failure, and verifying the fault safety mechanism of the collaborative interaction layer.

[0081] Scenario 3: Human-computer interaction and permission boundary verification like Figure 6 As shown, a dangerous scenario is simulated where the ship is less than the minimum safe distance from the berth. In this case, the propulsion command under system control is disabled. When the crew attempts to set propulsion parameters that exceed the emergency maximum power, the manual propulsion command is intercepted to ensure that the crew's operation does not exceed the physical limits of the propulsion system. After the crew maneuvers the ship to a safe distance, the remote control takeover mechanism is unlocked, and the propulsion system is restored to system control, verifying the human-machine interaction safety logic and permission boundaries of the propulsion system.

[0082] The simulation results for all three scenarios met expectations, proving that the method of the present invention can effectively verify the safety of the system and the overall berthing control logic, expose potential logical defects, and ensure that the control logic meets the expected functional safety requirements.

[0083] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for verifying the expected functional safety control logic of a conditionally autonomous, minimally staffed vessel, characterized in that: Includes the following steps: S1. Define the target operational scenario of conditionally autonomous navigation vessels with fewer personnel, clarify the scenario boundary conditions, core entities and physical constraints, and determine the verification scope as the control logic security verification within the scenario. S2. Using system theory process analysis methods, conduct system-level safety analysis on the target operation scenario of conditionally autonomous navigation vessels with fewer personnel, identify system-level losses and dangers, derive system-level safety constraints, construct a hierarchical control structure, identify unsafe control behaviors and transform them into verifiable positive refined safety constraints. S3. Establish standardized mapping rules from positive refined security constraints to formal models; S4. Based on the standardized mapping rules of the formal model, a three-layer progressive refinement strategy is adopted to construct the formal model, as follows: the basic boundary of ship kinematics is established through the physical context layer, the functional control layer introduces control authority and actuator safety interlock, and the collaborative interaction layer introduces shore-based communication and dynamic authority transfer logic. S5. Generate and resolve the proof obligations for each layer of formal model, and mathematically verify the invariant preservation and refinement correctness; verify the effectiveness of the security mechanism in dynamic scenarios through formal model simulation, and complete the expected functional safety verification of the control logic.

2. The verification method according to claim 1, characterized in that, In step S1: The target operational scenarios include autonomous docking scenarios; The boundary conditions include the size and maneuverability parameters of the vessel when berthing without tugboat assistance; The core entities include a shore-based control center, a shipboard intelligent control system, onboard crew members, and actuators. The physical constraints include threshold values ​​for ship physical parameters such as ship speed, propulsion power, and rudder angle.

3. The verification method according to claim 1, characterized in that: The system-level security analysis described in step S2 specifically includes: System-level analysis: Identify system-level losses that need to be avoided in the ship operation system, including ship damage, personal injury and infrastructure damage, deduce the system-level hazards that lead to the losses, and generate system-level safety constraints based on the hazards; Construct a hierarchical control structure: Construct a hierarchical feedback control structure that includes a shore-based control center, a shipboard intelligent control system, shipboard crew members and actuators, and clarify the control flow, feedback path and allocation of authority and responsibility at each level; Identifying unsafe control behaviors: Based on the process analysis method of system theory, four categories of unsafe control behaviors are identified: failure to provide control behavior leads to danger, provision of control behavior leads to danger, incorrect timing of control behavior, and incorrect duration of control behavior. All control actions are traversed to identify unsafe control behaviors. Derivation of safety constraints: Based on the constructed hierarchical control structure, the control actions of each controller are identified one by one, the unsafe situations of each control action under different operating scenarios are analyzed, and unsafe control behaviors are determined; the source of each identified unsafe control behavior is traced, the correlation with system-level hazards is established, and each unsafe control behavior is transformed into verifiable and refined safety constraints.

4. The verification method according to claim 1, characterized in that: The standardized mapping rule mentioned in step S3 is as follows: Static mapping: Abstracts the physical entities in the control structure of the system's theoretical process analysis method into a set in the formal model context, defines the threshold of ship physical parameters as constants, and defines inviolable physical laws as axioms; Dynamic mapping: Mapping the ship's motion state, control authority state, and system operation mode into state variables in the formal model machine, and modeling control command sending, authority transfer, and state update operations as events that trigger state transitions; Security rule mapping: Maps global system-level security constraints to invariants of a formal model machine, ensuring that all reachable states of the system satisfy the constraint, and maps the preconditions for event execution to guards of the event.

5. The verification method according to claim 1, characterized in that: The three-layer progressive refinement strategy described in step S4 is as follows: Through the physical context layer, the basic variables of ship kinematics and their physical value ranges are defined, and abstract environmental evolution and actuator setting events are established; By introducing control source variables on the basis of the physical context layer through the functional control layer, the system autonomous control and crew manual control are distinguished; the abstract actuator events are refined into two independent events: system control and crew control, and dynamic safety constraints are added to the actuator output. Through the collaborative interaction layer, permission mode variables and communication status variables are introduced on the basis of the functional control layer. Shore-based remote control permission application, communication timeout handling, and emergency takeover events are added to verify the permission transfer logic and fault safety mechanism in a distributed human-machine collaboration scenario.

6. The verification method according to claim 5, characterized in that... In the functional control layer: Adding invariants ensures that when the control source is the system, the thrust, rudder angle, and lateral thrust do not exceed the dynamic safety limits calculated in real time based on the current speed and distance from the target; Adding an event guard ensures that the current ship status meets all safety conditions for autonomous control before permissions are transferred from the crew to the system, and prohibits the transfer of unsafe states to the autonomous system.

7. The verification method according to claim 5, characterized in that: In the collaborative interaction layer: Add invariants to ensure that the control source in remote mode must be the system and that the ship's speed does not exceed the operating threshold set on shore. Add an event guard to ensure that remote control permission requests can only be executed when communication is normal, the ship is in a safe state, and the current mode is local. Add an emergency takeover event triggered by communication timeout to ensure that the system automatically degrades to crew local control mode after communication is interrupted.

8. The verification method according to claim 1, characterized in that: The verification of the proof obligation mentioned in step S5 specifically includes: The formal modeling platform is used to automatically generate proof obligations for each refinement layer, including proofs of invariant preservation, proofs of refinement correctness, and proofs of event feasibility. For proof obligations that cannot be resolved by the automatic prover, logical derivation is completed by manually instantiating axioms and assumptions, ensuring that all proof obligations are resolved. This mathematically guarantees that the system will not violate the safety constraints of the derivation under all possible state transitions.

9. The verification method according to claim 1, characterized in that: The model simulation verification mentioned in step S5 specifically includes: An executable simulation environment is built using a formal modeling platform, which instantiates abstract constants into specific ship physical parameters. Three progressive verification scenarios are designed: shore-based constraint and physical interlock verification, security degradation verification under communication failure, and human-computer interaction and permission boundary verification. By interactively triggering event sequences, observe the system state transition trajectory to verify the effectiveness of the system's safety mechanisms under normal operation, fault conditions, and emergency situations.

10. The verification method according to claim 1, characterized in that: The target operating scenarios include, but are not limited to, autonomous berthing, autonomous unberthing, obstacle avoidance, and navigation in open water. The method can be extended to different unmanned conditionally autonomous navigation vessel operating scenarios by adjusting the scenario boundary conditions and extracting safety constraints in a targeted manner. The controlled architecture of the conditionally autonomous vessel with reduced manpower consists of a three-tiered control system: a shore-based control center, a shipboard intelligent control system, and a crew member on board. It supports three operating modes: local manual, local autonomous, and remote autonomous.

Images