Ship driving control mode automatic control system and control method

Abstract

The invention discloses an automatic control system and method for a ship driving control mode. The system comprises a plurality of driving control mode instruction units, a power execution unit, a man-machine interaction unit and a power domain processing unit, and the power domain processing unit is connected with the driving control mode instruction units, the power execution unit and the man-machine interaction unit through a heterogeneous communication network. The control unit is configured to receive ship propulsion control instructions and self fault information from each driving control mode instruction unit, real-time operation parameters from the power execution unit and a driving control mode request from the man-machine interaction unit; arbitration is carried out according to a preset arbitration rule so as to determine a current unique effective driving control mode; and based on the effective driving control mode, the corresponding ship propulsion control instruction is issued to a power execution unit to be executed so as to drive a ship propulsion system. Through centralized intelligent arbitration, the uniqueness and safe takeover of the control right are ensured, and the reliability, the safety and the operation traceability of the system are improved.

Description

Technical Field

[0001] This invention belongs to the field of ship intelligent control technology, and more specifically, relates to an automatic control system and control method for ship driving mode. Background Technology

[0002] With the rapid development of the shipbuilding industry towards intelligence and electrification, the requirements for ship navigation control have upgraded from the traditional "single local manual operation" to "multi-scenario, multi-entity collaborative control". To adapt to industry needs such as remote scheduling, unmanned navigation tests, and efficient operation and maintenance, modern ships generally need to integrate four core navigation control modes: first, the local manual mode for emergency engine room operations (relying on the local operating unit to directly control the propulsion system); second, the remote control mode operated by the pilot in the bridge (meeting the needs of precise manual control in regular navigation); third, the autonomous navigation mode based on environmental perception and path planning (achieving unmanned navigation through intelligent algorithms); and fourth, the cloud-based remote control mode relying on the cloud platform (supporting scenarios such as shore-based remote scheduling and fleet collaboration).

[0003] However, the coexistence of multiple driving modes has also brought about technical bottlenecks in core control management. Existing technical solutions have not yet formed a mature collaborative control system, and mainly have the following key defects:

[0004] The decentralized control architecture poses significant risks of "multiple command centers": Existing solutions often employ simple "point-to-point" switching logic (such as the autonomous navigation unit directly issuing commands to the motor controller) or set up independent mode switches in different locations on the ship (such as mode switching buttons on the bridge and engine room), failing to construct a unified core control unit on the ship. Each control mode acts as an "independent command node," directly issuing control commands to the propulsion execution layer (such as the motor controller and battery management unit). However, the execution layer itself lacks intelligent arbitration capabilities—when multiple modes send commands simultaneously (such as conflicts between cloud-based remote control and autonomous navigation commands) or when mode switching is not seamless, the ship's propulsion system is prone to responsive chaos (such as speed fluctuations and abnormal steering), seriously threatening navigation safety.

[0005] Emergency response failures and insufficient safety redundancy: In scenarios involving system failures (such as a failure of the environmental perception module during autonomous navigation) or emergency takeovers (such as the need for manual local obstacle avoidance due to sudden obstacles), existing distributed architectures lack a "priority scheduling mechanism" and a "forced switching channel." For example, local operating units need to transmit signals through multiple levels to cover the control commands for autonomous navigation, resulting in delays in emergency takeover responses. Some solutions even lack unified control logic, leading to situations where "high-priority modes (such as local emergency control) cannot interrupt low-priority modes (such as cloud remote control)," creating potential safety hazards such as collisions and loss of control.

[0006] The existing solution suffers from unclear definition of responsibilities and poor traceability: it does not uniformly record and arbitrate the sending of commands, switching requests, and execution results for each driving control mode. When control anomalies occur (such as the propulsion system speed deviating from the command), it is impossible to determine whether the cause is an error in a command of a certain mode, a loophole in the switching logic, or a failure in the execution layer. This makes it impossible to accurately determine responsibility and brings great difficulties to accident investigation and maintenance.

[0007] Lack of security verification and degradation mechanisms: For "non-local manual modes" such as autonomous navigation and cloud remote control, existing solutions often do not have strict identity verification procedures, which poses a risk of unauthorized terminals accidentally accessing the system and malicious control. At the same time, when a certain advanced mode (such as autonomous navigation) cannot continue to run due to a malfunction, the system cannot automatically degrade to a safe mode (such as remote control from the control console), and manual intervention is required to restore control, which further reduces the reliability of navigation.

[0008] In summary, existing technologies are insufficient to meet the core requirements of "unique control, timely response, clear responsibilities, and safety redundancy" in multi-driver control modes. There is an urgent need for a centralized control system with unified arbitration capabilities and hierarchical priority management to solve the safety and efficiency issues in multi-mode collaboration. Summary of the Invention

[0009] The purpose of this invention is to propose an automatic control system and method for ship driving modes, which solves the technical problems of multi-mode command conflicts, emergency response failures, unclear division of responsibilities, and lack of advanced mode safety verification caused by the lack of a unified core arbitration unit in the existing distributed architecture of ships with multiple driving modes. It realizes centralized intelligent arbitration, ensures the uniqueness of control and safe takeover, and improves system reliability, security and operational traceability.

[0010] To achieve the above objectives, in a first aspect, the present invention proposes an automatic control system for ship navigation modes, comprising:

[0011] Multiple driving mode command units are used to generate ship propulsion control commands corresponding to the driving mode;

[0012] Power actuator, used to drive the ship's propulsion system;

[0013] The human-machine interaction unit is used to send driving mode requests and receive and display real-time status information of the system;

[0014] The power domain processing unit is connected to all the driving control mode command units, the power execution units, and the human-machine interaction units via a heterogeneous communication network. The power domain processing unit is configured as follows:

[0015] It receives ship propulsion control commands and its own fault information from each of the driving mode command units, real-time operating parameters from the power execution unit, and driving mode requests from the human-machine interaction unit;

[0016] Arbitration is conducted according to preset arbitration rules to determine the only valid driving mode at present;

[0017] Based on the effective driving mode, the corresponding ship propulsion control command is sent to the power execution unit to drive the ship propulsion system.

[0018] Optionally, the driving mode command unit includes:

[0019] The local operation control unit is located in the engine room, the bridge remote control unit is located in the bridge, the autonomous navigation control unit is located in the bridge, and the ship's remote terminal communicates with the cloud.

[0020] The driving control mode corresponding to the local operation control unit is the local operation mode;

[0021] The driving control mode corresponding to the remote control unit of the driver's console is the driver's console remote control mode;

[0022] The autonomous navigation control unit corresponds to the autonomous navigation mode.

[0023] The control mode corresponding to the ship's remote terminal is the cloud-based remote control mode.

[0024] Optionally, the heterogeneous communication network includes:

[0025] Ethernet is used to connect the local operation control unit, the control console remote control unit, the autonomous navigation control unit, the ship-side remote terminal, the human-machine interface unit, and the power domain processing unit;

[0026] A hard-wired direct-connect circuit is used to connect the local operation control unit, the human-machine interaction unit, and the power domain processing unit;

[0027] A controller area network bus is used to connect the power domain processing unit and the power execution unit.

[0028] Optionally, the power execution unit includes:

[0029] The motor control unit, energy management unit, and battery management unit, all connected to the power domain processing unit via the controller area network bus, are used to perform motor drive, energy distribution, and battery status monitoring, respectively.

[0030] The real-time operating parameters include:

[0031] The motor control unit contains information on motor speed, torque, temperature, and fault information;

[0032] The power grid load, fault information, and power distribution status information of the energy management unit;

[0033] The battery management unit displays the battery's state of charge, health status, allowable charge / discharge power, temperature, and fault information.

[0034] Optionally, the preset arbitration rules include:

[0035] Mode switching priority and conditional switching logic;

[0036] Operation commands transmitted via the hardwired direct-connect circuit have the highest real-time response priority.

[0037] The operation instructions include: an emergency stop signal, a local operation mode request, and a local remote control permission signal issued by the local operation control unit, as well as an emergency stop signal issued by the human-machine interaction unit.

[0038] Optionally, the mode switching priority includes:

[0039] The local operating mode has the highest switching priority and can interrupt and take over any other driving control mode;

[0040] The switching priority of the remote control mode on the control panel is higher than that of the autonomous navigation mode;

[0041] The autonomous navigation mode has a higher priority than the cloud-based remote control mode.

[0042] Optionally, the conditional switching logic, with "whether local remote control is allowed" as the general premise, defines the switching conditions between each driving control mode, including:

[0043] During system initialization, if remote control is not allowed locally, the system will enter the local operation mode; if it is allowed, the system will default to the remote control mode of the control panel.

[0044] To switch from the local operation mode to the driver control console remote control mode, the following conditions must be met simultaneously: there is no fault preventing switching from the driver control console remote control mode, local remote control is allowed, and the driver control mode request is a driver control console remote control mode request.

[0045] To switch from the local operation mode, the console remote control mode, or the autonomous navigation mode to the cloud remote control mode, the following conditions must be met simultaneously: the ship's remote terminal identity verification is successful, there is no cloud remote control mode switching failure, local remote control is allowed, and the console mode request is a cloud remote control mode request.

[0046] To switch from the local operation mode, the console remote control mode, or the cloud remote control mode to the autonomous navigation mode, the following conditions must be met simultaneously: the autonomous navigation control unit identity verification is successful, there is no fault prohibiting switching to autonomous navigation mode, local remote control is allowed, and the driving mode request is an autonomous navigation mode request.

[0047] To switch from the remote control mode of the control panel, the autonomous navigation mode, or the cloud remote control mode to the local operation mode, the following conditions must be met: local remote control is not allowed, or the control mode request is a local operation mode request.

[0048] Switching from the autonomous navigation mode or the cloud remote control mode to the console remote control mode requires the following conditions to be met: there is no console remote control mode switching failure and the control mode request is a console remote control mode request, or there is an autonomous navigation mode / cloud remote control mode switching failure, or the control mode request is a console remote control mode emergency request.

[0049] Optionally, the dynamic domain processing unit is further configured to:

[0050] When responding to a request to switch to the autonomous navigation mode or the cloud remote control mode, the corresponding identity verification process is executed first, and subsequent switching condition judgments are only performed after the verification is passed.

[0051] Optionally, the dynamic domain processing unit is further configured to:

[0052] The effective driving control mode, system fault information, mode switching prompts, and real-time operating parameters are fed back to the human-machine interaction unit for display in real time, and the effective driving control mode is fed back to the control console remote control unit, the autonomous navigation control unit, and the ship-side remote terminal.

[0053] Secondly, this invention proposes an automatic control method for ship navigation modes, based on the automatic control system for ship navigation modes described in any one of the first aspects, comprising:

[0054] Obtain the ship propulsion control commands and its own fault information from each of the driving mode command units, and the driving mode requests from the human-machine interaction unit;

[0055] Based on the driving mode request and the fault information of each driving mode command unit, arbitration is performed according to the preset arbitration rules to determine the current unique valid driving mode.

[0056] Based on the effective driving mode, the corresponding ship propulsion control command is sent to the power execution unit to drive the ship propulsion system.

[0057] The beneficial effects of this invention are as follows: By establishing a comprehensive connection with various control mode command units, power execution units, and human-machine interaction units through a heterogeneous communication network, with the power domain processing unit as the core, it can centrally acquire ship propulsion control commands under multiple modes, fault information of each command unit, real-time operating parameters of the power system, and control mode requests from human-machine interaction. Then, by filtering and determining the currently unique and valid control mode through preset arbitration rules, it completely solves the command conflict problem caused by multiple modes of "multiple commands" in existing distributed control architectures, ensuring the uniqueness and accuracy of ship propulsion control. Simultaneously, the arbitration process fully combines command unit fault information with power... The power execution unit's operating status can be quickly switched to an effective mode in case of abnormal or emergency conditions in a certain control mode, avoiding chaotic response of the propulsion system and significantly improving the safety redundancy of ship navigation. In addition, the human-machine interaction unit's display of real-time status and transmission of mode requests, combined with the arbitration decision of the power domain processing unit, can fully present the control mode switching and command execution process, clearly define operational responsibilities, and reduce the complexity of fault diagnosis and liability determination. Finally, based on the effective control mode, precise commands are issued to the power execution unit, ensuring that the ship's propulsion system always operates stably according to compliant commands, further enhancing the overall reliability and operational adaptability of the ship's control system.

[0058] The system of the present invention has other features and advantages that will be apparent from or will be set forth in detail in the accompanying drawings and following detailed description, which together serve to explain the particular principles of the invention. Attached Figure Description

[0059] The above and other objects, features and advantages of the present invention will become more apparent from the accompanying drawings, in which like reference numerals generally denote like parts.

[0060] Figure 1 A schematic diagram of an automatic control system for ship driving mode according to Embodiment 1 of the present invention is shown.

[0061] Figure 2 A schematic diagram of the network architecture of an automatic control system for ship driving mode according to Embodiment 1 of the present invention is shown.

[0062] Figure 3 A schematic diagram of the functional architecture of an automatic control system for ship driving mode according to Embodiment 1 of the present invention is shown.

[0063] Figure 4 A schematic diagram of the driving mode switching logic according to Embodiment 1 of the present invention is shown. Detailed Implementation

[0064] The invention will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0065] Example 1

[0066] like Figure 1 As shown, this embodiment provides an automatic control system for ship steering mode, including:

[0067] Multiple driving mode command units are used to generate ship propulsion control commands corresponding to the driving mode;

[0068] Power actuator, used to drive the ship's propulsion system;

[0069] The human-machine interaction unit is used to send driving mode requests and receive and display real-time status information of the system;

[0070] The power domain processing unit is connected to all driving mode command units, power execution units, and human-machine interaction units via a heterogeneous communication network. The power domain processing unit is configured as follows:

[0071] It receives ship propulsion control commands and its own fault information from each driving mode command unit, real-time operating parameters from the power execution unit, and driving mode requests from the human-machine interaction unit.

[0072] Arbitration is conducted according to preset arbitration rules to determine the only valid driving mode at present;

[0073] Based on the effective driving mode, the corresponding ship propulsion control commands are sent to the power execution unit for execution to drive the ship propulsion system.

[0074] Specifically, the core of the ship handling mode automatic control system constructed in this embodiment lies in establishing a centralized and intelligent control architecture to coordinate and manage diverse ship handling command sources. The system mainly comprises four functional modules: multiple handling mode command units, a power execution unit, a human-machine interface unit, and a power domain processing unit as the control center.

[0075] The driving mode command unit is the source of various control commands for the system. Each unit is specifically responsible for generating ship propulsion control commands corresponding to its specific driving mode, such as local manual operation, remote control from the control console, intelligent autonomous navigation, or cloud-based remote control. The power execution unit is the final executor of the commands, responsible for receiving and converting the control commands into actual physical actions, thereby driving the ship's propulsion system. The human-machine interface unit serves as the main interface between the crew and the system. On the one hand, it receives driving mode switching requests from the crew; on the other hand, it is responsible for centrally receiving and visually displaying real-time status information from various parts of the system, such as the current driving mode, equipment health status, and energy status, thereby achieving status monitoring and interactive control.

[0076] The power domain processing unit (PDU) is the central hub for the entire system's integration and scheduling. It connects to all the aforementioned driving mode command units, power execution units, and human-machine interface units via a heterogeneous communication network (integrating various communication methods with varying degrees of reliability and real-time performance, such as Ethernet, Controller Area Network (CLAN) bus, and hardwired direct connections). The PDU is programmed to execute a complete closed-loop control process: First, it continuously receives and aggregates propulsion control commands from various command units, along with its own reported fault status information, real-time operating parameters from the power execution units (such as motor speed, torque, and battery status), and operator mode switching requests from the human-machine interface unit. Second, based on a pre-set arbitration rule that incorporates priority logic and safety conditions, it comprehensively analyzes, judges, and makes decisions regarding all these inputs. Its core output is determining the single, valid driving mode that the entire system should follow at the current moment. Finally, based on this arbitration-determined mode, the PDU selects the corresponding, valid ship propulsion control command and accurately sends it to the power execution unit via the network, thereby achieving precise, safe, and conflict-free drive control of the ship's propulsion system.

[0077] like Figure 2 As shown, in this embodiment, the driving mode command unit includes:

[0078] The local operation control unit is located in the engine room, the bridge remote control unit is located in the bridge, the autonomous navigation control unit is located in the bridge, and the ship's remote terminal communicates with the cloud.

[0079] The driving control mode corresponding to the local operation control unit is the local operation mode;

[0080] The driving control mode corresponding to the remote control unit on the driver's console is the remote control mode on the driver's console.

[0081] The autonomous navigation control unit corresponds to the autonomous navigation mode.

[0082] The control mode corresponding to the ship's remote terminal is cloud-based remote control mode.

[0083] Specifically, in this embodiment, the system's driving control mode command unit is concretized into four physically and logically independent control entities, each carrying a specific driving control authority, collectively constituting the command source for the ship's diversified maneuvering. These units are purposefully deployed at different locations on the ship according to their functional positioning and control characteristics:

[0084] Local Operation Control Unit: This unit is located inside the ship's engine room and is the highest priority control node in the system design. Its corresponding local operation mode represents the most basic and reliable control level, and is typically activated during system commissioning, emergency fault handling, or when direct intervention at the engine room is required, ensuring absolute control of the propulsion system by personnel at the lowest level.

[0085] Bridge Control Remote Control Unit: This unit is located on the ship's bridge (bridge control console) and is the most important control interface for regular navigation. Its corresponding bridge control remote control mode is the standard mode in which crew members remotely operate the ship's propulsion system from the wheelhouse via electronic or telemetry devices, achieving centralized control across the engine room and bridge.

[0086] Autonomous navigation control unit: This unit, also integrated into the bridge area, is the core embodiment of the ship's intelligent capabilities. Its corresponding autonomous navigation mode relies on the perception, decision-making, and planning algorithms built into or connected to this unit. It can automatically generate and issue propulsion control commands based on environmental information and navigation tasks, representing a high level of automated driving capability.

[0087] Shipboard remote terminal: This unit serves as a hub connecting ship and shore information and is typically located in the bridge or a closely related communication compartment. Its corresponding cloud-based remote control mode uses this terminal to securely communicate with the cloud control center, enabling shore-based operators to exercise beyond-line-of-sight control of the ship's propulsion system via a remote network under certain authorization and conditions. This provides the possibility for remote monitoring, decision support, or remote operation in specific scenarios.

[0088] These four units and their corresponding four driving modes together define a complete control spectrum from local to remote and from manual to intelligent, providing the central arbiter (power domain processing unit) with clear and discrete command source selection. This forms the physical and logical basis for the entire system to achieve multi-mode collaboration and safety arbitration.

[0089] like Figure 2 As shown, in this embodiment, the heterogeneous communication network includes:

[0090] Ethernet is used to connect the local operation control unit, the bridge remote control unit, the autonomous navigation control unit, the shipboard remote terminal, the human-machine interface unit, and the power domain processing unit;

[0091] Hardwired direct-connect circuitry is used to connect the local operation control unit, human-machine interface unit, and power domain processing unit;

[0092] The controller area network bus is used to connect the power domain processing unit and the power execution unit.

[0093] Specifically, in this embodiment, the system relies on a carefully designed heterogeneous communication network to achieve reliable data exchange and command transmission between various functional units. This network does not employ a single communication protocol, but rather integrates three different communication technologies based on the real-time performance, reliability requirements, and functional safety levels of data transmission, forming a complementary hybrid communication architecture.

[0094] First, Ethernet, as the system's high-speed data backbone, handles most of the communication tasks with the highest non-real-time requirements but large data volumes or complex interactions. It connects the local operation control unit, the bridge remote control unit, the autonomous navigation control unit, the shipboard remote terminal, the human-machine interface unit, and the central power domain processing unit. Ethernet's high bandwidth is ideal for transmitting control mode commands, rich system status information, human-machine interaction data, and information flows requiring complex interactions such as identity verification and fault reporting, ensuring the smoothness of intelligent control and status monitoring.

[0095] Secondly, the hardwired direct-connect circuit, as the communication path with the highest reliability guarantee, is specifically used to transmit critical signals with extremely high requirements for real-time performance and determinism. It directly connects the local operation control unit, the human-machine interface unit, and the power domain processing unit. This physically independent channel primarily carries emergency local operation commands and local mode requests from the local operation control unit, as well as emergency stop signals from the human-machine interface unit. This design ensures that, even in extreme circumstances where other networks fail, these highest-priority commands concerning ship safety can still be received and executed by the central processing unit without delay or condition, forming the physical foundation of the system's fail-safe design.

[0096] Finally, the Controller Area Network (CAN) bus serves as an industry-standard fieldbus connecting the central control unit and the underlying actuators. It is specifically designed to connect the power domain processing unit and the power execution unit (including the motor control unit, energy management unit, and battery management unit). With its high reliability, strong anti-interference capabilities, and mature error detection mechanism, the CAN bus is well-suited for use in power systems with complex electromagnetic environments and extremely high requirements for the stability and determinism of control commands, ensuring that the final, arbitrated propulsion commands are accurately and reliably delivered to the execution end.

[0097] This heterogeneous communication network architecture, by separating the regular data flow from the safety-critical command flow at the logical and physical levels, not only optimizes the overall communication efficiency of the system, but more importantly, provides solid physical layer support for realizing multi-level priority management in the preset arbitration rules. It is a key technical support for building a centralized driving control system that is both intelligent and efficient as well as safe and reliable.

[0098] like Figure 3 As shown, in this embodiment, the power execution unit includes:

[0099] The motor control unit, energy management unit, and battery management unit are all connected to the power domain processing unit via the controller area network bus, and are used to perform motor drive, energy distribution, and battery status monitoring, respectively.

[0100] Real-time operating parameters include:

[0101] The motor control unit displays motor speed, torque, temperature, and fault information.

[0102] The power grid load, fault information, and power distribution status information of the energy management unit;

[0103] The battery management unit displays the battery's state of charge, health status, allowable charge / discharge power, temperature, and fault information.

[0104] Specifically, in this embodiment, the power execution unit, as the core drive and status monitoring carrier of the ship's propulsion system, adopts a "functional modularization and data interconnection" design. It consists of three core modules: a motor control unit, an energy management unit, and a battery management unit. All three units establish a stable connection with the power domain processing unit through a controller area network bus (CAN bus). The CAN bus has the characteristics of high reliability, strong anti-interference ability, and support for multi-node data interaction. It can adapt to the complex navigation environment of ships (such as vibration and electromagnetic interference), ensuring the real-time transmission of status data between each unit and the power domain processing unit and the accurate issuance of control commands. This provides the power domain processing unit with real and timely hardware status basis for arbitration decisions.

[0105] From a functional perspective, the three units each perform their respective duties and form a collaborative support: the motor control unit is the "direct executor" of the ship's propulsion power. Its core task is to receive ship propulsion control commands (such as target speed and forward / reverse commands) issued by the power domain processing unit. By adjusting parameters such as the power supply voltage and current of the motor, it drives the ship's propulsion motor to operate, thereby driving propulsion components such as the propeller to achieve speed and heading control of the ship; the energy management unit acts as the "scheduler" of the ship's energy system, responsible for real-time monitoring of the energy supply and demand status of the ship's entire power grid. On the one hand, it rationally allocates energy according to the power requirements of various electrical equipment (such as propulsion motors, navigation systems, and communication equipment) to avoid power grid overload or energy waste. On the other hand, it monitors the stability of the power grid operation in real time and promptly identifies and records abnormal power grid states; the battery management unit, as the "guardian" of the ship's power source (such as the power battery pack), focuses on the dynamic monitoring and safety protection of the battery status. By collecting the core parameters of the battery, it ensures that the battery is charged and discharged within a safe range, and at the same time evaluates the battery's performance and lifespan, providing key references for the power domain processing unit to judge the ship's endurance and the feasibility of continuous operation of the propulsion system.

[0106] Correspondingly, the real-time operating parameters fed back from the power execution unit to the power domain processing unit also form a refined, multi-dimensional dataset around the functions of the three units: For the motor control unit, the parameters fed back are directly related to the power output and operational safety of the propulsion system, including motor speed (intuitively reflecting the ship's current speed, which needs to match the target speed in the steering command), motor torque (determining the magnitude of propulsion force and affecting the ship's acceleration or heavy-load sailing capability), motor temperature (real-time monitoring to ensure the motor is within its safe operating temperature range, preventing overheating that could lead to motor burnout or performance degradation), and fault information generated during motor operation (such as fault codes corresponding to motor stall, winding short circuit, sensor failure, etc., facilitating rapid fault location); For the energy management unit, the parameters fed back focus on the overall status of the ship's energy system, including grid load (the total power consumption of all electrical equipment, determining whether the grid is overloaded or lightly loaded), grid fault information (such as grid voltage fluctuations, line short circuits, power distribution module failures, etc.). Information includes potential risks to the energy system, power distribution status information (actual supply voltage and current of each electrical device, reflecting whether the power distribution is balanced and whether there are local power supply anomalies); for the battery management unit, the feedback parameters are related to the safety and range of the power source, specifically including the state of charge (SOC, i.e., the percentage of remaining battery charge, which directly determines the remaining range of the ship), state of health (SOH, i.e., the ratio of the current performance of the battery to its initial performance, reflecting the degree of battery aging and affecting the charging and discharging efficiency and lifespan of the battery), allowable charging and discharging power (the maximum charging and discharging power that the battery can safely withstand under the current state, preventing overcharging and over-discharging from causing battery damage or fire risk), battery temperature (a core environmental parameter for battery operation, which needs to be maintained within a specific range to ensure charging and discharging performance; too high or too low a temperature will cause battery performance degradation or safety hazards), and battery fault information (such as uneven voltage of individual battery cells, battery pack leakage, temperature sensor failure, etc., providing a basis for battery maintenance and safety warnings).

[0107] In this embodiment, the preset arbitration rules include:

[0108] Mode switching priority and conditional switching logic;

[0109] Operation commands transmitted via hardwired direct-connect circuits have the highest real-time response priority.

[0110] The operation instructions include: emergency stop signals issued by the local operation control unit, local operation mode requests and local remote control permission signals, as well as emergency stop signals issued by the human-machine interaction unit.

[0111] Specifically, in this embodiment, the preset arbitration rules are the core algorithmic basis for the power domain processing unit to make intelligent decisions. Their design aims to ensure clear, secure, and orderly control. This rule system mainly consists of two complementary parts: mode switching priority and conditional switching logic. Mode switching priority is a static, predefined hierarchical relationship that establishes the relative order of different driving modes when vying for control, providing a basic criterion for quickly resolving command conflicts. Conditional switching logic, on the other hand, is a dynamic, state-based decision-making framework that specifies in detail under what specific conditions (such as system state, fault conditions, operator requests) the system can or must switch between different modes, ensuring that the switching behavior not only conforms to permissions but also adapts to the current operating environment and security situation.

[0112] Crucially, this rule assigns the highest real-time response priority to operational commands transmitted via hardwired direct-connect circuits at the physical level. This design embodies the principle of system fail-safety, ensuring that the most critical control commands can still be responded to instantly even if any other part of the system experiences delays, congestion, or even failure. These highest-priority operational commands are explicitly defined as several signals concerning the ship's absolute safety, primarily including: emergency stop signals from the local operation control unit (for emergency shutdown on the engine room side), local operation mode requests (mandatory takeover to local mode), and local remote control permission signals (master switch for remote functions); and emergency stop signals from the human-machine interface unit (bridge). By placing these two critical human-machine interface emergency commands at the top of the priority list, the arbitration rule constructs an uninterrupted safety channel at both the logical and physical levels, ensuring that human intervention in emergency situations is absolutely and reliably effective, thus laying a solid safety foundation for the entire multi-mode intelligent control system.

[0113] In this embodiment, the mode switching priority includes:

[0114] The local operation mode has the highest switching priority and can interrupt and take over any other driving control mode;

[0115] Switching to remote control mode on the control panel has a higher priority than switching to autonomous navigation mode;

[0116] The autonomous navigation mode takes precedence over the cloud-based remote control mode.

[0117] Specifically, in the ship's automatic control system for navigation modes in this embodiment, the setting of mode switching priorities is based on the core principles of "maximizing safety redundancy, optimizing control response, and centralizing manual intervention," forming a clear and rigid hierarchical order. This ensures that different navigation modes can avoid control conflicts when requesting switching, and that control is preferentially delivered to the most reliable control entity in emergency or complex situations. Among them, the local operation mode is given the highest switching priority. This design stems from its positioning as the "last line of defense" for the ship's propulsion system. The local operation mode is directly associated with the physical control unit in the engine room and is connected to the power domain processing unit via hardwired connections. It is not affected by the stability of communication links such as Ethernet and CAN bus. Even if other modes (such as autonomous navigation and cloud remote control) become abnormal due to communication interruption, algorithm failure, or module failure, the pilot can still initiate a switching request through the local operation unit. This request will forcibly interrupt any currently running navigation mode and immediately take over the control of the propulsion system. For example, when the autonomous navigation mode cannot avoid obstacles due to a failure of the environmental perception sensor, the engine room personnel can activate the local operation mode to instantly cut off the autonomous navigation command and achieve emergency avoidance by manually adjusting the propulsion parameters.

[0118] The priority of switching to the remote control mode on the control console is second only to the local operation mode and higher than the autonomous navigation mode. This setting is based on the safety logic that "human control on board is superior to intelligent algorithm control." In the remote control mode, the driver operates directly in the cockpit and can issue propulsion commands by combining real-time sea conditions, visual observation, and experience judgment. Compared with the autonomous navigation mode, which relies on preset algorithms and sensor data, it is better able to cope with sudden and complex scenarios (such as encountering ships at close range or sudden reefs). When the autonomous navigation mode is running, if the driver initiates a request to switch to the remote control mode on the control console through the human-machine interface unit, the power domain processing unit will respond to the request first, terminate the execution of autonomous navigation commands, and transfer control to the control console. At the same time, the human-machine interface unit will prompt the driver to complete the takeover, avoiding risks caused by algorithm decision delays or judgment errors.

[0119] The autonomous navigation mode takes precedence over the cloud-based remote control mode. The core consideration for this prioritization is that "local control response efficiency is superior to remote control." The control unit for autonomous navigation mode is deployed locally on the ship, and the generation and issuance of commands do not rely on the remote communication link between the shore and the ship. This avoids the communication delays, signal interruptions, or network interference problems that cloud-based remote control may face. For example, in offshore areas, if the cloud-based remote control mode experiences command transmission delays due to weak satellite signals, and an autonomous navigation mode switching request is initiated, the power domain processing unit will prioritize the control of the autonomous navigation mode, interrupt the cloud-based remote control commands, and allow the local autonomous navigation system to quickly adjust propulsion parameters based on real-time environmental data, ensuring the continuity and stability of the ship's navigation.

[0120] This hierarchical mode switching priority design essentially constructs a safety control system of "physical local control > onboard manual remote control > local intelligent autonomous control > remote cloud control". It ensures that control can be quickly transferred to the most reliable entity in emergency situations, and avoids control confusion when multiple modes request switching at the same time. It provides a rigid guarantee for the control safety and response timeliness of ships in different navigation scenarios.

[0121] like Figure 4 As shown, in this embodiment, the conditional switching logic, based on the premise of "whether local remote control is allowed," defines the switching conditions between each driving control mode, including:

[0122] During system initialization, if remote control is not allowed locally, the system will enter local operation mode; if it is allowed, the system will default to remote control mode.

[0123] To switch from local operation mode to driver control console remote control mode, the following conditions must be met simultaneously: no fault prohibiting switching to driver control console remote control mode, local remote control is allowed, and the driver control mode request is a driver control console remote control mode request.

[0124] To switch from local operation mode, console remote control mode or autonomous navigation mode to cloud remote control mode, the following conditions must be met simultaneously: the ship's remote terminal identity verification is successful, there is no cloud remote control mode switching failure, local remote control is allowed and the console mode request is a cloud remote control mode request.

[0125] To switch from local operation mode, console remote control mode or cloud remote control mode to autonomous navigation mode, the following conditions must be met simultaneously: the autonomous navigation control unit identity verification is successful, there is no fault prohibiting switching to autonomous navigation mode, local remote control is allowed, and the driving mode request is an autonomous navigation mode request.

[0126] To switch from the console remote control mode, autonomous navigation mode, or cloud remote control mode to the local operation mode, the following conditions must be met: local remote control is not allowed, or the driving mode request is a local operation mode request.

[0127] Switching from autonomous navigation mode or cloud remote control mode to console remote control mode requires the following conditions to be met: there is no console remote control mode switching failure and the control mode request is a console remote control mode request, or there is an autonomous navigation mode / cloud remote control mode switching failure, or the control mode request is an emergency request for console remote control mode.

[0128] Specifically, in the ship driving mode automatic control system of this embodiment, the conditional switching logic takes "whether local remote control is allowed" as the general premise throughout. By clarifying the rigid conditions for switching between each driving mode, a switching system of "safety first, authorized controllable, and fault degradation" is built to ensure that each mode switch is compliant and reliable, and to avoid control confusion or safety risks caused by the lack of conditions.

[0129] The mode determination during system initialization is the starting point for the entire switching logic. This phase directly divides the initial state based on the core premise of "whether local remote control is allowed": If a "local remote control not allowed" signal is detected (usually triggered by a hardware switch of the engine room local operating unit, applicable to scenarios requiring mandatory local control such as near-shore operations and equipment maintenance), the system will directly enter the local operation mode, fundamentally blocking the possibility of enabling all remote modes (chassis remote control, autonomous navigation, cloud remote control), ensuring that the ship's propulsion system is completely controlled by local physical operations; if a "local remote control allowed" signal is detected (usually triggered by a hardware switch of the engine room local operating unit, applicable to scenarios requiring multi-mode coordination such as ocean navigation and routine operations), the system will default to the chassis remote control mode—this design considers both the safety of direct operation by the pilot in the bridge in the chassis remote control mode and reserves a channel for subsequent switching to more advanced autonomous navigation or cloud remote control modes, forming a "safe from the start" control foundation. Simultaneously, in the "local remote control allowed" state, the system can directly enter the local operation mode through the switch corresponding to the "local remote control not allowed" signal in the local operating unit.

[0130] Switching from local operation mode to driver's console remote control mode requires the simultaneous fulfillment of three core conditions, none of which can be omitted: First, there must be no fault preventing switching to driver's console remote control mode. For example, the system must first check whether the hardware (such as the control handle and communication module) and software (such as the command generation algorithm) of the driver's console remote control unit are in normal condition to avoid switching to a faulty mode that would cause control failure. Second, the general premise of "local remote control is allowed" must remain valid. If the local system has already switched to "remote control is not allowed", the switching request will be rejected directly. Finally, the "driving mode request must be a driver's console remote control mode request", meaning that the driver must actively initiate the switching command through the human-machine interface unit to ensure that the switching behavior conforms to the operator's control intention and prevent operational confusion caused by accidental triggering or automatic switching.

[0131] Switching from local operation mode, console remote control mode, or autonomous navigation mode to cloud remote control mode, and vice versa, requires meeting a set of common and stringent conditions. Both types of switching point to an advanced "non-local manual" mode, thus requiring enhanced security authorization and fault diagnosis: common conditions include "local remote control permitted" (general prerequisite), "pilot mode request is a corresponding mode request" (clear control intent), and "no corresponding mode prohibition for switching fault" (ensuring no abnormalities in the target mode's hardware and software); the key condition distinguishing it from other switching is "identity verification passed"—when switching to cloud remote control mode, the ship's remote terminal (TBOX) and the cloud platform must complete two-way identity verification (such as encryption key verification and device unique identifier matching) to prevent unauthorized cloud terminals from maliciously accessing the system; when switching to autonomous navigation mode, the autonomous navigation control unit and the power domain processing unit must complete identity verification (such as unit hardware code matching and algorithm authorization verification) to prevent uncertified autonomous control modules from intervening, thus blocking security risks at the source.

[0132] The switch from remote control mode, autonomous navigation mode, or cloud-based remote control mode to local operation mode reflects the highest priority of local operation mode. It can be triggered by only one of two conditions: First, "remote control is not allowed locally." In this case, regardless of whether the current mode is running normally, the system will forcibly terminate all remote control commands and switch to local operation mode to ensure that control can be quickly returned to local in emergency scenarios (such as remote communication interruption or intelligent algorithm failure). Second, "the navigation mode request is a local operation mode request." That is, the cabin crew actively initiates the switch through the local operation unit. This is suitable for scenarios that require fine manual adjustment (such as ship docking or turning in narrow waters) or troubleshooting remote mode failures. It does not rely on other additional conditions and highlights the safety logic of "local control priority."

[0133] Finally, the switching from autonomous navigation mode or cloud remote control mode to console remote control mode covers two scenarios: active switching and passive degrading, each with different triggering conditions. Active switching requires both a "no console remote control mode switching failure" (ensuring the target mode is available) and a "control mode request is a console remote control mode request" (initiated by the operator), suitable for scenarios where the driver determines that manual intervention is necessary (such as complex sea conditions or route adjustments). Passive degrading is automatically triggered in two situations: first, "an autonomous navigation mode / cloud remote control mode switching failure exists" (such as a failure of the autonomous navigation environmental perception module or a continuous interruption of cloud communication), in which case the system will automatically terminate the fault mode and switch to console remote control mode to avoid loss of control; second, "a control mode request is an emergency request for console remote control mode" (such as an emergency stop button or emergency switch button initiated by the driver), this request has priority and can directly interrupt the autonomous or cloud mode, quickly transferring control to the console, forming a safety closed loop of "degradation upon failure of advanced mode and response upon emergency request".

[0134] In summary, this conditional switching logic, by setting conditions in layers, clarifying trigger scenarios, and strengthening safety verification, not only ensures the orderly switching of each mode, but also ensures the reliable transfer of control in emergency situations, providing rigid rule support for the collaborative operation of multiple ship control modes.

[0135] In this embodiment, the dynamic domain processing unit is further configured as follows:

[0136] When responding to a request to switch to autonomous navigation mode or cloud remote control mode, the corresponding identity verification process is executed first, and subsequent switching condition judgments are only carried out after the verification is successful.

[0137] Specifically, in the ship navigation mode automatic control system of this embodiment, the power domain processing unit uses identity verification as a "pre-emptive safety barrier" in response to requests to switch between autonomous navigation mode and cloud remote control mode. This verification process is explicitly placed before all switching condition judgments. Through strict identity legitimacy verification, unauthorized control units or illegal requests to access advanced navigation modes are blocked at the source, ensuring the security of control over the ship's propulsion system. When the power domain processing unit receives an autonomous navigation mode switching request from the human-machine interface unit (e.g., the pilot initiates an autonomous navigation activation command on the control console) or a cloud remote control mode switching request forwarded by the ship's remote terminal (TBOX) (e.g., a remote control command initiated by a shore-based cloud platform) via a heterogeneous communication network, it does not immediately proceed to subsequent condition judgments such as "whether local remote control is allowed" or "whether there is a mode prohibition fault." Instead, it prioritizes initiating the identity verification process corresponding to the target mode to ensure that the control entity initiating the switching request has legitimate operating authority.

[0138] For identity verification in autonomous navigation mode, the power domain processing unit proactively sends an identity verification request to the autonomous navigation control unit. This request includes preset verification dimensions and encryption rules: First, it verifies the hardware legitimacy of the autonomous navigation control unit by reading the unique device identifier built into the unit (such as hardware serial number or factory code) and comparing it with the "legitimate autonomous navigation device whitelist" pre-stored in the power domain processing unit to confirm that the unit is a certified and compliant device, rather than an unauthorized replacement or illegally accessed third-party unit. Second, it verifies the validity of the software license. The autonomous navigation control unit needs to return the currently running algorithm version information and software license certificate (such as digital signature). The power domain processing unit verifies the validity period of the certificate and the legitimacy of the signature to prevent abnormal autonomous navigation decisions caused by the use of pirated, tampered, or expired algorithms. Finally, it verifies the communication encryption (such as bidirectional data encryption transmission based on a preset key) to confirm that the communication link between the autonomous navigation control unit and the power domain processing unit has not been tampered with, avoiding the transmission of false identity information caused by man-in-the-middle attacks.

[0139] For identity verification in the cloud-based remote control mode, the power domain processing unit uses the shipboard remote terminal (TBOX) as the core interaction object and constructs a multi-level verification mechanism adapted to remote communication scenarios: The first step is device identity verification. The TBOX needs to submit its own device digital certificate (issued by an authoritative institution) to the power domain processing unit. The power domain processing unit verifies the integrity and validity of the certificate chain to confirm that the TBOX is a legitimate remote communication terminal standard on the ship, eliminating the risk of unauthorized TBOX access. The second step is cloud authorization verification. The TBOX needs to forward the authorization token of the cloud platform (such as a temporary access token generated based on the OAuth2.0 protocol). The power domain processing unit will verify the validity period and scope of permissions of the token (such as whether it includes "remote control enable permission") through a preset cloud authorization server interface to ensure that the switching request comes from a cloud platform with legitimate scheduling permissions, rather than a cloud command forged by a malicious third party. The third step is communication link verification. The power domain processing unit will verify the communication protocol between the TBOX and the cloud (such as whether SSL / TLS encrypted transmission is used) and link stability to prevent identity information leakage due to communication eavesdropping or interference, further strengthening the legitimacy verification of remote requests.

[0140] If the identity verification process passes, meaning the identity information and authorization status of the autonomous navigation control unit or the shipboard remote terminal (TBOX) meet the preset rules, the power domain processing unit will proceed to the subsequent switching condition judgment stage. This stage verifies conditions such as "whether local remote control is allowed" and "whether there is a switching prohibition fault in the target mode," ensuring the switching request proceeds while meeting safety and compliance requirements. If identity verification fails (e.g., device identifier not in the whitelist, expired authorization token, invalid digital signature), the power domain processing unit will immediately terminate the current switching request process, refusing to initiate autonomous navigation mode or cloud remote control mode. Simultaneously, it will provide the operator with a "verification failed" message (e.g., interface pop-up, audible and visual alarm) through the human-machine interface unit, and record the specific reason for the failure (e.g., unauthorized autonomous navigation unit, invalid cloud token) in the system log, facilitating subsequent troubleshooting of device authorization or communication link issues by maintenance personnel. This "identity verification first, condition judgment later" design uses identity legitimacy as the first line of defense for enabling advanced navigation control modes, effectively mitigating risks such as unauthorized control and malicious access, providing a robust guarantee for the security of multi-mode collaborative control of the ship.

[0141] In this embodiment, the dynamic domain processing unit is further configured as follows:

[0142] The effective driving mode, system fault information, mode switching prompts, and real-time operating parameters are fed back to the human-machine interaction unit for display, and the effective driving mode is fed back to the remote control unit of the control console, the autonomous navigation control unit, and the ship's remote terminal.

[0143] Specifically, in the ship navigation mode automatic control system of this embodiment, the power domain processing unit not only undertakes the core responsibility of central arbitration and command distribution, but also ensures that the key status of each module of the system and the operator are synchronized in real time through a two-way information feedback mechanism, forming a closed-loop control of decision-making-execution-feedback. The information feedback is mainly divided into two categories: visual feedback to the human-machine interaction unit and collaborative status feedback to the remote control unit of the navigation console, the autonomous navigation control unit, and the ship-side remote terminal. All feedback is based on the principles of real-time performance, accuracy, and relevance to ensure the transparency of system operation and the consistency of collaboration among various units.

[0144] In response to feedback from the human-machine interface unit, the power domain processing unit integrates and transmits four types of core information in real time to ensure that operators can fully grasp the system dynamics and respond quickly: First, effective driving mode information, specifically displaying the currently active driving mode (e.g., local operation mode, autonomous navigation mode, cloud remote control mode), while also indicating the activation time and triggering reason of the mode (e.g., switching from local mode to console mode due to cloud failure), allowing operators to clearly define the current control authority and avoid misoperation due to unclear mode understanding; Second, system fault information, presented according to the source and severity of the fault, including the fault type of each unit (motor control unit, battery management unit, autonomous navigation control unit, etc.) (e.g., motor temperature exceeding the limit, battery SOC too low, autonomous navigation sensor failure), corresponding fault code (facilitating quick reference to the fault manual to locate the problem), and fault level (e.g., warning emergency, emergency faults will be accompanied by audible and visual alarm prompts), helping operators to identify system risks immediately and prioritize handling high-priority faults; Third, mode switching prompt information. This type of information focuses on key nodes of mode switching, including the initiator of the switching request (e.g., the driver initiates a console mode request, or the cloud initiates a remote control mode request), the status of the switching process (e.g., identity verification in progress, waiting for troubleshooting, and successful switching), and the operation instructions after switching (e.g., the driver has switched to console mode, please take over control; autonomous navigation mode is activated; monitor environmental perception data). Especially in emergency switching scenarios (e.g., downgrading from autonomous navigation mode to console mode), the prompts will be highlighted in pop-up windows or highlighted to ensure that the operator can take over in time. Fourth, real-time operating parameters. These parameters are directly related to the operating status of the power execution unit and each command unit, covering motor speed, torque, temperature, battery SOC, SOH, allowable charging and discharging power, grid load, power distribution status, etc., and the parameters will be presented in a visual form such as dashboards, trend charts, and numerical lists (e.g., real-time motor speed curve, battery SOC percentage dashboard), which makes it convenient for operators to intuitively judge whether the system is operating normally. For example, by comparing the target speed with the actual motor speed, deviations in propulsion command execution can be quickly detected.

[0145] Regarding feedback from the control console remote unit, autonomous navigation control unit, and shipboard remote terminal, the power domain processing unit focuses on the core information of the effective control mode. This ensures that each command unit can adjust its operating status according to the current control authority, avoiding command conflicts with the effective mode: For the control console remote unit, upon receiving effective control mode information, if the current effective mode is itself (control console remote mode), it activates functions such as the control handle and command input interface, allowing the driver to issue propulsion commands; if the effective mode is another mode (such as autonomous navigation or cloud remote control), it automatically locks the operating functions, retaining only the emergency switch request button to prevent driver misoperation from interfering with the execution of currently effective commands; for the autonomous navigation control unit, if the effective mode... If the mode is self-contained (autonomous navigation mode), it continuously outputs preset propulsion control commands and synchronizes environmental perception data to the power domain processing unit. If the effective mode switches to another mode (such as the control console or local operation), it immediately pauses command generation and issuance, while saving the current navigation planning data. This data can be quickly restored when control is regained, avoiding response delays caused by recalculation. For ship-side remote terminals (associated with cloud remote control mode), if the effective mode is cloud remote control mode, it is allowed to forward propulsion commands from the cloud platform to the power domain processing unit. If the effective mode is another mode, it automatically blocks the transmission channel of cloud commands and feeds back the status information of the current non-cloud control period to the cloud, preventing control conflicts caused by erroneous commands issued by the cloud.

[0146] This multi-dimensional and targeted information feedback design not only allows operators to achieve visual monitoring and operation guidance through the human-machine interaction unit, but also enables various driving control command units to achieve adaptive collaboration through effective mode feedback. This ensures full transparency of the system's operating status, making it easy for operators to detect and handle anomalies in a timely manner. Furthermore, it avoids problems such as invalid command generation and control struggles through status synchronization, further enhancing the system's security and collaboration. At the same time, it provides complete status data support for subsequent operation traceability (such as fault diagnosis and responsibility determination).

[0147] Example 2

[0148] This embodiment provides an automatic control method for ship navigation mode, based on the automatic control system for ship navigation mode of Embodiment 1, including:

[0149] Obtain ship propulsion control commands and its own fault information from each driving mode command unit, as well as driving mode requests from the human-machine interaction unit;

[0150] Based on the driving control mode request and the fault information of each driving control mode command unit, arbitration is carried out according to the preset arbitration rules to determine the current unique valid driving control mode.

[0151] Based on the effective driving mode, the corresponding ship propulsion control commands are sent to the power execution unit for execution to drive the ship propulsion system.

[0152] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments.

Claims

1. An automatic control system for ship navigation mode, characterized in that, include: Multiple driving mode command units are used to generate ship propulsion control commands corresponding to the driving mode; Power actuator, used to drive the ship's propulsion system; The human-machine interaction unit is used to send driving mode requests and receive and display real-time status information of the system; The power domain processing unit is connected to all the driving control mode command units, the power execution units, and the human-machine interaction units via a heterogeneous communication network. The power domain processing unit is configured as follows: It receives ship propulsion control commands and its own fault information from each of the driving mode command units, real-time operating parameters from the power execution unit, and driving mode requests from the human-machine interaction unit; Arbitration is conducted according to preset arbitration rules to determine the only valid driving mode at present; Based on the effective driving mode, the corresponding ship propulsion control command is sent to the power execution unit to drive the ship propulsion system.

2. The automatic control system for ship navigation mode according to claim 1, characterized in that, The driving mode command unit includes: The local operation control unit is located in the engine room, the bridge remote control unit is located in the bridge, the autonomous navigation control unit is located in the bridge, and the ship's remote terminal communicates with the cloud. The driving control mode corresponding to the local operation control unit is the local operation mode; The driving control mode corresponding to the remote control unit of the driver's console is the driver's console remote control mode; The autonomous navigation control unit corresponds to the autonomous navigation mode. The control mode corresponding to the ship's remote terminal is the cloud-based remote control mode.

3. The automatic control system for ship navigation mode according to claim 2, characterized in that, The heterogeneous communication network includes: Ethernet is used to connect the local operation control unit, the control console remote control unit, the autonomous navigation control unit, the ship-side remote terminal, the human-machine interface unit, and the power domain processing unit; A hard-wired direct-connect circuit is used to connect the local operation control unit, the human-machine interaction unit, and the power domain processing unit; A controller area network bus is used to connect the power domain processing unit and the power execution unit.

4. The automatic control system for ship navigation mode according to claim 3, characterized in that, The power actuation unit includes: The motor control unit, energy management unit, and battery management unit, all connected to the power domain processing unit via the controller area network bus, are used to perform motor drive, energy distribution, and battery status monitoring, respectively. The real-time operating parameters include: The motor control unit contains information on motor speed, torque, temperature, and fault information; The power grid load, fault information, and power distribution status information of the energy management unit; The battery management unit displays the battery's state of charge, health status, allowable charge / discharge power, temperature, and fault information.

5. The automatic control system for ship navigation mode according to claim 4, characterized in that, The preset arbitration rules include: Mode switching priority and conditional switching logic; Operation commands transmitted via the hardwired direct-connect circuit have the highest real-time response priority. The operation instructions include: an emergency stop signal, a local operation mode request, and a local remote control permission signal issued by the local operation control unit, as well as an emergency stop signal issued by the human-machine interaction unit.

6. The automatic control system for ship navigation mode according to claim 5, characterized in that, The mode switching priority includes: The local operating mode has the highest switching priority and can interrupt and take over any other driving control mode; The switching priority of the remote control mode on the control panel is higher than that of the autonomous navigation mode; The autonomous navigation mode has a higher priority than the cloud-based remote control mode.

7. The automatic control system for ship navigation mode according to claim 6, characterized in that, The conditional switching logic, based on the premise of "whether local remote control is allowed," defines the switching conditions between each driving control mode, including: During system initialization, if remote control is not allowed locally, the system will enter the local operation mode; if it is allowed, the system will default to the remote control mode of the control panel. To switch from the local operation mode to the driver control console remote control mode, the following conditions must be met simultaneously: there is no fault preventing switching from the driver control console remote control mode, local remote control is allowed, and the driver control mode request is a driver control console remote control mode request. To switch from the local operation mode, the console remote control mode, or the autonomous navigation mode to the cloud remote control mode, the following conditions must be met simultaneously: the ship's remote terminal identity verification is successful, there is no cloud remote control mode switching failure, local remote control is allowed, and the console mode request is a cloud remote control mode request. To switch from the local operation mode, the console remote control mode, or the cloud remote control mode to the autonomous navigation mode, the following conditions must be met simultaneously: the autonomous navigation control unit identity verification is successful, there is no fault prohibiting switching to autonomous navigation mode, local remote control is allowed, and the driving mode request is an autonomous navigation mode request. To switch from the remote control mode of the control panel, the autonomous navigation mode, or the cloud remote control mode to the local operation mode, the following conditions must be met: local remote control is not allowed, or the control mode request is a local operation mode request. Switching from the autonomous navigation mode or the cloud remote control mode to the console remote control mode requires the following conditions to be met: there is no console remote control mode switching failure and the control mode request is a console remote control mode request, or there is an autonomous navigation mode / cloud remote control mode switching failure, or the control mode request is a console remote control mode emergency request.

8. The automatic control system for ship navigation mode according to claim 7, characterized in that, The dynamic domain processing unit is further configured to: When responding to a request to switch to the autonomous navigation mode or the cloud remote control mode, the corresponding identity verification process is executed first, and subsequent switching condition judgments are only performed after the verification is passed.

9. The automatic control system for ship navigation mode according to claim 1, characterized in that, The dynamic domain processing unit is further configured to: The effective driving control mode, system fault information, mode switching prompts, and real-time operating parameters are fed back to the human-machine interaction unit for display in real time, and the effective driving control mode is fed back to the control console remote control unit, the autonomous navigation control unit, and the ship-side remote terminal.

10. An automatic control method for ship navigation mode, based on the automatic control system for ship navigation mode according to any one of claims 1-9, characterized in that, include: Obtain the ship propulsion control commands and its own fault information from each of the driving mode command units, and the driving mode requests from the human-machine interaction unit; Based on the driving mode request and the fault information of each driving mode command unit, arbitration is performed according to the preset arbitration rules to determine the current unique valid driving mode. Based on the effective driving mode, the corresponding ship propulsion control command is sent to the power execution unit to drive the ship propulsion system.

Images