COMMAND AND CONTROL SYSTEM FOR A REMOTELY-OPERATED UNCREWED SURFACE VESSEL TECHNICAL FIELD OF THE INVENTION This invention relates to remotely-controlled uncrewed surface vessels. BACKGROUND The majority of crewed surface vessels have a control interface by which which a human operator can continuously monitor and control the vessel in real time. Fully autonomous unmanned surface vessels exist which employ a dedicated control system capable of safely operating the vessel for prolonged periods with little or no direct human input. These vessels are controlled by a dedicated computer processing unit (CPU) which has full control over the essential functions of the vessel in response to dynamic data input from various system sensors. The CPU generally incorporates sophisticated control software which is designed to provide comprehensive control over numerous sub-systems within the vessel to provide reliable steering, positioning, and collision avoidance functions. These computer control systems are often highly mission-specific. Each system is generally dedicated to performing particular functions such as surveying, fire fighting, re-fueling or rescue operations. Such autonomous vessels can be pre-programmed to perform a required task prior to deployment, e.g. using a hand-held programmer. Remote input following deployment is generally very limited, for example to allow remote activation after deployment, or activate specific work packages. Examples of such autonomous vessels are described in US 6 269 763-B1 and WO 2017062 764-A1. Autonomous unmanned surface vessels are therefore costly to implement, tend to be dedicated to performing specific functions, and are susceptible to loss or damage in the event that an unanticipated situation arises in the course of their operation. SUMMARY OF THE INVENTION The present invention proposes a command and control system which is suitable for installation in any uncrewed surface vessel having sub-systems which include power, propulsion and steering modules. The command and control system comprises three main components: a vehicle module, interfacing middleware, and a remote command component. The vehicle module (C2V) incorporates an embedded programmable logic controller (PLC) running control firmware with an uninterruptable power supply, and a system recovery module to monitor system health and provide a means of recovery from a fault-state. The interfacing middleware passes command and control information from the C2V module to modular sub-systems installed within the vessel. The remote command component (C2A) is located at an operators control station which provides a human-machine interface for a human-operator to monitor and control the modular sub-systems on the vessel, thus providing human-in-the-loop, human-assisted control from a shore-based remote operations centre (ROC), or an operators control station on a conventional crewed vessel, for example. The remote command component is linked to the vehicle module by a wireless communications link configured to pass information in both directions between the remote command component and the vehicle module. The use of a programmable logic controller in combination with interfacing middleware and a system recovery module, results in a system which is rugged, adaptable and more reliable compared with autonomous vessels controlled by a dedicated CPU. BRIEF DESCRIPTION OF THE DRAWINGS The following description and the accompanying drawings referred to therein are included by way of non-limiting example in order to illustrate how the invention may be put into practice. In the drawings: Figure 1 is a side view of a remotely-operated uncrewed surface vessel which is operated by the command and control system; Figure 2 is a bow elevation of the vessel; Figure 3 is a top plan view of the vessel; Figure 4 is a schematic drawing showing the internal layout of the vessel; Figure 5 is a block diagram of the command and control system. DETAILED DESCRIPTION OF THE DRAWINGS The remotely-operated uncrewed vessel (ROUV) described below is adaptable to carry out a variety mission specific tasks such as survey work collecting appropriate data. Rather than being a fully-autonomous vessel with self-governing behaviour the ROUV is a human-in-the-loop vehicle under the control of a human operator located on land or another vehicle such as a ship or aircraft. The command and control equipment used to control the vessel is not specific to any particular ROUV vehicle and may be installed in any suitable new-build vessel, retrofitted to existing ROUV vehicles, or installed upon conversion of a conventionally-crewed vessel for example. Referring to Fig.s 1 to 3, the ROUV 1 has an identical pair of mutually spaced hulls 2 and 3 linked by a deck 4. The hulls 2 and 3 contain equipment such as vessel sub-systems and mission-specific equipment which is accessed through a removable deck panel and access hatch 5. The deck 4 carries one or more fuel tanks 6. Towards the bow of the vessel the deck 4 carries a housing 7 for command and control equipment. Further back towards the stern is mounted a generator 8 which is powered by diesel or other hydrocarbon fuel stored in the fuel tanks 6. The generator is straddled by an upstanding gantry 9 which carries various communication and navigation equipment, e.g. radar, and situational awareness equipment such as navigation lights, search light and horn. Propulsion is provided by two electric or hydrocarbon-fuelled thrusters 10 and 11 located at the rear of the hulls 2 and 3. In the present embodiment a pair of electrical thrust motors are used. Fig. 4, shows the schematic internal layout of the ROUV with the bow on the left, the stern on the right, the port hull 3 at the bottom and the starboard hull 2 at the top. The various components are all interconnected by a suitable cabling infrastructure, including power distribution cabling as shown, and data cabling (not shown). The housing 7 contains an enclosure 21 for the vehicle part of the command and control system, and a rack 22 in which mission-specific client equipment may be installed. Further back, beneath the generator 8, is a self-contained generator start system 23 along with associated control and electrical distribution boxes. One of the hulls, the starboard hull 2 as shown, contains a general charger and inverter unit 24 to control the supply of DC power from the generator 8, or AC power from a socket 25, to on-board storage batteries, which in this case comprise a pair of starboard batteries 26.1 and 26.2 and a pair of port batteries 27.1 and 27.2 located in the respective hulls 2 and 3. The starboard and port thrust motors 10 and 11 are both supplied with power from the storage batteries via a respective control box 30, 31. Each hull 2, 3 also contains a respective electrical steering module 32 and 33. The command and control system (C2) is responsible for overseeing power management, health monitoring, alarm handling and data logging for the vehicle, and comprises three main elements: ^ A vehicle module (C2V) incorporating an embedded controller running control firmware with an uninterruptable power supply (UPS) and a system recovery module (SRM) to monitor system health and provide a means of recovery from a fault-state. ^ Interfacing middleware to pass command and control information from the vehicle module to modular sub-systems installed within the vessel. ^ A remote command component (C2A) at an operators control station which provides a human-machine interface with visual displays and input devices for a human-operator to monitor and control the modular sub-systems on the vessel. The C2A component is linked to the C2V module by a wireless communications link configured to pass information in both directions between the C2A component and the C2V module. In the present embodiment the C2V module and the interfacing middleware are both housed within the enclosure 21. Fig. 5 shows diagrammatically the ROUV vehicle 38 linked to a remote command centre 39 using a vehicle communication system 40, e.g. VHF or UHF radio, which is in two-way data communication with a shore-based communication system 41. The command centre incorporates the C2A component 42 along with a proprietary autopilot command system 43 and mission-specific client applications 44. On board the ROUV 38 the vehicle communication system 40 interacts with the C2V module, an on-board proprietary autopilot package 46, and any required mission-specific client systems 47. The autopilot system is responsible for vehicle propulsion and steering, maintaining speed and heading, line following, line planning, autonomy and handling situational awareness information. The C2V module 45 interfaces with various low-level proprietary automated vessel-specific systems, generally designated 48, via the interfacing middleware 49. Note that the command and control system does not replicate any autopilot or client systems and works alongside whichever of these systems are installed. The three main components of the present command and control system will now be described in greater detail. The C2A component is responsible for requesting configuration changes to the vehicle, displaying alarm messages, quality control and status information, and data logging. The C2A component comprises stand-alone computer hardware, or hardware integrated as part of a remote operations centre (ROC), running an off-board software application which is linked to the C2V module via the communication system 40, 41 in real time. This component is used by a human operator to monitor and control the shipboard systems on the ROUV. This provides the human-machine interface for what may be described as human-in-the-loop, or human-assisted autonomy, from a shore-based ROC, or an operators control station on a conventional crewed vessel, for example. The C2V module is responsible for actioning physical configuration changes to the vehicle, generation of alarm messages, passing on quality control and status information from third party instrumentation, and built-in self test. The C2V module comprises embedded hardware (off-the-shelf) with proprietary firmware. The C2V Module is configured for fault-tolerant, managed failure, with uninterruptable dual-redundant power supplies. The module incorporates a processor running the proprietary control firmware, and a system recovery module (SRM) to monitor system health and provide a means of recovery from a fault-state. More specifically, the C2V module comprises a programmable logic controller (PLC), which is an industrial controller with programmable memory used to store instructions and various functions. A suitable PLC includes: - a processor which interprets inputs, executes a control program stored in memory, and sends output signals; - an uninterruptable power supply unit (UPS), e.g. which converts AC voltage to DC; - a memory unit storing data from inputs and the program to be executed by the processor; - an input and output interface, where the controller receives and sends data from/to external devices, i.e. the vehicle-specific systems 48, via the interfacing middleware 49; - a communications interface to receive and transmit data on communication networks such as the communication system 40, 41. The firmware installed in the PLC may also include a watchdog facility which monitors the execution of instructions by the PLC and initiates an internal firmware reset if the system hangs. A programming device is normally used to develop and later download the control program into the memory of the PLC. The C2V module is provided with an automatic system recovery facility, also referred to herein as a master controller, which initiates a full system reboot, e.g. if the PLC crashes as a result of a non-recoverable failure. In one example the system recovery module (SRM) comprises a timer relay which, in normal operation, receives heartbeat pulses from the PLC, for example one pulse per second, which reset the timer. If the pulses stop because the PLC has crashed then the relay switches after a fixed interval sending a reset command to the PLC. The system recovery module can also report its status back to the C2A component. The interfacing middleware consists of general codified architecture which is capable of interfacing with many different embodiments of the ROUV to control a range of proprietary low-level (vessel specific) systems. The standard codified architecture of such low level systems includes, by way of non-limiting example: a. Power - comprising energy storage, power generation and power distribution. b. Propulsion - electric or conventionally-fuelled rotating machines in outboard / inboard, pumpjet or azimuthing pod drive configurations. c. Steering - comprising independent actuators to steer one or more propulsion drives or rudders. d. Fuel - comprising a series of multiple tanks and a system of motorised-valves and pumps to provide active control of constant heel and trim. e. Cooling - comprising dual redundant cooling systems to provide raw seawater to closed cooling systems for various equipment. f. Active ballast - comprising a system of pumps and motorised valves to fill and strip ballast tanks. g. Bilge - comprising a series of bilge water detection instruments, pumps and separators for overboard discharge. h. Anchor Windlass / Winch - for deployment and recovery of towed sensors. i. Ventilation and fire detection and control. j. Communications - comprising shipboard routers and network equipment connected to the radio, satellite and cellular apparatus for constant connection between the C2A component and C2V module. k. Navigation and situational awareness equipment including VHF radio, radar, AIS, LiDAR, cameras, lights and sound signaling apparatus. l. Payload - client hardware such as hydrographic survey equipment, sensors etc. The C2V module has a number of in-built procedures to ensure reliable operation of the vehicle and continued functioning of the in-built vehicle systems. One important procedure is the one intended to bring the vehicle control system on line and ensure correct functioning of the vehicle after first powering up or after a PLC reset. This procedure will now be described in greater detail by way of example. Vehicle Cold Startup Procedure Starting up the C2V control module may appear to be a straightforward task but there are a number of pitfalls. The process is complicated because of a chain of dependencies which require a series of components to be functional before the C2V module can boot up, or before the C2V module can remotely report its status. This requires the C2V module to go through a set of built in self-test procedures on startup so that it can confirm essential instruments are operating correctly before attempting to startup other, dependent instruments. It is also undesirable to switch all instruments on at once and potentially overload the power supplies. It is also necessary to consider the different ways in which the C2V module can be started. A cold start of the C2V module is from a situation where the main vehicle batteries are switched off. The cold start procedure for essential instruments and components is: 1. Main batteries, relay and fuse 2. C2 Cabinet master switch 3. DC-DC converters 4. PLC 5. Master Controller 6. Electronic Circuit Breakers (ECBs) 7. Navigation lights 8. Network router 9. Failover router 10. Selected communications instruments (A failover router is a router that provides connections to more than one internet connection.) If the C2V module is reset while the vehicle is operational, a different, warm start procedure may be required. Batteries There are four or more batteries fitted in the vehicle and only one battery has to be operational for the C2 system to be functional. If a battery fails due to an internal fault it would switch itself off automatically using its own protection relay. In the event of a more significant fault a thermal fuse mounted alongside each battery relay may blow, in which case the battery can only be used once the fuse has been replaced. A short or overload fault in the cables will also cause the batteries to switch themselves off. There is provision for the PLC to command the battery to switch off once the PLC has started up correctly. Cabinet Power Switch, Cold Start From a cold start the user switches on power to the C2V module using a switch on the top of the C2V module enclosure. A power LED next to the switch will illuminate if raw DC is available. DC-DC Converters Service DC-DC converters switch on automatically. The DC-DC converters are preferably dual redundant, with two converters on each power rail connected to a diode block. This provides redundancy in the event of failure because the DC supply is provided by the secondary converter if the first converter fails. PLC and Master Controller, Cold Start Power is then available to the PLC and associated IO module, which boots up automatically. Power is available to the master controller, which also starts, and to the Electronic Circuit Breakers (ECBs). The PLC heartbeat starts to the master controller and the PLC starts listening for messages from the C2A component. PLC and Master Controller Reset If the PLC is reset by itself or the master controller when it was previously up and running there is a different situation. In this condition, when the PLC starts its reboot: ● The master controller is powered and running ● The ECBs are powered and set ● The Data Logger is running ● Vehicle systems are running In this situation the safest option is to clear down and do a cold restart. ECB Status The PLC reads the ECBs to check they are operational and sets the ECBs so that all instrument power is switched off. The PLC ensures that the generator start is inhibited and the generator cannot run. The PLC switches on the navigation lights to indicate that vehicle startup is proceeding. The ECBs remember their state if their power is cycled. To ensure the correct startup sequence and operational safety the PLC switches everything off then switches on the ECB loads in the correct sequence. Battery Status The MasterBus communications are always on. The PLC next checks the battery status using a Modbus to MasterBus interface. The battery is checked early in the start sequence so that low battery conditions can be reported or managed. If the batteries are low and the vehicle is on shore or alongside a marina then they can be charged from a shore 240V supply. Data Logging The PLC starts on-board data logging so any logged error messages can be read from the earliest point after the PLC starts. Vehicle Sensors The PLC starts the fire system, bilge system, temperature system, cabinet temperature sensors and fans. The safety systems on board are started at the earliest opportunity so the PLC can find out if the vehicle is too hot, on fire or sinking. This restart of the C2V module may have been caused by fire or flood so the vehicle needs to detect serious problems and take the appropriate action. ● If the C2V enclosure temperature is too hot then the PLC runs the cooling fans. ● If the battery compartments are too hot then the PLC will run the bilge blowers. ● If a fire is detected on startup then the fire suppression system will activate automatically, or will already have activated. The C2V module will then undertake its Fire Procedure. ● If a flood is detected on startup then the C2V module will then undertake its Flood Procedure. The C2V module flashes the navigation lights in a predetermined pattern to indicate if a serious problem has occurred. Generator The generator is inhibited from running until the vehicle sensors have confirmed that the vehicle is not on fire or sinking. Once enabled, the C2V module will start running its Generator Procedure. Position Instruments Next to be powered up are the GNSS instruments, primary and secondary, and the serial data module. The GNSS system is dual redundant which minimises the possibility that vehicle position cannot be obtained. However, the startup procedure can continue even if no position is available. The serial data module will start publishing position messages on the network even though the network is not yet up and running. Vehicle Data Network The PLC switches on the breaker for the network switch which boots up automatically. If the vehicle is alongside another vessel or on shore an external hardwired connection on the C2V module enclosure can be used to communicate to the C2V module without needing the radio communications system. Radio Communications System The PLC switches on the breaker for the failover router. At this point we would only need to switch on the communications instruments that were being used, rather than all of them. For a vehicle not operational, the most likely communications channel to be used would be WiFi. If rebooting a vehicle at sea and at work then the last used communications channel should be powered, but this would require a means for the vehicle to save its configuration state. Alternatively, a brute force method can be used to switch all communications instruments on as the communications link could then be established with the shore by any means possible. At this point it should be possible for the C2A component to establish a communications link with the C2V module. Auxiliary Systems The next most important instruments are the primary forward looking camera, radar and AIS which are required for situational awareness, but only useful once communications to the C2A component is established. Other instruments to be brought on line include: ● Other cameras ● Radar transponder ● Anemometer ● VHF Radio Autopilot At this point it should be safe to start the Autopilot. The Moxa serial interface connects the Autopilot to the communications system so it should be powered up next, or the Autopilot redio communications link if that is being used instead. Next power up the autopilot, steering actuator interface, thruster interface and hand controller radio. The autopilot should start in a safe state with thrust demand set to zero. The EStop will be active at this point so even if the autopilot demanded thrust the thrusters would not run. The status of the autopilot can be monitored and reported to the C2A component. Light Messages The C2V module flashes the navigation lights in a pattern to indicate that startup has completed OK. Enable Propulsion Propulsion can be enabled if the vehicle is in a safe state, the vehicle position and attitude are known and the autopilot is running. However, the vehicle may have drifted into unsafe waters while it was rebooting so it should not be allowed to resume a survey task without approval from an operator. Instead, the vehicle should enter its safe state, which in most cases is to loiter in the position where it was when it came back online, as this should be safer than simply drifting downwind and down current. The operator will then have to choose to restart the survey task, perhaps after manually steering the vehicle to a safer position. Client Systems The client PC and client payload can be powered up at any point in the boot up sequence once communications to the C2A component have been established. However, it is important that any demands on the autopilot from a ‘backseat driver’ client system are disabled until the operator chooses to enable them. Scenarios The following scenarios illustrate, without limitation, some of the functionality of the command and control system. Lights on The Operator on shore clicks a button on the C2A component corresponding to the vehicle navigation lights on/off control. The C2A component sends a message to the C2V module to request that it switches on the navigation lights, and starts a command timer. The C2V module switches on the lights and replies with a Success message. The C2A component then updates its displays to show that the lights are now switched on. In the event that the C2V does not receive the message it does not reply. The C2A timer reaches a threshold and the command is considered to have failed. However, the operator cannot tell if the command was received at the vehicle and actioned and the reply failed, or if the command was not received by the vehicle, so the lights are now in an unknown state. The C2A component updates its displays to show that the lights are in an unknown state. Communications Lost The C2A component periodically sends a simple ping command to the vehicle to test the communications link, known as a heartbeat, which should elicit a simple reply from the vehicle. In the event of a communications failure, the C2A component continues to send heartbeat pings in an attempt to regain a communications link. If communications is re-established, the component requests one or more status update messages from the vehicle so that it can synchronise its status with the actual status on the vehicle (see lights failed example above). If communications are not re-established after a given interval then the C2A component activates a lost communications alarm and the displays are updated accordingly. In the event of lost communications to the vehicle for more than a threshold time the C2V module puts the vehicle into a predetermined Safe State. The component continues to try to re-establish communications until it is regained or the Operator chooses to stop trying. Critical Alarm The C2V module detects that Battery No. 4 has tripped its protective relay and shut down, so it sends a Battery Fault alarm message to the C2A component. The component displays the alarm to the operator and adds it to the list of currently active alarms. As this is a critical alarm it is styled accordingly on the display to highlight its status. The display is updated to show that Battery No. 4 is now not connected. The operator can clear the alarm manually as the failed state of the battery is displayed and the alarm is no longer shown in the active alarms list. Emergency Stop The operator notes on the on-board video camera that a floating object has appeared in front of the vessel. There is no time to plot a course to avoid it and the safest step is to stop the vessel immediately. The Operator clicks the Emergency Stop button which is always visible on the operator’s display. All other communications messages are interrupted to send an EStop message to the vehicle. The C2V module receives the message, stops the vessel propulsion using the EStop mechanism, and then replies to the C2A component with an acknowledgment message. Communications Reboot The primary communications channel is being reported as unreliable by the C2A component and the Operator thinks that rebooting it may help. The operator selects to use the secondary communications channel, the component sends a command to the C2V module requesting the switch over, and the new link to the vehicle is established. The Operator then cycles the power on the primary communications channel, and once rebooted the channel is tested by sending ping messages to and from the C2V module. Once the primary channel is proved to be working the C2A component requests that communications is switched back to using the original primary channel. Full Reboot The vehicle is exhibiting some unusual behaviour so a full reboot is ordered by the operator through the C2A component. The request requires confirmation by the operator as there is a degree of risk associated with it. Once accepted, the C2A component sends a Full Reboot message to the C2V module. The vehicle module receives the message and sends a reply. The C2V module then shuts down all instruments and sensors under its control and all communications links apart from the current primary link. The C2V module then commands the master controller to reset the PLC. Once reset, the C2V module powers up the other communications links and starts to broadcast ping messages to the C2A component. Once communications are re-established the vehicle is brought back on line by the operator. Whilst the above description places emphasis on the areas which are believed to be new and addresses specific problems which have been identified, it is intended that the features disclosed herein may be used in any combination which is capable of providing a new and useful advance in the art.