AV task planning and emergency handling using primitive commands

Abstract

An autonomous ship AV mission planning and monitoring system (500) generates an AV mission and determines a ship configuration of a ship to autonomously execute a mission plan. A task planning and monitoring system (500) generates a task plan (1102) including at least a mobilization phase, a sailing phase, and a reviewing phase. The mission planning and monitoring system may also generate an emergency fallback plan for the vessel for compliance in unexpected events where the vessel cannot complete the assigned mission. Each stage of the AV task is assigned one or more activities or jobs for execution by the vessel according to the task timeline (1104). Each of the one or more activities is associated with one or more primitive commands by the task plan (1106). A candidate autonomous vessel is identified for autonomously performing a task (1108), and then capability information of the candidate vessel for performing a task plan is obtained (1110) by a task plan and monitoring system. Based on the capability information, a vessel configuration is generated (1114) for the vessel to employ to autonomously execute the task plan. The vessel configuration associates one or more automation and / or navigation primitive commands with each activity that the vessel will perform according to the task timeline.

Description

[0001] This disclosure relates to autonomous vessel AV mission planning, for example, to AV management systems configured to support AV mission planning and related aspects. In particular, but not exclusively, the disclosed AV mission planning system can also be used to plan how to handle AV during emergencies or similar unforeseen events that interrupt a vessel's performance of its assigned mission plans.

[0002] AV operation, in other words, is the operation of a vessel, such as a ship or any other type of nautical or waterborne vessel, that is navigating on or under water without the joint or individual complete control of the vessel's operation by one or more persons on board. It is slightly more complex than the operation of a land-based vessel.

[0003] First, such AVs operate in a much more dynamic environment. For example, operations such as route navigation may need to take into account lateral water currents (e.g., currents), water depth (e.g., tidal movements), and the time of day, the time of month, and seasonal variations. This may also affect the time of day when berthing and departing from port, as well as other operations that working vessels may need to perform, both internally and externally, when approaching and departing from port, while berthing in port, and in open water or at one or more other locations on a navigation or channel plan. Weather, not only wind speed but also wave height, must also be considered, and vessels need to be able to react quickly to situations that may escalate in a short period of time. Second, the ability of different vessels to autonomously follow mission plans can vary considerably.

[0004] Therefore, there is a need to improve the management of AVs, including how AVs are assigned tasks for autonomous execution and how AVs are configured to respond to any unforeseen events or emergencies that may occur while they are autonomously performing their assigned ship tasks. Summary of the Invention

[0005] Although the invention is defined by the appended claims, various aspects of the disclosed technology, including the claimed technology, are illustrated in this summary section by examples of some preferred embodiments and indications of possible technical benefits.

[0006] The disclosed technology seeks to provide a non-shipboard AV management system capable of planning AV tasks and assigning AV task plans to one or more vessels for autonomous execution. The non-shipboard AV management system also provides remote monitoring of the vessels as they perform their assigned AV tasks and can also enable remote control of the vessels when appropriate.

[0007] Examples of disclosed AV management systems include various components and subsystems that can be on-board and / or off-board or distributed, and in some implementations, so-called cloud-based system control can be achieved.

[0008] As used herein, the term AV refers to any vessel, ship, or other surface vessel capable of autonomously performing certain navigational maneuvers and executing certain operational commands and functions that enable it to autonomously (in other words, without human supervision on its bridge) complete its assigned ship tasks. The term AV also refers to a vessel that can be monitored and remotely controlled from time to time or in emergency situations by a non-shipboard human supervisor located at a remote operations center.

[0009] Typically, but without limitation, the disclosed AV management system includes at least the following elements: one or more AVs, which can be controlled as a fleet to a larger or smaller extent; each AV having an onboard AV control system, which includes a mission management and monitoring subsystem that configures the vessel to autonomously process assigned AV mission plans. The AV control system on the AV is also capable of autonomously detecting and handling emergencies that unexpectedly prevent the AV from completing its assigned tasks. In addition, the AV management system also includes: a non-onboard mission planning and monitoring system that can be hosted at a remote operations center (ROC), where a supervisor can obtain supervision and / or remote control of one or more operations or functions performed by one or more AVs; and one or more suitable wireless data communication systems configured to provide connectivity between the ROC and one or more AVs.

[0010] When a task is assigned to a vessel, a task plan is configured at the ROC accordingly, based on an understanding of the vessel's ability to complete the task. The task plan can be designed and assigned to the vessel by a task planner, which may be a user of a task planning and monitoring system hosted at the ROC, or autonomously designed and assigned in the case of software with this capability and the ability to determine the vessel's ability to complete the assigned task, hosted at the ROC. In some implementations, more than one ROC can host a remote task planning system that allows access from multiple locations (including other vessels in the case of such a vessel acting as an ROC).

[0011] The first aspect of the disclosed technology includes a method for generating a ship configuration for autonomously executing a mission plan, the method comprising: generating a mission plan that includes at least a mobilization phase, a navigation phase, and a decommissioning phase; and assigning one or more activities to be performed by the ship according to a mission timeline to each phase of the mission; associating each of the one or more activities with one or more primitive commands; and identifying candidate ships for autonomously executing the mission; obtaining capability information of the candidate ships for executing the mission plan; and based on the capability information, generating a ship configuration for the ship to adopt for autonomously executing the mission plan, the ship configuration associating one or more automation and / or navigation primitive commands with each activity to be performed by the ship according to the mission timeline.

[0012] As used herein, a mission plan may include a set of tasks that the vessel must perform at each stage, and the mission plan may define a set of primitive commands for each job to be performed in a predefined sequence. Each primitive command is an element (e.g., an indivisible element) in the mission plan that causes a part of the vessel to perform one or more jobs, causing the vessel to perform multiple activities in sequence, thereby causing the vessel to execute the mission plan. Each primitive command may be associated with a control instruction that will cause a component of the marine vessel to perform a function synonymous with or related to the primitive command. Thus, depending on the example, a mission plan may be divided into activities, and activities may be divided into jobs, each job being divided into one or more primitive commands.

[0013] Advantageously, if capability information indicates that a particular vessel cannot complete the planned mission or is unlikely to complete it, the mission planner can adjust the mission to suit the vessel's capabilities and / or select other vessels with capabilities by consulting a database of such vessels and their capabilities.

[0014] In some implementations, the method further includes: in response to obtaining ship capabilities, determining whether the ship can be configured to perform a mission plan; and if it is determined that the ship has capabilities different from those required to perform the mission plan, determining whether the mission plan can be adjusted to use the different capabilities of the ship; and if the mission plan can be adjusted, updating the mission plan and generating a ship configuration for the ship to use based on the updated mission plan.

[0015] In some examples, the method includes: generating instructions based on capability information, the instructions associating one or more automation and / or navigation primitive commands with each activity the vessel is to perform according to a mission timeline, the instructions, when executed by the vessel, causing the vessel to adopt a vessel configuration to autonomously execute the mission plan by executing one or more automation and / or navigation primitive commands, thereby performing each activity according to the mission timeline. In this way, the output of the method can be a set of instructions that, when executed, cause the vessel to perform the mission plan.

[0016] In some implementations, a task plan is adjusted by changing at least one primitive command associated with one or more activities of the task plan and (or alternatively) changing activities associated with one or more phases of the task plan.

[0017] In some implementations, the mission plan configures the ship to autonomously perform: one or more activities in the mobilization phase, which mobilize the ship before voyage; one or more activities in the decommissioning phase, which decommission the ship after voyage; and one or more activities in the voyage phase, which are performed while the ship is voyaging.

[0018] In some implementations, the mission plan (or mission "time plan") configures the vessel to automatically initiate AV missions based on predetermined mission start times or events.

[0019] In some implementations, the mission plan defines at least one operation, which includes multiple activities that the ship can autonomously perform at one or more locations during one or more phases of the mobilization phase, demobilization phase, and navigation phase.

[0020] In some implementations, the task plan defines a set of primitive commands for each job to execute in a predefined sequence controlled by a set of flow control primitives, wherein each predefined sequence of primitive commands includes one or more automation primitive commands and / or navigation primitive commands. “Primitive commands” may also be referred to herein as “command primitives”.

[0021] In some implementations, the flow control primitives for each operation configure the vessel to perform multiple actions for each operation simultaneously.

[0022] In some implementations, the flow control primitives for each operation configure the vessel to perform multiple operations simultaneously.

[0023] In some implementations, the mission plan also includes a ship contingency plan that includes at least one rollback trigger condition associated with one or more rollback primitive commands that configure the ship to adopt a rollback state determined according to the ship contingency plan.

[0024] In some implementations, the ship's emergency plan includes multiple sequences of backoff primitive commands, each of which is assigned a selection priority, and the backoff primitive command sequences are selected based on their priority order and the availability of primitive commands in the selected sequences.

[0025] In some implementations, the rollback trigger condition includes detecting that the ship has not executed primitive commands according to the AV mission timeline assigned to the ship.

[0026] In some implementations, the mission configuration includes at least one coordinated action in the mission timeline, which will be performed autonomously by the vessel and is coordinated with the execution of at least one action performed by at least one other vessel.

[0027] In some implementations, at least one action performed by at least one other vessel includes at least one action that is also performed autonomously according to the mission configuration.

[0028] According to another, second aspect of this disclosure, a method is provided for configuring a fleet of ships to autonomously collaborate while performing a fleet mission plan, the method comprising: generating a fleet mission plan; assigning one or more activities from the fleet mission plan to an AV mission plan associated with each ship in the fleet, wherein an AV mission plan and a ship configuration for performing the AV mission plan are generated for each ship in the fleet by performing a method according to any of the first aspect or embodiments disclosed herein.

[0029] According to another or third aspect of this disclosure, an AV task scheduler system is provided, the system comprising: a memory; computer code; and one or more processors or processing circuitry systems, wherein the one or more processors or processing circuitry systems are configured to execute the computer program code when it is loaded from the memory, so as to cause the scheduler system (or "scheduler device") to perform a method according to any one of the first or second aspects or the embodiments disclosed herein.

[0030] According to another, fourth aspect of this disclosure, a ship is provided that includes an autonomous control system configured to enable the ship to execute one or more primitive commands based on a timeline, according to a mission plan received from a ship planner system of the third aspect or any of the disclosed embodiments.

[0031] Another, fifth aspect of the disclosed technology relates to a computer program product comprising computer-coded instructions that, when loaded from memory and executed by one or more processors or processing circuitry systems of a device, cause the device to implement any one of the first or second aspects disclosed, or a method of implementing one of the disclosed embodiments thereof.

[0032] The disclosed technology enables the generation of mission plans for autonomous execution by a vessel without requiring an initial determination of its capability to autonomously execute each primitive command associated with a planned mission activity. After this initial mission planning period, when the mission plan primitive commands and associated activities are known, the vessel's capability to autonomously execute primitive commands for mission plan activities can be checked by obtaining vessel capability information. If the vessel has the capability to execute the mission activity, but only if different primitive commands are used, the mission plan activity can be updated to reference primitive commands for which the vessel has the capability to execute autonomously. Alternatively, AV tasks can be assigned to different vessels with a more suitable set of capabilities for autonomously executing AV tasks. In this way, individual vessel-agnostic mission plans can also be generated, and then adapted to vessel-specific mission plans suitable for different capabilities of different vessel types. In other words, the disclosed technology enables the generation of both vessel-agnostic mission plans and vessel-specific mission plans in a very timely and computer resource-efficient manner using the same mission planner system.

[0033] Ship-agnostic mission plans can be stored as AV mission templates and retrieved later by the mission planner from storage, and adapted to suit specific ship types and capabilities. This not only allows users to generate mission plans more quickly, but also allows the stored missions to occupy less memory compared to storing a single ship-agnostic mission plan instead of multiple ship-specific mission plans.

[0034] Storing AV mission plans, whether ship-agnostic or ship-specific, enables rapid retrieval and allows for faster generation of modified AV missions, as mission plans can be updated later rather than regenerated from scratch. For example, if a ship has upgraded equipment items that allow it to be remotely monitored and controlled, or autonomously controlled by the ship's automated control system, such updates can accommodate both new and older ships with new mission capabilities. Ship capability information can also be stored, allowing ships capable of autonomously executing mission plans to be searched and identified as suitable candidates when planning autonomous missions.

[0035] Advantageously, the disclosed technology enables the generation of mission plans for autonomous ship execution without initially determining the ship's capability to autonomously execute the primitive commands associated with the planned mission activities during the initial mission planning phase. However, once the mission activities are known, the ship's capability to perform these activities can be checked by obtaining ship capability information. If the ship has the capability to perform the mission activities, but only if different primitive commands are used, the mission plan activities can be updated to alternatively reference those available primitive commands. In this way, a single mission plan can be generated and then adapted to accommodate the different capabilities of different ship types. In other words, advantageously, the disclosed technology enables the generation of both ship-agnostic mission plans and ship-specific mission plans using the same mission planner system. Alternatively, another ship can be located at that point by searching a database storing ship capabilities to see if the ship has the capability to match the capabilities required to complete the mission plan.

[0036] Therefore, task scheduling software tools offer at least the technical advantage of improving AV task scheduling for AVs. By better matching AV tasks with AVs capable of performing those tasks, tasks can be better matched with the AVs most suitable for performing them. This allows for the selection of AVs that are more appropriate for executing tasks in a time- and cost-efficient manner.

[0037] Another, sixth aspect of the disclosed technology includes a method for configuring a vessel to be safely managed in an emergency, wherein the vessel is configured to autonomously execute an assigned Active Mission Plan (AV), the emergency preventing the AV mission plan from being safely completed or not completed. The method includes: generating an AV mission plan comprising multiple activities for the vessel to perform according to a mission timeline, wherein each activity among the multiple activities is associated with a primitive command; generating a vessel contingency plan comprising one or more backoff trigger conditions for suspending the AV mission plan before completion, wherein each of the one or more backoff trigger conditions is associated with one or more backoff primitive commands; and assigning the AV mission plan and the contingency plan to the vessel, wherein the assigned contingency plan, in response to the detection of a backoff trigger condition while executing the assigned AV mission plan, configures the vessel to execute one or more backoff primitive commands associated with the detected backoff trigger condition according to the contingency plan.

[0038] In some implementations, at least one of one or more rollback trigger conditions includes determining that the availability status of at least one primitive command required to complete the AV task plan has changed to unavailable during the task.

[0039] In some implementations, one or more rollback primitive commands are ordered according to the priority order used for selection. For example, in some implementations, the commands are ordered based on operator preference and / or based on the ship's capabilities.

[0040] In some implementations, the contingency plan also configures the vessel to select at least one of one or more backoff primitive commands in response to the detection of a triggering backoff condition, based on a priority order for selection and the availability status of backoff primitive commands indicating their availability.

[0041] In some implementations, an emergency includes one or more of the following fallback trigger events: equipment failure or damage preventing the completion of an assigned AV mission, fuel loss or shortage sufficient to prevent the completion of an assigned AV mission, power loss / shortage preventing the completion of an assigned AV mission, weather forecast or weather event preventing the completion of an assigned AV mission, or any other type of maritime emergency that causes the status of the primitive command used to complete the mission to change from an available state to an unavailable state and prevent the completion of the assigned AV mission.

[0042] Another, seventh aspect of the disclosed technology includes a non-shipboard vessel emergency retreat planner comprising a memory, computer code, and one or more processors or processing circuitry systems, wherein the computer code, when loaded from the memory and executed by one or more processors or processing circuitry systems, causes the non-shipboard vessel emergency retreat planner to perform the methods of the sixth aspect or any of the disclosed embodiments, to configure a vessel configured to autonomously execute an assigned AV mission plan for safe management in an emergency situation that prevents the safe completion of the AV mission plan.

[0043] Another, eighth aspect of the disclosed technology includes an onboard ship emergency plan execution system for a vessel, configured to autonomously follow an assigned AV mission plan, the AV mission plan comprising multiple activities to be performed by the vessel according to a mission timeline, wherein each of the multiple activities is associated with a primitive command, wherein the onboard ship emergency plan execution system includes a memory, computer code, one or more processors or processing circuitry systems, and an AV control system, wherein, when the computer code is loaded from the memory and executed by one or more processors or processing circuitry systems, in response to the vessel detecting a backoff trigger condition, the AV control system performs the following operations: suspending the execution of the assigned AV mission plan; and autonomously implementing the ship emergency plan that associates one or more backoff trigger conditions with one or more backoff primitive commands by executing one or more backoff primitive commands associated with the detected backoff trigger condition.

[0044] In some implementations of the shipboard emergency planner execution system, the ship emergency plan sorts one or more rollback primitive commands in a priority order for selection, and when the computer code is loaded from memory and executed by one or more processors or processing circuitry systems, in response to the ship detecting a rollback trigger condition, causes the AV control system to perform the following operation: in response to detecting a rollback trigger condition, select at least one of the one or more rollback primitive commands according to the priority order for selection and based on the availability of the rollback primitive commands.

[0045] In some implementations, when computer code is loaded from memory and executed by one or more processors or processing circuitry systems, the AV control system: monitors the availability status of each of the primitive commands used by the ship to autonomously execute the AV mission plan assigned to the ship; if at least one monitored command changes the availability status of that command to unavailable, determines whether the change in availability status constitutes a fallback trigger condition for the ship to adopt a fallback state; and in response to determining that the change in availability status constitutes a fallback trigger condition for the fallback state to be adopted by the ship, according to the ship's contingency plan, reconfigures the ship for autonomous operation in the selected fallback state.

[0046] In some implementations, when the computer code is loaded from memory and executed by one or more processors or processing circuitry, the AV control system, in response to the ship detecting a backoff trigger condition, selects a backoff state based on a risk score of the backoff state adopted by the AV and according to the association of the selected backoff state with one or more backoff primitive commands having a valid state.

[0047] Advantageously, by configuring the AV to handle emergencies as well as when generating task schedules for the AV, the AV monitor can be more confident that even in emergency situations that disrupt communication between the AV and the ROC-based task monitor, the AV monitor will know how the AV will be able to adapt to changing circumstances.

[0048] Examples of the disclosed technologies include an onboard emergency backoff management system for safely controlling the autonomous operation of an AV in the event of an emergency or other unexpected and unforeseen event while the AV is configuring its mission to follow a task. The backoff management system configures the AV to execute one or more backoff primitive command sequences associated with backoff triggering events detected by the AV. These backoff primitive command sequences are associated with various triggers (e.g., lack of availability of a specific primitive command) and are configured by the task planner when planning the AV's mission. Each backoff primitive command identifies which alternative sequences should be executed by the AV in an event where an emergency results in one or more loss of ship capabilities, preventing the AV from performing one or more actions according to its assigned mission plan.

[0049] In some implementations, the rollback management system is configured to: monitor the validity status of multiple primitive commands used by the AV to autonomously execute the AV mission plan; determine whether a change in validity status constitutes a triggering event for the ship to adopt a rollback state if at least one of the monitored commands used by the currently executed mission plan no longer has a validity status; and in response to determining that a change in validity status constitutes a triggering event for the ship to adopt a rollback state, reconfigure the ship to perform autonomous operation in the selected rollback state.

[0050] In some implementations, the fallback state is selected based on the risk score of the fallback state and based on the fallback state being associated with one or more primitive commands that have invalid states.

[0051] The disclosed aspects and implementation methods can be combined with each other in any suitable manner that is obvious to those skilled in the art. Attached Figure Description

[0052] Some embodiments of the disclosed technology are described below with reference to the accompanying drawings, which are merely illustrative examples, and in the drawings:

[0053] Figure 1 An example of an AV fleet according to some embodiments of the disclosed technology is illustrated schematically;

[0054] Figure 2 An example of an AV task from port A to port B that can be performed by an AV according to some embodiments of the disclosed technology is illustrated schematically;

[0055] Figure 3 An example of an AV task from port A to a maritime operations area, which can be performed by an AV according to some embodiments of the disclosed technology, is illustrated schematically.

[0056] Figure 4 A system for full AV operation according to some embodiments of the disclosed technology is schematically illustrated;

[0057] Figure 5A A task planning and execution system according to some embodiments of the disclosed technology is illustrated schematically;

[0058] Figure 5B An example of data flow between a shipboard mission planning subsystem and non-shipboard mission planning subsystem and components, according to some embodiments of the disclosed technology, is illustrated schematically.

[0059] Figure 5C An example of data flow between a shipboard mission planning and execution subsystem and a non-shipboard mission planning and execution subsystem according to some embodiments of the disclosed technology is illustrated schematically.

[0060] Figure 6 An example of an automated sequence of multiple jobs / tasks running in a semi-parallel manner is illustrated according to an example implementation of the disclosed technology;

[0061] Figure 7A and Figure 7B The illustrations illustrate how unavailable primitive commands can affect automated equipment according to corresponding example implementations of the disclosed technology.

[0062] Figure 8 An example illustrating how task configuration code, according to some implementations of the disclosed technology, defines different phases of a task and also defines fallback state configurations;

[0063] Figure 9 A risk action table is schematically illustrated according to some embodiments of the disclosed technology;

[0064] Figure 10 An example of a task scenario in which a rollback trigger event occurs according to some implementations of the disclosed technology is illustrated;

[0065] Figure 11 An example of a method for generating a ship configuration for autonomously executing mission plans, according to some embodiments of the disclosed technology, is illustrated schematically.

[0066] Figure 12 An example of a method for generating a vessel configuration for each of multiple vessels in a fleet to autonomously perform a fleet mission plan, according to some embodiments of the disclosed technology, is illustrated.

[0067] Figure 13 The schematic diagram illustrates the configuration to implement Figure 11 and Figure 12 Examples of apparatuses for one or both of the methods illustrated herein; and

[0068] Figure 14 An example of a method for generating a ship emergency plan according to some embodiments of the disclosed technology is illustrated schematically. Detailed Implementation

[0069] The various aspects of this disclosure will be described more fully below with reference to the accompanying drawings. However, the apparatus and methods disclosed herein can be implemented in many different forms and should not be construed as limited to the aspects set forth herein. If some steps are not essential for some of the disclosed embodiments, steps may be rearranged or omitted, whether explicitly mentioned or implicit. Similar reference numerals in the drawings always denote similar elements. However, in different embodiments, the same elements may be referred to using different numbers in the drawings.

[0070] The terminology used herein is for the purpose of describing specific aspects of this disclosure only and is not intended to limit the technical implementations disclosed herein. As used herein, unless the context clearly indicates otherwise, the singular forms “a”, “an”, and “the” are also intended to include the plural forms.

[0071] Figure 1Examples of AV fleet infrastructure according to some embodiments of the disclosed technology are illustrated schematically. Figure 1 In this context, the fleet comprises three vessels 102, which are schematically shown to have individual wireless data connections 104 to the fleet's remote operations center (ROC) 100. The ROC 100 can host AV mission planning and execution systems 400 according to some of the embodiments of the disclosed technology described later.

[0072] Each AV 102 is capable of autonomously undertaking AV tasks; in other words, autonomously mobilizing to undertake navigation from a given location to another, and then subsequently decommissioning without interaction with a human operator. Each AV task accordingly comprises three phases. The first phase is the mobilization phase, which plans one or more mobilization activities prior to the vessel's departure. The second phase is the navigation phase, in which the vessel performs one or more activities after its departure and before reaching its destination. The third phase is the decommissioning phase, which includes one or more decommissioning activities for the vessel to autonomously perform after reaching its destination. Examples of mobilization and decommissioning activities include, but are not limited to, activities such as loading and unloading cargo, starting and stopping battery charging, engagement, mooring and unmooring, and deploying / disengaging the gangway.

[0073] The AV mission accordingly includes three phases (mobilization, navigation, and demobilization), each of which may include multiple activities to be autonomously performed by the AV 102.

[0074] Figure 2 and Figure 3 Different examples of AV tasks that can be configured using the disclosed techniques are illustrated schematically. Figure 2 An example of an AV task from port A to port B that can be autonomously performed by AV 102 according to some embodiments of the disclosed technology is illustrated. Figure 3 An example of an AV mission from port A to a maritime operations area, which can be autonomously performed by AV102 according to some embodiments of the disclosed technology, is illustrated.

[0075] exist Figure 2 AV 102 begins its assigned AV mission at waypoint WP1, located in port A. After conducting mobilization activities, AV 102 begins its navigation phase and follows shipping route 106, which includes waypoint WP1 to waypoint WP7, located in port B (wherein... Figure 2 (AV 102 is also marked). Shipping route 106 is configured to allow vessels to move safely, and takes into account factors beyond environmental conditions. Figure 2 The presence of other maritime traffic is shown as other vessels 108.

[0076] Figure 2 The diagram also schematically illustrates ROC 100, which assigns an autonomous AV mission plan to AV 102 for autonomous navigation from port A to port B. The mission plan defines one or more mobilization activities to be autonomously performed by the vessel before its departure from port A, one or more demobilization activities to be autonomously performed by the vessel after arrival at port B, and one or more navigation activities. An example of an autonomous mission plan defines unmooring and unberthing related activities at port A, one or more berthing and mooring related activities at port B, and activities the vessel may need to perform during its navigation from A to B. For example, when operating autonomously during the navigation phase of a planned AV mission, AV 102 must be able to avoid grounding in low waters and also avoid collisions with other hazardous obstacles along the way, such as other vessels 108 and any other objects that may be floating in the sea.

[0077] Figure 3 The illustration schematically shows how AV 102 can execute different types of mission plans that define shipping routes 106 from port A to a mission area, where the vessel will perform one or more operations, each operation comprising one or more activities. Figure 3 In the diagram, two task areas, 110a and 110b, are schematically shown as shaded areas for illustrative purposes. In task area 110a, AV 102 will operate in target-following mode, following a remotely operated transport vehicle ROV 112 controlled from ROC 100a. In task area 110b, AV 102 navigates along a predefined survey route.

[0078] Figure 3 The mission planning objective is for AV 102 to autonomously enter the operational area including mission areas 110a and 110b, rather than autonomously navigating to another specified location, for example. Figure 2 The destination of port B shown. Figure 3 The navigation portion of the AV mission shown has components for use with Figure 2 The capabilities required for missions shown are the same or similar, but demobilization activities can be very different.

[0079] In some implementations, each AV 102 can be configured to autonomously execute mission plans generated by one or more different ROCs 100, and the vessel's performance while following the mission plan can be monitored by the same ROC 100 that configured the mission plan, or by different ROCs. The ROC 100 can generate a mission timeline for executing activities associated with each phase of the mission plan. In some implementations, the mission timeline can specify a time within a day / week / month, etc., when the AV mission will be autonomously executed by the vessel. However, in some implementations, a mission plan with a mission timeline that enables the ROC 100 to remotely initiate the vessel to begin its AV mission can be generated.

[0080] Figure 3 ROC 100a is schematically shown. ROC 100a can be used to plan ship missions for autonomous execution by the AV and can also initiate the AV 102 to follow its mission schedule timeline. However, while the AV 102 is executing its autonomous mission plan, the AV 102 can alternatively be monitored and / or controlled by another ROC 100b.

[0081] In some embodiments, ROC 100 includes a computer platform that enables an operator to control a fleet comprising more than one AV 102, which may need to perform autonomous operations in parallel or sequentially. Fleet tasks may include multiple individual AV tasks configured for different vessels 102. In some embodiments, fleet tasks may be configured by the fleet operator.

[0082] According to some implementations of the disclosed technology, the ROC 100 managed task scheduling and monitoring system 500 (see below for a later description) Figure 5B (as described above), the mission planning and monitoring system 500 is used to generate and / or upload mission plans, and then send the mission plans, along with appropriate vessel configurations, to one or more vessels 102 so that each vessel can autonomously implement its assigned mission plan.

[0083] In some implementations, the mission planning and monitoring system 500, hosted by the ROC 100, is configured to send mission plans to each AV 102 in the fleet, wherein each vessel is assigned a subset of activities in its mission plan, and these subsets of activities are collectively allocated to the fleet of vessels for execution. The ROC 100 may be able to activate when each mission plan is to begin by each vessel in the fleet, and in some missions, activities and / or operations performed by different vessels in the fleet may be coordinated by the ROC 100.

[0084] The ROC 100 can also host devices that, in addition to mission planning, can be intervened by the operator while the vessel is engaged in ongoing and previous AV missions. An example of such intervention triggering is when a situation develops beyond the autonomous handling capabilities of the AV 102. Another example of intervention triggering is when a mission is being performed by the vessel, for example, when it dynamically changes due to one or more events near the vessel.

[0085] For clarity, Figure 2 and Figure 3 No suggestive indication Figure 2 Between AV 102 and ROC 100 or Figure 3 Any wireless data connection between vessels 102 and 112 and ROC 100a and 100b. Such a wireless connection is required to support wireless communication between ROC 100 and AV 102 (these are in...). Figure 1 (This is shown as connection link 104). Each vessel may establish or maintain communication links with one or more ROC 100s periodically or intermittently as needed.

[0086] In some implementations, the advantage of the vessel maintaining more than one channel or communication link with one or more ROC 100s is that this can support more reliable communication with the ROC 100s. The communication can be a cellular or other type of wireless communication link, and more than one carrier and different types of carriers can be used, for example, a radio link, a cellular telephone network, or a satellite link.

[0087] Figure 4 An example implementation of AV operation, AVO, system 400 according to the disclosed technology is illustrated schematically. In this example, the ROC 100, which includes a managed fleet monitoring and control system 402, and the AVO system 400, which includes an onboard ship control system 422 and various other systems, subsystems, and components, enable the vessel to be remotely configured by the ROC 100 to autonomously follow the AV mission plan.

[0088] exist Figure 4 In this system, AVO system 400 includes multiple interconnected functional systems 402 to 420 located differently on and outside AV 102. For example... Figure 4As shown, the functional systems 402 to 420 for AV operation include a non-shipboard fleet monitoring and control system 402 hosted or accessed by ROC 100, which communicates with AV 102 via a ship communication system 404. In some embodiments, the ship communication system 404 includes a ship-to-shore system 406a and a ship-to-ship communication system 406b. AV 102 also includes a shipboard equipment operating system 408, a ship maneuvering system 410, a ship navigation system 412, and a mission management system 414. The equipment operating system 408 can communicate with equipment 416 via wired or wireless communication. Equipment sensors 420 generate sensor data for one or more items of the equipment or equipment system, and sensor readings are transmitted to an equipment sensor analysis system 418a, which is configured to provide sensor analysis and can also communicate with the ship navigation system 412 and / or other shipboard systems (the latter in...). Figure 4 (Not shown) Shared data. The ship navigation system 412 is also configured to communicate with various other sensor analysis systems 418b, which are configured to receive sensor data from various other sensor systems 420. For example, in some embodiments, environmental sensors and analysis systems 418b may be provided to obtain sensor data from sensors located in the environment surrounding the ship.

[0089] exist Figure 4 In this system, ROC 100 implements a fleet monitoring and control system 402, which is capable of communicating with ships via one or more suitable communication links 104 using its ship-to-shore communication system 406a on AV 102. Depending on the ship's location and available network coverage, the communication links 104 may include, for example, satellite communication and / or cellular data communication. The ship-to-shore communication system 406a includes the functional communication components necessary to enable ships to communicate autonomously with ROC 100. For example, AV-to-shore communication 406a may use one or more security functions, such as network authentication and authorization. However, to realize ship-to-shore communication functionality, additional infrastructure may be required both on and outside AV 102. For example, land-based communication infrastructure may be needed to facilitate communication with AV 102 via shore-to-satellite communication systems. Another example of additional infrastructure that may be needed to enable AV 102 to autonomously execute mission plans includes ship-to-port communication infrastructure.

[0090] Some implementations of the fleet and control system 402 enable the AV 102 to be remotely monitored at the ROC 100 and, if necessary, to cease autonomous operation when the vessel deviates from its assigned task, and alternatively, to be remotely controlled via the ROC 100.

[0091] System 402 includes multiple fleet functional components configured to support more than one vessel at a time. Such fleet functional components may include, for example, functions for managing logbooks and reports for each vessel in the fleet; fleet management functions that provide management functions for more than one vessel at a time; fleet-level autonomous operation (e.g., some tasks may require coordination of more than one vessel simultaneously); AV mission planning functions (e.g., using an AV mission planner or a fleet mission planner such as described in more detail later); remote operation of one or more AVs in the fleet; and general monitoring of one or more autonomously operating vessels 102 in the fleet.

[0092] Although the fleet monitoring and control system 402 is in Figure 4 While shown as being located in ROC 100, it will be understood that the same control and monitoring functions can be provided by a distributed system or a cloud-based system. Additionally, although in Figure 4 In this context, ROC 100 is land-based, but in some embodiments of the disclosed technology, ROC 100 may also be located on another vessel.

[0093] like Figure 4 As shown, the ship communication system 404 also includes a ship-to-ship communication system 406b, which can provide ship-to-ship signaling functions as well as inter-ship communication. Examples of ship-to-ship signaling functions include optical signals and acoustic signals.

[0094] In some implementations... Figure 4 The navigation system 412 shown provides navigation control functions, which may include route monitoring, rerouting, and route reporting functions. In some embodiments, the navigation system 412 includes, in some embodiments, map-based grounding avoidance functions, as well as collision or obstacle avoidance functions and route verification functions. The navigation system 412 is configured to communicate with the mission management system 414.

[0095] The mission management system 414 provides engine decision information, maritime operations or scheduling mission information, payload processing, and nautical log / recording functions. It also provides decisions on how to obtain the least risk and can be configured to store data.

[0096] The ship navigation system 412 is configured to communicate with the ship maneuvering system 410, which provides functions such as berthing and unberthing maneuvers, mooring maneuvers, automatic passage maneuvers, and any other ship maneuvering functions such as full speed control. For example, the ship maneuvering system 410 is configured to communicate with the ship equipment operating system 408 to transmit control signals for one or more items of equipment 416. Examples of equipment operating functions that can be performed include damage handling (e.g., when the propeller is damaged), propulsion / steering functions, ballast / stability functions, deck machinery control, energy management (e.g., fuel cell management functions that can be provided for hydrogen batteries and / or battery systems), ship machinery control (auxiliary systems, pumps, etc.), and cargo handling functions. Examples of equipment 416 include engines, pumps, etc.

[0097] Examples of environmental sensors 420 include wireless sensor systems, motion sensors (e.g., gyroscopes), and motion reference units (MRUs). Examples of equipment sensors 420 include sensors configured to detect engine speed and other characteristics of a ship's propulsion system, load and weight distribution on loaded equipment, electrical and fuel energy consumption sensors, etc.

[0098] Figure 5A An example of an autonomous ship management system is illustrated, which includes a fleet monitor and control system 402 hosted by ROC100 and an onboard ship control system 422 hosted on AV 102.

[0099] like Figure 5A As shown, the fleet monitor and control system 402 is accessed and operated by the operator at ROC 100. The operator can use the fleet monitor and control system 402 to access the mission planning and monitoring system 500, also hosted at ROC 100, to plan AV missions and assign them to appropriate vessels for autonomous and / or remote execution. Additionally, in Figure 5A In the schematically illustrated implementation of the disclosed technology, the fleet monitor and control system 402 also receives Vessel Traffic Service (VTS) data 516 via a suitable data interface 518. The VTS data provides information about vessel traffic in one or more monitored vessel traffic areas, which can be used to give operators contextual awareness of other vessel traffic near one or more AVs 102 as one or more AVs 102 autonomously perform their AV tasks.

[0100] The mission planning and monitoring system 500 also enables the operator to configure the ship's emergency plan using the ship emergency return planner 500a when planning the AV mission, simultaneously with the planning, or at a later time. The mission planning and monitoring system 500 also enables the operator to monitor the mission, accessing different presentation views 508, 510, and 512 of the mission on the AV 102 from initial mobilization, through its navigation execution, and final demobilization. For example... Figure 5A As schematically shown, the monitoring display 506 at ROC 100 receives mission data feeds from the shipboard mission management system 414 of the AV via the off-board mission planning and monitoring system 500. Information provided by the shipboard mission management system 414 of the vessel to which AV mission plans have been assigned allows for visualization of how the vessel is carrying out its assigned activities according to the mission plans. When a particular AV 102 is carrying out its assigned AV mission, that particular AV 102 can access the mobilization execution monitoring view 508, the navigation execution monitoring view 510, and the demobilization execution monitoring view 512 in that order. These views are generated based on mission monitoring data feeds sent from the shipboard mission management system 414 located on the AV 102, and are therefore generated sequentially as the mission progresses; however, in some embodiments, historical views may be stored so that they can be retrieved, and if there is sufficient screen space compared to the current view.

[0101] As mentioned above, in some implementations, in addition to mission-related data, the fleet monitor and control system 402 at ROC 100 can also receive VTS data. This VTS data can also be shared with the monitoring capabilities of the mission planning and monitoring system 500, which allows for a more complete contextual awareness of vessel traffic around AV 102 to the ROC operator, for example, during mission execution, and in some cases, during mission planning, via the fleet monitor and control system 402.

[0102] The fleet monitor and control system 402's mission planning and monitoring system 500 can be used to generate two types of missions. First, there are ship-agnostic missions, which do not necessarily take into account the specific autonomous capabilities of a particular ship, but simply specify what activities the AV must perform to complete the AV mission. Second, there are ship-specific missions that take into account the ability of a particular AV to autonomously perform its AV mission.

[0103] In the case of generating a ship-agnostic mission plan, it can be stored in a suitable data storage 502 for subsequent conversion into a ship-specific mission plan. Figure 5B This section shows in more detail how a ship-agnostic mission plan generated at "A" can be converted into a ship-specific AV mission plan at "B". This will be described in more detail later below. Figure 5B .

[0104] The disclosed technology enables ROC operators, in other words, users of the fleet monitoring and management system 402, to access the vessel mission planning and monitoring system 500 at ROC 100 and to perform one or more, or all, of the following: planning AV missions, assigning them to appropriate vessels, and monitoring the progress of a vessel as it autonomously performs its assigned mission. Furthermore, ROC operators can monitor the progress of multiple vessels simultaneously executing mission plans, and in some embodiments, can also consider vehicle traffic based on information received via VTS.

[0105] The progress of each vessel (or one or more vessels if the fleet is being monitored) can be presented through sequential views 508, 510, 512 of the progress of each task, based on data feed signals received from the shipboard mission management system 414 via wireless communication link 514 using the shipboard communication system 404 and communication data interfaces 406a, 406b of the AV 102 assigned to the monitored task.

[0106] The shipboard mission management system 414 of the AV's control system 422 also includes a shipboard emergency return system 520, which is configured to provide autonomous emergency ship handling in the event that the AV 102 is unexpectedly unable to complete its assigned tasks. Therefore, even in the absence of a communication link with the non-shipboard planning and monitoring system 500, emergencies can be safely handled by having the AV 102 execute a predetermined emergency plan.

[0107] The non-shipboard AV mission planning and monitoring system 500 can also plan ship-agnostic and / or ship-specific missions for a group of ships at a time, as well as individual AV missions for ships to perform, in other words, independent missions. In some embodiments, mission plans generated by the operator at ROC 100 can be used for the fleet, in other words, for a group of ships, where missions are performed simultaneously. In some embodiments, ships in the fleet can independently execute their assigned independent ship plans to perform a group of AV missions. However, in some embodiments, AVs in the fleet are assigned subordinate ship plans that coordinate their individual actions to perform a group of AV missions.

[0108] Figure 5AData storage 502 is also shown. This can be provided by a suitable data management system in the form of multiple databases, some of which may store ship-specific information as a collection of ship capabilities and / or ship characteristics associated with a ship identifier. Examples of ship capabilities are autonomous capabilities, such as the ability to autonomously execute specific primitive commands such as “automatic anchor raising” (other examples are described later below). Examples of ship characteristics provided as parameter-value pairs include parameters such as “maximum speed” and values ​​such as “20 knots,” parameters for “ship cargo capacity” and values ​​such as “100 tons,” etc.

[0109] When planning AV missions, the mission planner is made available with information on ship characteristics and capabilities, so that AV missions can be tailored to the capabilities of a particular ship if needed, and / or, if available for the mission, allows the selection of a suitable ship with the capabilities and characteristics required to complete the planned mission.

[0110] These characteristics can be provided as input to the ROC operator for the mission planning and monitoring system 500 (and in some embodiments, also to the emergency return planner 500a), or, as mentioned above, they can be stored in the data storage 502 and then retrieved from it. In this way, if the ship identifier is known, it can be used to look up and retrieve previously stored ship characteristics and capability information.

[0111] Other examples of vessel characteristics used in mission configuration plans include vessel capacity based on vessel configuration, and vessel maneuverability, such as whether or not a vessel may have an automatic mooring and / or unmooring system.

[0112] Even if the overall mission is the same, the mission planning and monitoring system 500 can be used to configure ship-agnostic AV missions differently for different types of vessels. By taking into account any different vessel capability characteristics and configurations, each mission plan sent to AV 102 can be customized to make the mission plan feasible for execution on a specific vessel. In other words, based on the ability of AV 102 to perform the activities defined by the mission plan, the mission plan can be adapted to different types of vessels with different capabilities.

[0113] In some, but not all, mission planning configurations, a complete mission timeline is also planned and provided to the vessel, indicating when to commence the mission. However, in some implementations, the start of the mission timeline may be triggered by an event rather than set to a specific time of day. Accordingly, each mission is planned as multiple distinct operations, which are aligned with the timeline for each operation the vessel must perform relative to the mission start, or based on the actual time of the mission being constructed and / or selected according to the capabilities of the vessel to perform the mission.

[0114] A ship mission plan includes activities associated with three mission phases or periods: the mobilization phase, the sailing phase, and the demobilization phase. It can be considered as a set of operations that are collectively assigned to one or more mission phases or all mission phases, and their execution timelines accordingly form the AV mission.

[0115] After the AV mission has been planned, the mission planning and monitoring system 500 uploads the fully planned mission configuration to the AV 102 that has been selected to perform the mission. The AV 102 then confirms that the given mission is suitable for its specific vessel type and capabilities by sending an appropriate acknowledgment, such as an ACK (acknowledgment) message.

[0116] In some of the embodiments mentioned above, the task configuration includes: a timeline with a start time for the vessel to automatically begin the task when that start time is reached; or a timeline set relative to a start event, which begins when the start event is detected. Alternatively, in some embodiments, a user at ROC 100 can remotely initiate the start of a newly uploaded task. This can override a predetermined start time or start event; for example, if weather conditions are deteriorating but will not affect the task once underway, the user at ROC 100 can advance the task start time or override the event setting, while if adverse conditions exist but the weather is improving, the ROC may wish to advance the task.

[0117] During the execution of its assigned ship missions, AV 102 can use data communication interfaces 406a and 406b via ship communication system 404 to send status updates indicating mission progress (in other words, mission progress monitored by its onboard mission management system 414) at each stage of the ship's mobilization, navigation, and decommissioning phases. While AV 102 is performing a mission, these updates allow users at ROC 100 to monitor and check the overall progress of the mission.

[0118] While this description refers to a human user at the ROC as a user of the fleet monitoring and control system 402 or an ROC operator as a human operator, in some implementations, in addition to or in place of a human operator, one or more AI-based systems may be used to remotely monitor and control ships and / or fleets of ships.

[0119] Additionally, while each task can be planned by a human user of the task planning and monitoring system 500, in some implementations, the AV tasks can also be planned at least partially automatically using an AI-based system, provided that the task planning and monitoring system 500 is properly configured to allow collaboration with such an AI-based system.

[0120] Therefore, references to “user” or “operator” can be considered to refer to any suitable intelligent entity, whether machine or human.

[0121] In some embodiments, the mission planning and monitoring system 500 can be used to configure the vessel to perform mission plans, for example, using methods 1100 or 1200 described later below, and in some embodiments, it can also perform method 1600 described later below to provide the vessel with backup contingency plans.

[0122] exist Figure 5B and Figure 5C The diagram illustrates an example of a data stream that can be generated from the use of the task planning and monitoring system 500. Figure 5B It shows the relationship with Figure 5C The information shown is more about the mission planning period.

[0123] exist Figure 5B and Figure 5C The diagram illustrates the relationship between... Figure 5A The schematic architecture shown includes examples of the same autonomous ship management system subsystems and system components, as well as data flows according to some implementations of the disclosed technology.

[0124] like Figure 5B As shown, the Autonomous Ship Management System at ROC 100 includes a mission planning and monitoring system 500 and a backoff planner 500a (shown as a component block for clarity), as well as one or more data storage units 502 for storing AV missions and / or ship characteristics including ship capabilities.

[0125] Figure 5B The focus is on the task assignment phase, where tasks are planned by the operator at ROC 100 and assigned to AV 102 for autonomous execution. Figure 5C The focus is more on the project monitoring and execution phases. Figure 5B and Figure 5C In addition, the mission planning and monitoring system 500 also receives VTS data feeds 630 from the VTS provider, which allows vessel traffic to be taken into account when planning AV missions and when monitoring AV missions.

[0126] Figure 5C The diagram schematically illustrates the shipboard control system 422, ship communication 404 and communication data interfaces 406a, 406b, and the shipboard mission management system 414, including the shipboard emergency return system 520. However, in Figure 5B Only the shipborne ship control system 422 is shown in the image.

[0127] exist Figure 5B and Figure 5C In the example data stream shown, the operator at ROC 100 uses the fleet monitoring and control system 402's mission planning and monitoring system 500, along with the vessel emergency return planner 500a, to first prepare the initial AV mission "A" (see...). Figure 5B The 600A in the middle is used to generate AV mission plans and related ship emergency plans.

[0128] The initial AV task "A" can be generated based on vessel capability information stored for a specific type or category of vessel, or for a specific vessel, or for a more general class of vessels (e.g., container ships). If AV task "A" is not vessel-specific, it may be referred to herein as a vessel-agnostic task, even if task "A" considers a general set of capabilities typically found in vessels of a specific category or type. For example, a dredging vessel type vessel will have a general set of capabilities. The capabilities (and vessel characteristics) of a general dredging vessel will differ from the capabilities of a tanker type vessel that will have general tanker type characteristics and capabilities. By way of example, an AV task requiring AV 102 to transport Y tons of cargo from A to B may initially be planned based on general container carrying capacity, but at some point, the AV task will need to be assigned to AV 102 with a specific cargo volume and tonnage for carrying that cargo.

[0129] Once the initial AV task "A" has been planned or during its creation, the task scheduler at ROC 100 needs to find the appropriate AV 102 to autonomously execute the planned task. Figure 5B It is shown that AV 102 can be identified by first determining what capabilities 600B needs to perform the task, and then using those capabilities to identify vessel 600C, for example by querying data store 502 to find vessels whose capabilities closely match the capabilities required for the task.

[0130] Once a suitable vessel is identified in this manner (or in any other way, such as by simply entering the vessel identifier into the mission planning and monitoring system 500), a request 602 is sent to the AV 102 to find and / or confirm its current set of vessel characteristics and capabilities.

[0131] Request 602 can be sent in any suitable manner, but it will typically be done via suitable wireless communication. Request 602 is received through the AV's wireless communication system interfaces 406a, 406b and processed by the AV's control system 422, which then sends 604 providing (or acknowledging) a response from the AV regarding its current vessel characteristics and capabilities.

[0132] The vessel's capabilities are then processed (608A) by the mission planning and monitoring system (500) and the rollback planner (500a) at ROC 100 to determine if they are compatible with the capabilities required for mission "A". If they are compatible, mission "A" (608) can be assigned to AV 102 without any modifications. Alternatively, the mission can be modified to accommodate the capabilities of that AV, and a new vessel-specific mission "B" (608B) can be generated and assigned to the vessel (608). If the mission cannot be adjusted or if the operator does not wish to adjust the mission, they may search for another vessel (600C) by performing a lookup in the vessel capability and characteristics data store (102) to locate a vessel whose previously stored capabilities closely match the capabilities required for the completed mission.

[0133] Optionally, the received vessel capability information can also be stored in a database, thereby enabling the vessel's capabilities to be taken into account when planning or assigning other subsequent autonomous AV missions.

[0134] When planning AV missions, the ship capability information received by the AV mission can be taken into account. A ship-specific mission plan can be generated directly at point B, or a ship-specific mission plan can be generated by refining the mission plan generated at point A with the capabilities of a specific ship.

[0135] The assigned task plan 608 includes a set of operations and functions that the vessel must perform in each of the mobilization execution phase 508, the navigation execution phase 510, and the demobilization execution phase 512, and in some embodiments may also include an emergency rollback plan. Once the task assignment has been uploaded to the vessel's control system 422, the control system 422 confirms that the task plan has been assigned, for example, by sending an ACK message 608a back to the task planning and monitoring system 500 and the rollback planner 500a.

[0136] In some implementations, each mission plan, generated in either a ship-agnostic or ship-specific form, is also stored. In the latter case, a ship identifier may be associated with a ship plan configured for the AV 102, ship characteristics indicating the ship's capabilities for later retrieval that are beneficial to the mission, and a suitable ship for executing the plan.

[0137] Once received and processed by the ship control system 422, the task is not executed until, for example, by triggering the start of task 610A through a specific time, tide, current conditions, and / or weather, or by a remote command from ROC 100. At this point, task 610B is initiated. The start of the task will also communicate / share with the shipboard task management and monitoring system 414 of the AV that initiates task monitoring 612.

[0138] If the task plan includes a task timeline with a start time that will serve as the AV task start trigger event 610A, the AV 102 may automatically start the task at that time, subject to environmental events (e.g., an unexpected severe storm could disrupt the task start time). Alternatively, or in the case of delayed automatic start, the task planning and monitoring system 500 generates a task start command and sends it to the AV 102. Figure 5B (Not shown in the image).

[0139] Now turn to Figure 5C ,Should Figure 5C The illustration schematically shows how mission monitoring 612 begins by the shipboard mission monitoring and management system 414 after AV 102 commences its AV mission. In some embodiments, various equipment and environmental sensors are used to monitor the mission, generating multiple data feeds which are processed by the mission management system 414. These data feeds may be merged together or sent separately by the mission management system 414 via the AV control system 422 as mission feedback data 614 to the mission planning and monitoring system 500 at ROC 100.

[0140] The feedback data includes mission status data feeds and may also include other monitored mission-related data and / or other data (e.g., vessel traffic service data). This performance and mission status feedback data allows the operator at ROC 100 to see the status of AV 102 as it autonomously performs its AV tasks. In some embodiments, the feedback data 616 may be stored in a suitable data storage 502.

[0141] In some implementations, the AV task can be reconfigured using feedback and / or other information obtained from the AV 102 during the execution of the assigned AV task. For example, the level of autonomy can be adjusted based on how the AV task is performed. Each AV 102 may have a different level of autonomous operation or autonomous operation capability, and in some implementations, the AV 102 may be remotely controlled at some or all times, depending on the progress and capability status of the AV 102 during a particular task phase, such as during mobilization.

[0142] The complexity of an AV task depends in part on the degree of autonomous operation that the AV 102 is capable of performing. Each AV task is planned as a specified set of activities for the AV 102 to perform autonomously (and / or remotely) using the task planning and monitoring system 500, and may also include a schedule or one or more timelines for performing each activity.

[0143] In some implementations, instead of being pushed by the mission planning and monitoring system 500 and the rollback planner 500a, the AV mission plan or configuration can be downloaded upon request by the mission monitor 502 on board the ship. For example, when an AV completes its AV mission, the mission monitor 502 can be configured to automatically request another AV mission. Alternatively or additionally, in some implementations, the AV 102 can conditionally request a new mission plan, for example, after completing a previous mission, depending on its fuel level, and / or after a certain amount of time has elapsed to allow for refueling and / or maintenance, etc.

[0144] Feedback data 614, sent back to ROC 100 by AV 102 after the start of the task, can be sent periodically or intermittently, for example, at times scheduled within the AV task. AV 102 can also be configured to send feedback data at certain time intervals after the start of each task phase and / or after the start of each activity or set of activities associated with a job defined for a specific task, and / or upon completion, and optionally at certain time intervals during the AV task.

[0145] AV 102 will also generate data during mission planning and may transmit some or all of this data via a ship-configurable interface. Data that can be transmitted via the ship-configurable interface includes actuation data, such as data indicating when equipment is actuated to complete mission operations or other situations. Other examples of data that can be transmitted via the ship-configurable interface include ship attitude data (e.g., ship pitch, yaw, roll), ship situation awareness data, haptic feedback data, ship health data, emergency status data, and also includes historical data that can be stored on the ship and / or exported for use by the ROC.

[0146] In some implementations, AV 102 may also generate data that can be sent to the mission planning and execution system 500 for sharing with the Vessel Traffic Service (VTS) provider.

[0147] Each task plan is configured using the task planning and monitoring system 500 with multiple primitive commands, each associated with a small activity. Each primitive command is an atomic element in the task plan that causes certain parts or components of the AV 102 to perform small but well-defined activities. Multiple activities executed in a specific order cause the AV to perform a specific job defined by the task plan it is assigned to.

[0148] An AV task includes at least two types of primitive commands: automation primitive commands and navigation primitive commands. Optionally, an AV task may also include one or more flow primitive features for processing task job flows and sorting.

[0149] Automation primitives are commands typically executed by ship automation systems such as deck machinery, charging equipment, gangway equipment, lights, anchor winches, etc. These commands are given atomically, allowing each task, comprising multiple actions to be performed, to be configured using well-defined commands specific to that task: for example, "drop port anchor," "raise starboard anchor," "connect charger," "start charging," "engage gangway," "disengage gangway," "moor ship," etc.

[0150] Some commands can be given without additional parameters, while others can be given with specific parameters. For example, the primitive command "raise port anchor" can be given without additional parameters, while the primitive command "turn on lights" can be qualified by one or more additional parameters, such as specifying which light to turn on, for example, "navigation light," and in some cases, specifying the light color if the light color is configurable.

[0151] A ship's automation capabilities can also be expressed using automation primitive commands. For example, a ship capable of performing autonomous mooring and unmooring operations will have at least the autonomous primitive commands "mooring" and "unmooring" listed in its ship capability configuration.

[0152] Navigation primitive commands are associated with atomic operations related to ship navigation. Examples of navigation commands include "push to dock," "depart," "hold," "ship," and "stand by." Similar to automation primitive commands, navigation primitive commands can be given with or without additional parameters. For example, "push to dock" can be given without parameters, while "ship" can be given with a long list of waypoints to follow to perform a shipping operation from one location to another. Waypoints in this particular navigation primitive will be given to avoid grounding during navigation. On the other hand, collision avoidance is a necessary additional function that temporarily deviates from the original waypoint list to achieve collision avoidance. This particular maneuver, of course, cannot be included in the original waypoint set of the "ship" primitive command.

[0153] A ship's navigation capabilities can also be expressed using navigation primitive commands. For example, a ship capable of performing a target-following maneuver will have the navigation primitive command "Follow Target" listed in the ship's capability configuration.

[0154] To control the flow of operations executed via primitive commands associated with each atomic element constituting a job or each job, an additional set of primitives is required, called flow primitive features. Examples of such primitives include the "wait time countdown" flow primitive, "wait absolute time", "wait operator input", etc.

[0155] A task (or job) comprises a sequence of automated primitives executed sequentially. An automated sequence may include multiple tasks or jobs. In some implementations, for example, an automated sequence may be associated with N tasks or jobs that include primitive activities to be executed in parallel or semi-parallel. For example, an automated sequence may include (Task 1: A10–A3–A9), (Task 2: A1–A7–F2) (…) (Task N: XXXX), where each task includes multiple automated primitive activities or steps. The automated primitive activities constituting each task are executed according to the timeline defined for that task and may be executed independently of the timelines of activities in other tasks that are executed in parallel. In other words, in some implementations, the timeline of each task may run in parallel with the timelines of other tasks. This allows for the ship to execute more than one primitive activity at any given time; in other words, automated primitive commands can be executed simultaneously.

[0156] Figure 6The following example illustrates a scenario where job timelines are concurrent, and jobs are executed in semi-parallel mode because some automation primitives execute simultaneously, while others do not. The term "semi-parallel" as used here refers to a situation where a given step in a given job waits for some other steps in another job to complete before being executed. When jobs are executed in semi-parallel mode, the execution of one or more activities assigned to one job depends on one or more activities associated with another job. In other words, as... Figure 6 As shown, starting A8 in Operation 2 requires completing the A10 primitive command activity in Operation 1. The execution, completion, start, or end of a primitive activity in one operation can trigger the start or end of a primitive activity in another operation. The example automation sequence shown can be used in any phase of the mobilization or demobilization phase of an AV mission and / or in a fallback sequence established in the ship's emergency plan.

[0157] Figure 6 The example shown includes an automated sequence of three different jobs running in semi-parallel. In this example, job 1 includes the primitive activity “charge the battery” and includes the primitive automation command A10 associated with the primitive activity “start charging”, the flow primitive feature F1 (120), and the automation command A11 associated with the primitive activity “stop charging”. In this example, F1 specifies the number of minutes after which charging should end. Executing primitive automation command A10 triggers automation command A8 “turn on the light” in job 2, which has a parameter identifying which light (here, the port light) to turn on. Job 2 includes the task of turning on the port light. After the primitive activities associated with both automation command A11 in job 1 and A8 in job 2 are completed, automation command A3 is executed, and the primitive activity “unmooring” in job 3 is executed.

[0158] As mentioned above, each job comprises multiple primitive activities, which are autonomously executed based on automated primitive commands and / or navigation primitive commands executed by the AV 102 according to its task timeline. In some implementations, the timing of these jobs and the execution of primitive commands are configured using stream primitive features.

[0159] The primitive automation commands are associated with identifiers A1, ..., A10. These primitive automation commands can be configured using the task planning and monitoring system 500 or predefined and used by the task planning and monitoring system 500, ensuring that these primitive automation commands cannot be erroneously redefined. Examples of automation primitive commands include, but are not limited to:

[0160] A0 Idle

[0161] A1 Operation Function

[0162] A3 Uncable

[0163] A4 mooring

[0164] A5 stopped

[0165] A6 set sail

[0166] A7 Flag Raising

[0167] A8 lower the flag

[0168] A8 Turn on the light

[0169] A9 Turn off the lights

[0170] A10 starts charging

[0171] A11 stopped charging

[0172] Examples of navigation primitive commands include, but are not limited to:

[0173] N0 Idle

[0174] N1 pushes to the dock (parameters: direction / force)

[0175] N2 Departure (parameter)

[0176] N3 berthing (parameters)

[0177] N4 Shipping (Optional parameter: Waypoints)

[0178] N5 Maintain Position (Heading / Position)

[0179] N6 Deceleration (Parameter: Acceleration)

[0180] N7 Follow target (parameter: target id)

[0181] N8 Maintains route and speed

[0182] N9 maintains the minimum speed through the water.

[0183] N10 enters the desired (parameter: region)

[0184] N11 maintains final thrust

[0185] The difference between a navigation sequence and an automated sequence is that only a single sequence is allowed to be executed by the vessel at a time. Primitive commands are executed one by one; for example, a navigation sequence may include a sequence in which the vessel executes navigation and automated primitive commands such as: N1-A3-N2-N4-N3-N1-A4-N0. This will be described later below. Figure 10Examples of navigation sequences are also shown. A navigation sequence moves a vessel from one location to another by executing one or more automation and navigation primitive commands within a single sequence. Examples of such sequences could be “push to dock,” “unmoor,” “depart,” “ship,” “berth,” “push to dock,” and “moor.” This example would autonomously guide a vessel from one port to another, including unmooring and mooring operations (see, for example, [link to example]). Figure 2 ).

[0186] Figure 7A and Figure 7B This illustration schematically shows how primitive commands can be aggregated and used to detect faults.

[0187] Figure 7A A more detailed example implementation is shown where the automated equipment on AV 102 malfunctions while AV 102 is performing an AV task, and Figure 7B The diagram illustrates a simpler, more general example.

[0188] like Figure 7A and Figure 7B As shown, two aggregates 700 and 702 are illustrated, including primitive commands used by AV 102 to perform assigned tasks according to embodiments of the disclosed technology.

[0189] exist Figure 7A In the context of Automated Aggregation 700, the aggregation of automated primitives includes, but is not limited to:

[0190] A0 Idle

[0191] A1 Operating Functions and Test Parameters

[0192] A3 Uncable

[0193] A4 mooring

[0194] A5 stopped

[0195] A6 set sail

[0196] A7 Flag Raising

[0197] A8 lower the flag

[0198] A8 Turn on the light

[0199] A9 Turn off the lights

[0200] A10 starts charging

[0201] A11 stopped charging

[0202] like Figure 7AAs shown in the example implementation, automation primitives A5 and A6 include an unavailable or invalid state primitive command 704 associated with a fault affecting the anchor winch equipment 706a and / or the anchor winch lubrication pump 706b. Figure 7A In this design, the anchor winch 706a utilizes functions provided by the anchor lubrication pump 706b. The anchor winch 706a also utilizes functions provided by a hydraulic power unit HPU2 706c, which is associated with an HPU level sensor 708a, configured to read the oil level of the HPU2 unit, and with an HPU2 oil temperature sensor, another sensor configured to read the oil temperature of the HPU2 unit. The HPU2 unit also relies on a generator 2 706d to supply power to it. The same generator 2 706d also supplies power to one or more navigation thrusters #1 706g…#n 706n. Each navigation thruster can also be associated with other equipment. For example, thruster #1 706g is driven by a lubricated main gear 706f, and the main gear lubrication device 706e provides this lubrication used by the main gear 706f. Figure 7A The example shows two equipment sensors 708c and 708d associated with the main gear lubrication device 706e. Sensor 708c provides a reading of the main gear lubrication temperature, and sensor 708d provides a reading of the main gear lubrication pressure. Additionally, in some embodiments, equipment monitoring functionality may be provided. If either the anchor winch device 706a or the anchor winch lubrication pump 706b fails, this may cause commands A5 and A6 to become unavailable, such as... Figure 7A As shown.

[0203] exist Figure 7A The example implementation also illustrates a navigation aggregation 702 of navigation primitives, which includes, but may not be limited to, the following examples of navigation primitives:

[0204] N0 Idle

[0205] N1 pushes to the dock (parameters: direction / force)

[0206] N2 Departure (parameter)

[0207] N3 berthing (parameters)

[0208] N4 Shipping (Optional parameter: Waypoints)

[0209] N5 Maintain Position (Heading / Position)

[0210] N6 Deceleration (Parameter: Acceleration)

[0211] N7 Follow target (parameter: target id)

[0212] N8 Maintains route and speed

[0213] N9 maintains the minimum speed through the water.

[0214] N10 enters the desired (parameter: region)

[0215] N11 maintains final thrust

[0216] All navigation primitive commands in these navigation primitive commands are Figure 7A It is available in [the Chinese version]. Figure 7A In the diagram, navigation thruster #1 706g is shown connected to main gear 706f, which in turn is connected to main gear lubrication device 706e, which in turn is connected to main gear lubrication temperature sensor 708c and main gear lubrication pressure sensor 708d. Figure 7A In the example shown, the anchor dropping primitive command A5 and the anchor raising primitive command A6 are shown as unavailable primitive command 704 because the anchor winch equipment is not working (and / or the anchor winch lubrication pump 706b is not working). By using sensor readings from sensors 708a and 708b, the system controller can determine what is causing the malfunction and automatically take further action to investigate why the sensor readings indicate that the sensors are not functional.

[0217] Now turn to Figure 7B Automation aggregation 700 includes an aggregation of automation primitives A#0 to A#N, in which, by way of example, automation primitive command A#N is an unavailable or invalid state primitive command 704. For example... Figure 7B As illustrated schematically, the aggregation of automation primitive commands 700 and navigation primitive commands 702 utilizes AV's device monitoring and system functions 408 to aggregate into valid or invalid automation primitive commands and navigation primitive commands. Figure 7B The diagram also schematically illustrates that the aggregation of automation primitive commands 700 and navigation primitive commands 702 uses the AV’s ship maneuvering system and function 410 to aggregate into valid or invalid automation primitive commands and navigation primitive commands.

[0218] exist Figure 7B In the illustration, two equipment nodes are shown only by way of example. Equipment node 706x, used by equipment monitoring and system function 408 in the illustrated example, and equipment node 706y, used by ship maneuvering system and function 410.

[0219] In this simplified example, if ship equipment 706x malfunctions, it affects the ship's equipment monitoring and system functions, and renders commands such as A#N unavailable for autonomous execution. Understanding why this might have occurred can be achieved using sensor data from equipment sensors 708x and environmental sensors 710x. Assuming the automated control system can read information directly or indirectly from these sensors, the cause of the malfunction in equipment 706x can be detected at least remotely, and it is feasible for the autonomous system to attempt to perform a function during this period using different primitive commands. The malfunction can also be corrected (e.g., if something overheats, it can resolve this automatically, and the equipment becomes operational again once it has cooled down).

[0220] However, if the equipment monitoring and system function system 408 attempts to perform monitoring function F#1 or provide system function F#2 using invalid primitive command A#N 704 on the ship equipment 706x before the faulty equipment is repaired, the function (F#1 or F#2) will not be performed or will not be successfully performed.

[0221] By identifying which primitive commands, such as A#N, are no longer available, monitoring system 408 can determine whether a failure has occurred that will not affect the ship's ability to complete its assigned tasks, or whether a rollback trigger event has occurred that requires the ship to suspend its assigned tasks.

[0222] like Figure 7B As shown, the equipment sensor 708x and / or the ambient sensor 710x provide sensor readings that can indicate the influence of the equipment 706x. By way of example, the equipment sensor 708x can sense the temperature of the pump, while in cases such as a fire in the engine compartment, the ambient sensor 710x can sense that the ambient temperature is very hot.

[0223] exist Figure 7B In the navigation aggregation 702, there is an aggregation of navigation primitive commands N#0 to N#N, all of which are available and in a valid state. Since all the relevant mission navigation primitive commands are available, for example, those used by the navigation equipment 706y can all be used by AV 102 to autonomously execute the functions performed by configuring the ship's maneuvering system 410 for mission planning.

[0224] On AV 102, the automated equipment item 706 used by AV 102 to perform the tasks assigned to the ship utilizes one or more automated primitive commands from aggregate 700, and one or more navigation equipment items may also use one or more navigation primitive commands from aggregate 702.

[0225] In some implementations, each aggregation 700, 702 is associated with the validity status of the task to be performed by AV 102. For example... Figure 7A As shown, equipment 706a includes an anchor winch controlled using automation primitive commands A5 and A6. It also includes a non-shipboard monitoring system 402 at ROC 100 and a shipboard mission management and monitoring system 422 (see also...). Figure 4 This could include, for example, the Kongsberg K-Chief monitoring and automation system or a similar system.

[0226] The off-board monitoring system 500 can, for example, monitor how a vessel configured to perform a task executes one or more functions assigned to AV 102 via the task plan. For instance, a function such as "testing anchor winch operation" can be monitored to check if the function is executed successfully; another example is the function "anchor winch in automatic mode," which can be monitored to check if the vessel can operate its anchor winch autonomously. To perform these functions, the anchor winch 706a may require the use of an anchor winch lubrication pump 706b. It may also require, for example... Figure 7A The image shows the power source 706c for the hydraulic power unit HPU 2. For example... Figure 7A As shown in the example, the HPU 2 706c uses the generator 2 706d, and can also generate, for example, such as Figure 7A The sensor data 708 shown is for the HPU oil level sensor reading 708a and the HPU oil temperature sensor reading 708b.

[0227] exist Figure 7A The diagram also shows navigation equipment 706g and 706n that draw power from generator 2 706d and utilize main gear 706f and main gear lubrication 706e. The main gear lubrication equipment 706e generates sensor data in the form of main gear lubrication temperature sensor readings 708c and main gear lubrication pressure sensor readings 708d. Sensor readings associated with various equipment items or system components of the ship's equipment system can be provided as separate data feeds, but in some embodiments, they can also be provided to the equipment monitoring system as fused data feeds. Figure 7A (Not shown in the image).

[0228] The navigation thrusters 706g and 706n are shown as... Figure 7A The N5 navigation primitive command is associated with and controlled by the ship's maneuvering platform 410 (see Figure 4 The AV 102 is configured so that it performs various navigation functions for the tasks it is assigned.

[0229] As mentioned above, the validity status of primitive commands in each aggregate affects the ability of AV 102 to perform the assigned task. The validity status of primitive commands and / or each aggregate 700, 702 may be included in or represented by capability information, provided by AV 102 when AV 102 confirms its ability to complete the assigned task, or it may include more detailed capability information. In some embodiments, AV 102 uses... Figure 5A The communication 514 shown provides capability information to the mission planning and monitoring system 500. This communication 514 can be a simple confirmation or more detailed information. In some embodiments, the capability information includes, for example, specific ship capability configuration information in the form of a list or spreadsheet file, indicating the ship's ability to execute each of the automation primitive commands and navigation primitive commands that collectively form the mission.

[0230] Additionally, in some implementations, the ship's capability configuration information may include information on always-available capabilities—in other words, mission-independent capabilities—(e.g., an additional list). This set of always-effective capability primitive commands is a subset of the ship's capabilities and may also be listed in the primitive command aggregation status list. For example, even if a given AV 102 may have the capability to "raise port anchor," this particular automation primitive command may sometimes fail to execute, perhaps because it is inappropriate, such as the port anchor may already be raised. However, a brief lack of available capability may also indicate a malfunction. For example, if the energy to "raise port anchor" is unavailable, this could be because the lubrication pump of the port anchor winch is malfunctioning at that time.

[0231] Some embodiments of the disclosed technology provide methods for configuring the functionality and operation of AV using primitive commands that also support fault detection.

[0232] In some implementations, the aggregation of primitive commands 700, 702 provides a primitive command validity status for each included primitive command. This aggregation mechanism enables fault detection based on the availability or unavailability of task-related primitive commands.

[0233] Some implementations of the disclosed technology will handle all fault behaviors when configuring tasks for the AV. In this context, where the task involves autonomous ship operation to perform well-defined mission tasks, fault handling differs from collision avoidance maneuvers. Collision avoidance maneuvers are not considered fault handling processes because they include mechanisms necessary for performing normal navigation operations from a given point to another.

[0234] Fault handling addresses more serious, unseen situations that may occur during mission execution. An example of this could be AV 102 losing its main propulsion or situational awareness for some reason during shipping operations. In this situation, AV 102 is unable to continue performing the mission it was assigned to perform in its original or "normal" configuration. In this case, fault handling is used to manage how to abort the mission so that it proceeds safely to a safe state, also referred to herein as a "rollback state." According to the disclosed art, this rollback state is also defined in the mission configuration.

[0235] Therefore, it should be understood that a vessel can be controlled to achieve objectives as set by the mission plan. The mission plan may include, for example, be divided into a set (e.g., one or more) of activities. Each activity may include a set (e.g., one or more) of tasks. Each task may include one or more primitive commands. Thus, these primitive commands can constitute indivisible elements of the mission plan. A task may include multiple primitive commands, or a task may include only one primitive command (e.g., if the task is anchoring, then the task may consist only of primitive command A5 as above). Similarly, an activity may include multiple tasks or may include only one task. Similarly, a mission plan may include multiple activities or may include only one activity. When executed sequentially, one or more tasks may constitute an activity. Similarly, when executed sequentially, one or more activities may constitute a mission plan. The term "sequentially" in this document should be considered synonymous with "according to a predefined sequence," and the predefined sequence may be stored, for example, along with task and / or activity data.

[0236] Therefore, a mission plan can include a set of operations that the vessel must perform at each stage, and the mission plan can define a set of primitive commands for each operation to be executed in a predefined sequence. Each primitive command is an element (e.g., an indivisible element) in the mission plan that causes a part of the vessel to perform an activity. Multiple activities executed in sequence cause the vessel to perform the operation. Each primitive command can be associated with a control instruction that will cause components of the marine vessel to perform functions that are synonymous with, related to, or based on the primitive command. Therefore, each primitive command can be associated with the operation of one or more marine vessel components.

[0237] To control a vessel executing a mission plan, examples of this disclosure may include: determining or generating vessel control instructions. These instructions, when executed by a processor or controller, will cause at least a portion of the vessel to perform actions that enable the vessel to fulfill the functions of the primitive commands, thereby carrying out operations, activities, and achieving objectives as set forth in the mission plan (depending on the mission plan and how it is composed, etc.).

[0238] Therefore, some examples include: generating instructions that associate one or more automation primitive commands and / or navigation primitive commands with each activity the vessel will perform according to the mission timeline, which, when executed by one or more components of the vessel, enable the vessel to adopt a vessel configuration to autonomously execute the mission plan by executing one or more automation primitive commands and / or navigation primitive commands, thereby performing each activity according to the mission timeline. "Adopting a configuration," as used herein, can depend on the primitive command. For example, for the primitive command "anchor," the instructions would involve controlling the anchor winch (and any other associated equipment, etc.), and thus could include anchor winch instructions in this example. Therefore, the instructions could include instructions for each component of the vessel, which would be used by the vessel to complete the mission plan. These instructions could be executed by the vessel's central controller and / or by individual controllers of the respective marine vessel components. In the latter case, those component controllers could enable the components to perform functions corresponding to the primitive commands, enabling the vessel to perform the operation or each operation (and thus the activity or each activity and the mission plan as a whole). As shown above, the primitive commands associated with the operation or activity can be automation primitive commands and / or navigation primitive commands.

[0239] Instructions can be generated on board the ship, or they can be generated offboard and transmitted to the ship for execution by the ship.

[0240] The attached image Figure 8 The diagram schematically illustrates some of the code elements constituting task configuration computer code 800, which uses, for example... Figure 5A The task planning system of the task planning and monitoring system 500 shown is generated by the task planning system. For example, refer to... Figure 8 The described code may include instructions that, when executed, cause the vessel (e.g., one or more components of the vessel) to perform operations and / or activities and / or, as a whole, a mission plan, as described above. Figure 8 As shown, the mission configuration includes mission configurations for each of the three mission phases (mobilization 508, navigation 510, and demobilization 512) and a backoff state configuration 808. As shown, the mobilization phase configuration code includes an automated sequence 802a of primitive commands, the navigation phase configuration code includes a navigation sequence 804a of primitive commands, and the demobilization phase configuration code includes another automated sequence 802b of primitive commands. The backoff state configuration includes a backoff automated sequence 802c of primitive commands and a backoff navigation sequence 804b.

[0241] Other elements, such as the planned ship mode 806, can also be included in the mission configuration code.

[0242] In some implementations, in addition to the rollback state configuration 808 in the mission configuration established by various automation and navigation sequences 802a, 802b, 802c, 804a, 804b, there is typically a large set of low-level rollback state mechanisms. These low-level rollback mechanisms include primitive command sequences that are executed regardless of the rollback state configuration in the mission configuration. An example of a low-level rollback state is: "If a fire is detected in the engine room, stop the engines and begin fire suppression."

[0243] On the other hand, an example of a configurable high-level rollback state is: "If the main propulsion is not working while a shipping operation is in progress, use the remaining portion of the propulsion capacity to stop and hold at a fixed point, anchor and notify the ROC of the current situation."

[0244] In some implementations, the high-level rollback state configuration 808 and its execution are defined at least by rollback triggers and rollback actions.

[0245] For AV 102, a set of backoff triggers is defined based on conditions that could cause the AV to disengage. Such backoff trigger events include, but are not limited to, loss of one or more of ship propulsion, ship position system, and ship situation awareness. Detection of backoff trigger events is handled by one or more backoff trigger systems. The backoff trigger systems monitor certain state variables or conditions to assess whether a backoff event has been detected and / or what backoff action should be taken in response to the detection of a backoff event.

[0246] In some implementations, during a task, multiple rollback trigger detection processes run in parallel according to the rollback state configuration 808 in the task configuration 800, see, for example, see Figure 8 .

[0247] It will be apparent to anyone skilled in the art that numerous failures may occur on the AV 102, requiring specialized rollback actions to terminate in a suitable and feasible rollback state for a specific failure that has been detected. This may ultimately result in an extremely complex rollback state configuration that covers all possible failure scenarios.

[0248] As described above, each task comprises multiple primitive commands, which are categorized as valid or invalid by being included in or excluded from a list of valid primitive commands assigned to a specific AV 102 for performing that task. This list is maintained by a mechanism that aggregates faulty nodes into valid or invalid primitive commands; see [link to relevant documentation]. Figure 7A and Figure 7B .

[0249] The list of valid primitive commands is used accordingly by the mission's backoff mechanism to determine whether the vessel is operating as it should. (See Shipboard Emergency Backoff System 520) Figure 5A A list of valid primitives is provided, and this list can be used to detect when a fault occurs in AV 102, what kind of fault has occurred, and what type of fault exists in AV 102.

[0250] When configuring the mission plan, the user (or mission planner) of the mission planning and monitoring system 500 can select which primitive commands are assigned to or associated with a fault condition, or in other words, which commands are associated with a backoff state action. For example, suppose AV 102 is operating in the navigation sequence N1-A3-N2-N4-N1-A4-N0. The ship emergency backoff planner 500a associates the navigation primitive command N7 "Follow Target" with the fault condition. If a fault condition is detected, for example, possibly due to some backoff state action determined by the ship's emergency backoff system 520 that would cause that particular navigation primitive command to be executed, then that particular navigation primitive command will not be executed as part of the navigation primitive command sequence. Therefore, when the ship's emergency backoff system 520 detects that AV 102 is now executing the "Follow Target" N7 primitive command, the ship's emergency backoff system 520 can determine that a fault has occurred.

[0251] On the other hand, assuming the main propulsion terminates in the event of a failure, this is reflected in the navigation primitives "shipping" and "autopilot". Therefore, since the "shipping" navigation primitive is part of the navigation sequence given above, and assuming for this example that AV 102 is not started or is not currently running in the "shipping" navigation primitive command, the shipboard emergency backoff system 520 will detect the execution of the navigation primitive "shipping" as a backoff trigger event, and in response to detecting that the ship is executing the navigation primitive command "shipping", the shipboard emergency backoff system 520 will perform the appropriate backoff action.

[0252] Rollback triggers and rollback actions are typically given in pairs in the rollback state configuration configured by the task configuration user or task planner. However, note that in the same fault condition as described above, assuming the vessel completes the navigation sequence with a fault primitive, no rollback action is required. The vessel can directly continue with the remaining portion of the sequence's primitives that is not yet in a fault state.

[0253] The second part of the rollback state configuration in task configuration code 800 includes the rollback state action. Figure 8The rollback state actions shown include both automation sequence 802c and navigation / navigation sequence 804b. Each of the configured rollback state configuration elements includes an action trigger element and an associated resulting action element. Each action element consists of several sets of navigation and automation sequences that collectively provide a risk action table for the rollback of the task. For example, see the example of a risk action table schematically shown. Figure 9 The risk action table includes a priority list of risk actions that can be performed in the indicated priority order in response to a failure occurring on AV102, such as a failure of the ship's transponder system. The priority order is designed to indicate the best possible backoff state in the event of a backoff trigger condition.

[0254] For the attached diagram Figure 9 The risk action table, schematically illustrated, shows that the optimal solution with priority 1 includes the navigation sequence "N4, N6, N5, A5" corresponding to the primitive commands "Proceed to Safe Area," "Decelerate," "Hold to Point," and "Anchor." However, if this solution is not feasible, the next optimal solution would be to execute the navigation sequence with priority 2, which includes N6-N5-A5 corresponding to the primitive commands "Decelerate," "Hold to Point," and "Anchor." Lower priority solutions include the automated sequence A5 or "Anchor." Figure 9 It was also shown that when none of the solutions with priorities 1 to 3 were available, the ship did not perform any navigation or automation sequence, which caused the ship to enter a "drift" state.

[0255] Some implementations of the shipboard emergency backoff system 520 determine which action to take in a prioritized manner by comparing different primitive commands in different priority rows with the list of mission-independent or "always available" primitive commands described above.

[0256] Some implementations of the configured fallback state include n-tuples, where the sequence of n-tuples is a sequence or ordered list of n elements.

[0257] Figure 10 An example of an AV mission is shown, where AV 102 has deviated from waypoint WP1 and is en route along the assigned route (N4) via waypoints WP2, WP3, and WP4 when the vessel experiences a loss of main propulsion as a fault-triggered event. At this point, the first priority is for the vessel to attempt to execute the mission from... Figure 9 The solution with priority 1. If the vessel is unable to perform this operation, the vessel will attempt to execute the solution from [the previous solution]. Figure 9 The solution has priority 2. If this solution cannot be implemented, the ship will attempt to anchor, thus forming... Figure 9The shown action priority 3 is an automated primitive command action. All of these solutions resulted in the abandonment of the initial task of configuring the vessel to continue along the route passing waypoints WP5, WP6, WP7, WP8 to port B.

[0258] Examples of configured rollback state tuples accordingly include rollback triggers and configured rollback action sequences. In some implementations, a rollback trigger event includes a situation where a primitive command, which is to be executed as part of a primitive command assigned to a specific task phase, stops executing; in other words, there is a lack of execution of the primitive command expected by the assigned task. However, in some implementations, a rollback trigger may include the execution of primitive commands not assigned to a specific task. The configured rollback action sequence includes a priority-ordered sequence of primitive commands that AV 102 should attempt sequentially upon detecting a trigger event.

[0259] For example, return to reference Figure 10 If it can be assumed that the ship is currently operating on the shipping segment and suddenly loses main propulsion, this is detected as a trigger event by the onboard emergency backoff system 520 because the current navigation primitive command "shipping" is no longer valid. AV 102 then determines which action to take in response to this specific trigger. An example of a risk action table in the tuple configured for that trigger could be... Figure 9 The table of risk actions is shown schematically.

[0260] This particular risk action table has several action sequences provided in a priority order as described above, which is also in Figure 10 The diagram illustrates this. The first sequence of actions, and the one considered the best to take, is priority 1: "Proceed to a safe area, reduce speed, maintain position, and anchor." However, since priority 1 actions contain the currently unavailable primitive command "N4," because the triggering failure in this case is "loss of propulsion," the vessel will determine and check if the next highest priority retreat sequence is available: "Reduce speed, maintain position, and anchor." Because this sequence does not contain any unavailable primitive commands based on the validity status of the listed primitive commands, the execution of this command sequence with priority 2 is what the vessel attempts to do, and should be able to complete in this case.

[0261] The shipboard emergency return system 520 will send navigation sequence primitives N6-N5, followed by an automated action A5 of priority 2, to the rest of the ship's control system, causing AV 102 to follow the navigation sequence.

[0262] The attached image Figure 11An example implementation of a method 1100 for generating a ship configuration for autonomously executing a mission plan is shown. In some implementations, method 1100 is performed by a mission planning and monitoring system 500. In some implementations, method 1100 includes: generating 1102 a mission plan that includes at least a mobilization phase, a navigation phase, and a demobilization phase; and assigning 1104 one or more activities to be performed by the ship according to a mission timeline to at least one phase of the mission. Not all phases can be assigned activities for autonomous execution according to the ship plan. For example, in some implementations, the mobilization phase may not be assigned any activities from the AV mission. The method also includes: associating each of the one or more activities with one or more primitive commands 1106; identifying 1108 candidate ships for autonomous mission execution; and obtaining 1110 information on the candidate ships' ability to execute the mission plan.

[0263] Activities may not be assigned during the mobilization phase, especially if AV 102 is not able to fully mobilize personnel.

[0264] like Figure 11 As shown, method 1100 further includes: generating 1114 a ship configuration for the ship to adopt in order to autonomously perform the AV tasks planned in 1114, based on the obtained ship capability information. The AV ship configuration associates one or more automation primitive commands and / or navigation primitive commands with each activity that the AV 102 is to autonomously perform according to the mission timeline.

[0265] like Figure 11 As shown, method 1100 further includes, if it is determined 1112 that the vessel can be configured to perform the mission plan in response to obtaining vessel capabilities, then transmitting the mission plan and vessel configuration to the vessel 1116. However, if AV 102 is determined to have capabilities different from those required to perform the mission plan, the method further includes: determining 1118 whether the mission plan can be adjusted to use the different capabilities of AV 102. If the mission plan can be adjusted, the method includes: updating 1120 the mission plan and generating a vessel configuration for the vessel to use based on the updated mission plan in 1114.

[0266] Therefore, method 1100 enables the adaptation of a mission plan to different vessel capabilities by changing at least one primitive command associated with one or more activities of the mission plan and / or activities associated with one or more phases of the mission plan. For example, a vessel's ability to perform a mission will depend on its configuration and available vessel commands. One vessel may have an automated mooring and unmooring system, while another vessel in the same fleet may not. The mission plan can be adapted to each vessel by adjusting the primitive commands used to form the mission plan assigned to each vessel during the mobilization and demobilization phases.

[0267] In some implementations, the vessel is configured to autonomously perform one or more activities in the mobilization phase, which mobilizes the vessel prior to voyage, by executing the mission plan generated by method 1100; one or more activities in the demobilization phase, which demobilizes the vessel after voyage; and one or more activities in the voyage phase, which are to be performed while the vessel is undergoing voyage.

[0268] In some implementations, the mission timing schedule configures AV 102 to automatically initiate AV missions based on predetermined mission start times or events. For example, the start of the mission timing schedule is triggered by a time of day or in response to a decrease in wind speed and / or wave height to below a threshold speed or level. In some implementations, one or more activities and / or primitive commands can be triggered by events defined by the mission timing schedule events. For example, in some implementations, the mission configuration timing schedule configures AV 102 to automatically initiate AV missions based on non-predetermined mission start times, wherein the mission is initiated by the vessel in response to the satisfaction of one or more mission initiation conditions.

[0269] In some implementations, method 1100 generates a task plan that defines at least one operation, or job. Each operation or job includes multiple activities that the ship can autonomously perform at one or more locations during one or more phases of the mobilization phase, demobilization phase, and navigation phase.

[0270] Method 1100 can also generate a task plan that defines a set of primitive commands for each job to be executed in a predefined sequence, the predefined sequence being controlled by a set of flow control primitives. For example, each predefined sequence of primitive commands may include one or more automation primitive commands and / or navigation primitive commands to be executed in a flow defined by a set of flow control primitives.

[0271] In some implementations, the flow control primitives for each operation configure the vessel to perform multiple actions for each operation simultaneously and / or perform multiple operations simultaneously.

[0272] To manage failures affecting mission plan execution, in some embodiments, method 1100 further configures at least one rollback trigger event associated with one or more rollback primitive command sequences that configure the vessel to adopt a rollback state determined according to the mission plan. Each rollback primitive command sequence is assigned a selection priority such that if a primitive command in the highest priority rollback command sequence is unavailable, the next highest priority rollback sequence can be selected if it includes primitive commands without an invalid command state. In other words, the rollback primitive command sequence is selected based on the priority order of the rollback primitive command sequences and the availability of primitive commands in the selected sequence.

[0273] Examples of rollback-triggered events include events associated with detecting or determining that the vessel is no longer executing primitive commands according to its assigned mission timeline. In some implementations, rollback-triggered events include detecting environmental events or sensor readings of the vessel while it is executing primitive commands according to the mission timeline of the mission plan.

[0274] In the case where the mission planning and monitoring system 500 executes method 1100 to plan missions for multiple different vessels, a mission plan can be generated that coordinates at least one action in a vessel's mission timeline. This at least one action will be autonomously performed by the vessel at a time associated with or coordinated with the execution of at least one action performed by at least one other vessel. The at least one action performed by at least one other vessel includes at least one action that is also autonomously performed according to the mission plan configured for that vessel by the mission planning and monitoring system 500. In this way, the mission planning and monitoring system 500 can also be configured to execute methods for configuring a fleet of vessels to autonomously cooperate in executing a fleet mission plan, for example... Figure 12Method 1200 is schematically illustrated herein. Such method 1200 includes: generating at least a fleet task plan 1202 comprising fleet operations and / or activities to be autonomously performed by multiple fleet vessels 102. Method 1200, at 1204, assigns one or more activities and operations to be performed by the fleet to the multiple vessels in the fleet for execution. The one or more activities and / or operations assigned from the fleet task plan form an AV task plan, which is associated with each participating vessel in the fleet. Method 1100 can be used to generate a suitable AV task plan that takes into account the capability of each vessel to execute primitive commands assigned to activities and / or operations at the fleet level, and generates a vessel configuration for each vessel to execute its portion of the fleet AV task plan. These AV task plans can then be updated based on the vessel's capabilities and / or assigned to each AV 102 in the fleet by performing appropriate steps 1106 to 1116 of method 1100 according to any embodiment disclosed herein, as shown at 1206. Step 1208 includes transmitting the vessel mission plan and the vessel configuration for executing the mission plan to each vessel participating in the fleet mission.

[0275] Figure 13 An apparatus 1300 configured to implement an AV task planner system is schematically shown as an example task planning and monitoring system 500 according to the disclosed embodiment. Figure 13 As shown, apparatus 1300 includes memory 1302, computer code / circuit system 1304, and one or more processors or processing circuit systems 1306. When computer code or circuit system 1304 is loaded from memory 1302 and executed by one or more processors or processing circuit systems 1306 of apparatus 1300, computer code or circuit system 1304 causes apparatus 1300 to implement method 1100 and / or method 1200 according to any of the embodiments of the methods disclosed herein.

[0276] Therefore, the disclosed methods 1100 and 1200 enable, for example, an AV mission planner system 500 hosted by ROC 100 to be configured with suitable mission plans within the capabilities of one or more vessels 102, which have suitable onboard ship control systems, for example... Figure 4The ship control system 422 shown executes autonomously, i.e., automatically. Each AV mission plan can be generated initially at a ship-agnostic level and then adapted based on each ship's capabilities to execute primitive commands associated with the activities and operations assigned to the AV mission using the mission planner system 500. If the ship lacks the capability to execute the primitive commands specified by the mission plan for performing specific activities within the AV mission, the mission planner system 500 can be configured to automatically determine alternative primitive commands for autonomously executing the mission plan actions.

[0277] In some embodiments, ROC 100 or task planning and execution system 500 may include device 1300, and computer code or circuitry 1304 may be provided by a computer program product including computer-coded instructions that, when loaded from memory and executed by one or more processors or processing circuitry 1306 of the device, cause the device 1300 to implement one or both of the methods 1100 or 1200 described herein.

[0278] The method for generating task configurations can be performed by a task planner system, such as the task planning and monitoring system 500 shown in Figure 5, to assign tasks to AV 102. The task configuration of the task plan configures AV 102 to autonomously execute task plans.

[0279] In some implementations, the mission plan can be generated by the mission planner initially independently of the ship configuration used by the ship to autonomously execute its assigned mission plan.

[0280] In some implementations, the initial mission plan may be initially ship-agnostic, and the method may include adapting the ship-agnostic mission plan to a ship-specific mission plan in response to receiving ship capability information.

[0281] Some, if not all, of the above method implementations can be implemented using computer program code, which may be provided as software or, for example, hard-coded as a computer program product.

[0282] Those skilled in the art will also understand that the processing circuitry system and memory or computer-readable storage unit described above can refer to a combination of analog and digital circuitry and / or one or more processors configured with software and / or firmware, for example, stored in memory, which, when executed by one or more processors, such as the processing circuitry system, perform as described above. One or more of these processors, along with other digital hardware, may be included in a single application-specific integrated circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, either individually packaged or assembled into a system-on-a-chip (SoC).

[0283] The communication channel used by the ROC to communicate with the AV 102 can be point-to-point or a network, such as through a cellular network or satellite network that supports wireless communication. Wireless communication may conform to one or more public or proprietary communication standards, protocols and / or technologies, including but not limited to Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), High-Speed ​​Downlink Packet Access (HSDPA), Wideband Code Division Multiple Access (W-CDMA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth, Wi-Fi (e.g., IEEE 802.11a, IEEE 802.11b, IEEE 802.11g and / or IEEE 802.11n), Voice over Internet Protocol (VoIP), Wi-MAX, protocols for email (e.g., Internet Message Access Protocol (IMAP) and / or Post Office Protocol (POP)), instant messaging (e.g., Extensible Messaging and Presence Protocol (XMPP), SIMPL for Instant Messaging and Presence and / or Instant Messaging and Presence Service (IMPS)), and / or Short Message Service (SMS) or any other suitable communication protocol.

[0284] The computer code and / or circuit system 1304 may include components of an operating system, including various software components and / or drivers for control, components for managing general system tasks (e.g., memory management, storage device control, power management, etc.), and components for facilitating communication between various hardware and software components, which will be obvious to those skilled in the art and will not be further disclosed herein for the sake of brevity.

[0285] The attached diagram Figure 14 An example embodiment of a method 1600 for configuring a vessel to be safely managed in an emergency, based on the disclosed technology, is illustrated schematically. Figure 14In method 1600, the process includes: generating an AV mission plan for execution by AV 102 in 1102; and generating a vessel contingency plan in 1602 based on capabilities and mission requirements, for autonomously controlling how to abort the mission plan in the event that AV 102 detects a backoff triggering event or condition, and then assigning the plan to AV 102 in 1606. In 1604, the vessel contingency plan associates multiple backoff triggering events with one or more backoff primitive commands.

[0286] By implementing method 1600, AV 102 can be assigned an AV task schedule and is also configured to autonomously handle emergencies that occur during the execution of the assigned AV task schedule, wherein the emergency prevents the AV task schedule from being completed safely or causes the AV task schedule to fail to be completed.

[0287] In some implementations, method 1600 includes generating an AV mission plan 1102, which includes multiple activities for a vessel to perform according to a mission timeline 1104, wherein each activity in the multiple activities is associated with a primitive command 1106; generating a vessel contingency plan, which includes one or more rollback trigger conditions for terminating the AV mission plan before completion, wherein each of the one or more rollback trigger conditions is associated with one or more rollback primitive commands; and assigning the AV mission plan and the contingency plan to the vessel, wherein the assigned contingency plan configures the vessel to execute one or more rollback primitive commands associated with the detected rollback trigger condition in response to the detection of a rollback trigger condition while performing the assigned AV mission plan.

[0288] At least one of one or more backoff triggering conditions includes determining that the availability state of at least one primitive command required to complete the AV mission plan has changed to unavailable during the mission. Therefore, for example, if a component in the engine unexpectedly fails and the vessel loses power, any primitive command requiring engine operation will no longer be available. In some examples, multiple backoff primitive commands can be prioritized for selection; thus, for example, "go to nearest port" may have a higher priority than "anchor and stop engine activity," but if there is no capability to go to the nearest port, the second prioritization solution "anchor and stop engine activity" will instead be selected. In some implementations, the contingency plan may also configure the vessel to select at least one of one or more backoff primitive commands in response to detecting a triggering backoff condition based on the priority order used for selection and the availability state of the backoff primitive command indicating its availability.

[0289] Examples of emergency situations may include any one or more events that prevent AV 102 from completing its mission, or that determine it is capable of safely completing its mission or that pose an acceptable higher risk than failure to complete the mission. For example, sensors may malfunction and / or be damaged, as may equipment, and some backoff triggering events may include equipment malfunction or damage that prevents the assigned AV mission from being completed. Other examples of an AV possibly failing to complete its mission include when there is sufficient fuel loss or lack to prevent the assigned AV mission from being completed, for example, if the vessel encounters an object and fuel leaks. Other possible backoff triggering events include: power loss / lack that prevents the assigned AV mission from being completed, weather forecasts or weather events that prevent the assigned AV mission from being completed, or any other type of maritime emergency where the status of a primitive command used to complete the mission changes its availability to unavailable and prevents the assigned AV mission from being completed.

[0290] The disclosed method 1600 can be implemented using an off-board vessel emergency return planner, which includes memory, computer code, and one or more processors or processing circuitry systems. When loaded from memory and executed by one or more processors or processing circuitry systems, the computer code can cause the off-board vessel emergency return planner to execute method 1600 to configure a vessel configured to autonomously execute an assigned AV mission plan for safe management in an emergency situation that prevents the safe completion of the AV mission plan.

[0291] On AV 102, an onboard vessel emergency plan execution system can be set up for AV 102, which is configured to autonomously follow the assigned AV mission plan. The AV mission plan includes multiple activities to be performed by the vessel according to a mission timeline, wherein each of the multiple activities is associated with a primitive command. The onboard vessel emergency plan execution system includes memory, computer code, one or more processors or processing circuitry systems, and an AV control system, wherein, when loaded from memory and executed by one or more processors or processing circuitry systems, the computer code causes the AV control system to suspend the execution of the assigned AV mission plan in response to the vessel detecting a backoff trigger condition, and to autonomously implement the vessel emergency plan that associates one or more backoff trigger conditions with one or more backoff primitive commands by executing one or more backoff primitive commands associated with the detected backoff trigger condition.

[0292] The vessel's emergency plan can prioritize or sort one or more rollback primitive commands for selection. Computer code can be configured, when executed on board, to trigger the AV control system such that, in response to AV 102 detecting a rollback trigger condition, AV 102 is configured to select at least one of the one or more rollback primitive commands based on the priority order used for selection and the availability of the rollback primitive commands. For example, the computer code can be configured, when executed, to cause the AV control system to monitor the availability status of each primitive command among those used by the vessel for autonomously executing its assigned AV task plan, determine whether the change in availability status, if at least one monitored command changes its availability status to unavailable, includes a rollback trigger condition for the vessel to adopt a rollback state, and, in response to determining that the change in availability status includes a rollback trigger condition for the rollback state the vessel will adopt, reconfigure the vessel for autonomous operation using the selected rollback state according to the vessel's emergency plan.

[0293] The shipboard emergency planner system can also be configured using computer code to select a backoff state in response to the ship detecting a backoff trigger condition, based on the risk score of the backoff state the ship is currently employing and depending on whether the selected backoff state is associated with one or more backoff primitive commands that have a valid state.

[0294] In describing the disclosed technology with reference to the accompanying drawings in the form of block diagrams and / or flowcharts, it should be understood that certain entities in the drawings, such as blocks in the block diagrams and combinations of entities in the drawings, can be implemented by computer program instructions, which can be stored in a computer-readable storage medium and can also be loaded onto a computer or other programmable data processing apparatus. Such computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, and / or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer and / or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of the block diagrams and / or flowcharts.

[0295] In some implementations and according to some aspects of this disclosure, the functions or steps described in the method blocks of methods 1100 and 1200 may not occur in the order described in the instructions for operation, depending on whether the functions or steps are causally related.

[0296] The descriptions of the exemplary embodiments provided herein are presented for illustrative purposes. The descriptions are not intended to be exhaustive or to limit the exemplary embodiments to the precise forms disclosed, and modifications and variations are possible, or can be derived from the practice of various alternatives to the provided embodiments, in accordance with the teachings above. The examples discussed herein were chosen and described to illustrate the principles and properties of various exemplary embodiments and their practical application, enabling those skilled in the art to use the exemplary embodiments in various ways and through various modifications as suited to the particular purpose contemplated. Features of the embodiments described herein can be combined in all possible combinations of methods, apparatuses, modules, systems, and computer program products. It should be understood that the exemplary embodiments presented herein can be practiced in any combination of each other.

[0297] It should be noted that the word "comprising" does not necessarily exclude the presence of other elements, features, functions, or steps besides those listed, and the word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements, features, functions, or steps. It should also be noted that any reference numerals do not limit the scope of the claims, exemplary embodiments can be implemented at least in part by means of both hardware and software, and several "means," "units," or "devices" can be represented by the same item of hardware.

[0298] The various exemplary implementations described herein are described in the general context of the method and may refer to elements, functions, steps, or processes. In one aspect, one or more or all of these elements, functions, steps, or processes may be implemented by a computer program product embodied in a computer-readable medium, including computer-executable instructions such as program code executed by a computer in a networked environment.

[0299] Computer-readable media can include removable and non-removable storage devices, including but not limited to read-only memory (ROM) and random access memory (RAM), which can be static RAM (SRAM) or dynamic RAM (DRAM). ROM can be programmable ROM, PROM, erasable programmable ROM (EPROM), or electrically erasable programmable ROM (EEPROM). Suitable storage components for memory can be integrated as chips into printed circuit boards or other substrates connected to one or more processors or processing modules, or provided as removable components, such as via flash memory (also known as USB sticks), compact discs (CDs), digital versatile discs (DVDs), and any other suitable form of memory. Unless unsuitable for the application at hand, memory can also be distributed across various forms of memory and storage components and can be provided remotely on one or more servers, for example, by a cloud-based storage solution. Typically, program modules can include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code used to perform steps of the methods disclosed herein. Such a specific sequence of executable instructions or associated data structures represents an example of the corresponding action used to implement the function described in such a step or process.

[0300] Memory used by any device, regardless of its form, may include any suitable device-readable and / or writable medium, examples of which include, but are not limited to: any form of volatile or non-volatile computer-readable memory, including but not limited to persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drives, compact discs (CDs), or digital video discs (DVDs)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions that can be used by a processing circuitry system. Memory may store any suitable instructions, data, or information, including computer programs, software, applications including logic, rules, codes, tables, etc., and / or other instructions that can be executed by a processing circuitry system and utilized by a device of any form of electronic device. Memory may be used to store any calculations performed by the processing circuitry system and / or any data received via a user or communication or other type of data interface. In some embodiments, the processing circuitry system and memory are integrated. Memory can also be distributed among one or more system or device components. For example, memory can include multiple different memory modules, including modules located on other network nodes in some embodiments.

[0301] Exemplary aspects of the disclosure have been shown in the accompanying drawings and description. However, many variations and modifications can be made to these aspects that fall within the scope of the appended claims. Therefore, this disclosure should be considered illustrative rather than restrictive in supporting the scope of the claims, which are not limited to the specific examples of the aspects and embodiments described above. The invention illustrated herein by way of example through the various aspects and embodiments described above has the scope defined by the appended claims.

Claims

1. A method for generating a ship configuration for autonomously executing mission plans, the method comprising: Generate a mission plan, which includes at least a mobilization phase, a navigation phase, and a demobilization phase; Assign one or more activities to be performed by the vessel according to the mission timeline to each phase of the mission; Associate each of the one or more activities with one or more primitive commands; Identify candidate vessels for autonomously performing the mission; Obtain information on the candidate vessel's ability to execute the mission plan; as well as Based on the capability information, a ship configuration is generated for the ship to use in autonomously executing the mission plan. The ship configuration associates one or more automation primitive commands and / or navigation primitive commands with each activity that the ship is to perform according to the mission timeline.

2. The method according to claim 1, wherein, The method further includes: In response to obtaining the vessel's capabilities, determine whether the vessel can be configured to execute the mission plan; and If it is determined that the vessel possesses capabilities different from those required to execute the mission plan, then it is determined whether the mission plan can be adjusted to utilize the vessel's different capabilities; and, If the mission plan can be adjusted, the mission plan is updated and a ship configuration for the ship is generated based on the updated mission plan.

3. The method according to claim 2, wherein, Adjust the task plan by changing at least one of the following: Primitive commands associated with one or more activities of the task plan; and / or Activities associated with one or more phases of the task plan.

4. The method according to any one of the preceding claims, wherein, The mission plan configures the vessel to perform autonomously: One or more activities in the mobilization phase that mobilize the vessel prior to voyage; One or more activities in the decommissioning phase that decommission the vessel after the voyage; as well as One or more activities in the navigation phase, which are performed while the vessel is navigating.

5. The method according to any one of the preceding claims, wherein, The task scheduler configures AV 102 to automatically start the AV task based on a predetermined task start time or event.

6. The method according to any one of the preceding claims, wherein, The mission plan defines at least one operation, which includes multiple activities that the vessel can autonomously perform at one or more locations during one or more of the mobilization phase, the demobilization phase, and the navigation phase.

7. The method according to claim 6, wherein, The task plan defines a set of primitive commands for each job to be executed in a predefined sequence, the predefined sequence being controlled by a set of flow control primitives, wherein each predefined sequence of primitive commands includes one or more automation primitive commands and / or navigation primitive commands.

8. The method according to claim 6, wherein, The flow control primitives for each operation configure the vessel to perform multiple actions for each operation simultaneously.

9. The method according to claim 7 or 8, wherein, The flow control primitives used for each job configure the vessel to perform multiple jobs simultaneously.

10. The method according to any one of the preceding claims, wherein, The mission plan also includes a ship contingency plan, which includes at least one rollback trigger condition associated with one or more rollback primitive commands that configure the ship to adopt a rollback state determined according to the ship contingency plan.

11. The method according to claim 10, wherein, The ship emergency plan includes multiple backoff primitive command sequences, wherein each backoff primitive command sequence is assigned a selection priority, and wherein the backoff primitive command sequence is selected based on the priority order of the backoff primitive command sequences and the availability of the primitive commands in the selected sequence.

12. The method according to any one of claims 10 or 11, wherein, The rollback triggering conditions include: detecting that the ship has not executed primitive commands according to the ship's assigned mission timeline.

13. The method according to any one of the preceding claims, wherein, The mission configuration includes at least one coordinated action in the mission timeline, the at least one coordinated action to be performed autonomously by the vessel, and the at least one coordinated action to be coordinated with the execution of at least one action performed by at least one other vessel.

14. The method according to claim 13, wherein, The at least one action performed by the at least one other vessel includes at least one action that is also performed autonomously according to the mission configuration.

15. A method for configuring a fleet of ships to autonomously cooperate in executing a fleet mission plan, the method comprising: Generate fleet mission plans; One or more activities from the fleet mission plan are assigned to the AV mission plan associated with each vessel in the fleet of the vessel, wherein, for each vessel in the fleet, the AV mission plan and the vessel configuration for executing the AV mission plan are generated by performing the method according to any one of claims 1 to 14.

16. An AV task scheduler system, comprising: Memory; Computer code; One or more processors or processing circuitry systems, wherein the one or more processors or processing circuitry systems are configured to execute the computer program code when the computer program code is loaded from the memory, so as to cause the AV task scheduler system to perform the method according to any one of claims 1 to 15.

17. A ship including an autonomous control system, wherein, The autonomous control system is configured to enable the ship to execute one or more primitive commands based on a timeline, according to a mission plan received from the AV mission planner system as claimed in claim 16.

18. A computer program product comprising computer-coded instructions that, when loaded from memory and executed by one or more processors or processing circuitry systems of a device, cause the device to implement the method according to any one of claims 1 to 15.

19. A method for configuring a vessel to be safely managed in an emergency, the vessel being configured to autonomously execute an assigned AV mission plan, the emergency preventing the safe completion of the AV mission plan or causing the AV mission plan to fail to be completed, the method comprising: Generate an AV mission plan, which includes multiple activities for the ship to perform according to a mission timeline, wherein each of the multiple activities is associated with a primitive command; Generate a ship contingency plan, the ship contingency plan including one or more rollback trigger conditions for suspending the AV mission plan before completion, wherein each of the one or more rollback trigger conditions is associated with one or more rollback primitive commands; and The AV mission plan and the contingency plan are assigned to the vessel, wherein the assigned contingency plan configures the vessel to: in response to the detection of a rollback trigger condition while executing the assigned AV mission plan, execute one or more rollback primitive commands associated with the detected rollback trigger condition according to the contingency plan.

20. The method according to claim 19, wherein, At least one of the one or more rollback trigger conditions includes: determining that the availability status of at least one primitive command required to complete the AV task plan has changed to unavailable during the task.

21. The method according to any one of claims 19 or 20, wherein, The one or more fallback primitive commands are ordered according to the priority order used for selection.

22. The method according to claim 21, wherein, The contingency plan also configures the vessel to: in response to detecting a triggered backoff condition, select at least one of the one or more backoff primitive commands according to the priority order used for selection and based on the availability status of the backoff primitive commands indicating that they are available.

23. The method according to any one of claims 19 to 22, wherein, The emergency situation includes one or more of the following rollback trigger events: Equipment malfunction or damage prevents the assigned AV task from being completed; Fuel loss or lack sufficient to prevent the assigned AV task from being completed; Power loss / lack, which prevents the assigned AV task from being completed; Weather forecasts or weather events that prevent the assigned AV task from being completed; Any other type of maritime emergency that causes the status of the primitive command used to complete the task to change from the availability state of the primitive command to the unavailability state, and prevents the assigned AV task from being completed.

24. A non-shipborne vessel emergency return planner, the non-shipborne vessel emergency return planner comprising: Memory; Computer code; as well as One or more processors or processing circuitry systems The computer code, when loaded from memory and executed by the one or more processors or processing circuitry, causes the off-board vessel emergency return planner to perform the method according to any one of claims 19 to 23, to configure a vessel configured to autonomously execute an assigned AV mission plan for safe management in an emergency situation that prevents the safe completion of the AV mission plan.

25. A shipboard emergency plan execution system for a vessel, configured to autonomously follow an assigned active mission plan (AV), the AV mission plan comprising multiple activities to be performed by the vessel according to a mission timeline, wherein, Each of the multiple activities is associated with a primitive command, wherein the shipborne emergency plan execution system includes: Memory; Computer code; One or more processors or processing circuitry systems; and AV control system When the computer code is loaded from memory and executed by the one or more processors or processing circuitry, it causes the AV control system to perform the following operations in response to the ship detecting a reversal trigger condition: Suspend the execution of the assigned AV task plan; and By executing one or more rollback primitive commands associated with the detected rollback trigger conditions, a ship emergency plan that associates one or more rollback trigger conditions with the one or more rollback primitive commands is autonomously implemented.

26. The shipborne emergency planner execution system according to claim 25, wherein, The ship's emergency plan sorts one or more rollback primitive commands in order of priority for selection, and wherein, when the computer code is loaded from memory and executed by the one or more processors or processing circuitry, it causes the AV control system to perform the following operations in response to the ship detecting a rollback trigger condition: In response to the detection of a triggered fallback condition, at least one of the one or more fallback primitive commands is selected based on the priority order used for selection and the availability of the fallback primitive commands.

27. The shipborne emergency planner execution system according to claim 25 or 26, wherein, When the computer code is loaded from memory and executed by the one or more processors or processing circuitry, it causes the AV control system to: Monitor the availability status of each of the primitive commands used by the vessel to autonomously execute the AV mission plan assigned to the vessel; If at least one monitored command changes the availability status of the command to unavailable, then determine whether the change in availability status constitutes a backoff trigger condition for the vessel to adopt a backoff state, and In response to the determination that the change in availability status constitutes a reversal trigger condition for the vessel to adopt a reversal state, the vessel is reconfigured for autonomous operation in the selected reversal state according to the vessel's contingency plan.

28. The shipborne emergency planner system according to claim 27, wherein, When the computer code is loaded from memory and executed by the one or more processors or processing circuitry, the AV control system causes the vessel to perform the following operations in response to the vessel detecting a reversal trigger condition: The backoff state is selected based on the risk score of the backoff state adopted by the vessel and according to the association of the selected backoff state with one or more backoff primitive commands with valid states.

Images