Schuhmann-Better-design-decisions-through-operational-modelling-2013

Better Design Decisions through Operational Modeling during the Early Design Phases Benjamin Schumann1, Mario Ferraro2, Amrith Surendra3, James P Scanlan4 and Hans Fangohr5 University of Southampton, Southampton, Hampshire, SO17 1BJ, UK This work presents an operational simulation based on a unique mission ontology that enables recreating any aviation scenario using a small set of parameters The tool is designed to suit the early design phases where time pressures, uncertainties and knowledge gaps peak It is embedded in a stack of software allowing early design phase optimization based on operational constraints This stack was used to design and build several Unmanned Aerial Vehicles Two case studies demonstrate how the tool can act as a decision support or optimization tool, leading to improved designs and better operations It is found that early design decisions can be based on a more rigorous analysis and that it is possible to optimize both the design and the operational environment by employing an operational simulation I T Introduction HE design of large aerospace structures such as aircrafts or spacecraft is usually categorized into conceptual, preliminary and detailed design phases The conceptual design phase is used to map customer requirements into quantifiable design goals and select a number of promising technologies to be included into the future product The preliminary design phase focuses on the initial analysis of the selected design ideas, exploration of the design space and selection of the most promising design candidate This choice is then carried through to the detailed design phase, the most time-consuming and costly phase of product design [1] However, aerospace design has seen a paradigm shift occurring during the last two decades: design processes shifted from sequential and iterative PhD researcher, Institute for Complex Systems Simulation & Computational Engineering and Design Centre, Faculty of Engineering and the Environment, AIAA student member PhD researcher, Computational Engineering and Design Centre, Faculty of Engineering and the Environment, AIAA student member PhD researcher, Computational Engineering and Design Centre, Faculty of Engineering and the Environment Professor of Design, Computational Engineering Design Centre, Faculty of Engineering and the Environment Professor of Computational Modeling, Computational Engineering Design Centre, Faculty of Engineering and the Environment analysis that focus on weight and cost reduction (“design for performance”) towards more integrated design tool chains that allow dynamic tradeoffs and optimization (“design for quality”) [2] This paradigm shift has been facilitated by the increase in available computing power and better analysis tools, especially in computational fluid dynamics (CFD) and computer-aided design (CAD) However, the early design phase has not progressed to the same extent Although it is estimated that up to 85% of the life-cycle costs of a product are defined and fixed during the early design phase decisions through concept selection and fundamental design decisions, companies allocate only limited time and funds to this period [3,4] One of the reasons is a limited perspective upon the total life-cycle of the future product due to fundamental knowledge gaps and knowledge uncertainties early on In the past, these shortcomings were overcome by using simplistic deterministic models with no uncertainties and perfect product functionality [2] However, resulting designs often featured high sensitivities to system variation and today, it is widely accepted that stochastic variation must be included in the early design phases [5] Any systematic improvement to the early design phase procedures can increase profits manifold However, adapting existing detailed design phase tools for the early design phase is difficult Often, tools for detailed design analysis (like CAD, CFD or specialized operational simulations) are not capable of handling large uncertainties and unknowns with respect to the design itself, the product environment and the final product application by the customer Instead, the early design phases require tools tailored for the unique challenges that designers face early on These challenges are threefold: First, designers need to understand the customer requirements and expectations fully, i.e they need to know the product capabilities early on Second, they need to rate a number of potential design candidates with respect to the customer requirements Third, they need to account for the dynamic nature of the product life-cycle, i.e they need to translate the static customer requirements into a product that dynamically interacts with its environment over its life time The last aspect is usually the most difficult one: lack of time, knowledge and tools does not allow a full investigation into the life-cycle performance of each design candidate Moreover, it is inherently difficult to understand the influence of design decisions upon life-cycle performance and product value The reason is the complex nature of the interaction of the product with its environment and the difficulty of valuing the resulting performance Here, the term ‘environment’ refers not only to the physical surrounding of a design, i.e the air flowing past a wing or the airfield rolling beneath the landing gear It includes interactions with other aircraft of the same type but also with competing systems It includes ground handling, weather, wear and repair This leads to a life-cycle performance view including every aspect of aircraft usage made available for the early design phases Analyzing these aspects of aircraft life is usually conducted during the detailed design phase when most of the cost-sensitive design decisions have already been fixed This research aims to improve aircraft design by introducing advanced life-cycle analysis into the early design phases There is a need for a generic tool that links design decisions to life-cycle performance, taking into account uncertain and partial knowledge about the design and its environment This tool can be used during the early design phases to compare design candidates, feedback on design decisions and optimize early designs for detailed design work The rest of the paper is structured as follows: Section II introduces the concept of operational modeling and justifies the use of operational simulations during the early design phases Section III describes the structure and implementation of a generic operational simulation tool for the early design phase of aircraft products Moreover, it outlines how the generic tool is streamlined for specific case studies and how it is embedded into a host of other design tools, creating a sophisticated integrated design loop for aircraft design optimization The remainder of the paper presents two case studies based on real scenarios: The first case study in Section IV demonstrates using the operational simulation tool for decision support for Kent Police authorities: is it worth acquiring Unmanned Aerial Vehicles (UAVs) for their marine unit to improve services and reduce cost? The second case study in Section V uses the operational simulation to improve an existing UAV design and its application for the Port of Rotterdam Authority (PRA) II Operational Modeling Modeling the operations of a product has been used for short-term planning and logistics control since the 1980s when computer power allowed detailed factory floor recreation and real-time data upload [6] However, there are a number of reasons to extend the use of such simulations to product design and go beyond traditional product design tools based on analytical models or simplified, deterministic simulations First, an operational simulation model allows taking into account dynamic interactions of the product Analytical models are inherently static (or, at best, pseudo-dynamic) and cannot account for changes in the environment, the product or operational procedures over time These changes are either neglected or incorporated through complicated analytical functions that must be tailored for each dynamic development individually Dynamic interactions between separate effects are usually neglected Using simulations, these interactions and dynamic changes can be modeled intuitively based on existing knowledge or expert opinion Consider the effect of increasing the wing-span of a UAV designed for crop spraying: The designer wants to increase the wing span to reduce the landing speed on bumpy fields However, a larger wing span leads to more drag during flight which, in turn, causes higher fuel burn If the design burns more fuel, it needs to refuel more often during its crop spraying activity, leading to additional landings and take-offs during its life time This, in turn, requires a sturdier landing gear, adding weight to the design and reducing its operating speed Lower operating speed, on the other hand, reduces the fuel burn, effectively counteracting the effect of a larger wing span Analytical models require enormous sophistication in order to recreate and estimate the impact of such design changes [7] demonstrated a straightforward implementation of this counterintuitive feedback loop using an operational simulation Second, a simulation allows recreating much more realistic models than analytically possible The advantages of an object-oriented simulation package (see below) allow quick and intuitive recreation of real systems using the “bottom-up” modeling approach Here, uncertain or partial knowledge can be added easily Analytically, this would be much harder to achieve as the inherent “top-down” approach requires perfect system knowledge before model building Although each model should always be as simple as possible, this paper argues that added model complexity during the early design phases can benefit the product Third, an operational simulation allows implementing uncertainties for any aspect of the product environment During the early design phases, engineers usually not know how often a new component will fail, how likely it is to crash upon landing or how often the design will fly a specific mission each day Any simulation model can (in theory) be extended with uncertainties at any point in the model and at any time during development While it is possible to include uncertainty in analytical models using stochastic functions and Monte-Carlo simulations, these are limited by the level of detail that the analytical model can reproduce As argued above, a simulation model can usually provide a higher level of detail for the same development effort However, more uncertainty requires more computing power when it comes to evaluating simulation outputs In order to avoid excessive computing power to achieve converging outputs, limiting uncertainties to important inputs is required Fourth, a generic simulation model allows easy change of scenarios If the simulation tool should be used for a different customer, a different design or different product scenarios, the underlying structure and logic remains in place Only inputs (such as mission definition, design definition and environmental parameters) change Analytical models, on the other hand, are often inherently focused on one application type Any small change to the product design or its mission definition may require redesigning major parts of the model Last, an aerospace life-cycle simulation lends itself to be built through Agent-based Modeling & Simulation (ABMS) Recent years have seen the advent of ABMS, allowing a more natural way of modeling the dynamic interactions of entities in a system [8] Here, the aircraft life-cycle environment can be divided into separate agents that act based on perceptions and simple rules Such agents can be the aircraft itself, its components, airports, pilots or even flight routes ABMS supports a “divide & conquer” approach to large complex systems and their interactions by splitting it into manageable bits with well-known characteristics [9] To date, the aerospace industry rarely uses operational simulations during the early design phases for product design Instead, companies often rely on simplified, linear models with coarse mission representation [10] These models cannot employ the benefits of simulation listed above On the other hand, operational simulations have been used extensively during the detailed design phase and beyond Here, sophisticated tools such as STAGE [11] or FLAMES [12] offer highly realistic operational environments, including detailed 6-DoF flight models, detailed mission definitions and advanced sensor models However, these tools require advanced training, extensive data availability and large computer clusters to be useful for design analysis and optimization [13] They are primarily designed for operational support, not for product design Therefore their disadvantages may be acceptable for the detailed design phase but render them unsuitable for the early design phases In summary, there is a need to develop a simulation tool that is simple enough to be used during the early design phases where timing is critical The tool should be computationally cheap to allow quick evaluation of design spaces and competing designs It must be generic enough to be used across a wide array of design concepts found in the early design phases Ideally, an ABMS approach supports creating a complex operational environment through simple agent definitions The next chapter will describe such a tool aiming to improve the early design phase through operational modeling III • Implementation Model structure The operational simulation model presented here is created using AnyLogic © 6.9.1 [14], a multi-method simulation tool supporting agent-based simulation in Java The object-oriented structure of Java lends itself ideally to using ABMS and recreating the aircraft environment [15] Further advantages of object-oriented programming include reusability of objects, easier debugging and simplified code maintenance The simulation model consists of four Java classes, namely Incidents, Stations, Vessels and Vessel Components Each class can have an infinite number of instances with varying characteristics, depending on the scenario definition All objects are connected via a central Geographical Information Systems (GIS) map representing the mission area (see Fig 1) The vessel is the main object in the simulation It acts as an agent because it actively pursues its own agenda based on its environment perceptions This agenda is defined in a state chart mapping perceptions like “I am running out of fuel” into appropriate actions like “I will return home for refuel” A vessel can be of any kind, ranging from animals to cars, ships, helicopters or aircrafts In general, each will follow a given mission profile, taking into account vessel-specific characteristics (cars not fly, aircrafts burn kerosene…) Vessels are characterized by their type, speed and a simple fuel-burn model (where “fuel” can be petrol, diesel but also food or wood) It is possible to extend vessels with more advanced modules as is done below for UAVs featuring a more advanced flight performance model and camera-system model to detect incidents and points-of-interest Each vessel can be made up of an infinite number of components, each an agent itself Each vessel component is characterized through weibull failure distributions, repair details and the likelihood of destroying the vessel upon failure (see Table in Appendix for sample entries for UAVs) One drawback in the current model is that components are independent of each other: A broken wing tip does not deteriorate the performance of the wing Stations are very simple agents that represent home bases for vessel agents They can be airports, fields, harbors, homes or other points of interest Vessels start any mission from stations and return to stations upon completion Incidents are specific agents that are used for one specific mission type only, namely searching for humans If a vessel is assigned such a Search-and-Rescue (SAR) mission, the incident represents the entity to be found It contains a simple survival model reflecting the deteriorating condition of humans in water or in the wilderness It was developed especially for the purpose of assessing SAR UAVs [16] All classes are connected through an agent environment representing the whole world via a GIS map as in Fig Fig GIS map showing SAR incidents (squares) and lifeboat stations (ovals) around southern UK waters Here, vessels, stations and incidents can be viewed together and opened individually for a more detailed view Combining GIS maps with agent-based models is not yet common in Engineering despite advances in other fields such as Geography [17] However, implementing GIS into the early design phase of aerospace products can be advantageous: customers usually know well where and how they intend to use their future product Simple mission simulations often reduce existing mission data to key parameters like “distance” or “duration” However, many aerospace applications are more complicated, featuring loitering, patrolling or search operations GIS maps allow implementing and editing mission data easily without loss in detail To define a wide array of aerospace missions, a generic ontology for aerospace missions was developed [18] It is based on the assumption that any mission can be depicted as a combination of points and paths A database contains the flight profile for each point/path segment such as height, speed and loiter times Moreover, missions can be repeated at intervals, may be conducted by a fleet of vessel agents and feature a priority value • UAVs Initially, the simulation tool was developed for designing UAVs Therefore, the generic vessel class was extended with purpose-build UAV models enabling a more realistic representation of UAV agents (compared to other vessels drawing on the simpler generic vessel model) The UAV used as a basis for the case studies below is a design by the 2Seas team at the University of Southampton and can be seen in Fig Fig 2seas virtual UAV design (left) and assembled after 3D printing (right) Its main design goal was to ensure reliability in the harsh maritime environment of the English Channel This was achieved mainly by employing backup redundant components where possible Amongst others, the aircraft features two engines, four batteries and two autopilots In this simulation, the UAV consists of 60 components that group into 31 component categories such as engines, autopilots or batteries Each category is defined by characteristics to specify its maintenance and failure behavior such as weibull parameters, a robustness scaling factor or the probability to lose the UAV when this component fails inflight and has no redundant components (see Table in the Appendix for an excerpt) i UAV flight model The operational simulation model allows adding individual performance models to any agent In order to assess the case studies, a more realistic flight model was included for the UAV Inputs include a number of parameters describing the aircraft size, aerodynamics and propulsion system The aircraft size parameters include the aircraft dry weight, the wing area and the maximum fuel weight For the drag polar of the aircraft, a parabolic approximation is used in the form C D = k1 + k × C L + k × ( C L ) (1) where CL and CD are the drag and lift coefficient, respectively The k-terms are coefficients that depend on the aircraft configuration (take-off, landing or cruise configuration) Another input is the maximum coefficient of lift It is used to compute the optimal landing speed depending on the aircraft weight (which depends on the fuel on board at the moment of touch down) Propulsion parameters include the maximum continuous available power, the maximum engine rpm, the coefficients of a 4th degree polynomial describing the specific fuel consumption as a function of the engine output power and a 6th degree polynomial describing the propeller efficiency curve as function of the flight speed and rpm At any point in time during a mission, the performance function calculates the fuel burn rate and the remaining range at a given speed and cruise altitude before running out of fuel ii Camera model The main purpose of a UAV is to provide a platform for the payload to operate from The UAV enables sensors to be used in the desired location Hence, the design of the UAV and its operational requirements are highly influenced by the payload parameters Accurately capturing payload performance and its influence on UAV design at an early design stage allows a more effective overall system solution The main purpose of the current UAV is to gather intelligence by the use of cameras to capture imagery of a location of interest This section describes a simplistic camera model that was developed to understand how the parameters within the camera model influence the overall mission performance of a UAV in a given operational environment Digital imaging cameras use a collection of individual detectors to form an image The individual detectors are arranged in a rectangular array known as the focal plane array (FPA) The field of view (FOV) at the focal plane array is the angular view of the focal plane In general, the FOV characteristics are determined by the sensor designers and forwarded as inputs to UAV manufactures For a greater understanding of detector physics and design, the reader is referred to [19] One of the fundamental parameters that govern image quality is Ground Sample Distance (GSD) It is a function of focal lane array, optics, and collection geometry GSD can be calculated using easily understood engineering parameters:  FOVH GSDH = × tan  × PixH   × R  (2) Where GSDH refers to the horizontal GSD, FOVH is the horizontal FOV, PixH are the number of horizontal sensor pixels, and R is the slant range Similarly the vertical GSD can be given as GSDV = × tan ( 0.5 × FOVV × PixH ) ×R cos( θ Look ) (3) where θLook is the look angle Both the look angle and slant range are dependent on the UAV operational parameters such as altitude and velocity (see Fig 3) Fig Ground Sample Distance (GSD) definition [19] The slant range R between the UAV and the object of interest is found by R = h + GR where h is the UAV altitude and GR is the ground range from the UAV to the target (compare Fig 4) (4) Table Deterministic outputs Number of objects spotted Average spotting time (hrs) Boat use time (hrs) Boat fuel used (kg) Scenariocurrent 890 0.92 2,228 333,639 ScenarioUAV See Fig See Fig 946 141,659 From Fig and Table 1, it can be seen that the number of spotted objects increases from 890 to over 3300 by introducing a UAV This is because additional missions (Hythe & Goodwin Sands patrols) are conducted frequently by the UAV The average time to spot an object reduces significantly from almost an hour to just over 15 minutes This reduction is caused by the flight speed of the UAV which is between and times faster than the boat cruise speed The UAV spends about 6.3 hours in the air each day, mainly due to the daily patrol missions The boat cruise time is reduced from 6.1 hours per day in Scenario current to 2.6 hours per day in ScenarioUAV because the UAV takes over the majority of boat missions (specified in Table and Table 6) The total fuel purchased by Kent Police reduces drastically from Scenariocurrent (333 tons) to ScenarioUAV (boat=141 tons plus UAV=2.5 tons) The UAV requires about half an hour of maintenance work each day 11 UAVs are lost during operations and require replacements ii Cost outputs The stochastic simulation outputs were fitted to the most suitable distribution and copied into the value model together with the deterministic outputs A Monte Carlo simulation (100,000 samples) computed cost, benefit and value distributions as shown in Table Note that the last row “Value” is not applicable to the Scenario-categories as it combines the two scenario outputs Table Cost, benefit and value outputs (100,000 observations, all values in $) Scenariocurrent UAV costs Boat costs Benefits Profit Value Mean 207,534 1,113,862 560,395 (151,790) 568,487 (1,265,652) (199,238) Mean = 1,066,227 St.dev 15,227 3,043 15,227 15,295 ScenarioUAV Variance Min 231,879,429 172,782 560,395 9,262,782 560,346 231,890,761 (251,320) 233,951,420 984,089 Median 206,548 560,395 568,883 (198,632) 1,067,180 Max 267,698 560,395 574,721 (159,479) 1,116,674 The overall value distribution of introducing a UAV to Scenariocurrent (last row in Table 2) is shown in Fig Fig Frequency distribution for value of introducing a UAV fleet for Kent Police • Analysis and Discussion The mean value of introducing one UAV to Scenariocurrent for Kent Police is about $ 1.07M with the minimum value just below $ 1M Therefore, the operational simulation and the value model strongly support the acquisition of a UAV to change from Scenariocurrent to ScenarioUAV The value is based on simplistic benefit assumptions of how much it is worth to spot more objects faster However, even neglecting arbitrary benefits, a cost improvement is observed: by changing from Scenariocurrent (cost: $ 1.1M) to ScenarioUAV (total cost: $ 0.56M + $ 0.21M), annual savings of about $ 0.33M can be realized There are several reasons for this clear answer: (a) The setup of the scenarios: In ScenarioUAV, the boat has to conduct 2.3 times less work and burns less fuel to that effect, halving the boat costs from over $ 1.1M to just over $ 0.56M (b) The setup of the benefits: In the value model, there is significant benefit assigned to spotting more objects in less time As the UAV flies faster than the boat can cruise and because the UAV can conduct additional missions with many objects (Hythe & Goodwin Sands patrols), these metrics accrue much monetary benefit for ScenarioUAV (c) Low UAV costs: The cost reduction due to using the boat less often is not offset by the additional cost of using a UAV This is due to the low acquisition cost of a single UAV (about 30 times less than the boat) and its low fuel burn (about 400 times less compared to the boat for the same distance) These value model results are given as an indication of the analysis power of using an operational simulation early on The value model described is very simplistic as it neglects inflation and many cost drivers associated with operating boats and UAVs Moreover, the value model parameters are based on expert judgment rather than analysis The value model outputs were not validated against Kent Police cost information due to the limited accuracy of the model The results are based on a simulation period of one year only Ideally, the whole life-cycle of the UAV would be covered to allow for long-life parts to fail and to include maintenance and repair on the boat as well During one year, it is extremely unlikely to see boat failures so boat maintenance was neglected However, longer simulation periods were not desirable because Kent Police authorities prefer simulation results to match their financial planning periods (3 months or fiscal year) Future work will compare current results to those of a life-cycle period simulation including full boat maintenance and failures Together with net-present value considerations in the value model, this will allow more precise decision support for long-term planning One major limitation of the current approach is the static mission profile specification Mission profile considerations like flight altitude or base station location are not varied as input parameters This optimization is frequently done in military design because mission requirements vary dynamically during the life time of a military product [27] However, in civil applications, mission profiles and requirements are relatively static compared to product life time In general, customers know in advance what kind of missions they plan to use the product for, even during the early design stages Technically, it is possible to include mission specification parameterization to find optimum mission profiles or ideal placement of UAV airports However, Kent Police will introduce UAVs prudently and mission optimization is not required at this stage of the acquisition process V Case Study: Rotterdam harbor design optimization The following case study will demonstrate a different application of an operational simulation for aerospace design As before, it is based on the 2seas research project described above However, this case study presents how the operational simulation can be used to optimize an existing design to meet customer life-cycle specifications A Requirements & goals The Port of Rotterdam Authority (PRA) is responsible for the safe and efficient conduct of operations for the port of Rotterdam in the Netherlands The port is more than 40 kilometers long, covers an area of over 10,500 hectares and mainly handles cargo ships and oil tankers of all sizes In this case study, it is assumed again that the 2Seas project has finished successfully and a working UAV prototype has been designed and tested This prototype, however, is designed for a large variety of missions that were deemed appropriate for the English Channel stakeholders The PRA is committed to purchasing a UAV to improve harbor operations However, managers want to know if the existing 2Seas design is good enough for the challenging harbor environment or if they should purchase an improved design streamlined towards port environment requirements and mission profiles Moreover, managers require a comprehensible investigation into the number of UAVs required for optimal coverage To this respect, the PRA expects to see three benefits of introducing a UAV: (a) increased situational awareness of the port area through continuous patrolling during daylight hours, (b) faster response to incidents within the port area using the Search-and-Rescue (SAR) capability of the UAV, and (c) additional intelligence about ship anchor areas outside the port through regular patrols • Scenario setup For this case study, the PRA provided expected mission profiles for using a UAV in the future There are four missions that the UAV is supposed to conduct: (a) harbor area patrol, (b) regular anchor area monitoring census, (c) irregular anchor area emergency response, and (d) SAR support The geographical distribution can be seen in Fig 10 Harbor patrol Anchor area positions SAR incidents Maasvlakte airfield Fig 10 Rotterdam harbor missions and SAR types Each mission starts and ends at Maasvlakte airfield, a dedicated grass strip at the western edge of the harbor The harbor area patrol is conducted every day between 8am and 6pm The UAV follows a pre-defined loop around the harbor area and loiters above specific places of interest PRA receives live imagery in order to spot possible illegal activity such as small high-speed boats trafficking goods One patrol round takes about 2.5 hours The UAV monitors its fuel status and returns to Maasvlakte for a refuel when required The regular anchor area monitoring census is conducted every 60 days The UAV goes out to every offshore anchor position to report about possible problems Offshore anchor positions are used as parking spaces for arriving ships if the harbor cannot accommodate them Oftentimes, ships dump waste illegally before entering the harbor area and currently, there is no capability to stop this effectively A census flight takes about 6.5 hours as the UAV loiters for a few minutes at every position The irregular anchor area emergency response occurs every 30 days Here, an emergency at one or more of the anchor positions is announced and the UAV is sent out to investigate For operator convenience, the UAV is then sent to all other anchor positions as well, just like in the regular census mission The SAR support comprises six incidents around the wider harbor area that require intelligence support by the UAV As the exact position of the incidents is unknown to PRA, the UAV starts an expanding-square pattern search [28] to find the incidents as soon as possible in order to save their lives Once found, it reports the position and imagery back to PRA for further action and loiters above the incident until it is resolved Note that in this case study, the UAV will conduct missions not currently conducted by PRA (except the SAR incidents) Moreover, PRA is not interested in the added value of introducing UAVs as they are already committed to buying (see case study assumptions above) Therefore, it is not necessary to model the current PRA capability for comparison (as in the previous case study) The simulation period is set to one year to model enough SAR incidents (only about 5-10 incidents happen in the port area each year, in this case study) and to allow for UAV component failures (see Table in Appendix) 100 iterations were required following the simulation stop criterion in Equation On a typical 8-core desktop PC, one iteration took 500 seconds (6500 seconds in total) • Cost model Outputs from the operational simulation are hard to interpret for managers at PRA A simplified cost model was used to convert the raw outputs into a single monetary cost metric that indicated the cost of operating the UAV for the simulation period (as in Fig 12) The model neglects inflation as it spans a period of one year only Stochastic simulation outputs were mapped into the most appropriate distribution and fed into the cost model Here, each output distribution was factorized with appropriate cost parameters, i.e the fuel used was multiplied with the cost per unit fuel, the number of maintenance operations was multiplied with the cost per maintenance shop visit, etc The cost parameters (trapezoid boxes in Fig 12) were based on real data, PRA input and engineering judgment Finally, all costs were added and a Monte Carlo simulation with 100,000 runs created a total cost distribution Moreover, cost metrics and simulation outputs could be analyzed for their relative influence on total costs • Results Table shows some key output metrics from the operational simulation On average, the UAV spends about 10.7 hours in the air each day, mainly due to patrolling the harbor area for 10 hours daily It needs to interrupt a mission for refueling more than once every day The UAV burns 3.5 tons of fuel within a year In that time, the UAV scans a total area of about 13,700 km and produces more than 8,000 GB of raw data SAR incidents are spotted after 90 minutes, on average Maintenance is required every other day for about 1.5 hours The simulation shows that operators lose one UAV every three weeks due to component failure or landing incidents Table Flight time (hrs) # refuels during mission Fuel (kg) Area scanned (km2) Data acquired (GB) Incident waiting time (s) # maintenance jobs maintenance time (s) # UAVs lost Rotterdam harbor metrics (100 iterations) Mean 3,921 388.21 3,370 13,670 8,095 5,331 183 950,454 17.51 St.dev 5.8 2.24 9.6 28.1 22.3 3,489 21 110,749 2.81 Min 3,915 386 3360 13,640 8,071 1,618 137 691,200 10 Max 3,940 396 3401 13,761 8,167 16,740 241 1,218,600 24 1500 1000 500 Frequency 2000 2500 Histogram of myRealData$Data * -1 500000 550000 600000 650000 700000 750000 myRealData$Data * -1 Fig 11 Cost distribution for PRA (in $) Fig 11 shows the expected cost distribution for the PRA based on the simplified cost model Expected costs spread nearly triangular between $ 500,000 and $ 750,000 with the most likely cost around $ 650,000 Fig 12 shows the simplified cost model with the cost parameters (trapezoid boxes) and the operational simulation outputs (square boxes in right column) The costs shown are drawn from an individual Monte Carlo run It can be seen that the strongest cost drivers (lightest box shades) are the number of lost UAVs and the total flight time On the other hand, total cost is relatively insensitive to the amount of fuel used (and the fuel price) and to the data acquired Fig 12 • Simplified cost model (in $) Shaded to indicate cost sensitivity Analysis Base design This section analyzes the results for the initial 2seas UAV design, called the base design below The operational simulation and cost model outputs show that the current 2seas design can be optimized for PRA operations Currently, the UAV has to interrupt almost every mission (except the SAR missions) in order to refuel as its fuel capacity of kg is too small to finish the anchor area and harbor area patrols The anchor area patrols demands an endurance of hours and a fuel capacity of kg Conducting a harbor patrol without refueling would require 10 hours of endurance and a fuel capacity of kg However, the average search operation requires only about hours of endurance and 1kg of fuel Depending on the position of the UAV while running out of fuel, refueling can delay the current mission by up to one hour Therefore, significant service improvement can be achieved by increasing the fuel tank size However, doubling the required fuel tank size requires major re-design of the 2seas UAV This shows the advantage of using an operational simulation during the conceptual and preliminary design phase when design decisions have not been frozen Another major cost driver is the number of lost UAVs (compare Fig 12) More so, losing a 25 kg UAV every three weeks above one of the busiest harbors of the world is not acceptable to PRA (especially since the harbor area comprises oil refineries and other highly dangerous grounds) UAVs are lost due to inflight crashes and landing crashes Inflight crashes occur randomly based upon the reliability of the 2seas UAV components (see Table in Appendix) However, these values are based upon expert judgments since very little information exists about UAV component long term reliabilities Fig 13 shows the six components causing most inflight UAV losses Fig 13 Average number of UAV losses due to component failures Thereby, design work should focus on increasing the reliability of these components to reduce the number of inflight crashes ii First design iteration Following these recommendations, a new improved UAV was designed with an increased fuel tank capacity of kg (to conduct every mission without refuels) Moreover, the reliability of the components in Fig 13 was increased by a factor of 5, mimicking improved component design However, doubling the fuel capacity has major influences on the design of an aircraft Here, the empty weight increased from 20.5 kg to 36 kg, the wing area increased from 1.4 m2 to m2 and the propeller diameter increased from 0.46 to 0.61 meters In other words, the new design grew larger, thereby causing more drag and burning more fuel at the same speed and altitude The outcome of this first design iteration can be seen in Table 4: The number of refuels during missions does not reduce significantly because the larger fuel capacity caused a correspondingly larger fuel burn, effectively keeping the flight endurance constant Table Original and redesigned UAV outputs # refuels during missions Fuel burned (kg) # UAV losses Maintenance (sec/day) 2seas base design First Design iteration 388 3371 17.51 2604 386 4846 70.77 1051 Second Design iteration 3557 13.92 3152 The absolute fuel burn of the first design iteration increases by 43% due to the increase in weight and drag Moreover, the number of UAV losses rises fourfold to over 70 losses (more than UAV lost every week) This was not expected as the first design iteration comprised more reliable components to avoid inflight crashes However, UAVs are also lost at landing due to bumps, turbulences or pilot error The chance of a landing crash rises exponentially with kinetic energy upon landing Design iteration is not only 75% heavier than the base design but also has to land at higher speeds On average, its kinetic energy is twice as high as that of the baseline design Therefore, crashes are much more likely during landing although inflight crashes become rarer Because the first design iteration crashes every week, a replacement UAV with new components is automatically purchased every week These new UAVs not need as much maintenance because their new components fail less often, thereby lowering the maintenance time significantly This exemplifies how intuitive and reasonable design recommendations can lead to unexpected performance degradation The complex interplay of design factors and the environment of the design are beyond analytical capabilities In this case study, a new approach is required to satisfy the customer requirements If it is not possible to design a UAV to fly through missions without refueling, then the mission definition must be scrutinized more closely iii Second design iteration This time, the UAV design will be kept as in the first design iteration, i.e a larger fuel capacity of kg and more reliable critical components However, the anchor area and harbor patrol missions are not flown at the maximum possible speed as before Instead, the UAV flies at the most fuel-economical speed Table compares the results for the second design iteration: The number of refuels during a mission has decreased significantly to almost zero The reason is the increase in flight endurance at economic speed that is well above the duration of any mission Accordingly, the fuel burn has reduced from the first design iteration and is now just above the baseline design The number of crashes has reduced to below the baseline design Of the remaining 14 crashes per year, 13 happen during landing, i.e away from critical and dangerous harbor infrastructure Future designs would require major improvements to landing performance to reduce life-cycle costs further The maintenance time for the second design iteration has increased above the baseline design The reason is that UAVs tend to fly longer before a crash and parts grow older than with the baseline design This is not offset by the increased reliability of the most critical components (see Fig 13) because 26 other components still fail during the flight but not cause fatal damage Fig 14 Cost comparison for design iterations Fig 14 compares the total cost for PRA for operating the different designs for one year The baseline cost is based upon the results from the baseline scenario as in Fig 11 Cost more than doubles for the first design iteration, largely due to the much higher number of lost UAVs that require repurchases The cost for design iteration is just below that of the baseline cost because fewer UAVs are lost The additional fuel and maintenance costs for the second design iteration are not large enough to offset the benefit of losing fewer UAVs Therefore, the second design iteration should be chosen over the baseline design • Discussion This case study showed the advantages of an operational simulation for the early design phase An initial design was found inadequate operationally based upon given mission profiles This finding would be hard to uncover using analytical tools The first design iteration revealed how obvious design improvements can actually degrade the performance of a design based upon its performance and the complex relations with the environment (i.e mission profiles) At this point, a thorough design optimization loop would explore the design space in more detail to find the optimum design for the given goals (reduce cost and keep operations safe) This optimization type is beyond the typical focus on weight, aerodynamics and performance Instead, it would focus on performance that is directly relevant to the customer, i.e cost and safety However, this is beyond the scope of this paper and is explored in more detail in [21] VI Conclusion This research demonstrated the usage of a generic operational simulation tool to support and improve early design phase decisions The simulation structure and functionalities were presented along with a unique mission ontology allowing generic mission generation for almost any aerospace scenario In order to prove the usefulness of the generic model, detailed flight and camera models for UAVs were implemented The model inclusion in a wider integrated software design loop was shown and model inputs and outputs presented Two case studies applied the model in real-world contexts The first case study modeled Kent Police services to ascertain the effects of a potential UAV acquisition It was shown that overall costs can be reduced while service levels increase because UAV operating costs are much lower than current Kent Police costs However, results are based on assumptions and simplifications that must be reviewed by decision makers The model overcomes current limitations in aerospace design where it is not commonly possible to obtain detailed monetary feedback for a design during the early design phase The second case study evaluated the performance of a given UAV design for the Port of Rotterdam (PRA) authority It was found that the design was not optimal for its intended usage and two design iterations improved the overall value for PRA Uniquely, one of the iterations did not change the UAV design but altered the intended UAV usage This demonstrated a unique advantage of operational simulations, namely to quantify the interaction between a design and its environment during the early design phases Appendix Table Conducted by Spring Summer Fall Winter High Risk Margate UAV & Tamar boat 10 Kent police mission repetitions (in days) for the ScenarioUAV Medium Risk Dover UAV & Tamar boat Table Conducted by Spring Summer Fall Winter Diver Patrol Goodwin Sands UAV Never UAV UAV Wind farms (Thanet & Kentish Flats) UAV 28 28 28 28 High Risk Margate Medium Risk Dover Low Risk Dungeness Beach Patrol Hythe Diver Patrol Goodwin Sands Wind farms (Thanet & Kentish Flats) Tamar boat 10 Tamar boat Tamar boat Never Never Never Never Never Never Never Never Tamar boat 28 28 28 28 Repeat every (days) Patrol for (hours) Deterioration mechanism hours Cycles hours hours hours cycles … Rotterdam harbor mission repetitions Harbor patrol 10 Table Engine Battery Propeller Autopilot Payload Flaps … Beach Patrol Hythe Kent police mission repetitions (in days) for Scenariocurrent Table category Low Risk Dungeness Anchor area patrol 60 n/a Anchor area emergency 30 n/a Harbor SAR n/a n/a UAV components specification (excerpt) Weibull eta 10 1 … Weibull beta 1080000 1000 1080000 3600000 3600000 500 … Crash probability if fails 1 1 0.2 … Quantity onboard 2 … Replacement time (s) 10800 1800 1800 3600 3600 7200 … Acknowledgments The authors wish to acknowledge the EPSRC for funding this work with the Doctoral Training Centre grant EP/G03690X/1 The authors are grateful to Simon Hiscock from Kent Police and Reinout Gunst from Port of Rotterdam authority for their input on scenario selection and data supply References [1] Park, J H., and Seo, K.-K., "Incorporating Life-Cycle Cost into Early Product Development," Journal of Engineering Manufacture, Vol 218, 2004, pp 1059–1066 [2] Kirby, M R., and Mavris, D N., "A Method for Technology Selection Based on Benefit Available Schedule and Budget Ressources," Proceedings of the 2000 World Aviation Conference, AIAA, San Diego, Ca, USA, 2000, 2000-01-5563 [3] Raj, P., "Aircraft Design in the 21st Century: Implications for Design Methods," AIAA Journal, 1998 [4] Will, P M., "Simulation and Modeling in Early Concept Design: An Industrial Perspective," Research in Engineering Design, Vol 3, 1991, pp 1–13 doi: 10.1007/BF01580064 [5] Frangopol, D M., and Maute, K., "Life-Cycle Reliability-Based Optimization of Civil and Aerospace Structures," Computers and Structures, Vol 81, 2003, pp 397–410 [6] Andersson, M., and Olsson, G., "A simulation based decision support approach for operational capacity planning in a customer order driven assembly line," Proceedings of the 1998 Winter Simulation Conference, 1998 [7] Schumann, B., Scanlan, J., and Fangohr, H., "Complex Agent Interactions in Operational Simulations for Aerospace Design," Proceedings of the 2012 Winter Simulation Conference, Berlin, Germany, 2012 [8] Macal, C M., and North, M J., "Tutorial on Agent-Based Modelling and Simulation," Journal of Simulation, Vol 4, 2010, pp 151–162 [9] Niedringhaus, W P., "The Jet:Wise Model of National Air Space System Evolution," Simulation, Vol 80, 2004 [10] Krus, P., and Jouannet, C., "Whole Mission Simulation for Aircraft Preliminary Design," AIAA Journal, 2010, pp 1–11 [11] "STAGE," V6.2., Presagis Corporation, Montreal, Canada, 2013 [12] "FLAMES," V11.0.1., Ternion Corporation, Huntsville, Al, USA, 2013 [13] Wilson, D., Allen, N., and Topping, B., "Use of STAGE Modelling to quantify Survivability Effectiveness," Proceedings o the European Survivability Workshop 2008, 2008 [14] "AnyLogic," V6.9.1., The AnyLogic Company, St Petersburg, Russia., 2013 [15] Budd, T., Understanding Object-Oriented Programming with Java, Pearson Education, 2002, p 428 [16] Schumann, B., Scanlan, J., and Takeda, K., "Evaluating Design Decisions in Real-Time Using Operations Modelling," Air Transport and Operations Symposium 2011 (ATOS), Delft University of Technology, Delft, the Netherlands, 2011 [17] Heppenstall, A J., Crooks, A T., See, L M., et al., eds., Agent-Based Models of Geographical Systems, Springer, 2012, p 759 [18] Schumann, B., Scanlan, J., Fangohr, H., et al., "A Generic Unifying Ontology for Civil Unmanned Aerial Vehicle Missions," Aviation Technology, Integration, and Operations (ATIO) Conferences, American Institute of Aeronautics and Astronautics, Indianapolis, In, USA, 2012 [19] Leachtenauer, J C., and Driggers, R G., Surveillance and Reconnaissance Imaging Systems: Modeling and Performance Prediction, Artech House, 2001, p 399 [20] Gundlach, J., Designing Unmanned Aircraft Systems: A Comprehensive Approach, AIAA Education Series, 2012 [21] Ferraro, M., Gorissen, D., Scanlan, J P., et al., "Toward Value-Driven Design of a Small, Low-Cost UAV," 53rd AIAA/ASME/ASCE/AHS/AS Structures, Structural Dynamics and Materials Conference, AIAA, Honolulu, Hawaii, 2012 [22] Gorissen, D., Quaranta, E., Ferraro, M., et al., "A Decision Environment for Complex Design Evaluation," AIAA Journal, 2012 [23] Raymer, D., Aircraft Design: A Conceptual Approach, AIAA Educational Series, 2006 [24] Law, A M., and Kelton, W D., Simulation Modeling and Analysis, McGraw-Hill Higher Eduaction, 1997 [25] "Vanguard Studio," Vanguard Software Corporation, Cary, NC, USA, 2013 [26] Scanlan, J., and Rao, A., "DATUM Project: Cost Estimating Environment for Support of Aerospace Design Decision Making," Journal of Aircraft, Vol 43, July 2006, pp 1022–1028 [27] Cassidy, P F., Gatzke, T D., and Vaporean, C N., "Integrating Synthesis and Simulation for Conceptual Design," Proceedings of the 46th AIAA Aerospace Sciences Meeting and Exhibit, AIAA, Reno, NV, USA, 2008 [28] IAMSAR, "International Aeronautical and Maritime Search and Rescue Manual Volume III," International Maritime Organisation, Albert Embankment, London, SE1 7SR, UK, 2007