AV mission planning and emergency handling using primitive commands

Abstract

An autonomous vessel mission planning method 1100 generates an AV mission 1102 and determines 1112 a vessel configuration for a vessel to autonomously perform a mission plan. The mission plan 1102 has

Description

[0001] The present disclosure relates to autonomous vessel, AV, mission planning, for example, to an AV management system configured to support AV mission planning and to related aspects. In particular, but not exclusively, the disclosed AV mission planning system may also be used to plan how an AV is handled during an emergency or similar unexpected event disrupting the execution by the vessel of its assigned mission plan.

[0002] AV operation, in other words the operation of a vessel such as a ship or any other type of sea-going or water-travelling craft which navigates on or under water without a person or persons on the vessel having collectively or individually complete control of the vessel operation is somewhat more complicated than the operation of land-based craft.

[0003] Firstly, such AVs operate in a far more dynamic environment. An operation such as route navigation, for example, may need to take into account lateral water movement (e.g. currents), water depth (e.g. tidal movement), as well as time of day, time of month, and seasonal variation. This can also impact time of day when docking and departing a port, as well as other operations that a working watercraft may need to perform internally and externally when approaching and departing a port, when docked in port, and when on the open water or at one or more other locations on a voyage or passage plan. The weather must also be taken into account, not just wind speed but also wave height, and watercraft need to be able to react swiftly to situations which may escalate over a short amount of time. Secondly, the capabilities of different vessels to follow a mission plan autonomously may differ hugely.

[0004] There is accordingly a need to improve the management of AVs, including improving how AVs are assigned missions for autonomous execution and how AVs are configured to cope with any unexpected events or emergencies which arise whilst they are autonomously executing an assigned vessel mission. SUMMARY

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

[0006] The disclosed technology seeks to provide an off-board AV management system capable of planning AV mission(s) and assigning an AV mission plan to one or more vessels for autonomous execution. The off-board AV management system also provides remote oversight of a vessel whilst it is performing an assigned AV mission and may also enable remote control of the vessel when appropriate.

[0007] The disclosed examples of AV management systems comprise various components and sub-systems which may be on-board and / or off-board the vessels or distributed, for example, so called cloud-based system control may be implemented in some embodiments.

[0008] As used herein the term AV refers to any vessel, ship, or other water-craft, which is able of autonomously performing certain navigational actions and autonomously performing certain operational commands and functions so that it can complete an assigned vessel mission autonomously, in other words, without requiring human oversight on its bridge. The term AVs also refers to vessels which may also be monitored by and remotely controlled from time to time or in emergencies by an off-board human overseer located at a remote operations centre.

[0009] Generally, and without limitation, the disclosed AV management system(s) comprise at least the following elements: one or more AVs, which may be controlled to a greater or lesser extent as a fleet, each AV having an on-board AV control system including a mission management and monitoring sub-system which configures the vessel to be capable of handling an assigned AV mission plan autonomously. This AV control system on-board the AV is also capable of autonomously detecting and handling emergencies which unexpectedly prevent an AV from completing its assigned mission. Complementing this, the AV management system also includes an off-board mission planning and monitoring system which may be hosted at a remote operation centre, ROC, where an overseer may obtain oversight of and / or remotely control one or more operations or functions performed by the one or more AVs , and one or more suitable wireless data communications systems configured to provide connectivity between the ROC and the one or more AVs .

[00010] A mission plan is accordingly configured at the ROC based on an understanding of a vessel’s capability to complete the mission if it is assigned to that vessel. The mission plan is designed and assigned to the vessel by a mission planner, which may be a user of the mission planning and monitoring system hosted at the ROC or autonomously designed and assigned if software with such a capability and the ability to determine a vessel’s ability to complete an assigned mission is hosted at the ROC. In some embodiments, more than one ROC may host a remote mission planning system allowing access from a number of locations, including another vessel if such a vessel acts as a ROC.

[00011] A first aspect of the disclosed technology comprises a method for generating a vessel configuration for a vessel to autonomously perform a mission plan, the method comprising generating a mission plan, the mission plan comprising at least a mobilization phase, a voyage phase, and a demobilization phase, and assigning to each phase of the mission one or more activities for the vessel to perform according to a mission time-line, associating each activity of the one or more activities with one or more primitive commands, and determining a candidate vessel for autonomously performing the mission, obtaining capability information for the candidate vessel to perform the mission plan, and based on the capability information, generating a vessel configuration for the vessel to adopt to autonomously perform the mission plan, the vessel configuration associating one or more automation and / or navigation primitive commands with each activity the vessel is to perform according to the mission time-line.

[00012] Advantageously, if the capability information indicates a particular vessel cannot complete a mission being planned or is unlikely to, the mission planner can either adapt the mission to suit the vessel’s capabilities and / or select another vessel which has capabilities by consulting a data base of such vessels and their capabilities.

[00013] In some embodiments, the method further comprises, responsive to obtaining the vessel capability, determining if the vessel can be configured to perform the mission plan and if the vessel is determined to have a different capability from a capability required to perform the mission plan, determining if the mission plan can be adapted to use the different capability of the vessel; and, if the mission plan can be adapted, updating the mission plan and generating a vessel configuration for the vessel to adopt based on the updated mission plan.

[00014] In some embodiments, the mission plan is adapted by changing at least one primitive command associated with one or more activities of the mission plan and (or alternatively) changing an activity associated with one or more phases of the mission plan.

[00015] In some embodiments, the mission plan configures the vessel to autonomously perform one or more activities in the mobilization phase, the activities mobilizing the vessel prior to a voyage, one or more activities in a demobilization phase, the activities demobilizing the vessel after a voyage, and one or more activities in the voyage phase, the activities to be performed whilst the vessel undergoes a voyage.

[00016] In some embodiments, the mission plan (or mission “time-plan”) configures the vessel to automatically initiate the AV mission based a predetermined mission initiation time or event.

[00017] In some embodiments, the mission plan defines at least one task comprising a plurality of activities for the vessel to autonomously perform at one or more locations during one or more of the mobilization phase, the demobilization phase and the voyage phase.

[00018] In some embodiments, the mission plan defines for each task a set of primitive commands for execution in a predefined sequence controlled using a set of flow control primitives, wherein each predefined sequence of primitive commands comprises one or more automation primitive commands and / or navigation primitive commands. “Primitive commands” may also be referred to as “command primitives” herein.

[00019] In some embodiments, the flow control primitives for each task configure the vessel to perform a plurality of actions for each task concurrently.

[00020] In some embodiments, the flow control primitives for each task configure the vessel to perform a plurality of tasks concurrently.

[00021] In some embodiments, the mission plan further comprises a vessel emergency plan comprising at least one fall-back trigger condition associated with one or more fall-back primitive commands which configure the vessel to adopt a fall-back state determining according to the vessel emergency plan.

[00022] In some embodiments, the vessel emergency plan comprises a plurality of fall-back primitive command sequences, wherein each fall-back primitive command sequence is assigned a selection priority, and wherein a fall-back primitive command sequence is selected based on its priority ranking and the availability of the primitive commands in the selected sequence.

[00023] In some embodiments, the fall-back trigger condition comprises detecting the vessel is not performing a primitive command according to its assigned AV mission time-line.

[00024] In some embodiments, the mission configuration includes at least one coordinated action in the mission time-line which is to be autonomously performed by the vessel which is coordinated with the performance of at least one action performed by at least one other vessel.

[00025] In some embodiments, the at least one action performed by the at least one other vessel comprises at least one action also performed autonomously in accordance with a mission configuration.

[00026] According to another, second, aspect of the disclosure a method for configuring a fleet of vessels to co-operate autonomously when performing a fleet mission plan is provided, 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 vessel in the fleet of vessels, wherein the AV mission plan and vessel configuration for performing the AV mission plan is generated for each vessel in the fleet by performing the method according to the first aspect or any one of its disclosed embodiments.

[00027] According to another, third, aspects of the disclosure, an AV mission planner system is provided, the system comprising memory; computer code; and one or more processor(s) or processing circuitry, wherein the one or more processor(s) or processing circuitry are configured to execute the computer program code when loaded from the memory to cause the planner system (or “planner apparatus”) to perform a method according to the first aspect or second aspect or any one of their disclosed embodiments.

[00028] According to another, fourth, aspect of the disclosure, a vessel comprising an autonomous control system is provided, the autonomous control system being configured to cause the vessel to execute one or more primitive commands based on a time-line according to a mission plan received from the vessel planner system of the third aspect or any one of its disclosed embodiments.

[00029] Another, fifth, aspect of the disclosed technology relates to a computer program product comprising computer coded instructions which when loaded from memory and executed by one or more processor(s) or processing circuitry of an apparatus, cause the apparatus to implement the method of any one of the disclosed first or second aspects or one of their disclosed embodiments.

[00030] The disclosed technology enables a mission plan for a vessel to autonomously execute to be generated without needing to determine initially if a vessel has the capability to autonomously perform every primitive command associated with the planned mission activities. After this initial mission planning stage when the mission plan primitive commands and related activities are known, a vessel’s capabilities to autonomously execute the primitive commands to the mission plan activities can be checked by obtaining vessel capability information. If the vessel has the capability to perform the mission activities but only if different primitive commands are used, the mission plan activities can be updated to refer to primitive commands which the vessel has the capability to execute autonomously. Alternatively, the AV mission may be assigned to a different vessel which has a more suitable set of capabilities to perform the AV mission autonomously. In this way, it is also possible to generate a single vessel agnostic mission plan and to then adapt that mission plan to vessel specific mission plans which suit the different capabilities of different vessel types. In other words, the disclosed technology enables both vessel agnostic and vessel specific mission plans to be generated using the same mission planner system in a very timely and computer resource efficient manner.

[00031] A vessel agnostic mission plan can be stored in the form of an AV mission template and later retrieved from storage by a mission planner and adapted to suit the capabilities of specific vessel types and vessels. This not only allows mission plans to be generated more speedily by a user but may also allow stored missions to occupy less memory than if a single vessel agnostic mission plan is stored instead of multiple vessel specific mission plans.

[00032] Storing AV mission plans, whether vessel agnostic or vessel specific, also rapid retrieval and allows modified AV missions to be more quickly generated, as a mission plan can be later updated rather than regenerated from scratch. Such updates may accommodate new vessel types and both new and old vessels which have new mission capabilities, for example, if a vessel has an item of equipment upgraded so that it can be remotely monitored and controlled, or autonomously controlled by a vessel automation control system. Vessel capability information can also be stored which enables vessels which can execute a mission plan autonomously to be searched for and identified as suitable vessel candidates when planning a mission for autonomous execution.

[00033] Advantageously, the disclosed technology enables a mission plan for a vessel to autonomously execute to be generated without needing to determine initially if a vessel has the capability to autonomously perform primitive commands associated with planned mission activities at the initial mission planning stage. Once the mission plan activities are known however, a vessel’s capabilities to perform those activities can be checked by obtaining vessel capability information. If the vessel has the capability to perform the mission activities but only if different primitive commands are used, the mission plan activities can be updated to refer to those available primitive commands instead. In this way, it is possible to generate a single mission plan and to then adapt that the mission plan to suit the different capabilities of different vessel types. In other words, advantageously the disclosed technology enables both vessel agnostic and vessel specific mission plans to be generated using the same mission planner system. Alternatively, another vessel may be located at this point by looking up in a database of stored vessel capabilities to see if a vessel has a capability match with the capabilities required to complete the mission plan.

[00034] The mission planning software tool accordingly provides at least the technical advantage of being able to improve AV mission planning for an AV. By being better able to match an AV mission to an AV capable of implementing the AV mission missions may be better matched to AVs which are the most suitable to perform the mission. This allows for AVs to be selected which are better adapted to execute a mission in a time and cost-efficient way.

[00035] Another, sixth, aspect of the disclosed technology comprises a method of 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 AV mission plan from being safely completed or not completed. The method comprises generating an AV mission plan comprising a plurality of activities for a vessel to perform according to a mission time-line, wherein each activity of the plurality of activities is associated a primitive command, generating a vessel emergency plan comprising one or more fall-back trigger conditions for aborting the AV mission plan prior to completion, wherein each of the one or more fall-back trigger conditions is associated with one or more fall-back primitive commands, and assigning the AV mission plan and emergency plan to the vessel, wherein the assigned emergency plan configures the vessel, responsive to the detection of a fall-back trigger condition whilst executing the assigned AV mission plan, to execute the one or more fall-back primitive commands associated with the detected fall-back trigger condition according to the emergency plan.

[00036] In some embodiments, at least one fall-back trigger condition of the one or more fall-back trigger conditions comprises determining an availability status of at least one primitive command required to complete the AV mission plan has changed to unavailable during the mission.

[00037] In some embodiments, the one or more fall-back primitive commands are ranked in a priority order for selection. For example, in some embodiments, the commands are ranked according to an operator’s preference, and / or are based on a vessel’s capability.

[00038] In some embodiments, the emergency plan further configures the vessel to select at least one of the one or more fall-back primitive commands responsive to detecting a trigger fall-back condition according to the priority order for selection and based on availability status of the fall-back primitive command indicating that fall-back primitive command is available.

[00039] In some embodiments, the emergency comprises one or more of the following fall-back trigger events: an equipment malfunction or breakdown which prevents the assigned AV mission from being completed, a sufficient loss or lack of fuel to prevent the assigned AV mission from being completed, a loss / lack of electrical power which prevents the assigned AV mission from being completed, a weather forecast or weather event which prevents the assigned AV mission from being completed or any other type of emergency at sea that causes the status of a primitive command for completing the mission to change its availability status to unavailable and prevents the assigned AV mission from being completed.

[00040] Another, seventh, aspect of the disclosed technology comprises an off-board vessel emergency fall-back planner, the off-board vessel emergency fall-back planner comprising memory, computer code, and one or more processors or processing circuitry, wherein the computer code, when loaded from memory and executed by the one or more processors or processing circuitry, causes the off-board vessel emergency fall-back planner to perform the method according to the sixth aspect or any one of its disclosed embodiments to configure a vessel configured to autonomously perform an assigned AV mission plan to be safely managed in an emergency which prevents the AV mission plan from being safely completed.

[00041] Another, eighth, aspect of the disclosed technology comprises an on-board vessel emergency plan execution system for a vessel configured to autonomously follow an assigned AV mission plan comprising a plurality of activities for the vessel to perform according to a mission time-line, wherein each activity of the plurality of activities is associated with a primitive command, wherein the on-board vessel emergency plan execution system comprises memory, computer code, one or more processors or processing circuitry, and an AV control system, wherein the computer code, when loaded from memory and executed by the one or more processors or processing circuitry, causes the AV control system, responsive to the vessel detecting a fall-back trigger condition, to: abort execution of the assigned AV mission plan and autonomously implement a vessel emergency plan associating one or more fall-back trigger conditions with one or more fall-back primitive commands by executing the one or more fall-back primitive commands associated with the detected fall-back trigger condition.

[00042] In some embodiments of the on-board vessel emergency planner execution system, the vessel emergency plan ranks one or more fall-back primitive commands in a priority order for selection, and the computer code, when loaded from memory and executed by the one or more processors or processing circuitry, causes the AV control system, responsive to the vessel detecting a fall-back trigger condition, to: select at least one of the one or more fall-back primitive commands responsive to detecting a trigger fall-back condition according to the priority order for selection and based on availability of the fall-back primitive command.

[00043] In some embodiments, the computer code, when loaded from memory and executed by the one or more processors or processing circuitry, causes the AV control system to monitor an availability status of each of the primitive commands used by the vessel to autonomously execute its assigned AV mission plan, determine, if at least one monitored command changes its availability status to unavailable, if the change of availability status comprises a fall-back trigger condition for the vessel to adopt a fall-back state, and, responsive to determining the change of availability status comprises a fall-back trigger condition for a fall-back state to be adopted by the vessel, cause the vessel to be reconfigured for autonomous operation with a selected fall-back state according to the vessel emergency plan.

[00044] In some embodiments, the computer code, when loaded from memory and executed by the one or more processors or processing circuitry, causes the AV control system, responsive to the vessel detecting a fall-back trigger condition, to select a fall-back state based on a risk score for that fall-back state being adopted by the AV and dependent on the selected fall-back state being associated with one or more fall-back primitive commands having an valid status.

[00045] Advantageously, by configuring the AV to also handle an emergency when generating a mission plan for the AV, the AV monitor can be more confident that they will know how the AV will be able to adapt to changing situations even in the event of an emergency which severs communications between the AV and the ROC-based mission monitor.

[00046] An example of the disclosed technology comprises an on-board emergency fall-back management system for safely controlling the autonomous operation of an AV if it encounters an emergency or other type of unexpected and unforeseeable event at the time the mission was configured whilst following the mission. The fall-back management system configures the AV to execute one or more fall-back primitive command sequences associated with a fall-back trigger event being detected by the AV. The fall-back primitive command sequences are associated with various triggers, for example, the lack of availability of a particular primitive command, and are configured by the mission planner when planning the AV mission. Each fall-back primitive command identifies which alternative sequence(s) should be executed by the AV in the event an emergency results in one or more of the vessel capabilities being lost so that the AV cannot execute one or more actions according to its assigned mission plan.

[00047] In some embodiments the fall-back management system is configured to monitor the validity status of a plurality of primitive commands used by the AV to autonomously execute an AV mission plan, determine, if at least one monitored command used by the currently executing mission plan no longer has a valid status, if the change of validity status comprises a trigger event for the vessel to adopt a fall-back state, and responsive to determining the change of validity status comprises a trigger event for a fallback to be adopted by the vessel, causing the vessel to be re-configured for autonomous operation with a selected fall-back state.

[00048] In some embodiments, the fall-back state is selected based on a risk score for that fall-back state and based on the fall-back state being associated with one or more primitive commands having an invalid status.

[00049] The disclosed aspects and embodiments may be combined with each other in any suitable manner which would be apparent to someone of ordinary skill in the art. LIST OF FIGURES

[00050] Some embodiments of the disclosed technology are described below with reference to the accompanying drawings which are by way of example only and in which: Figure 1 shows schematically an example of an AV fleet according to some embodiments of the disclosed technology; Figure 2 shows schematically an example of an AV mission from port A to port B which may be performed by an AV according to some embodiments of the disclosed technology; Figure 3 shows schematically an example of an AV mission from port A to an area of operation on the water which may be performed by an AV according to some embodiments of the disclosed technology; Figure 4 shows schematically a system for fully AV operation according to some embodiments of the disclosed technology; Figure 5A shows schematically a mission planning and execution system according to some embodiments of the disclosed technology; Figure 5B shows schematically an example of a data flow between the on and off-board mission planning sub-systems and components according to some embodiments of the disclosed technology; Figure 5C shows schematically an example of a data flow between the on-board and off-board mission planning and execution sub-systems according to some embodiments of the disclosed technology; Figure 6 shows schematically an example of an automation sequence comprising a plurality of tasks / jobs running in a semi-parallel manner according to an example embodiment of the disclosed technology; Figures 7A and 7B show schematically respective examples of how unavailable primitive commands may affect automated equipment according to respective example embodiments of the disclosed technology; Figure 8 shows schematically an example of how mission configuration code defines different phases of a mission and also defines a fall-back-state configuration according to some embodiments of the disclosed technology; Figure 9 shows schematically a risk action table according to some embodiments of the disclosed technology; Figure 10 shows schematically an example of a mission scenario where a fall-back trigger event occurs according to some embodiments of the disclosed technology; Figure 11 shows schematically an example of a method for generating a vessel configuration for a vessel to autonomously perform a mission plan according to some embodiments of the disclosed technology; Figure 12 shows schematically an example of a method for generating a vessel configuration for each of a plurality of vessels in a fleet to collectively autonomously perform a fleet mission plan according to some embodiments of the disclosed technology; Figure 13 shows schematically an example of an apparatus configured to implement one or both of the methods shown schematically in Figures 11 and 12 and described herein; and Figure 14 shows schematically an example of a method of generating a vessel emergency plan according to some embodiments of the disclosed technology. DETAILED DESCRIPTION

[00051] Aspects of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. The apparatus and method disclosed herein can, however, be realized in many different forms and should not be construed as being limited to the aspects set forth herein. Steps, whether explicitly referred to a such or if implicit, may be re-ordered or omitted if not essential to some of the disclosed embodiments. Like numbers in the drawings refer to like elements throughout. However, the same element may be referred to in different embodiments using a different number in the drawings.

[00052] The terminology used herein is for the purpose of describing particular aspects of the disclosure only, and is not intended to limit the disclosed technology embodiments described herein. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[00053] Figure 1 shows schematically an example of an AV fleet infrastructure according to some embodiments of the disclosed technology. In Figure 1, the fleet comprises three vessels 102 which are shown schematically having individual wireless data connections 104 with a fleet remote operations centre, ROC 100. ROC 100 may host an AV mission planning and execution system 400 according to some of the embodiments of the disclosed technology described later below.

[00054] Each AV 102 is capable of undertaking an AV mission autonomously, in other words autonomously mobilizing to undertake a voyage from a given location to another location and then demobilizing afterwards without need for interaction from a human operator. Each AV mission accordingly comprises three phases. The first phase is a mobilizing phase which plans for one or more mobilizing activities prior to departure of the vessel. The second phase is a voyage phase where the vessel performs one or more activities after its departure and before it arrives at its destination. The third phase is a demobilizing phase which comprises one or more demobilizing activities for the vessel to autonomously perform after its arrival at its destination. Examples of mobilizing and demobilizing activities include but are not limited to activities such as loading and unloading cargo, starting and stopping battery charging, engaging, mooring and unmooring, and deploying / disengaging a gangway, etc.

[00055] An AV mission accordingly comprises three phases (mobilize, voyage, demobilize) which may each comprise a number of activities which are to be performed autonomously by the AV 102.

[00056] Figure 2 and Figure 3 show schematically different examples of an AV mission which may be configured using the disclosed technology. Figure 2 shows schematically an example of an AV mission from port A to port B which may be autonomously performed by an AV 102 according to some embodiments of the disclosed technology. Figure 3 shows schematically an example of an AV mission from port A to an area of operation on the water which may be autonomously performed by AV 102 according to some embodiments of the disclosed technology.

[00057] In Figure 2, AV 102 starts its assigned AV mission shown at waypoint 1, labelled WP1, which is located in port A. After performing mobilization activities, the AV 102 starts its voyage phase and follows a transit route 106 comprising waypoints WP1 to WP7, located in port B (where the AV 102 is also labelled in Figure 2). Transit route 106 is configured so that the vessel moves safely and takes into account in addition to environmental conditions, the presence of other marine traffic shown as other vessels 108 in Figure 2.

[00058] Figure 2 also shows schematically a ROC 100 which assigns the AV mission plan to AV 102 to autonomously travel from port A to port B. The mission plan defines one or more mobilizing activities for the vessel to autonomously perform prior to its departure from port A, one or more demobilizing activities for the vessel to perform autonomously after arriving at port B, and one or more voyage activities. An example of an autonomous mission plan defines unmooring and unberth related activities in port A, one or more berth and mooring related activities at port B as well as activities which the vessel may need to perform during the voyage from A to B. For example, when operating autonomously in the voyage phase of a planned AV mission, the AV 102 must be able to avoid grounding in low water and also avoid collisions with other hazardous obstacles along the journey, such as other vessels 108 and any other objects which may be floating in the sea.

[00059] Figure 3 shows schematically how AV 102 may execute a different type of mission plan which defines a transit route 106 from port A to a mission area where the vessel is to perform one or more tasks, each task comprising one or more activities. In Figure 3, two mission areas 110a, 110b are shown schematically as hatched areas byway of example. In mission area 110a, the AV 102 will operate in a follow target mode, following a remote operated vehicle, ROV 112 controlled from the ROC 100a. In mission area 110b, the AV 102 navigates along a predefined survey route.

[00060] The mission plan objective in Figure 3 is for AV 102 to autonomously enter an operation area comprising mission areas 110a, 110b rather than autonomously navigate itself to another designation such as the port B destination shown in Figure 2. The voyage part of the AV mission shown in Figure 3 has capability requirements which include the same or similar capabilities as those used for the mission voyage shown in Figure 2, however the demobilization activities may be very different.

[00061] Each AV 102 may be configured to autonomously execute a mission plan generated by one or more different ROCs 100 and the performance of the vessel whilst following a mission plan may be monitored by the same ROC 100 that configured that mission plan or by a different ROC in some embodiments. A ROC 100 may generate a mission time-line for performing the activities associated with each phase of a mission plan. In some embodiments, the mission time-line may specify a time of day / week / month etc. when the AV mission is to be autonomously executed by the vessel. In some embodiments, however, a mission plan may be generated with a mission time-line which allows the ROC 100 to remotely initiate the vessel starting its AV mission.

[00062] Figure 3 shows schematically a ROC 100a which may be used to plan a vessel mission for an AV to autonomously execute and which may also initiate AV 102 following its mission plan time-line, however, whilst the AV 102 performing its autonomous mission plan, the AV 102 may alternatively be monitored and / or controlled by another ROC 100b.

[00063] In some embodiments a ROC 100 comprises a computer platform which allows an operator to have control of a fleet comprising more than one AV 102 which may each have to perform autonomous tasks in parallel or sequentially. Fleet missions may comprise a plurality of individual AV missions which are configured for different vessels 102. A fleet mission may be configured by a fleet operator in some embodiments.

[00064] According to some embodiments of the disclosed technology a ROC 100 hosts a mission planning and monitoring system 500 (see the description of Figure 5B provided later below) which is used to generate and / or upload mission-plans which are then sent to one or more vessels 102 along with a suitable vessel configuration to allow each vessel to implement its assigned mission plan autonomously.

[00065] In some embodiments, the mission planning and monitoring system 500 hosted by a ROC 100 is configured to send a mission-plan to each AV 102 in a fleet where each vessel is assigned in its mission plan a subset of activities which are collectively assigned to a fleet of vessels to perform. The ROC 100 may be capable of initiating when each mission plan is to be started by each vessel in the fleet and in some missions, the activities and / or tasks performed by different vessels in the fleet can be coordinated by the ROC 100.

[00066] The ROC 100 may also host apparatus which enables in addition to mission planning, intervention by an operator whilst a vessel is involved in an ongoing and previously AV mission. An example of a trigger for such an intervention is when a situation develops which is beyond the capability of an AV 102 to handle autonomously. Another example of an intervention trigger is when a mission changes dynamically whilst being performed by the vessel, for example, due to one or more events in the vicinity of the vessel.

[00067] Figures 2 and 3 do not represent schematically any wireless data connectivity between the AVs 102 and ROC 100 in Figure 2 or between the vessels 102, 112 and ROCs 100a and 100b in Figure 3 for the sake of clarity. Such wireless connections are required to support wireless communications between the ROC 100 and an AV 102 (these were shown as connection links 104 in Figure 1). Each vessel may establish a communication link periodically, intermittently as needed, or maintain a communication link with one or more ROCs 100.

[00068] In some embodiments, a benefit of a vessel maintaining more than one channel or communications link with one or more ROCs 100 is that this can support more reliable communications with a ROC 100. The communications may be cellular or another type of wireless communications link and may use more than one carrier and carriers of different types, for example, a radio link, cellular phone network, satellite link may be used.

[00069] Figure 4 shows schematically an example embodiment of an AV operation, AVO, system 400 according to the disclosed technology. In this example, AVO system 400 comprising a ROC 100 which hosts a fleet monitoring and control system 402 and an AV 102 which includes an on-board vessel control system 422 and various other systems and subsystems and components enable the vessel to be remotely configured by the ROC 100 to autonomously follow an AV mission plan.

[00070] In Figure 4, AVO system 400 comprises a number of interconnected functional systems 402-420 located variously on and off an AV 102. As shown in Figure 4 the functional systems 402 to 420 used for AV operation comprise an off-board fleet monitor and control system 402 hosted or accessed by the ROC 100, which communicates with an AV 102 via vessel communication system 404. The vessel communication system 404 comprises in some embodiments a vessel to shore system 406a and a vessel to vessel communications system 406b. AV 102 also comprises an on-board equipment operation system 408, a vessel manoeuvring system 410, a vessel navigation system 412, and a mission management system 414. The equipment operation system 408 can communicate via wired or wireless communication with equipment 416. Equipment sensors 420 generate sensor data for one or more items of equipment or equipment systems and the sensor readings are communicated to equipment sensor analysis system 418a which is configured to provide sensor analysis, and which may also share data with the vessel navigation system 412 and / or other on-board systems (the latter is not shown in Figure 4). The vessel 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 an environment sensor and analysis system 418b may be provided which obtains sensor data from sensors located in the environment around the vessel.

[00071] In Figure 4, ROC 100 implements a fleet monitoring and control system 402 which is able to communicate with the vessel using its vessel to shore communication system 406a on-board AV 102 via one or more suitable communications links 104, which may include, for example, satellite communications and / or cellular data communications depending on the location of the vessel and available network coverage. The vessel to shore communication system 406a comprises the functional communication components required to allow the vessel to autonomously communicated with ROC 100. For example, AV to shore communications 406a may use one or more security functions such as cyber authentication and authorization. To implement the vessel to shore communications functionality, however, additional infrastructure may be required on and off the AV 102, for example, land-based communications infrastructure may be needed to facilitate communications with AV 102 via a shore to satellite communications system. Another example of additional infrastructure which may be needed to allow an AV 102 to autonomously execute a mission plan comprises vessel-to port communications infrastructure.

[00072] Some embodiments of vessel fleet and control system 402 enable AV 102 to be remotely monitored at the ROC 100 and, if required, for the vessel to stop autonomous operation if it deviates from its assigned mission and instead for the vessel to be remotely controlled via ROC 100.

[00073] System 402 comprises a number of fleet functional components which are configured to support more than one vessel at a time. Such fleet functional components may include, for example, a function for administration of logbooks and reports for each vessel in the fleet, fleet management functionality, which provides management functionality for more than one vessel at a time, autonomous operation at a fleet level, for example, some missions may require coordinating more than one vessel at the same time, the AV mission planning functionality, for example, using an AV mission planner or fleet mission planner such as that described in more detail later, the remote operation of one or more AVs in the fleet of vessels, and general monitoring of one or more autonomously operating vessels 102 in the fleet.

[00074] Whilst the fleet monitoring and control system 402 is shown in Figure 4 as being located in the ROC 100 it will be appreciated that the same control and monitoring functionality may be provided by a distributed or cloud-based system. Also, although in Figure 4, ROC 100 is land-based but it may also be located on another vessel in some embodiments of the disclosed technology.

[00075] As shown in Figure 4, the vessel communications system 404 also comprises a vessel to vessel communications system 406b which may provide an own-ship signalling functionality as well as inter-vessel communication. Examples of own-ship signalling functionality include: light signals and horn signals.

[00076] The navigation system 412 shown in Figure 4 provides voyage control functionality which may include route monitoring, re-routing, and route reporting functions in some embodiments. In some embodiments the navigation system 412 comprises grounding avoidance functionality, which may be map based in some embodiments, as well as collision or obstacle avoidance functionality and route verification functionality. It is configured to communicate with the mission management system 414.

[00077] Mission management system 414 provides engine decision information, marine operations or schedule mission information, payload handling, logbook / records functionality, and also decisions on available minimum risk and may be configured to store data as well.

[00078] The vessel navigation system 412 is configured to communicate with the vessel manoeuvring system 410 which provides functionality such as berthing and unberthing manoeuvres, mooring manoeuvres, auto-crossing manoeuvres, and any other vessel manoeuvres such as all-speed control. The vessel manoeuvring system 410 is configured to communicate with the vessel equipment operation system 408, for example, to communicate control signals for one or more items of equipment 416. Examples of equipment operation functionality which may be performed include damage handling (for example, if a propeller is damaged), propulsion / steering functionality, ballast / stability functionality, deck machinery control, energy management, for example fuel cell management functionality may be provided for hydrogen cells and / or battery systems, vessel machinery control (auxiliary system(s), pumps, etc.), and also cargo handling functionality. Examples of equipment 416 include engines, pumps, etc.

[00079] 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 configure to detect engine speeds and other characteristics of the vessel propulsion system, loads on loading equipment and weight distribution, electrical and fuel energy consumption sensors, and the like.

[00080] Figure 5A illustrates schematically an example of autonomous vessel management system comprising a fleet monitor and control system 402 hosted by a ROC 100 and an on-board vessel control system 422 hosted on the AV 102.

[00081] As shown in Figure 5A, the fleet monitor and control system 402 is accessed and operated by an operator at the ROC 100 who may use it to access a mission planning and monitoring system 500 hosted also at ROC 100 to plan AV missions and assign them to suitable vessels for autonomous and / or remote execution. In addition, in the embodiment of the disclosed technology shown schematically in Figure 5A, the fleet monitor and control system 402 also receives a 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 an operator situational awareness of other vessel traffic in the vicinity of one or more AVs 102 when they are autonomously executing their AV missions.

[00082] The mission planning and monitoring system 500 also allows an operator to configure a vessel emergency plan when planning an AV mission either at the same time as planning the mission or at a later time using a vessel emergency fall-back planner 500a. The mission planning and monitoring system 500 also enables mission monitoring by an operator who can access different presented views 508, 510, 512 of a mission as it is executed by an AV 102 from initial mobilization, through its voyage execution, and final demobilization. As shown schematically in Figure 5A, a monitoring display 506 at ROC 100 receives a mission data feed from an AV’s on-board mission management system 414 via the off-board mission planning and monitoring system 500. The information provided by the on-board mission management system 414 of a vessel to which an AV mission plan has been assigned allows the presentation of how the vessel is progressing through its assigned activities according to the mission plan. The mobilization execution monitoring view 508, the voyage execution monitoring view 510 and the demobilization execution monitoring view 512 are accessible in that order for a particular AV 102 as it progresses through its assigned AV mission. These views are generated based on mission monitoring data feed(s) sent from the on-board mission management system 414 located on the AV 102 and so are sequentially generated as the mission progresses, although historical views may be stored in some embodiments so they could be retrieved, and if there is sufficient screen real-estate compared to a current view.

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

[00084] The mission planning and monitoring system 500 of the fleet monitor and control system 402 can be used to generate two types of missions. Firstly, vessel agnostic type missions which do not necessarily take into account a particular vessel’s autonomous capabilities but simply specify what activities an AV must perform to complete the AV mission. Secondly, vessel specific missions may be generated which take into account a specific AV’s capabilities to autonomously execute an AV mission.

[00085] In the case where a vessel agnostic mission plan is generated, this may be stored in a suitable data store 502 for subsequent conversion to a vessel specific mission plan. Figure 5B illustrates in more detail how a vessel agnostic mission plan generated at “A” may be converted into a vessel specific AV mission plan at “B”. Figure 5B is described in more detail later below.

[00086] The disclosed technology enables a ROC operator, in other words a user of the fleet monitoring and management system 402 to access the vessel mission planning and monitoring system 500 at the ROC 100 and do one or more or all of: plan an AV mission, assign it to a suitable vessel, and monitor a vessel’s progress as it autonomously executes its assigned mission. Moreover, the ROC operator can monitor the progress of a plurality of vessels which are concurrently executing mission plans and also, in some embodiments, whilst also taking into account vehicle traffic based on information received via the VTS.

[00087] The progress of each vessel (one or more if a fleet is being monitored) can be presented by sequential views 508, 510, 512 of each mission’s progress based on a data feed signal received over a wireless communications link 514 from the on-board mission management system 414 via the on-board vessel control system 422 using the vessel communications system 404 and communications data interface(s) 406a, 406b of the AV 102 to which a mission being monitored was assigned.

[00088] The on-board mission management system 414 of the AV’s control system 422 also includes on-board emergency fall-back system 520 which is configured to provide autonomous emergency vessel handling in the case the AV 102 unexpectedly cannot complete its assigned mission. The emergency can accordingly be handled safely by the AV 102 executing a predetermined emergency plan even if there is no communications link with the off-board planning and monitoring system 500.

[00089] The off-board AV mission planning and monitoring system 500 can also plan vessel agnostic and / or vessel specific missions for groups of vessels at a time as well as a single AV mission, in other words a stand-alone mission, for a vessel to execute. In some embodiments, the missions plans generated by an operator at ROC 100 may be for a fleet, in other words for a group of vessels, where the missions execute concurrently. In some embodiments, the vessels in the fleet may independently execute their assigned independent vessel plans to perform a group AV mission. In some embodiments, however, AVs in the fleet are assigned dependent vessel plans which co-ordinate their individual actions so that a group AV mission is performed.

[00090] Figure 5A also shows a data store 502. This may be provided by a suitable data management system in the form of multiple databases, some of which may store vessel specific information in the form of a set of vessel capabilities and / or vessel characteristics in association with a vessel identifier. Examples of vessel capabilities are autonomous capabilities such as the ability to autonomously execute a particular primitive command, such as “automatically raise anchor” (other examples are described later below). Examples of vessel characteristics provided as parameter-value pairs include a parameter such as “maximum speed” and a value such as “20 knots”, a parameter for “vessel cargo capacity” and a value “100 tonnes” etc.

[00091] The vessel characteristics and capabilities are made available to the mission planner when planning an AV mission so that the AV mission can be tailored if required to a particular vessel’s capabilities and / or to allow selection of a suitable vessel if available for the mission which has the required capabilities and characteristics to complete a mission being planned.

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

[00093] Other examples of vessel characteristics which are used in mission configuration planning include vessel capacity based on the vessel configuration, and also vessel manoeuvring capabilities, for example, a vessel may or may not have an automated mooring and / or unmooring system.

[00094] A vessel agnostic AV mission may be configured using the mission planning and monitoring system 500 differently for different types of vessels, even though the overall mission is the same. By taking into account any different vessel capability characteristics and capability configurations for different vessels, each mission plan sent to an AV 102 can be tailored so that it is feasible for that particular vessel to execute. In other words, based on the capabilities of the AV 102 to perform the activities defined by the mission plan, the mission plan can be adapted to suit different types of vessels with different capabilities.

[00095] In some, but not all, mission plan configurations, a complete mission time-line is also planned and provided to the vessel which also indicates to the vessel when to start performing the mission, although in some embodiments the start of the mission time-line may be triggered by an event instead of being set to a specific time of day. Each mission is planned accordingly as a plurality of different tasks which are aligned with a time-line for when a vessel must perform each task relative to the mission start or based on actual times where the tasks are structured and / or selected according to the capabilities of the vessel which is to perform the mission.

[00096] A vessel mission plan comprises activities associated with three mission phases or stages: a mobilization phase, a voyage phase, and a demobilization phase which can be considered as a set of tasks which are collectively assigned to one or more or all of the mission phases and their time-line(s) for execution accordingly form an AV mission.

[00097] After an AV mission has been planned, the mission planning and monitoring system 500 causes the completely planned mission configuration to be uploaded to the AV 102 which has been selected to execute the mission. The AV 102 then confirms the given mission is suitable for its specific vessel type and capabilities by sending a suitable acknowledgement, for example an ACK (short for acknowledgement) message.

[00098] In some embodiments as mentioned above a mission configuration includes a time-line with a start time for a vessel to automatically start the mission when that start time is reached or a time-line set out relative to a start event which starts when that start event is detected. Alternatively, a user located at the ROC 100 can remotely initiate the start of a newly uploaded mission in some embodiments. This could override a predetermined start time or event, for example, if a weather situation is deteriorating but will not affect a mission once underway, a user at the ROC 100 may bring forward a mission start time, or override an event setting, whereas if a bad situation exists but the weather is improving, the ROC may wish to bring a mission forwards.

[00099] During execution of its assigned vessel mission, the AV 102 may send status updates indicating the mission progress, in other words, the progress of the tasks monitored by its on-board mission management system 414 to be provide as the vessel performs each part of the mobilization, voyage, and demobilization phases back via the vessel communications system 404 using the data communication interfaces 406a, 406b. These updates enable a user at the ROC 100 to be able to monitor and inspect the total progress of the mission while it is being executed by the AV 102. [000100] Whilst this description refers to a human user at the ROC or a ROC operator being the user of the fleet monitoring and control system 402 being a human operator, one or more artificial intelligence, Al-based systems may be used in addition to or instead of a human operator to remotely monitor and control the vessel and / or vessel fleet in some embodiments. [000101] In addition, whilst each mission may be planned by a human user of the mission planning and monitoring system 500, it is also possible to at least in part automatically configure or to use an Al-based system to plan AV missions in some embodiments providing the mission planning and monitoring system 500 is suitably configured to allow collaboration with such Al-based systems. [000102] A reference to a “user” or “operator” accordingly may be considered to refer to any suitably intelligent entity whether machine or human. [000103] In some embodiments, the mission planning and monitoring system 500 can be used to configure a vessel to perform a mission plan, for example, using method 1100 or 1200 described later below and also may perform method 1600 described later below to provide the vessel with a back-up emergency plan in some embodiments. [000104] An example of data flows which may result from use of the mission planning and monitoring system 500 are illustrated schematically in Figures 5B and 5C. Figure 5B shows more information on the mission planning stage than is shown in Figure 5C. [000105] In Figures 5B and 5C, the same autonomous vessel management system subsystems and system components are shown schematically as were shown in the schematic architecture shown in Figure 5A along with an example of a data flow according to some embodiments of the disclosed technology. [000106] As shown in Figure 5B, the autonomous vessel management system comprises at the ROC 100, the mission planning and monitoring system 500 and the fallback planner 500a, which are illustrated as one component block for clarity, and one or more data store(s) 502 for storing AV missions and / or vessel characteristics including vessel capabilities. [000107] Figure 5B focusses on the mission assignment phase where a mission is planned and assigned to an AV 102 for autonomous execution by an operator located at ROC 100. Figure 5C focusses more on the project monitoring and execution phase. In Figures 5B and 5C, the mission planning and monitoring system 500 is also receiving a VTS data feed 630 from a VTS provider which allows vessel traffic to be taken into consideration when planning an AV mission and also when monitoring it. [000108] Figure 5C shows schematically the on-board vessel control system 422, vessel communications 404 and communications data interfaces 406a, 406b, and on-board mission management system 414 including the on-board vessel emergency fall-back system 520. In Figure 5B, however, only the on-board vessel control system 422 is shown. [000109] In the example data flow shown in Figures 5B &5C, an operator uses the mission planning and monitoring system 500 and the vessel emergency fall-back planner 500a of the fleet monitoring and control system 402 at ROC 100 to generate both an AV mission plan and a related vessel emergency plan by first preparing a preliminary AV mission “A” (see 600A in Figure 5B). [000110] This preliminary AV mission “A” may be generated based on stored vessel capability information for a particular type or class of vessel or for a specific vessel, or for a vessel at a more generic level (for example, a container ship). If the AV mission “A” is not vessel specific, it may be referred to herein as a vessel agnostic mission, even if the mission “A” takes into account the set of generic capabilities usually found in a particular class or type of vessel. For example, a dredger type of vessel dredging a channel will have a generic set of capabilities. The generic dredger vessel capabilities (and vessel characteristics) differ from those of an oil tanker type of vessel which will have generic oil tanker type characteristics and capabilities. By way of example, an AV mission which requires an AV 102 to transport Y tonnes of cargo from A to B may be planned initially based on generic container carrier capabilities, but at some point, will need to be assigned to an AV 102 which has the specific cargo volume and tonnage for carrying that cargo. [000111] Once the preliminary AV mission “A” has been planned or during its creation, accordingly, the mission planner at the ROC 100 has to find a suitable AV 102 to autonomously perform the mission being planned. Figure 5B shows that an AV 102 can be identified by first determining what capabilities are required for the mission to be executed 600B and then using those capabilities to identify a vessel 600C, for example, by querying a data store 502 for a vessel whose capabilities have the closed match to the mission required capabilities. [000112] Once a suitable vessel has been identified 600C in this way (or in any other way, for example, an operator may just input a vessel identifier into the mission planning and monitoring system 500), a request 602 is sent to that AV 102 to find and / or confirm its current set of vessel characteristics and capabilities. [000113] The request 602 may be sent in any suitable manner but this will usually be via a suitable wireless communications. This request 602 is received over the AV’s wireless communications system interface(s) 406a,b and is processed by the AV’s control system 422 which then sends a response 604 providing (or confirming) the AV’s current vessel characteristics and capabilities. [000114] The vessel capabilities are then processed 608A by the mission planning and monitoring system 500 and fall-back planner 500a at the ROC 100 to find if they are compatible with the capabilities required for mission “A”. If they are compatible, then mission “A” may be assigned 608 to the AV 102 without any modification, alternatively, the mission may be modified to suit the capabilities of that AV and a new vessel specific mission “B” may be generated 608B and assigned 608 to the vessel. If the mission cannot be adapted or if the operator does not want to adapt the mission, they may look for another vessel 600C, possibly by performing a lookup in a data store 102 of vessel capabilities and characteristics to locate a vessel whose previously stored capabilities are the closest match to those that the mission requires for completion. [000115] Optionally, the received vessel capability information may also be stored 606 in a data base allowing that vessel’s capabilities to be taken into account when planning or assigning other subsequent autonomous AV missions. [000116] The AV mission received vessel capability information can be taken into account when planning the AV mission and a vessel specific mission plan can be generated either directly at point B or by refining the mission plan generated at point A with a particular vessel’s capabilities. [000117] The assigned mission plan 608 comprises a set of tasks and functions which the vessel must perform in each of the mobilization execution phase 508, the voyage execution phase 510, and the demobilization execution phase 512 and may also include an emergency fall-back plan in some embodiments. Once a mission assignment has been uploaded AV mission to the control system 422 of the vessel, the control system 422 confirms the mission plan has been assigned, for example, by sending an ACK message 608a back to the mission planning and monitoring system 500 and fall-back planner 500a. [000118] In some embodiments, each mission plan generated either in its vessel agnostic or vessel specific form is also stored. In the latter case, a vessel identifier may be associated with the vessel plan which was configured for that AV 102 and also the vessel characteristics which indicate the vessel’s capabilities to facilitate later retrieval of the mission and a suitable vessel for executing the plan. [000119] Once received and processed by the vessel control system 422, the mission is not executed until the mission start is triggered 610A, for example, by a particular time, or tidal or current condition, and / or the weather, or by a remote command from ROC 100 to start the mission. At this point the mission is initiated 610B. The mission start will also be communicated / shared with the AV’s on-board mission management and monitoring system 414 which starts the mission monitoring 612. [000120] If the mission plan includes a mission time-line with a start time which will act as the AV mission start trigger event 610A, the AV 102 may automatically start the mission at that point in time, subject to environmental events (e.g., an unexpectedly severe storm may disrupt the mission start time). Alternatively, or in the event of a delayed automatic start, the mission planning and monitoring system 500 generates and sends a start mission command to the AV 102 (not shown in Figure 5B). [000121] Turning now to Figure 5C, this shows schematically how after the start of the AV mission execution by AV 102, the mission monitoring 612 by the on-board mission monitoring and management system 414 starts. The mission is monitored using various equipment and environment sensors which generate a number of data feeds which are collated by the mission management system 414 in some embodiments. These data feeds may be fused 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. [000122] The feedback data comprises the mission status data feed(s) and may also include other monitored mission related data and / or other data (for example, vessel traffic service data). This performance and mission status feedback data allows an operator located at the ROC 100 to see the state of the AV 102 as it autonomously performs its AV mission. The feedback data may be stored 616 in a suitable data store 502 in some embodiments. [000123] In some embodiments, an AV mission may be reconfigured using the feedback information and / or other information obtained from the AV 102 during execution of an assigned AV mission. For example, the degree of autonomy may be adjusted depending on how an AV mission is progressing. Each AV 102 may have different levels or capabilities of autonomous operation and in some embodiments, the AV 102 may be remotely controlled some or all of the time depending on its progress and capability status in a particular mission phase, for example, during mobilization. [000124] The complexity of the AV mission depends in part on the degree of autonomous operation of which an AV 102 is capable. Each AV mission is planned using the mission planning and monitoring system 500 as a specified set of activities for the AV 102 to perform autonomously (and / or remotely) and may also include a schedule or one or more time-lines for the execution of each activity. [000125] The AV mission plan or configuration may be downloaded 514 on request by the mission monitor 502 on-board the vessel in some embodiments instead of being pushed by the mission planning and monitoring system 500 and fall-back planner 500a, for example, as an AV finishes one AV mission it may be configured to request another automatically. Alternatively, or in addition, in some embodiments, AV 102 may request a new mission plan conditionally, for example, after completion of a previous mission, depending on its fuel levels and / or after a certain amount of time has relapsed to allow for refuelling and / or maintenance etc. [000126] The feedback data 614 which is sent after the mission has started by the AV 102 back to the ROC 100 may be sent regularly or irregularly from time to time, for example, at times scheduled in the AV mission. The AV 102 may also be configured to send feedback data after each mission phase and / or each activity or a group of activities associated with a particular mission-defined task is started, and / or on completion and optionally at certain intervals of time during the AV mission. [000127] The AV 102 will also generate data as the mission plan is executed and may communicate some or all of this data via a vessel configurable interface. Data which may be communicated over the vessel configurable interface includes actuation data, for example, data indicating when equipment has been actuated to complete a mission task or otherwise. Other examples of data which may be communicated over the vessel configurable interface include the vessel’s pose data (for example, the vessel’s pitch, yaw, roll), the vessel’s situational awareness data, tactile feedback data, the vessel health data, emergency status data, and also historical data which may be stored on the vessel and / or exported for storage by the ROC. [000128] In some embodiments, an AV 102 may also generate data which may be sent to the mission planning and execution system 500 for sharing with a vessel traffic service, VTS, provider. [000129] Each mission plan is configured using the mission planning and monitoring system 500 with a plurality of primitive commands which are each associated with a small activity. Each primitive command is an atomic element in the mission plan which causes some part or component of the AV 102 to do a small but a well-defined activity. A plurality of activities which are performed in a particular sequence result in the AV performing a particular task defined by its assigned mission plan. [000130] An AV mission comprises at least two types of primitive commands: automation primitive commands and navigational primitive commands. Optionally, an AV mission may also include one or more flow primitive features for handling mission task flow and sequencing. [000131] The automation primitive commands are commands typically performed by the vessel automation system such as, for example, deck machinery, charging equipment, gangway equipment, lights, anchor winches etc. These commands are given in an atomic manner so that each task which comprises a plurality of actions to be performed can be configured using a well-defined command for the task to be performed: for example, “drop port anchor”, “raise starboard anchor”, “connect charger”, “start charging”, “engage gangway”, “disengage gangway”, “moor vessel”, etc. [000132] Some commands may be given without additional parameters, while others may be given with specific parameters. For example, a primitive command “raise port anchor” may be given without additional parameters, while a primitive command to “turn on light” may be qualified by one or more additional parameters, for example, telling which light to be turned on, for example “navigational lights” and in some cases, if the light colour is configurable, the light colour. [000133] The automation capability for a vessel can also be expressed by using automation primitive commands. For example, a vessel that is capable of performing autonomous mooring and unmooring operations, will have at least the autonomous primitive commands “moor” and “unmoor” listed in the vessel capability configuration. [000134] Navigational primitive commands are associated with atomic tasks related to the vessel navigation. Examples of navigational commands include “push to quay”, “unberth”, “station keep”, “transit”, “stop and stay”, etc. Similarly to the automation primitive commands, the navigational primitive commands may also be given with or without additional parameters. For example, “push to quay” may be given without a parameter, while “transit” may be given with a long list of waypoints to be followed in order to perform a transit operation from one location to another. The waypoints in this particular navigational primitive will be given in such a way that grounding is avoided during the voyage. On the other hand, collision avoidance is a needed additional functionality that will temporarily deviate from the original list of waypoints in order to fulfil the collision avoidance functionality. This particular manoeuvre will of course not be able to be included in the original set of waypoints in the “transit” primitive command. [000135] The navigation capability for a vessel may also be expressed by using navigation primitive commands. For example, a vessel that is capable of performing a follow target operation, will have the navigation primitive commands “follow target” listed in the vessel capability configuration. [000136] In order to control the flow of running through the primitive commands associated with each atomic element which makes up a task or each task, an additional set of primitives is needed, named flow primitive features. Example of such primitives include a “wait for time count down” flow primitive, “wait for absolute time”, “wait for operator input” etc. [000137] A task (in other words a job) comprises a sequence of automation primitives which are executed one by one. An automation sequence may comprise a plurality of tasks or jobs. In some embodiments, for example, an automation sequence may be associated with N tasks or jobs which comprise primitive activities to be executed in parallel or in semiparallel. For example, an automation sequence may comprise (Task 1: A10-A3-A9), (Task 2: A1 - A7 - F2) (...) (Task N: XXXX) where each task comprises a number of automation primitive activities or steps. The automation primitive activities which make up each task are executed according to the defined time-line for that task and may be performed independently of the time-lines for activity execution in the other tasks where the tasks are executed in parallel. In other words, each task’s time-line may run in parallel with the time-lines for other tasks in some embodiments. This allows scope for more than one primitive activity to be executed at any given time by a vessel, in other words the automation primitive commands may execute concurrently. [000138] Figure 6 shows an example, where the task time-lines are concurrent, and the tasks are performed in semi-parallel as some automation primitives are performed concurrently and some not. The term “semi-parallel” is used here to refer to a given step in a given task waiting for some other steps in another task to be finished before being executed. When tasks are performed in semi-parallel, the execution of one or more activities allocated to one task are dependent on one or more activities associated with another task. In other words, starting A8 in task 2 as shown in Figure 6 requires the A10 primitive command activity to be finalized in task 1. The execution, completion or start end of a primitive activity in one task may trigger the start or end of a primitive activity in another task. The example automation sequence shown may be used in any of the mobilization or demobilization phases of an AV mission and / or in a fall-back sequence established in the vessel emergency plan. [000139] The example shown in Figure 6 comprises an automation sequence for three different tasks which are running in semi-parallel. In this example, task 1 comprises the primitive activity “charge battery” and includes primitive automation command A10 which is associated with the primitive activity “start charging”, the flow primitive feature F1 (120), and the automation command A11 which is associated with the primitive activity “stop charging”. In this example, F1 specifies the number of minutes the charging should be over. Executing primitive automation command A10 triggers in task 2 automation command A8 “turn on light”, with a parameter identifying which light to turn on (here the port light). Task 2 comprises the job turn on port light. After completion of primitive activity associated with both automation command A11 in task 1 and A8 in task 2, automation command A3 is executed, and the primitive activity “unmoor” of task 3 is performed. [000140] As mentioned above, each task comprises a plurality of primitive activities which are performed autonomously based on automation and / or navigation primitive commands being autonomously executed by AV 102 according to its mission time-line. The timing of these tasks and the execution of the primitive commands is configured using flow primitive features in some embodiments. [000141] The primitive automation commands are associated with identifiers A1, ...A10 which may be configured using the mission planning and monitoring system 500 or be predefined and used by the mission planning and monitoring system 500 so that they cannot be erroneously redefined. Examples of automation primitive commands include but are not limited to: A0 idle A1 run function A3 unmoor A4 Moor A5 drop anchor A6 raise anchor A7 raise flag A8 lower flag A8 turn on light A9 turn off light A10 start charging A11 stop charging [000142] Examples of navigation primitive commands include but are not limited to: NO idle N1 push to quay (parameter: direction / force) N2 unberth (parameters) N3 berth (parameters) N4 transit (optional parameters: waypoints) N5 station keeping (heading / position) N6 slow down with (parameter: acceleration) N7 Follow target (parameter: target id) N8 Keep course and speed N9 keep min speed through water N10 Go inside desired (parameter: area) N11 Keep last thrust [000143] A voyage sequence differs from an automation sequence by only allowing one single sequence to be implemented by the vessel at a time. Executing primitive commands one-by-one for example a voyage sequence may comprise a vessel executing, for example, the following sequence of navigation and automation primitive commands: N1-A3-N2-N4-N3-N1-A4-N0. Figure 10 described later below also shows some examples of voyage sequences. A voyage sequence moves a vessel from a given location to another location by performing one or more automation primitive commands and navigation primitive commands, in one single sequence. An example of such a sequence could be “push to quay”, “unmoor”, “unberth”, “transit”, “berth”, “push to quay”, “moor”. This example will take a vessel from a given port to another port fully autonomously including unmooring and mooring operation (for example, see Figure 2). [000144] Figure 7A and Figure 7B shows schematically how primitive commands can be aggregated and used to detect malfunctions. [000145] Figure 7A shows a more detailed example embodiment where automated equipment has malfunctioned on-board an AV 102 whilst it is performing an AV mission whereas a simpler more generic example is shown schematically in Figure 7B. [000146] As shown in Figures 7A and 7B, two aggregations 700, 702 are shown comprising primitive commands which are used by an AV 102 to complete an assigned mission according to an embodiment of the disclosed technology. [000147] In Figure 7A, automation aggregation 700 comprises an aggregation of automation primitives, including but not limited to: A0 idle A1 run function, test parameter A3 unmoor A4 Moor A5 drop anchor A6 raise anchor A7 raise flag A8 lower flag A8 turn on light A9 turn off light A10 start charging A11 stop charging [000148] As shown in the example embodiment of Figure 7A, the automation primitives A5 and A6 comprise unavailable or invalid status primitive commands 704 which are associated with malfunctions affecting anchor winch equipment 706a and / or anchor winch lubrication pump 706b. In Figure 7A, anchor winch 706a uses functionality provided by anchor lubrication pump 706b. The anchor winch 706a also uses functionality provided by hydraulic power unit, HPLI2, 706c which is associated with a HPU oil level sensor 708a, which is a sensor configured to read the oil level of the HPLI2 unit, and with a HPLI2 oil temp sensor, another sensor configured to read the oil temp of the HPLI2 unit. The HPLI2 unit is also dependent on a power generator 2 706d providing power to the unit. The same power generator 2 706d also provides power to one or more navigation thrusters #1 ... #n 706g... 706n. Each navigation thruster may be also associated with other equipment. For example, thruster #1 706g is driven by a main gear 706f which uses lubrication, and the main gear lubrication equipment 706e provides this lubrication used by the main gear 706f. Two equipment sensors 708c, 708d are shown in the example of Figure 7A associated with main gear lubrication equipment 706e. Sensor 708c provides readings of the main gear lubrication temperature and sensor 708d provides readings of the main gear lubrication pressure. In some embodiments in addition, equipment monitoring functionality may also be provided. If either of the anchor winch equipment 706a or the anchor winch lubrication pump 706b fail, this can result in the commands A5 and A6 becoming unavailable as is shown in Figure 7A. [000149] Also shown in the example embodiment of Figure 7A, is a navigation aggregation 702 of navigation primitives which comprises, but may not be limited to the following examples of navigation primitives: NO idle N1 push to quay (parameter: direction / force) N2 unberth (parameters) N3 berth (parameters) N4 transit (optional parameters: waypoints) N5 station keeping (heading / position) N6 slow down with (parameter: acceleration) N7 Follow target (parameter: target id) N8 Keep course and speed N9 keep min speed through water N10 Go inside desired (parameter: area) N11 Keep last thrust [000150] All of these navigation primitive commands are available in Figure 7A. In Figure 7A the navigation thruster #1 706g is shown connected to the main gear 706f, which in turn is connected to main gear lubrication equipment 706e, which in turn is connected to main gear lubrication temp sensor 708c and to main gear lubrication pressure sensor 708d. In the example shown in Figure 7A, the drop anchor and the raise anchor primitive commands A5 and A6 are shown as unavailable primitive commands 704 as the anchor winch equipment is not working (and / or the anchor winch lubrication pump 706b is not working). By using the sensor readings from sensors 708a, 708b, the system controller can determine what has caused the loss of functionality and automatically take further action to seek to resolve why the sensor readings are indicating the sensor has no functionality. [000151] Turning now to Figure 7B, automation aggregation 700 comprises an aggregation of automation primitives A#0 to A#N, of which, by way of example, automation primitive command A#N is an unavailable or invalid status primitive command 704. As shown schematically in Figure 7B, the aggregation of automation primitive commands 700 and the aggregation of navigation primitive commands 702 uses the AV’s equipment monitoring and system function(s) 408 to aggregate into valid or invalid automation and navigation primitive commands. Also shown schematically in Figure 7B, the aggregation of automation primitive commands 700 and the aggregation of navigation primitive commands 702 uses AV’s vessel manoeuvring system and function(s) 410 to aggregate into valid or invalid automation and navigation primitive commands. [000152] In Figure 7B, only two equipment nodes are shown schematically by way of example. Equipment node 706x, which is used in the example shown by the equipment monitoring and system function(s) 408 and equipment node 706y which is used by the vessel manoeuvring system and functions 410. [000153] In this simple example, if the vessel equipment 706x malfunctions, then this affects the vessel’s equipment monitoring and system functions, and results in command A#N for example no longer being available for autonomous execution. Understanding why this may happen may be achieved using the sensor data from equipment sensor(s) 708x and environment sensor(s) 71 Ox. Providing the automation control system can read the information from these sensors directly or indirectly, it is possible for the cause of the malfunction of equipment 706x to be at least detected remotely, and it may be that the autonomous system can manage to achieve certain functionality in the interim using a different primitive command. It is also possible for the malfunction to be fixed (for example, if the temperature of something is too high, it may automatically resolve, and that equipment become operational again once it has cooled down). [000154] Until the malfunctioning equipment is fixed, however, if the equipment monitoring and system functions system 408 attempts to perform a monitoring function F#1 or provide a system function F#2 which uses the invalid primitive commands A#N 704 on vessel equipment 706x, the function (F#1 or F#2) will not execute or not execute successfully. [000155] By determining which primitive commands, for example, A#N, is / are no longer available, it is possible for the monitoring system 408 to be able to determine if a malfunction has occurred that will not affect a vessel’s ability to complete its assigned mission or if a fallback triggering event has occurred which requires the vessel to abort its assigned mission. [000156] As shown in Figure 7B, equipment sensor(s) 708x and / or environment sensor(s) 71 Ox provide sensor readings which may indicate that it is equipment 706x that is affected. By way of example, an equipment sensor 708x may sense the temperature of a pump, but an environment sensor 71 Ox may sense an ambient environment temperature is very hot, e.g., if an engine room is on fire etc. [000157] In Figure 7B, navigation aggregation 702 comprises an aggregation of navigation primitive commands N#0 to N#N, which are all available and have a valid status. As all of the relevant mission navigation primitive commands are available, those used for example by navigation equipment 706y are all available for the AV 102 to autonomously execute the functionality which the mission plan configures the vessel manoeuvring system 410 to execute. [000158] On the AV 102, each automated item of equipment 706 used by the AV 102 to complete a mission assigned to the vessel to perform draws on one or more automation primitive commands from aggregation 700 and one or more navigation items of equipment may also use one or more navigation primitive commands from aggregation 702. [000159] In some embodiments, each aggregation 700, 702 is associated with a validity status for a mission which an AV 102 is to perform. As shown in Figure 7A, equipment 706a comprises an anchor winch which is controlled using the automation primitive commands A5 and A6. The off-board monitoring system 402 at ROC 100 and the on-board mission management and monitoring system 422 (see also Figure 4), may comprise for example, a Kongsberg K-Chief monitoring and automation system or similar type of system. [000160] Off-board monitoring system 500 for example, may monitor how a vessel configured to perform a mission performs one or more functions which the AV 102 was assigned by the mission plan. For example, functions such as “test anchor winch run” may be monitored to check if it was successfully performed, another example is a function “anchor winch in auto mode” which may be monitored to check the vessel can autonomously operate its anchor winch. To perform these functions, the anchor winch 706a may need to use an anchor winch lubrication pump 706b. A power source 706c for example, that shown in Figure 7A as hydraulic power unit, HPU, 2 may also need to be used. As shown in the example of Figure 7A, the HPU 2, 706c, uses power generator 2, 706d, and may also generate sensor data 708 such as for example, the HPU oil level sensor readings 708a and HPU oil temperature sensor readings 708b as shown in Figure 7A. [000161] In Figure 7A, navigation equipment 706g and 706n is also shown drawing power from power generator 2 706d and using 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. The sensor readings associated with individual items of equipment or system components of a vessel equipment system may be provided as separate data feeds but may also be provided in the form of fused data feed in some embodiments to the equipment monitoring system (not shown in Figure 7A). [000162] The navigation thrusters 706g and 706n are shown associated with the N5 navigation primitive command in Figure 7A and are configured by the vessel manoeuvring platform 410 (see Figure 4) so the AV 102 perform various navigation functions for its assigned mission. [000163] As mentioned above, the validity status of the primitive commands in each aggregation affects the capability of an AV 102 to perform an assigned mission. The validity status of the primitive commands and / or each aggregation 700, 702 may be included in or represented by the capability information provided by the AV 102 when it provides its capability status when acknowledging its capability to complete an assigned mission or it may comprise more detailed capability information. In some embodiments, the AV 102 provides capability information to the mission planning and monitoring system 500 in the form of the communication 514 shown in Figure 5A which may be a simple acknowledgement or more detailed information. This capability information comprises in some embodiments specific vessel capability configuration information, such as in the form of a list or spreadsheet file type, indicating the vessel’s ability to execute each of the automation and navigation primitive commands which collectively form the mission. [000164] In addition, in some embodiments, the vessel’s capability configuration information may include information (for example, an additional listing) of capabilities which are available at all times, in other words, capabilities which are mission independent. This “at all times” set of capability primitive commands that are valid to be executed at all times is a subset of the vessel’s capabilities and may also be listed in a primitive command aggregated status list. For example, even though a given AV 102 may have the capability of “raise port anchor”, this particular automation primitive command may not be able to be executed at a time, perhaps because it would not be appropriate, for example, maybe the port anchor is already raised for example. However, transient lack of a capability being available may also indicate a malfunction. For example, if the capability “raise port anchor” is not available, it may be because a lubrication pump for the port anchor winch is malfunctioning at that time. [000165] Some embodiments of the disclosed technology which provide a method for configuring the functionality and operations of an AV using primitive comments which also support malfunction detection. [000166] In some embodiments, the aggregations 700, 702 of primitive commands provide for each included primitive command a primitive command validity status. This aggregation mechanism enables malfunction detection based on which mission dependent primitive commands are available or not. [000167] Some embodiments of the disclosed technology all fault behaviour to be handled when configuring a mission for an AV. In this context, where a mission comprises a vessel autonomously operating to perform a well-defined mission task, fault handling is distinguished from collision avoidance manoeuvring. A collision avoidance manoeuvre is not considered a fault handling procedure as the collision avoidance manoeuvre comprises a mechanism needed in order to perform a normal voyage operation from a given point to another. [000168] Fault handling addresses more severe unseen situations that may occur during a mission execution. Examples of this may be the case that the AV 102 during a transit voyage operation is, for some reason, losing main propulsion or situational awareness capability. In case of this situation, the AV 102 is not able to proceed with the original or “normal” configured mission it was assigned to perform. In this case, fault handling is used to manage how the mission is aborted so this proceeds in a safe manner to reach a safe state, also referred to herein as a “fall-back state”. Such fall-back states are also defined in the mission configuration according to the disclosed technology. [000169] Figure 8 of the accompanying drawings shows schematically some of the code elements which make up mission configuration computer code 800 which is generated using a mission planning system such as the mission planning and monitoring system 500 shown in Figure 5A. As shown in Figure 8, the mission configuration comprises mission configurations for each of the three mission phases (mobilize 508, voyage 510 and demobilize 512) as well as for a fall-back state configuration 808. As shown, the mobilize phase configuration code includes an automation sequence 802a of primitive commands, the voyage phase configuration code includes a voyage sequence 804a of primitive commands, and the demobilize phase configuration code comprises another automation sequence 802b of primitive commands. The fall-back state configuration comprising a fallback automation sequence 802c and a fall-back voyage sequence 804b of primitive commands. [000170] Other elements may also be included in the mission configuration code, for example planned vessel modes 806. [000171] In some embodiments, in addition to the fall-back state configuration 808 in the mission configuration built up by the various automation and voyage sequences 802a,b,c, 804a, 804b, there are typically also present a large set of low-level fall-back state mechanisms as well. A low-level fall-back mechanism comprises a sequence of primitive commands which is executed regardless of the fall-back state configuration in the mission configuration. An example of a low-level fall-back state is: “If detecting fire in machine room, stop engine and start fire fight.” [000172] An example of a configurable high level fall-back state, on the other hand, is: “If main propulsion is not working while running transit operation, use rest of thruster capacity to stop and station keep, drop anchor and inform ROC of current situation” [000173] In some embodiments, a high-level fall-back state configuration 808 and its execution is defined by at least a fall-back trigger and a fall-back action. [000174] For an AV 102, a set of fall-back triggers is defined based on situations that can bring the AV out of operation. Such fall-back trigger events include but are not limited to losing of one or more of vessel propulsion, vessel position system, and vessel situational awareness. The detection of a fall-back trigger event is handled by one or more fall-back trigger systems. The fall-back trigger systems monitor certain state variables or conditions to evaluate if a fall-back event has been detected and / or what fall-back actions shall be taken responsive to detecting a fall-back event. [000175] In some embodiments, during a mission, many fall-back trigger detection processes run in parallel according to the fall-back state configuration 808 in the mission configuration 800, see for example, Figure 8. [000176] It will be apparent to anyone skilled in the art of the disclosed technology that a large number of faults may occur on an AV 102 where there is need for taking a dedicated fall-back state action in order to end up in a suitable and feasible fall-back state for which ever particular fault has been detected. One may end up with an extremely complex fall-back state configuration that is covering all such fault situations that may occur. [000177] As described earlier, each mission comprises a number of primitive commands which are categorised as either valid or not valid by being included in or by being excluded from a list of valid primitive commands for the particular AV 102 assigned to perform the mission. This list is maintained by a mechanism which aggregates faulty nodes into resulting primitive commands being valid or not, see Figures 7A and 7B. [000178] The list of valid primitive commands accordingly is used by the fall-back mechanism for a mission to determine if a vessel is working as it should be or not. The onboard emergency fall-back system 520 (see Figure 5A) is provided with list of valid primitives and can use this to detect when a fault occurs in the AV 102 and also which fault has occurred, and which the fault in the AV 102. [000179] When configuring a mission plan, a user (or mission planner) of the mission planning and monitoring system 500 is able to select which primitive commands are assigned to or associated with a fault situation or in other words, which commands are associated in a fall-back state action. For example, assume an AV 102 is running on a voyage sequence N1-A3-N2-N4-N1-A4-N0. The navigational primitive command N7 “follow target” is associated with a fault condition using vessel emergency fall-back planner 500a. If fault situation is detected, for example, perhaps due to some fall-back state action determined by the on-board emergency fall-back system 520, which results in this particular navigation primitive command being performed, it will not be performed as part of the voyage primitive command sequence. Accordingly, when the on-board emergency fall-back system 520 detects the AV 102 is now performing the “follow target” N7 primitive command it can determine a fault has occurred. [000180] On the other hand, assume the main propulsion is ending up in a fault situation, being reflected in the navigational primitives “transit” and “autopilot”. Hence, since the “transit” navigational primitive is part of the voyage sequence given above, and if it is assumed for this example that AV 102 is not started or currently running in the “transit” navigational primitive command, the on-board emergency fall-back system 520 will detect the execution of the navigational primitive “transit” as a fall-back trigger event and responsive to detecting the vessel is performing the navigational primitive command “transit” the on-board emergency fall-back system 520 performs suitable fall-back action. [000181] The fall-back triggers and fall-back actions are typically given in pairs in the fall-back state configuration which is configured by the mission configuration user or mission planner. However, note that in case of the same fault situation as described above, assume on the other hand the vessel is finished with the faulty primitive in the voyage sequence, there is no need to take any fall-back action. The vessel can just proceed with the rest of the primitives in the sequence that still are not in a fault state. [000182] The second part of the fall-back state configuration in the mission configuration code 800 comprises a fall-back state action. The fall-back state action shown in Figure 8 comprises both an automation sequence 802c and a navigation / voyage sequence 804b. Each of the configured fall-back state configuration elements comprises an action trigger element and an associated resulting action element. Each action element constitutes of several sets of voyage sequences and automation sequences which collectively provide a risk action table for the fall-backs of a mission. For example, see Figure 9 which shows schematically an example of a risk action table which comprises a prioritized list of risk actions which may be performed in the indicated prioritized order responsive to a malfunction occurring on-board the AV 102, for example, if the vessel’s transponder system(s) malfunction. The prioritized order seeks to result in the best possible fall-back state being achieved in case of a fall-back trigger situation. [000183] For the risk action table shown schematically in Figure 9 of the accompanying drawings, the best solution with priority level 1 comprises the voyage sequence of primitive commands “N4, N6, N5, A5” which correspond to the primitive commands “Go to safe area”, “slow down”, “station keep” and “drop anchor”. If, however if this solution is not possible, the next best solution would be to perform the voyage sequence with priority level 2 comprising N6-N5-A5 which corresponds to the primitive commands to “Slow down”, “station keep” and “drop anchor”, etc. Lower priority solutions comprise the automation sequence A5 or “drop anchor”. Figure 9 also shows in the event that none of the solutions with priorities 1 to 3 are available, the vessel does not perform any voyage or automation sequence which results in the vessel entering a “drift” state. [000184] Some embodiments of the on-board emergency fall-back system 520 determine which action to take in a prioritized manner by comparing the different primitive commands in the different prioritized rows with the list of mission independent or “at all times available” primitive commands described above. [000185] Some embodiments of configured fall-back states comprise n-tuples where an n-tuple sequence is a sequence or ordered list of n elements. [000186] Figure 10 shows an example of an AV mission where an AV 102 has departed from waypoint WP1 and is in transit along an assigned route (N4) via waypoints WP2, WP3, and WP4 at which point the vessel experiences a loss of main propulsion which is a fault trigger event. At this point, the first priority is for the vessel to attempt to perform the solution with priority level 1 from Figure 9. If the vessel cannot do this, then it attempts to perform the solution with priority level 2 from Figure 9. If that cannot be performed then it will attempt to drop anchor, the automation primitive command action which forms action priority 3 shown in Figure 9. All of these result in the mission, which originally configured the vessel to continue in transit along the route passing through waypoints WP5, WP6, WP7, WP8 to port B being abandoned. [000187] An example of a configured fall-back state 2-tuple comprises accordingly a fall-back trigger and configured fall-back action sequence. In some embodiments a fall-back trigger event comprises when a primitive command which was being performed as part of the original primitive commands assigned to a particular mission phase stops being performed, in other words a lack of performance of an assigned mission expected primitive command. In some embodiments however, a fall-back trigger may comprise performance of a primitive command not assigned to a particular mission. The configured fall-back action sequence comprises the priority ordered sequences or primitive commands the AV 102 should attempt in order in the event a triggering event is detected. [000188] For example, referring back to Figure 10, if it can be assumed that the vessel is currently running on a transit part of a voyage, and the vessel suddenly loses main propulsion. This is detected as a trigger event by the on-board emergency fall-back system 520 since the current operating navigational primitive command “transit” is not valid anymore. The AV 102 then determines which action is to be taken responsive to this particular trigger. In the configured tuple for this trigger, an example of a risk action table may be that shown schematically in Figure 9. [000189] This particular risk action table has several action sequences provided with in a prioritized order as described above which were also shown schematically in Figure 10. The first and the one that is assumed to be the best action to take is the priority 1: “Go to safe area, slow down, station keep and drop anchor”. However, since priority 1 action contains a primitive command “N4” that is currently not available as the triggering fault in this case was a “loss of propulsion”, the vessel will determine and check if the next highest priority fall-back action sequence is available: “Slow down, station keep and drop anchor”. Since this one is not containing any unavailable primitive command based on the validity status of the primitive commands listed, execution of this sequence of commands with priority level 2 is the one that the vessel attempts and in this case should be able to complete. [000190] The on-board emergency fall-back system 520 would accordingly send the voyage sequence primitives N6-N5 followed by the automation action A5 of priority 2 to the rest of the vessel control system so that this was followed by the AV 102. [000191] Figure 11 of the accompanying drawings shows an example embodiment of a method 1100 for generating a vessel configuration for a vessel to autonomously perform a mission plan. In some embodiments, method 1100 is performed by the mission planning and monitoring system 500. In some embodiments, method 1100 comprises generating a mission plan 1102, the mission plan comprising at least a mobilization phase, a voyage phase, and a demobilization phase, assigning 1104 to at least one phase of the mission one or more activities for the vessel to perform according to a mission time-line. Not all phases may be assigned activities for autonomous execution according to a vessel plan. For example, in some embodiments, the mobilization phase may not be assigned any activities in an AV mission. The method also comprises associating each activity of the one or more activities with one or more primitive commands 1106, determining a candidate vessel for autonomously performing the mission 1108 and obtaining capability information for the candidate vessel to perform the mission plan 1110. [000192] The mobilization phase may not be assigned activities in particular where the AV 102 is not capable of self-mobilizing sufficiently. [000193] As shown in Figure 11, method 1100 further comprises, based on the capability information obtained for the vessel, generating 1114a vessel configuration for the vessel to adopt to autonomously perform the planned AV mission 1114. The AV vessel configuration associates one or more automation and / or navigation primitive commands with each activity the AV 102 is to autonomously perform according to the mission time-line. [000194] As shown in Figure 11, the method 1100 further comprises, if it is determined, responsive to obtaining the vessel capability, that the vessel can be configured to perform the mission plan 1112, transmitting 1116 the mission plan and vessel configuration to the vessel. If however, the AV 102 is determined to have a different capability from a capability required to perform the mission plan, the method further comprises determining if the mission plan can be adapted 1118 to use that different capability of the AV 102. If the mission plan can be adapted, the method comprises updating the mission plan 1120 and generating in 1114a vessel configuration for the vessel to adopt based on the updated mission plan. [000195] The method 1100 accordingly allows a mission plan to be adapted to suit different vessel capabilities by changing at least one primitive command associated with one or more activities of the mission plan and / or an activity associated with one or more phases of the mission plan. For example, the ability of a vessel to perform a mission will depend on the vessel configuration and available vessel commands. One vessel may have an automated mooring and unmooring system, whilst another vessel in the same fleet may not. The mission plan can be adapted to suit each vessel by adapting the primitive commands for the mobilization and demobilization phases forming the mission plan assigned to each vessel. [000196] In some embodiments, the mission plan generated by performing the method 1100 configures the vessel to autonomously perform one or more activities in the mobilization phase, the activities mobilizing the vessel prior to a voyage, one or more activities in a demobilization phase, the activities demobilizing the vessel after a voyage, and one or more activities in the voyage phase, the activities to be performed whilst the vessel undergoes a voyage. [000197] In some embodiments, the mission time-plan configures the AV 102 to automatically initiate the AV mission based a predetermined mission initiation time or event. For example, a time of day or responsive to a wind speed and / or wave height dropping to below a threshold speed or level which triggers the start of the mission time-plan. One or more activities and / or primitive commands can be triggered by events defined by the mission time-plan events in some embodiments. For example, in some embodiments, the mission configuration time-plan configures the AV 102 to automatically initiate the AV mission based a non-predetermined mission initiation time, wherein the mission is initiated by the vessel responsive to one or more mission start conditions being met. [000198] In some embodiments, the method 1100 generates a mission plan which defines at least one task, in other words a job. Each task or job comprises a plurality of activities for the vessel to autonomously perform at one or more locations during one or more of the mobilization phase, the demobilization phase and the voyage phase. [000199] The method 1100 may also generate a mission plan which defines for each task a set of primitive commands for execution in a predefined sequence controlled using a set of flow control primitives. For example, each predefined sequence of primitive commands may comprise one or more automation primitive commands and / or navigation primitive commands which are executed in a flow defined by the set of flow control primitives. [000200] In some embodiments, the flow control primitives for each task configure the vessel to perform a plurality of actions for each task concurrently and / or to perform a plurality of tasks concurrently. [000201] To manage malfunctions which impact the execution of a mission plan, in some embodiments the method 1100 further configures at least one fall-back trigger event associated with one or more fall-back primitive command sequences which configure the vessel to adopt a fall-back state determining according to the mission plan. Each fall-back primitive command sequence is assigned a selection priority so that if a primitive command in the highest priority fall-back command sequence is not available, a fall-back sequence with the next highest priority can be selected if that sequence comprises primitive commands which do not have an invalid command status. In other words, a fall-back primitive command sequence is selected based on its priority ranking and the availability of the primitive commands in the selected sequence. [000202] Examples of fall-back trigger events include events associated with detecting or determining a vessel is no longer performing a primitive command according to its assigned mission time-line. In some embodiments, a fall-back trigger event comprises detecting an environmental event or sensor reading for the vessel whilst it is performing a primitive command according to the mission time-line for that mission plan. [000203] Where the mission planning and monitoring system 500 performs method 1100 to plan missions for a plurality of different vessels, a mission plan may be generated which co-ordinates at least one action in a mission time-line for one vessel which is to be autonomously performed by that vessel at a time associated with or coordinated with the performance of at least one action performed by at least one other vessel. At least one action performed by the at least one other vessel comprises at least one action also performed autonomously in accordance with a mission plan configured by the mission planning and monitoring system 500 for that vessel. In this way the mission planning and monitoring system 500 may also be configured to perform a method for configuring a fleet of vessels to co-operate autonomously when performing a fleet mission plan such as method 1200 shown schematically in Figure 12. Such a method 1200 comprises at least generating a fleet mission plan 1202 comprising fleet tasks and / or activities which are to be autonomously performed by a plurality of fleet vessels 102. Method 1200 assigns one or more of the activities and tasks for the fleet to perform to a plurality of vessels in the fleet to execute in 1204. The one or more activities and / or tasks assigned from the fleet mission plan form an AV mission plan which method associates with each participating vessel in the fleet of vessels. The method 1100 can be used to generate a suitable AV mission plan which takes into account each vessel’s capabilities to perform the primitive commands assigned to activities and / or tasks at the fleet level and to generate vessel configuration for each vessel to perform its part of the fleet AV mission plan. These AV mission plans can then be updated and / or assigned to each AV 102 in the fleet based on that vessel’s capabilities by performing suitable steps 1106 to 1116 of the method 1100 according to any one of its embodiments disclosed herein, as shown at 1206. Step 1208 comprises transmitting the vessel mission plan and vessel configuration for performing the mission plan to each vessel participating in the fleet mission. [000204] Figure 13 shows schematically apparatus 1300 configured to implement an AV mission planner system, which is an example mission planning and monitoring system 500 according to the disclosed embodiments. As shown in Figure 13, the apparatus 1300 comprises memory 1302, computer code / circuitry 1304, and one or more processor(s) or processing circuitry 1306. When the computer code or circuitry 1304 is loaded from memory 1302 and executed by the one or more processor(s) or processing circuitry 1306 of the apparatus 1300 it causes the apparatus 1300 to implement method 1100 and / or method 1200 according to any one of the embodiments of these methods disclosed herein. [000205] The disclosed methods 1100 and 1200 accordingly allow an AV mission planner system 500 of hosted by a ROC 100 for example to configure suitable mission plans which are within the capability of one or more vessels 102 having a suitable on-board vessel control system such as the vessel control system 422 shown in Figure 4 to autonomously, in other words, automatically, perform. Each AV mission plan can be first generated at vessel agnostic level and then adapted based on each vessel’s capabilities to perform primitive commands associated with the activities and tasks assigned using the mission planner system 500 to the AV mission. If a vessel lacks the ability to execute a primitive command specified by the mission plan for performing a particular activity in the AV mission, the mission planner system 500 can be configured to automatically determine alternative primitive commands for executing the mission plan action autonomously. [000206] The ROC 100, or the mission planning and execution system 500, may comprise apparatus 1300 in some embodiments and the computer code or circuitry 1304 may be provided by a computer program product comprising computer coded instructions which when loaded from memory and executed by one or more processor(s) or processing circuitry 1306 of an apparatus, cause the apparatus 1300 to implement one or both of the methods 1100 or 1200 according to one or more of their embodiments described herein. [000207] The method for generating a mission configuration may be performed by a mission planner system such as mission planning and monitoring system 500 shown in Figure 5 to assign a mission to an AV 102. The mission configuration for a mission plan configures the AV 102 to autonomously perform the mission plan. [000208] In some embodiments, a mission plan may be generated by the mission planer initially independently from the vessel configuration used by a vessel to autonomously execute its assigned mission plan. [000209] In some embodiments, an initial mission plan may be initially vessel agnostic, and the method may comprise adapting the vessel agnostic mission plan to be a vessel specific mission plan responsive to receiving vessel capability information. [000210] Some, if not all, of the above method embodiments may be implemented using computer program code which may be provided as software or hardcoded, for example, as a computer program product. [000211] Those skilled in the art will also appreciate that the processing circuitry and the memory or computer readable storage unit described above may refer to a combination of analog and digital circuits, and / or one or more processors configured with software and / or firmware, e.g., stored in a memory, that when executed by the one or more processors such as the processing circuitry perform as described above. One or more of these processors, as well as the 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, whether individually packaged or assembled into a system-on-a-chip (SoC). [000212] The communication channels used by a ROC to communicate with an AV 102 may be point-to-point, or networks, for example, over cellular or satellite networks which support wireless communications. The wireless communications may conform to one or more public or proprietary communications 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, Wireless Fidelity (Wi-Fi) (e.g., IEEE 802.11a, IEEE 802.11b, IEEE 802.11g and / or IEEE 802.11n), voice over Internet Protocol (VoIP), WiMAX, a protocol 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), Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE), and / or Instant Messaging and Presence Service (IMPS)), and / or Short Message Service (SMS)), or any other suitable communication protocol. [000213] The computer code and / or circuitry 1304 may include components of an operating system comprising various software components and / or drivers for controlling and components for managing general system tasks (e.g., memory management, storage device control, power management, etc.) as well as components for facilitating communication between various hardware and software components which would be apparent to anyone of ordinary skill in the art and which for the sake of brevity are not further disclosed herein. [000214] Figure 14 of the drawings shows schematically an example embodiment of a method 1600 for configuring a vessel to be safely managed in an emergency according to the disclosed technology. In Figure 14, the method 1600 comprises generating an AV mission plan for an AV 102 to execute in 1102 and based on the capabilities and mission requirements, generating a vessel emergency plan 1602 for autonomously controlling how a mission plan is aborted in the event of a fall-back trigger event or condition being detected by the AV 102 and then assigning the plan to the AV 102 at 1606. The vessel emergency plan associates a plurality of fall-back trigger events with one or more fall-back primitive commands in 1604. [000215] By implementing method 1600, an AV 102 can be assigned an AV mission plan and also configured to autonomously handle an emergency which occurs during execution of the assigned AV mission plan where the emergency prevents the AV mission plan from being safely completed or not completed. [000216] In some embodiments, the method 1600 comprises generating an AV mission plan 1102 comprising a plurality of activities for a vessel to perform according to a mission time-line 1104, wherein each activity of the plurality of activities is associated a primitive command 1106, generating a vessel emergency plan comprising one or more fall-back trigger conditions for aborting the AV mission plan prior to completion, wherein each of the one or more fall-back trigger conditions is associated with one or more fall-back primitive commands, and assigning the AV mission plan and emergency plan to the vessel, wherein the assigned emergency plan configures the vessel, responsive to the detection of a fallback trigger condition whilst executing the assigned AV mission plan, to execute the one or more fall-back primitive commands associated with the detected fall-back trigger condition according to the emergency plan. [000217] At least one fall-back trigger condition of the one or more fall-back trigger conditions comprises determining an availability status of at least one primitive command required to complete the AV mission plan has changed to unavailable during the mission. So, for example, if a part fails unexpectedly in an engine, and the vessel loses power, any primitive commands which require the engine to be operational will no longer be available. In some examples, a plurality of fall-back primitive commands can be ranked in a priority order for selection, so for example, “head to nearest port” may have a higher priority over “drop anchor and cease engine activity” but if there is no ability to head to the nearest port, the second ranked solution “drop anchor and cease engine activity” would be selected instead. In some embodiments, the emergency plan may also configure the vessel to select at least one of the one or more fall-back primitive commands responsive to detecting a trigger fall-back condition according to the priority order for selection and based on availability status of the fall-back primitive command indicating that fall-back primitive command is available. [000218] Examples of emergencies can include any one or multiple event which prevents an AV 102 from completing its mission, or being determined to be capable of safely completing the mission or having a higher probable risk than is acceptable of the mission not being completed. For example, sensors can malfunction and / or breakdown, as can equipment, and some fall-back trigger events may comprise equipment malfunction or breakdown which prevents an assigned AV mission from being completed. Other examples where an AV may not complete its mission include when there is a sufficient loss or lack of fuel to prevent the assigned AV mission from being completed, for example, if the vessel encounters an object and fuel leaked. Other possible fall-back triggering events include; a loss / lack of electrical power which prevents the assigned AV mission from being completed, a weather forecast or weather event which prevents the assigned AV mission from being completed, or any other type of emergency at sea that causes the status of a primitive command for completing the mission to change its availability status to unavailable and prevents the assigned AV mission from being completed. [000219] The method 1600 disclosed may be implemented using an off-board vessel emergency fall-back planner, the off-board vessel emergency fall-back planner comprising memory, computer code, and one or more processors or processing circuitry. The computer code, when loaded from memory and executed by the one or more processors or processing circuitry, may cause the off-board vessel emergency fall-back planner to perform the method 1600 to configure a vessel configured to autonomously perform an assigned AV mission plan to be safely managed in an emergency which prevents the AV mission plan from being safely completed. [000220] On-board the AV 102, an on-board vessel emergency plan execution system may be provided for an AV 102 configured to autonomously follow an assigned AV mission plan. The AV mission plan comprises a plurality of activities for the vessel to perform according to a mission time-line, wherein each activity of the plurality of activities is associated with a primitive command. The on-board vessel emergency plan execution system comprises memory, computer code, one or more processors or processing circuitry, and an AV control system, wherein the computer code, when loaded from memory and executed by the one or more processors or processing circuitry, causes the AV control system, responsive to the vessel detecting a fall-back trigger condition, to abort execution of the assigned AV mission plan, and, autonomously implement a vessel emergency plan associating one or more fall-back trigger conditions with one or more fall-back primitive commands by executing the one or more fall-back primitive commands associated with the detected fall-back trigger condition. [000221] The vessel emergency plan may prioritise or rank one or more fall-back primitive commands in a priority order for selection. The computer code may be configured when executed on-board to cause the AV control system, so that, responsive to the AV 102 detecting a fall-back trigger condition, the AV 102 is caused to select at least one of the one or more fall-back primitive commands responsive to detecting a trigger fall-back condition according to the priority order for selection and based on availability of the fall-back primitive command. For example, the computer code may be configured when executed to cause the AV control system to monitor an availability status of each of the primitive commands used by the vessel to autonomously execute its assigned AV mission plan, determine, if at least one monitored command changes its availability status to unavailable, if the change of availability status comprises a fall-back trigger condition for the vessel to adopt a fall-back state, and responsive to determining the change of availability status comprises a fall-back trigger condition for a fall-back state to be adopted by the vessel, cause the vessel to be reconfigured for autonomous operation with a selected fall-back state according to the vessel emergency plan. [000222] The on-board vessel emergency planner system may also be configured using the computer code to, responsive to the vessel detecting a fall-back trigger condition, to select a fall-back state based on a risk score for that fall-back state being adopted by the vessel and dependent on the selected fall-back state being associated with one or more fallback primitive commands having a valid status. [000223] Where the disclosed technology is described with reference to drawings in the form of block diagrams and / or flowcharts, it is understood that several entities in the drawings, e.g., blocks of the block diagrams, and also combinations of entities in the drawings, can be implemented by computer program instructions, which instructions can be stored in a computer-readable memory, and also loaded onto a computer or other programmable data processing apparatus. Such computer program instructions can be provided to a 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 / acts specified in the block diagrams and / or flowchart block or blocks. [000224] In some implementations and according to some aspects of the disclosure, the functions or steps noted in the method blocks for methods 1100 and 1200 can occur out of the order noted in the operational illustrations depending on whether they have a causal relationship. [000225] The description of the example embodiments provided herein have been presented for the purposes of illustration. The description is not intended to be exhaustive or to limit example embodiments to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of various alternatives to the provided embodiments. The examples discussed herein were chosen and described in order to explain the principles and the nature of various example embodiments and its practical application to enable one skilled in the art to utilize the example embodiments in various manners and with various modifications as are suited to the particular use contemplated. The features of the embodiments described herein may be combined in all possible combinations of methods, apparatus, modules, systems, and computer program products. It should be appreciated that the example embodiments presented herein may be practiced in any combination with each other. [000226] It should be noted that the word “comprising” does not necessarily exclude the presence of other elements, features, functions, or steps than those listed and the words “a” or “an” preceding an element do not exclude the presence of a plurality of such elements, features, functions, or steps. It should further be noted that any reference signs do not limit the scope of the claims, that the example embodiments may be implemented at least in part by means of both hardware and software, and that several “means”, “units” or “devices” may be represented by the same item of hardware. [000227] The various example embodiments described herein are described in the general context of methods, and may refer to elements, functions, steps or processes, one or more or all of which may be implemented in one aspect by a computer program product, embodied in a computer-readable medium, including computer-executable instructions, such as program code, executed by computers in networked environments. [000228] A computer-readable medium may include removable and non-removable storage devices including, but not limited to, Read Only Memory (ROM), Random Access Memory, RAM), which may be static RAM, SRAM, or dynamic RAM, DRAM. ROM may be programmable ROM, PROM, or EPROM, erasable programmable ROM, or electrically erasable programmable ROM, EEPROM. Suitable storage components for memory may be integrated as chips into a printed circuit board or other substrate connected with one or more processors or processing modules, or provided as removable components, for example, by flash memory (also known as USB sticks), compact discs (CDs), digital versatile discs (DVD), and any other suitable forms of memory. Unless not suitable for the application at hand, memory may also be distributed over a various forms of memory and storage components, and may be provided remotely on a server or servers, such as may be provided by a cloud-based storage solution. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes. [000229] The memory used by any apparatus whatever its form of electronic apparatus described herein accordingly may comprise any suitable device readable and / or writeable medium, examples of which include, but are not limited to: any form of volatile or non-volatile computer readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by processing circuitry. Memory may store any suitable instructions, data or information, including a computer program, software, an application including one or more of logic, rules, code, tables, etc. and / or other instructions capable of being executed by processing circuitry and, utilized by the apparatus in whatever form of electronic apparatus. Memory may be used to store any calculations made by processing circuitry and / or any data received via a user or communications or other type of data interface. In some embodiments, processing circuitry and memory are integrated. Memory may be also dispersed amongst one or more system or apparatus components. For example, memory may comprise a plurality of different memory modules, including modules located on other network nodes in some embodiments. [000230] In the drawings and specification, there have been disclosed exemplary aspects of the disclosure. However, many variations and modifications can be made to these aspects which fall within the scope of the accompanying claims. Thus, the disclosure should be regarded as illustrative rather than restrictive in terms of supporting the claim scope which is not to be limited to the particular examples of the aspects and embodiments described above. The invention which is exemplified herein by the various aspects and embodiments described above has a scope which is defined by the following claims.

Claims

23 06 251. A method for generating a vessel configuration for a vessel to autonomously perform a mission plan, the method comprising:generating a mission plan, the mission plan comprising at least a mobilization phase, a voyage phase, and a demobilization phase;assigning to each phase of the mission one or more activities for the vessel to perform according to a mission time-line;associating each activity of the one or more activities with one or more primitive commands;determining a candidate vessel for autonomously performing the mission;obtaining capability information for the candidate vessel to perform the mission plan; andbased on the capability information, generating a vessel configuration for the vessel to adopt to autonomously perform the mission plan, the vessel configuration associating one or more automation and / or navigation primitive commands with each activity the vessel is to perform according to the mission time-line,wherein method further comprises:responsive to obtaining the vessel capability, determining if the vessel can be configured to perform the mission plan; andif the vessel is determined to have a different capability from a capability required to perform the mission plan, determining if the mission plan can be adapted to use the different capability of the vessel; and,if the mission plan can be adapted, updating the mission plan and generating a vessel configuration for the vessel to adopt based on the updated mission plan.

2. The method of claim 1, wherein the mission plan is adapted by changing at least one:primitive command associated with one or more activities of the mission plan; and / oran activity associated with one or more phases of the mission plan.23 06 253. The method of any one of the previous claims, wherein the mission plan configures the vessel to autonomously perform:one or more activities in the mobilization phase, the activities mobilizing the vessel prior to a voyage;one or more activities in the demobilization phase, the activities demobilizing the vessel after a voyage; andone or more activities in the voyage phase, the activities to be performed whilst the vessel undergoes a voyage.

4. The method of any one of the previous claims, wherein the mission plan configures the AV 102 to automatically initiate the AV mission based a predetermined mission initiation time or event.

5. The method of any one of the previous claims, wherein the mission plan defines at least one task comprising a plurality of activities for the vessel to autonomously perform at one or more locations during one or more of the mobilization phase, the demobilization phase and the voyage phase.

6. The method of claim 5, wherein the mission plan defines for each task a set of primitive commands for execution in a predefined sequence controlled using a set of flow control primitives, wherein each predefined sequence of primitive commands comprises one or more automation primitive commands and / or navigation primitive commands.

7. The method of claim 6, wherein the flow control primitives for each task configure the vessel to perform a plurality of actions for each task concurrently.

8. The method of claim 6 or 7, wherein the flow control primitives for each task configure the vessel to perform a plurality of tasks concurrently.23 06 259. The method of any one of the previous claims, wherein the mission plan further comprises a vessel emergency plan comprising at least one fall-back trigger condition associated with one or more fall-back primitive commands which configure the vessel to adopt a fall-back state determining according to the vessel emergency plan.

10. The method of claim 9, wherein the vessel emergency plan comprises a plurality of fall-back primitive command sequences, wherein each fall-back primitive command sequence is assigned a selection priority, and wherein a fall-back primitive command sequence is selected based on its priority ranking and the availability of the primitive commands in the selected sequence.

11. The method of any one of the previous claims 9 or 10, wherein the fall-back trigger condition comprises detecting the vessel is not performing a primitive command according to its assigned vessel mission time-line.

12. The method of any one of the previous claims, wherein the mission configuration includes at least one co-ordinated action in the mission time-line which is to be autonomously performed by the vessel which is coordinated with the performance of at least one action performed by at least one other vessel.

13. The method of claim 12, wherein the at least one action performed by the at least one other vessel comprises at least one action also performed autonomously in accordance with a mission configuration.

14. A method for configuring a fleet of vessels to co-operate autonomously whenperforming 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 vessel in the fleet of vessels, wherein the AV mission plan and vessel23 06 25configuration for performing the AV mission plan is generated for each vessel in the fleet by performing the method according to any one of claims 1 to 13.

15. An AV mission planner system comprising:memory;computer code;one or more processor(s) or processing circuitry, wherein the one or more processor(s) or processing circuitry are configured to execute the computer program code when loaded from the memory to cause the AV mission planner system to perform a method according to any one of claims 1 to 14.

16. A vessel comprising an autonomous control system, wherein the autonomous control system is configured to cause the vessel to execute one or more primitive commands based on a time-line according to a mission plan received from the AV mission planner system of claim 15.

17. A computer program product comprising computer coded instructions which when loaded from memory and executed by one or more processor(s) or processing circuitry of an apparatus, cause the apparatus to implement the method of any one of claims 1 to 14.

Images