When using computational methods to underpin the design of any reasonably complex system, a bewildering array of potential software tools presents itself. These span everything from the computer aided design (CAD) tools that are used to define the geometry to be manufactured through a range of analysis codes to support computational fluid dynamics (CFD) or computational structural mechanics (CSM) calculations to simple spreadsheets where overall sizing and performance calculations can be made. If a modern approach is also taken to the management of knowledge and decision making, a further range of somewhat less familiar tools must be considered, such as databases and optimizers. Almost inevitably, it will not be clear which are the best ones to choose for the project at hand, and, moreover, the range of tools available will grow and change throughout the design process; the work at Southampton has been no different in this respect from any other design project. We can, however, set out a few main principles that have guided our choices:
- 1. Where possible, we have opted for tools that are either freely available on the Web or are low cost or are almost ubiquitous in their availability. This has not always been possible, but if a relatively expensive commercial tool has been adopted, it has had to provide a clear and convincing benefit.
- 2. We have aimed to build systems that are not locked too tightly into any given tool choice, since one never knows when there will be compelling reasons for a change of tool.
- 3. We have opted to use the Microsoft Windows operating system as the background to our work since it is almost the de facto standard in most technical organizations these days; this extends even to the large numerical clusters we have used to support CFD calculations (note, however, that many of the tools we have used are available for other operating systems).
- 4. Since we are fundamentally academics interested in the design process, consideration of the design system itself and the value any tool brings to it is of just as great an importance to us as the resulting designs being produced, the raison d’etre of the DECODE project, for instance, being to investigate the interplay between design tools, designers, and the resulting designs.
Small Unmanned Fixed-wing Aircraft Design: A Practical Approach, First Edition. Andrew J. Keane, Andras Sobester and James P. Scanlan.
©2017 John Wiley & Sons Ltd. Published 2017 by John Wiley & Sons Ltd.
It is useful when considering tool choice to sketch out what we term the “design workflow”: that is, the sequence of steps and tasks that designers must undertake when moving from initial design goals to a product or series of products to meet those goals. This is rather different from the design spiral introduced in Chapter 1: here we are interested in data and knowledge flows between tools rather than the iterative consideration of disciplines as a design becomes more refined. Figure 9.1 sets out this workflow in an abstract sense without reference to particular methods; it essentially deals with the questions “why?,” “how?,” “what?,” and “what if?”. These map onto a series of tasks that must be tackled and justified so that a balanced design can be achieved. Note that “why?” relates to issues of design rationale and supports “how?,” which deals with the process of turning rationale into possible geometry. “What?” describes the current designs being compared, and “what if?” is supported by making changes to these designs so that consequent performance variations can be assessed. The overall aim is, of course, to gradually evolve and detail a design description suitable for manufacture that will deliver high-value products, with value being taken in a very broad sense to encompass monetary and mission performance issues through the life of the products being designed and the mission under consideration. This is the role of “design search” in Figure 9.1. Fleet mix and characteristics are a mixture of information relating to the tasks at hand and the way possible assets are used to address them. They are thus not really concerned with “what” the air vehicles are, as opposed to the use they are put to. Here we treat these aspects as part of the mission planning and value assessment tools. These various functions and the possible tool choices to support each are next considered in turn. Figure 9.2 shows how this workflow can be mapped onto a range of analysis domains and tasks along with possible tool choices.