Modelling the operational effects of deploying and retrieving a fleet of uninhabited vehicles on the design of dedicated naval surface ships

Uninhabited vehicles (UXVs) are becoming an important component of naval warfare, providing an entirely new capability. By projecting military power in a more affordable way, through the use of UXVs, exposure of human life to military threats should be significantly reduced. While several navies are employing UXVs for a variety of applications, the concept of operating a fleet of such vehicles from a mothership that supports their overall operations during a mission, is a further challenge. This paper describes the research conducted by University College London (UCL) Design Research Centre (DRC) to develop and demonstrate a relevant analytical approach to design a mothership supporting a fleet of UXVs. This research should provide ship designers with the basis for early stage assessment of the impact of the various facilities seen as appropriate to host and support a substantial fleet of UXVs. It is particularly focused on the Launch and Recovery (LAR) capability of the UXV mothership. The research explored various options to demonstrate the proposed approach, rather than producing a definitive mothership design solution. This was appropriate given the fact that any UXV fleet composition is hard to predict (since mission related) and UXV technology is rapidly developing, so both must be speculative. It was found that the QT tool could provide meaningful investigation into the impact of potential tasks to be undertaken by a fleet of UXVs, addressing the design of mission bays, which were shown to be key to USV mothership design. While more focused simulations could refine subsystem options, this was not pursued, given the technology is still developing. Consequently, at this very early stage of investigating the deployment of a fleet of USVs from surface ships (through case studies), queuing network theory was seen to be more appropriate than a simulation-based analysis for this initial exploratory and investigatory work on future naval deployment of UXVs.


Introduction
In recent years, Western navies have been attracted to the concept of deployment of UXVs in naval operations for a wide range of roles, including Communication and Navigation Network Nodes (CN3), detection and identification of threats, Mine Counter Measure (MCM), Anti-Submarine Warfare (ASW), Anti-Air Warfare (AAW) and Anti-Surface Warfare (ASuW) (Clapper et al., 2007). Western navies are actively exploring the deployment of UXVs from surface ships. The Littoral Combat Ship (LCS) consists of a large class of surface combatant in the U.S. Navy that can accommodate and support a few UXVs, which are deployed for littoral zone operations (O'Rourke, 2016). The Type 26 Global Combat Ship (GCS) class of multi-mission warships are being procured for the Royal Navy with an adaptable mission space for some UXV modules, providing the capability to deploy Uninhabited Air (UAV), Surface (USV) and Underwater (UUV) warfare vehicles/modules (Ministry of Defence, DE&S, 2012). In contrast to the discrete UXV capability of both the LCS and the Type 26, the concept of hosting, deploying and supporting a large fleet of UXVs (say over 50 vehicles) from a mother surface vessel can be seen as a new capability. Consequently, there is a need to investigate the ship design implications of this new operational concept.
The deployment of a fleet of UXVs in a theatre of operations requires the presence of a mother vessel (or several vessels) capable of transporting and hosting a considerable force of UXVs, together with supporting facilities. This means a design approach needs to be devised in order to explore at a concept level how a fleet of UXVs could drive the design of a mothership. The proposed approach exploits the UCL originated Design Building Block (DBB) approach to Early Stage Ship Design (ESSD) (Andrews and Pawling, 2003) and combines it with an analytical tool, which would quantify the operations of a fleet of UXVs where the mothership supports the LAR of that fleet. This is seen to be a holistic, numerically and architecturally focused investigation of the initial design of such a vessel type. Studies have been undertaken using a recently developed UCL DBB based ship design tool informed by the proposed method for evaluating the LAR implications of a fleet of UXVs and their associated facilities, which drive the mothership designs.
The paper firstly outlines the problem of deploying, supporting and retrieving a fleet of UXVs from warships, followed by the proposed approach to tackle the LAR demands. Thereafter, several ship design case studies demonstrate the proposed approach. Finally, the mothership evaluation approach for the early design stages is discussed and the main conclusions are provided from the research.

Background to UXV naval deployment
This section considers issues raised by the deployment of a UXV fleet from a naval surface ship. It explores the topics of UXVs and naval ship design with the aim of identifying issues that are both relevant and feasible in investigating the deployment of a large number of naval UXVs from surface vessels.

Deployment of a fleet of uninhabited vehicles in support of naval missions
UXVs provide a number of potential benefits to naval operations, as they can act as force multipliers, while reducing the operational risks to which personnel might be exposed (Savitz et al., 2013). The future vision of naval operations involves the application of autonomous vehicles that could potentially reduce personnel related costs, by reducing the extent of facilities on-board naval combatants required for humans (Canning, 2005). This would lessen humans' exposure to tasks that are dirty (dealing with hazardous material), dull (long duration) and dangerous (exposure to hostile environment) (Alkire et al., 2010) (Pawling and Andrews, 2009). Additionally, removing the human from the vehicle can significantly reduce vehicle size and also lower its signatures (Clapper et al., 2012). Advances in computer software, speed and processing power, improved sensor technologies, enhanced communications, better image-processing capabilities, efficient and miniaturized propulsion systems (giving longer endurance and range), make UXVs potentially attractive.
Rather than deploying one or two UXVs per ship, a substantial coordinated fleet of UXVs could provide an increased capability to naval missions, especially if supported from a mothership. Mission profiles would be determined by a range of appropriate Concepts of Operations (CONOPs), where each CONOP should define the number and types of UXVs required to operate in each mission theatre. The capabilities UXVs deliver for each mission would be driven by the needs to meet each selected mission scenario, which can then give the technological requirements for both UXVs and support vessels (Canning, 2005).
The operations of UXVs during a naval mission could cover all evolutions, from the deployment of the vehicles to the mission theatre to their recovery on-board the host ship, including the required support while they are deployed. The off-board tasks involve the support of the UXVs while on-station, i.e. monitoring, identification of potential problems, Command and Control (C2), interpreting sensor information, communications and interoperation, authorisation of weapon systems use or other mission related activities, refuelling/recharging and replenishing ordnance on-station. UXV operations on-board the mothership could include fault diagnosis and repair, maintenance, refuelling, rearming, stowage, pre-mission checks and LAR (Clapper et al., 2007) (Broadbent and Binns, 2006).
A UXV mothership would provide the base for a group of UXVs integrated into an overall naval force, providing not just their stowage, maintenance and LAR operations, but also significantly contributing to C2 and communications to manage them (Braithwaite, 2013). Although, stowage space demands, on-board handling systems, maintenance and refuel equipment, and ordnance for the UXVs systems have implications on the design of a mothership, any successful UXV operations are likely to depend substantially on the capabilities of delivering and recovering the vehicles from the operational area (Thomsen, 2007). This would have a major impact on the performance, configuration and size of the intended mothership.
There are numerous potential ways of deploying and retrieving UXVs from naval ships, including catapult launcher, crane and stern ramp. Issues relevant to selecting appropriate LARS for operating a fleet of UXVs from a surface vessel include: space allocation, appropriate LARs location to compensate for wave-induced motions in limiting sea state conditions, adequate freeboard, operational availability, deck loading, well-trained personnel, power needs and cost implications (Lester, 2007). A dedicated UXV mothership should have the ability to deploy a range of types and sizes of UXVs, that can provide a network of interconnected UXVs, able to adjust to changing operational needs (Braithwaite, 2013). This could be achieved by providing flexible mission compartments on the host ship to enable it to support a wide range of UXV operations.

AAW
The implications of the UXVs on a host ship design and the resultant interfaces between the ship and the UXVs are of vital importance, and hence need to be considered from the start of designing any host ship. To enhance safety, multi-mission capability, mission effectiveness and affordability, the mission-oriented spaces need to be effectively integrated into the host ship's architecture. Mothership integration issues include: • LARSs; • Stowage spaces and handling systems, with a lifting allowance required to allow for the vehicles to be handled inside the mission bay (Pawling and Andrews, 2013); • Maintenance and repair equipment; • Refuelling and rearming facilities; • Relevant crew and their accommodation needs (as part of the ship infrastructure) • Power system demands; •F020 Relevant communications systems (Eaton et al., 2014); • The capabilities of a mothership relevant to host and support a UXV fleet, i.e. ship performance, including speed, range, endurance, seakeeping, manoeuvrability and stability.

The challenge of deploying a fleet of uninhabited vehicles from a naval vessel
Future naval capabilities may be delivered by a system composed of a variety of conventional, (or unconventional) vessels and uninhabited vehicles. Whereas, traditionally, a set of naval capabilities could be provided by a single unit and thus designers could focus on that design, the evaluation of UXV system concepts is likely to require a broader, more holistic approach to designing the complete system. Thus, a ship concept designer must trade-off model resolution for speed and flexibility in methods and tools in the early stages of design. The DBB approach can be utilised to assess the performance of an individual mothership and daughter craft designs, by addressing the capability of the mothership to operate a fleet of UXVs.
The DBB approach can also examine the impact the UXV fleet and the required facilities, sub-systems and on-board services, to support such a fleet, will have on the size, configuration, performance and cost of the resultant mothership solution. Additionally, certain ship architectural decisions (e.g. integration of mission oriented spaces into overall General Arrangement (GA)), could also affect the ability of a mothership to host and support such UXV fleets.
Consideration to date of the design of a ship that would be able to carry and support the overall operations of a number of UXVs has been limited to both a specific small number of vehicles and generic CONOPs studies. CONOPs studies would normally provide estimates of the numbers and types of UXVs, required to bring distinct capabilities into a theatre of operations (Purton and Andrews, 2014). However, OA assessment that is restricted only to the study of particular CONOPs scenarios was not considered sufficient to inform a generic mothership solution. This is because such studies alone would not take into account any potential issues regarding the physical impact of a fleet of UXVs on the design of an equivalent mothership. A wider design-based approach could capture the overall usage of a fleet of UXVs and then integrate support of that fleet into the design of a mothership.
Therefore, accommodating the above features in the ship, so it can deliver its primary UXV support function, was considered to be key to the design of UXV fleet mothership. Given the immaturity of the UXV fleet concept and of any appropriate systems for the LAR of such a sizeable number of vehicles, the physical demands on the mothership had to be speculative. Thus, it is not possible to currently exploit speculative ship design technologies, such those for UXVs and LARSs, given their rapid evolution. However, the design approach is not aimed at delivering definitive or absolute design solutions, appropriate to precise UXV technological solutions, but to provide ship designers with an approach able to investigate a wide range of potential and generic UXV systems and their supporting equipment and resources.
Most significant decisions ought to be explored, if not all fixed, in the concept phase of ship design (Andrews, 2018). This was achieved in this investigation through the use of OA to couple CONOPs alternatives with considering the impact of a fleet of uninhabited assets on the design of a dedicated supporting vessel. Thus OA derived functional requirements were postulated (e.g. extent of LARSs, C2, maintenance, refuelling, rearming, space, etc.) to support the operations of a fleet of UXVs during a set of representative UXV-led missions.

The importance of an architectural approach to ship design
The traditional numerically based approach to naval ship design synthesis delays architectural modelling while focusing on the readily quantified aspects of speed, seakeeping, stability, strength and the combat system numerical demands. Thus, the initial ship sizing ends up largely considering the internal arrangement once an initial numerically balanced (gross weight and space) design has been achieved (Andrews, 2003). Such sizing ignores the disposition of the different space requirements within the overall envelope and hence is bound to limit exploration of design variety. The examination of key design-related issues, such as the integration of mission bay systems, are likely to be postponed to later design stages, despite the fact that most warships are generally not weight or space limited, but architecturally driven (Brown, 1993).
Andrews "inside-out" or architecturally driven approach to ESSD, namely the UCL DBB approach, has been summarised in Andrews (2018) and has become an accepted approach to ESSD (Tupper, 2013). The DBB approach deliberately encourages exploration of novel solutions, both at macro and major level, from the commencement of ship design. Andrews and Pawling (2006) analytically described the appropriate steps of using the DBB approach for the design of innovative vessels, such as the US Navy LCS design. The design of an innovative vessel such that of a UXV mothership, where large mission bays are to be integrated in the ship, is seen to be configurationally driven. So the DBB approach was proposed and adopted in the USV Mothership case studies described later.

A novel integrated approach to UXV-Mothership system design
The proposed approach combines two tools; a UCL-developed on-line implementation of the Design Building Block approach, and a Fortranbased Queuing Theory analysis tool developed by Kouriampalis (2019).

The UCL ship design layout tool
The use of sophisticated 3D Computer Aided Design (CAD) models such as that of Paramarine in the implementation of the DBB approach has a particular drawback. Such full design level sophisticated naval architectural tools can require a level of detail often inappropriate to the very earliest stage of requirements elucidation (Andrews, 2018). Such comprehensive tools demand a high learning and familiarisation overhead for new users, such as students (Pawling et al., 2015). In order to address these issues, an online ship design toolset, implementing the DBB approach in ESSD, has been developed at UCL for use in ESSD teaching and research (Pawling et al., 2015). Coded in JavaScript, this tool uses a simplified cellular representation of the arrangeable space on the ship in a "2.5D" (i.e. decks) rather than fully 3D approach (Link, 2016). Fig. 1 shows an example GA for a UCL study of a UXV capable Offshore Patrol Vessel (OPV) (Pawling et al., 2017) as presented by this on-line tool.
Although including basic analysis tools, such as intact stability and resistance and powering, the JavaScript tool was primarily developed to allow visualisation and manipulation of ships' GAs. The numerical sizing is carried out in Excel (or any other tool capable of outputting the appropriate data), with any more detailed analysis needing to be carried out in sophisticated CASD tools, such as Paramarine. Moreover, using network analysis (Pawling et al., 2015) and 2D modelling, the Java-Script toolset enables quick extraction of a range of spatial features, such as the extent of block adjacency. These additional geometric metrics can also then be used for innovative network-based layout analysis (Pawling et al., 2016).

Modelling the operation of UXVs
In order to produce an indicative UXV mothership design, it was necessary to investigate the overall UXVs operations required to operate a fleet of UXVs. Those revealed the necessary physical interfaces between the uninhabited assets and the mothership, while also suggesting non-intuitive improvements to the overall operations. The latter were taken into consideration in the mothership studies. The likely operations of a fleet of UXVs supported by a mothership was represented as a number of interconnected nodes, forming a network system shown in Fig. 2, where each node represents a task in the UXV operations. Some nodes relate to mothership characteristics (such as launch and recovery), and others to the UXV capabilities, such as reliability.
Analysis of the operation of a fleet of UXVs from a mothership was seen to need a novel quantitative approach. The method developed used Queuing Theory (QT), which is a mathematical representation of waiting lines, i.e. queues, suitable for the modelling and analysis of certain systems (Robertazzi, 1994). QT has been used in Operations Research (OR) to determine the type and number of resources to be allocated to provide a specific service within certain time limitations (Hillier and Lieberman, 2001). QT has also been applied to various issues involving transport, airports, production lines, telecommunications and the internals of computers (Bhat, 2008). By providing a quantification of performance, QT can provide a ship designer with measures of effectiveness of a potential UXV mothership, by indicating the ability of a given ship design option to support the operations of the ship's UXV fleet. These metrics could then be used to compare the capabilities required to support a fleet of UXVs provided on various potential mothership solutions.
QT can be adopted to represent any system where "customers" arrive looking for "service" of some kind and depart once the appropriate service has been provided. Such models can be constructed to predict performance measures appropriate to a queuing system, such as the queue length (i.e. number of customers waiting in the queue) and waiting time, which would also contribute to understanding the behaviour of such systems (Bhat, 2008). A simple queuing model can have two distinct elements: the waiting area and the service area, as is schematically shown in Fig. 3. Such a model may be used to represent a number of customers (i.e. UXVs) that arrive at a waiting area, where they queue up if all servers are busy. Such a conceptual model can be used to represent each task shown in Fig. 3, forming a network of queuing nodes.
In a QT representation of a UXV mothership, the UXVs themselves are the "customers", and the LARS can be considered resources that need to be allocated. Two key features of QT that led to its adoption were the short computation times and, most significantly, the high level of abstraction. This permitted a wide range of novel LARS, UXVs and even UXV tasks to be included in a common representation, through changing the numerical characteristics of the nodes.
QT analysis can generate various numerical outputs and in this application these were divided into two broad categories; (i) information on node performance and (ii) ship impact due to providing the necessary ship equipment, systems and resources to support such a fleet of uninhabited assets (i.e. space requirements and consequential mothership size, layout and performance).
(i) Node Performance: • Total time a UXV spent at a node (i.e. facility) requesting the appropriate service (e.g. LAR). This relates to the performance of the LARS adopted in a given ship installation; (ii) Ship impact: • Number of vehicles in a queue at a node as a measure of the space (i. e. waiting area) required in front of the facility that provides the service in question; • Number of servers, being a measure of the space required for the facilities (e.g. LARSs) that provide the appropriate service (e.g. LAR).
The service rate of a node within a queuing network system could be improved by either allocating more servers of identical type (e.g. more LARS), or by employing faster servers (e.g. better LARS). The designer could explore the extent of necessary changes to the underperforming nodes, noting subsequent impacts on the mothership design.
Based on such investigations, the ship designer could assess whether the performance of the selected network was satisfactory. Thus, the QT tool contributed to the decision-making process with regards to the mothership design in terms of the features needed for the mothership to deliver its primary functions, see Fig. 4. In general, smaller times spent at each node, along with high throughput values and low queue lengths, indicated a mothership design of enhanced ability to support the UXV fleet. Hence, by analysing a queuing network of UXV operations on a mothership, if the resulted network metrics quantifying the mothership   capability to support those operations, is satisfactory then the relevant mothership design is accepted. Otherwise, the inputs to queuing network could be modified until the queuing network performance is acceptable.

Applying the QT approach to mothership options
Based on the broader UXV system activities shown in Fig. 2, the interactions between the UXVs and mothership could be identified, as summarised in Fig. 5.
For a dedicated UXV mothership, these interactions would likely be significant drivers of the ship design, ranging from high level topological decisions, such as the location of UXV "hangars", through design impacts of accommodating multiple LARS to specific performance features, e.g. seakeeping, to ensure low motions during launch and recovery.
The QT demonstration of LAR capability was used as a proxy measure of the overall effectiveness of potential mothership concepts, i.e. the faster a fleet of UXVs can be launched and subsequently recovered on-board, then the more efficiently a mission should be executed. This focus was primarily to constrain the problem to that which could be assessed in a university research scenario, given limited technical information available and the rapid development of UXV technologies.
The QT tool results were incorporated in the design of a mothership by modelling the performance of the relevant launching nodes and their implications on a mothership design. The following issues were considered for their impact on the configuration of the mission bays and thus on the overall mothership design: i. The implication of the number of UXVs for a given set of LAR facilities on a mothership or the implication of the number of LAR facilities for a given fleet of UXVs; ii. The implication of the type of LAR facilities for a given fleet of UXVs. Distinct types of LAR equipment provided assumed different LAR service time per vehicle, based on current data obtained from UXV manufacturers (Knight, 2012). Future LARSs are likely to be enhanced and more sophisticated LARSs would provide more specific (and improved) metrics.
The QT tool was not used to analyse different UXV fleet compositions subject to various operational scenarios, although this could have been done to gain insight into how the design drivers (for ship and UXV LARS) would affect the design of potential UXV motherships. For the case studies described a particular fleet of UXVs was proposed. Thus, changes in the values adopted for the queuing network could reveal the likely impact on the mothership's capability to support UXVs. Such changes might have resulted in further distinct mothership solutions, due to the implications regarding the required equipment, systems, spaces, associated complement and on-board supporting services. Fig. 6 summarises the overall flow of information that would be expected in a study of UXV-mothership system capability. Thus information would flow from the CONOPS to the QT model and then to the architectural model of the mothership, enabling the calculation of ship size and its UPC. The development of multiple options in each of the first three stages would allow a Cost and Operational Effectiveness Analysis (COEA) to be conducted.
The arrows from QT and the DBBA represent two possible approaches: the use of the QT model to develop specifications for mothership alternatives (as was done in this study); or the use of mothership designs to constrain the numerical characteristics for nodes in a QT analysis. The latter could have been used to drive LARS or even UXV development.
CONOPS studies are typically conducted to define the payload required throughout a set of mission scenarios. For the purpose of demonstrating the proposed UXV mothership design approach a fleet of UXVs was proposed for potential mission scenarios.
The QT network tool is a numerical approach that employs the Mean Value Analysis (MVA) algorithm for queuing networks without buffers, as described by Bose (2002). Analysing a proposed network of UXV operations supported by a mothership, the tool provides information regarding: i) the LAR capability (i.e. LAR duration) of the resulted mothership, and ii) mission bay and UXV-related ship facilities, as well as the incurred queuing demands that have to be considered in the mission bay configurations.
The JavaScript UCL concept ship design tool that employs the DBB approach is then used to configure the mission bay arrangements and the overall disposition of the blocks resulting in the UXV mothership design, while also preforming basic architectural analyses, i.e. stability, powering. The resulted designs were costed using UCL UPC algorithms (UCL, 2014a).
Finally, various UXV mothership options can be assesses against cost (UPC) and operational effectiveness (LAR capability) measures. The proposed UXV mothership design approach is presented in the USV case studies below.

USV case study CONOPS and system modelling
For the purpose of this study, a USV fleet package of some 60 vehicles was assumed, consisting of two distinct USV types, as shown in Table 1. Fleets composed of multiple vehicle types could have diverse capabilities, but may also present distinct demands for mission bay systems and equipment, including LARSs. The large number of vehicles was specified to present a challenging requirement, contrasting with current ship designs featuring small numbers of UXVs.
The wider system network analysed using the QT model is shown in Fig. 7, which is a modification of generic Fig. 2, with the input data for nodes shown in Table A1 in Appendix 1. This analysis gives the amount of space required around each shipboard node (e.g. LARS) in the form of queue length, which could be multiplied by the physical size of each relevant USV to determine area required. The USV related activities were divided into the following stages: 1. The deployment of the USV fleet for a given mission scenario would start with positioning the stowed vehicles on board the mothership adjacent to the LAR positions, using internal handling systems (i.e. Stowage/handling node); 2. Vehicles would be directed towards the LAR points (i.e. launch nodes), where final pre-mission checks would be performed, involving fuel-battery-ammunition levels checks and fault tracing, before launching them into the water; 3. Once launched, the USVs transit towards the mission theatre (i.e. mission theatre nodes) where certain tasks would be performed according to the appropriate CONOPs scenario; 4. In case of a detected malfunction in the USVs control room on the mothership (i.e. malfunction at sea node) the affected vehicle(s) would abort the mission and (if possible) head back to the mothership, where they would be intended to be recovered on-board for repairs, refuel/recharge and rearming (i.e. maintenance/refuelling and rearming nodes) and are then re-launched. Alternatively, if a repair by exchange policy was deemed appropriate, spare vehicles would be launched to replace defective ones. Generally, during peacetime, vehicles would be recovered on-board and stowed, where any necessary further vehicle repairs could be undertaken; 5. Given that the installed energy and ammunition capacity of a USV is likely to be limited, it may be necessary for vehicles to be able to be refuelled and rearmed on-station (i.e. refuel and ordnance nodes); 6. Once the operations at the mission theatre had been completed, the vehicles would return to the mothership to be recovered on-board at the LAR points (i.e. recovery nodes). Thereafter the vehicles would be stowed, while any ammunition replenished (unless directed energy weapons were employed); 7. Once the vehicles completed their allocated activities, they would be recovered on-board and stowed. While stowed the vehicles are likely to require certain activities, including refuel/recharge, as well as exchange of any collected data/information with the mothership (i.e. through plug-ins, or without physical connections via wireless technology).

USV mothership design case studies
The approach shown in Fig. 6 was applied to three mothership case studies. The QT model was used in a comparative manner, with different LARS options being compared against a common USV fleet requirement. Metrics appropriate to operational effectiveness and ship requirements were extracted from the QT model, with concept level balanced ship designs then being developed and costed using Excel tools and the JavaScript layout tool. Costing of the potential mothership options was performed using the UCL ship costing procedure (UCL, 2014a). Fig. 8 summarises the Baseline and two variant designs. Design Variant 1 represented an incremental design change (i.e. enhancement of a single ship's LAR capability). The effect investigated was to increase the number of LARSs fitted in a single mothership, by doubling the LAR capability through fitting four cranes in the amidships mission bay (i.e.  two port and two starboard cranes) and two ramps in the stern mission bay. In contrast, Design Variant 2 represented a step design change. The effect investigated was to distribute equally the fleet of USVs in two smaller identical mothership designs, each with the same LARSs as the Baseline ship.

Baseline mothership design
The principal particulars of the Baseline USV mothership design are described in Table 2, and Table 3 summarises the various craft carried by the mothership. In addition to these, a basic frigate-level self-defence and communications system was included. Fig. 9 shows the GA of the baseline mothership, colour coded by Functional Group; FLOAT functional group in blue, MOVE functional group in yellow, FIGHT functional group in red and INFRASTRUCTURE functional group in green. The baseline design featured two USV bays and ocean interfaces; one amidships in the superstructure, and one at the stern. The details of the GA beyond the USV features are extracted from Kouriampalis (2019), which needs to be consulted for completeness, which is beyond the main thrust of this paper.
The service facilities associated with the proposed mission bay arrangements are listed in Table 4, while the queuing spaces, resulting from modelling the network considered, are shown in Table 5.
Two mission bay arrangements (i.e. amidships and stern) were proposed, as shown in Figs. 10 and 11, based on the required number of USV spaces and allowances for equipment, personnel access, etc.
The LAR capability for the Baseline mothership design was defined by the queuing network model in the form of the total time (i.e. actual service time plus queuing delay) required to deploy and retrieve the whole fleet of USVs, namely 20 USVs Type "A" operated from stern mission bay and 40 USVs Type "B" operated from amidships mission bay. This is summarised in Table 6.

Mothership design variants
Other than the LARS and UXV requirements, the design requirements for Variant 1 (increased LARS) were identical to those for the Baseline (i. e. defensive weapons, accommodation, etc.). Design Variant 2 had a smaller complement per ship due to the smaller number of UXVs. However, the duplication of defensive and auxiliary systems in a multiship approach conributed to the increased overall cost. Table 7 summarises several comparative characteristics across the three ship designs, including LARS and overall ship design characteristics. These are shown in absolute values and non-dimensionalised to the baseline mothership design.

Analysis of the results of LAR capability and USV mothership configuration
The resultant USV mothership Baseline design option was quite large relative to current USV carrying naval combatants. This was due to the substantial mission bay arrangements for such a fleet of USVs having to be integrated into a naval ship design.
The overall beam of each USV mothership design was driven by the arrangement of the mission-oriented spaces. Additionally, the mission bay spaces were seen to drive the general configuration of the ship. It was observed that the disposition of the Fight and Move functional group elements (primarily USV bays and main machinery) were prioritised, while the Infrastructure and Float functional groups had to meet typical naval standards, as did the overall ship. All contributed to the overall substantial USV mothership designs.

First design variant
Assessing the impact of increasing the number of the LARSs employed in the mission bay arrangements and the resulting USV mothership design, showed that the increase of these service facilities enhanced the deployment and retrieval of the prospective USV fleet for an assumed mission scenario. This first design variant gave an improved ship's LAR capability, thus leading to a faster launching and recovering of the specified USV fleet. Design Variant "1 ′′ enabled concurrent LAR activities for the same size of USV fleet (when compared to the fleet operated from the Baseline USV mothership design), because of the increased number of LAR service facilities, which were able to be operated independently.
The major ship design characteristics, namely displacement, enclosed volume, density and UPC were comparable for the USV    Fig. 9. Baseline USV mothership design internal arrangement produced using UCL JavaScript ship concept layout design tool [Kouriampalis, 2019].
N. Kouriampalis et al. Baseline Design and Design Variant "1" (Table 1). Despite the similarities in the overall ship design characteristics, the LAR capability performances achieved in the Baseline design and the Design Variant "1 ′′ were noticeably different, as seen in Table 7. Although LAR overall capability in Design Variant "1 ′′ was improved by roughly 25%, when compared to the Baseline Design, through installing twice the number of LARSs, the overall ship impact was relatively small (Design Variant "1 ′′ UPC was 1.0% less than that of Baseline Design). Although more LARSs were installed in Design Variant "1 ′′ , the resultant mission bays were smaller than those of the Baseline Design, since the queuing spaces were decreased, which allowed the mission bays to be reconfigured.
Moreover, it was observed that the integration of the appropriate mission-oriented spaces resulted in distinctly different mothership design configurations, illustrated in Figure A2.1 in Appendix 2. This was due to the integration of twice the number of LARSs, which meant (for Design Variant "1 ′′ ) different configurations of the mission bays and thus for the overall mothership arrangement, including the ship passageway arrangement and the arrangement of the crew accommodation spaces, compared to the Baseline.
The amidships mission bay of Design Variant "1 ′′ was significantly reconfigured, since the need of queuing spaces ahead of the port and starboard crane based LARSs, was significantly reduced. Therefore, the spaces that were initially used for queuing in the amidships mission bay of the Baseline USV mothership design, could then be employed for stowage space, resulting in the reduced amidships mission bay configuration in Design Variant "1". Moreover, the resultant stern mission bay configuration of Design Variant "1 ′′ required no queuing space, resulting in a smaller stern mission bay arrangement than for the Baseline Design. This counter intuitive result shows that using the DBB ship synthesis approach over purely numerical sizing ensured a better means for initial ship sizing, certainly for such architecturally driven ships.
Since the resultant stern mission bay arrangement fitted in Design Variant "1 ′′ was smaller in length, this readily enabled a double sided and athwartships passageway arrangement within comparable overall ship design characteristics (i.e. displacement, gross volume and overall length). This was considered plausible due to the space made available in Design Variant "1 ′′ through accommodating a smaller stern mission bay. It is noteworthy that the overall beams (i.e. 31 m) of both the Baseline Design and Design Variant "1 ′′ were driven by the size of the proposed mission bay arrangements. Given the maximum beam, a double sided and athwartships passageway arrangement might be desirable, in easing accessibility (i.e. enhanced routeability, given a degree of passageway redundancy) throughout the main access decks. However, this raised possible structural considerations arising from such an arrangement. Such issues, as the arrangement of openings (i.e. uptakes, downtakes, hatches and other openings), would need to be addressed for longitudinal strength implications [Chalmers, 1993]. With the extensive stern mission bay integrated in the Baseline Design, a double passageway arrangement was likely to have resulted in a bigger ship.
Given a smaller stern mission bay accommodated in Design Variant "1 ′′ than in the Baseline Design, a more flexible overall ship arrangement was possible with regards to the accommodation spaces. The available deck area, due to the shorter stern mission bay, meant the accommodation spaces could be pushed further aft in the ship. This could prove to be a more attractive solution for laying out these JR accommodation spaces, given wave-induced ship motions are likely to be less in the    a Overall comparison refers to full fleet support, where in the case of Design Variant "2 ′′ the fleet is supported from the two identical USV motherships, i.e. overall LAR capability for Design Variant "2" is considered when the two ships operate concurrently, while the overall UPC for Design Variant "2" addresses the total cost for the two identical ships, where the fleet is distributed to. b Per ship capability refers to each ship's characterisics.
central-aft portion of the ship than in the forward location of the ship. It was also observed that Design Variant "1 ′′ ought to achieve a noticeably better LAR capability (seen in Table 7), with an estimated cost (UPC) that is comparable to that of the Baseline USV mothership design. This comparison indicated that the LAR capability of the mothership could be noticeably improved for almost the same major ship design characteristics (ship displacement 1% smaller than that of Baseline) and assessed UPC.

Second design variant
The concept of splitting equally the assumed fleet of USVs between two identical smaller motherships, was considered as a plausible second alternative to the quite large and costly Baseline Design. Compared to the option of a single USV mothership design, two Design Variant "2 ′′ ships, shown in Figure A2.2 in Appendix 2, would provide the Force Command with better force redundancy, by distributing the USV fleet across two hulls. This would avoid a single hull lethality hit destroying the whole of the Force's USV fleet's capability or mitigating lesser damage states.
The proposed measure of the mothership's LAR capability for the assumed generic mission scenario was found to be significantly improved for Design Variant "2 ′′ , when compared to the Baseline design. This was due to a more effective LAR arrangement for the given USV fleet. Such an overall LAR enhancement could have been expected, due to the decrease of the number of USVs operated from each of the Design Variant "2 ′′ vessels, since each one of them had two mission bays. In such a design option, the overall USV capability was maintained, but it was accommodated and independently supported by the two identical motherships. Furthermore, these two smaller motherships could independently transit towards a potential theatre of operations and concurrently deploy their USV capability to meet that mission.
The reduced mission bay size for the Design Variant "2 ′′ solution, consequent on a reduced number of USVs operated by each ship, plus the decrease in accommodation space for the lower crew numbers (given the reduction of USV fleet per ship and the smaller ship size), resulted in a noticeably smaller ship design solution than the Baseline option (i.e. 25% smaller in gross volume and 22% smaller in displacement than the Baseline at a UPC 19% cheaper per ship). Hence, when compared to the Baseline design, the integration of the resultant mission-oriented arrangements into the mothership design resulted in a ship design option with different major ship design characteristics and internal arrangements. Design Variant "2 ′′ mission bays were reconfigured from those for the Baseline, based on the derived reduced stowage demands and the reduced queuing effects (70% less queuing demands in amidships mission bay for Design Variant "2 ′′ compared to the Baseline, plus needing a third fewer queuing spaces for the stern mission bay), giving smaller and noticeably different ship arrangements to those of the Baseline Design. This enabled the maximum beam requirement to be reduced to 26 m (from 31 m for the Baseline), which subsequently drove the overall beam of Design Variant "2" (i.e. maximum beam 16% smaller to that of the Baseline Design). The proposed GA of Design Variant "2 ′′ , followed the generic deck plan arrangement adopted in both the Baseline Design and Design Variant "1 ′′ , i.e. double-bottom, two machinery decks, two main passageway decks and superstructure.
Two vessels of Design Variant "2 ′′ could together achieve a significantly enhanced LAR capability over the Baseline Design, since the two ships could simultaneously deploy and retrieve the fleet of USVs. However, the overall UPC to acquire the two smaller identical USV motherships was estimated to 62% greater than that for the single Baseline Design, consequent on procuring two ships and would have greater running costs.

Review of the proposed UXV fleet mothership design approach
The proposed UXV mothership design approach, i.e. combining the QT tool with the architectural-oriented ship design, provides a requirement driven approach to the design of a mothership for a fleet of UXVs. For mothership design studies such an approach could be employed in an actual Concept Phase in collaboration with mission specialists. Thus, various potential ship design solutions could be investigated in terms of technical feasibility and affordability, and result in refining the user requirements captured through a comprehensive requirements elucidation process (Andrews, 2018).
Due to the immature nature of UXV technology, the mothership design case studies were a means to demonstrate the capabilities of the proposed evaluation approach to aid early work on a future concept of a fleet of UXVs, rather than the initiation of a full concept design. Since UXV technology continues to develop rapidly, the research aim was to scope the problem of a UXV fleet operational scenario supported by a mother vessel, while providing reasonable and believable results of varying the LARSs and mission bay features at high level.
The purpose of this research was to devise a plausible approach for Fig. 11. Proposed stern mission bay arrangement for Baseline USV mothership design (see Fig. 9 for location on ship).
exploring the implications of deploying a fleet of UXVs on the design of a potential mothership, able to host many such autonomous assets onboard, deploy, recover and support their operations for typical naval missions. Thus, incremental and step design changes were undertaken to a sufficient level of detail appropriate to what might be considered Pre-Concept research. The research investigated major ship's capabilities to accommodate and support a fleet of USVs, emphasising the impact of LARS on the design of a mothership, the proposed approach was broadbrush, and focused on USV operational impacts on the mission bay configurations and hence on the overall configuration of a potential USV mothership, while still producing (concept level) naval architecturally balanced ship designs. Given the driving ship design issue for such a mothership would be the deployment of a large number of USVs, recourse to a numerical and structured approach for assessing the impact of such operating conditions was necessary. Network theory seemed to provide the basis of modelling the fleet of USVs when operated from a mothership, due to the set of tasks the USVs would undertake in a predefined sequence. This sequence could be assumed to meet a generic flow of activities in the order of: launch (i.e. mission initiation); mission activities and appropriate support during a mission scenario; and recovery (i.e. mission completion). Consequently, a network system of UXV-related activities was devised, where those activities taking place on-board the mothership, including LAR operations, would be likely to significantly impact the design of a ship. This is because, the on-board ship support systems could be represented as the facilities providing an appropriate service to each USV, and thus queuing network theory was able to capture the relevant operational steps. Use of QT was possible due to the limited number of service facilities likely to be available on a ship and the large number of USVs to be processed through the deployment process. Additionally, the queuing network model was used to quantify a mothership's LAR capability, as a proxy measure of the USV fleet's mission effectiveness. This then provided a means to compare different mothership design options. With the addition of comparative UPC estimates from the concept level balanced ship designs, it was possible to define some COEA like conclusions.
Applying QT to network systems is a mathematical modelling approach that can be considered to approximate the behaviour of a real process. One alternative to QT in modelling network systems would be to use a simulation software package that would mimic the behaviour of the deployment/recovering of the fleet of UXVs more realistically than simple numerical models (such as the QT based approach explored). Simulations ought to provide more accurate representations of the process of deploying a fleet of UXVs from a surface ship, as well as providing further potential insights through (for example) animations. However, such simulation software would require detailed understanding of a yet to be developed use of a large number of disparate UXVs at sea. Currently it would probably still be preferable to adopt a combination of both numerical modelling and high-level simplified simulation techniques. This is because numerical modelling (such as provided by QT) enables an abstraction of the problem, revealing its underlying structure, and the cause and effect relationships inside the system. Consequently, at this very early stage investigation, the use of queuing network theory was seen to be more appropriate and sufficient when used with an early stage architecturally driven ship synthesis approach (e.g. the UCL DBB approach (Andrews, 2018)).
The demonstrated combination of QT and the UCL DBB approach enabled exploration of both processes and the arrangements for handling different UXV-related aspects on-board a mothership. The QT tool could provide meaningful investigation into the impact of potential tasks to be undertaken by a fleet of UXVs, addressing the design of mission bays, which were shown to be key to such mothership design options.

General conclusions
Overall, a new quantitative and structured approach was proposed and implemented to capture, at early stage design, the implications of rapidly deploying from and retrieving a fleet of UXVs to a new concept (mothership) surface vessel. This showed operating such a fleet of uninhabited vehicles resulted in large and costly naval vessels.
It was demonstrated through the ship design case studies that the proposed approach was able to differentiate between different design options. This difference centred on the choice and use of the metrics extracted from the QT model, acting as measures of a UXV mothership's capability, as well as assessing the impact of UXV operations on the mission bay arrangements. Thus, distinct mothership design options, in terms of size, configuration and performance, were produced by integrating the various proposed mission bay arrangements into a new, overall ship design solution. The mothership options were assessed against what was considered to be meaningful criteria, which were met using the proposed design approach. Thus, ship UPC and LAR capability acted jointly as a proxy measure of operational cost effectiveness in the absence of direct mission performance indicators and fully costed procurement and through life expenditure. Although specific downselection methods were not considered as part of this research, COEA can be seen as a framework to assist such a decision-making process.
Given the values were essentially indicative, the results could only be strictly considered on a comparative basis, when judging potential options. Furthermore, the latter should be seen as part of a wider exploration of the available solution space (Andrews, 2018).
The integration of the QT tool with a ship design tool was seen as providing the ship designer with insights into the space demands, from operating an assumed UXV fleet composition. Additionally, the number and types of on-board UXV facilities, the ship's performance requirements (i.e. S 5 plus combat systems capability (Brown and Andrews, 1980) and the appropriate configuration for a mothership to successfully carry on-board and support the operations of a given fleet of UXVs, were all broadly assessed. Furthermore, QT modelling was considered a reasonable means in assessing a UXV mothership's capability by numerically indicating the operational effectiveness that can be achieved by the engagement of a potential UXV mothership in a generic mission scenario. Thus, believable and informative concept solutions, informing the impacts of future technologies, were considered to be demonstrated.

Further work
This broad exploration of a limited set of designs necessarily revealed several limitations, which emerged throughout the development, implementation and application of the proposed UXV mothership design approach in ESSD. Such aspects merit further investigation, in order to improve the proposed evaluation approach: • The JavaScript tool could be further developed to include modelling different hull types and important ESSD analyses, such as damage stability and seakeeping. A full concept phase would not just require further CONOPs, but also a comparative ship solution space exploration (Andrews, 2018). This might well reveal unconventional or multi-hull configurations could provide cost-effective competing design styles. • In reality the duration of LAR activities per vehicle is likely to be affected by endogenous (i.e. human factor-related aspects, ship speed) and exogenous (i.e. sea state and headings-ship motions) factors. The Anglo-Dutch LAURA project has been investigating probabilistic methods for describing LAR operations, in order to quantify some of those factors (Knight, 2012). Such investigations are based on ESSD experience, simulations (i.e. seakeeping, model testing), LAR research, probabilistic and risk-based design research, as well as feedback from operators involved in current UXV LAR operations. Thus, the proposed UXV mothership design evaluation approach could be used to interface with such insights. Such investigation should be able to inform the LAR service times per vehicle modelled in the proposed queuing network tool, since more realistic data/modelling would then be available, albeit for specific current vehicles. • Simulation techniques, although computationally more expensive, could provide a more accurate analysis of queuing networks. The proposed mothership design evaluation approach can be seen to provide an early investigation of the implications of a fleet of UXVs on the configuration of a mothership, since it allows a relatively fast (depending on the complexity of the network system under study) exploration and comparison of different mothership design options against a cost-LAR capability criteria. Favourable design options might then emerge through conducting comparative studies. These could then be explored using simulation techniques, providing more accurate results on the vehicles' operations supported from the ship and keeping in step with UXV technologies for 'fleet like' operations.
Despite the above issues, it is considered that the research presented here has shown how high level and generic information, resulting from numerical operating modelling techniques, can be integrated with the early and formative stages of designing complex, diverse and highly integrated engineering systems, such as future naval vessels.

Declaration of competing interest
The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. *The values of the facility levels were speculative and based on the candidate's engineering judgement, while the processing times were based on the broad specifications resulted from relevant references and discussions with BAE Systems representatives.
Appendix 2 Figure A1. Internal arrangement of mothership Design Variant "1 ′′ produced using UCL JavaScript concept ship layout design tool.
N. Kouriampalis et al. Figure A.2.2. Internal arrangement of mothership Design Variant "2 ′′ produced using UCL JavaScript concept ship layout design tool.