Howard Matthers is a mechanical engineer specialising in the design of complex mechanical systems. As part of Think Up’s Royal Academy of Engineering-funded research into the design strategies of engineers from different sectors of industry, I interviewed Howard about the conceptual design of complex mechanical systems, in this case in the context of the design of warships and warship systems.
The questions below are loosely based around a standard set that I have been using with engineers from a range of different disciplines. The answers come from responses provided by Howard and his colleagues to our online questionnaire, supplemented with responses he gave in our face-to-face discussion. (To answer the questions yourself, you can do so on our online form and contribute to our research).
What is being designed?
Howard and his colleagues are involved in all stages in the product delivery process from concept through to validation. A completely different set of challenges exist in post-design of warships, because, firstly, they are not prototyped so it is not unusual to get unexpected emergent properties at whole-ship level, which call for a through-life management solution based on a re-evaluation of the design; and secondly, the range of demands on a warship change through life and therefore major systems changes are often required. The responses here have not focused on these later aspects.
Establishing the brief
In response to what need?
For complex systems, the kick-off period takes the shape of an extended period of evaluation of client aspirations. This involves numerous concepts to test the feasibility of those aspirations within explicit constraints like cost or implicit constraints like physics.
There are usually a multitude of military capabilities embodied in a single ship system. The client is inclined to set a range of broadly stated requirements that need to be evaluated for their feasibility within explicit and implicit constraints. An example of an explicit constraint might be the order of cost or a cost-proxy like the ship size; an implicit example might be maintaining the stability of the ship when capabilities place a heavy demand on the upper deck.
What key information does the brief give you?
A design brief is not necessarily the best way to describe the initiation of the design process. A set of user requirements (outcomes) are often generated out of a dialogue with the client, involving the production of numerous concepts. This process includes trading between the benefits and impacts of different mixes of requirements within the constraints. Emerging from this will be a set of user requirements, which could be seen as the top-level design brief, but in practice, this early concept work will start to provide indicative system solutions, so the start-up process is not as clean as might be thought.
What is the key piece of information that you look for in a brief which is likely to dominate the nature of the outcome? How does this information impact on the design outcome?
We look for direction towards specific product solutions within the overall ship system. This includes: client direction to incorporate a specific product in the design, client appetite to take risk with emerging technology that may only mature during the project timeframe, and the likely set of product solutions available from the supply chain.
What, if anything, is usually missing from a brief that you usually need to go and find out?
The relative importance of different user requirements and the client’s acknowledgement of design constraints. These will become clearer during the early concept reviews described above.
Having received a design brief, what are the first things you go and find out to enable you to do your design work?
The process by which the user requirements and constraints (e.g. safety) will be validated. There is a real sense in which the derivation of the design needs to work backwards from the validation of the requirements to a feasible design, through the traditional “V” model.
Developing ideas
Do new ideas tend to be evolutions of previous designs, or can they be very different?
At whole-ship level, designs tend to be evolutionary, although there are examples of changes that could be said to be revolutionary (e.g. from displacement ships to hydrofoil-carried ships). On the whole though, innovation is introduced at the lower system levels.
A point that both Howard and Paul Holbourn (see my interview with Paul) made is that existing complex mechanical and electrical systems represent the sum of many hundreds of thousands of person hours of development, and so to implement a radically different technology takes such a large amount of work to get it up to the same level of development as the existing approaches that disruptive innovation is rare.
An important factor is the role that the client plays in setting the conditions for innovation, which is manifested in how they prepare the brief. If they put too much focus on the analysis and solution of problems and not enough focus on the synthesis of ideas, then innovation is harder.
When developing an initial response to a brief, what are the key systems that you usually address in your response?
Because the product is required to deliver a range of user requirements, we tend to address its key characteristics rather than the systems.
Are there are a set of ‘go-to’ answers that you regularly turn to for ideas in response to a brief. If so, what are these?
There are probably three sets of go-to answers. The first is to ask what did we do last time? We will have the maximum information on this, and with parametric tools, may be able to use this as a first approximation. The second go-to answer is to ask what public information is there about what other people have been doing? We will have less information about this than on our own work, but it will stimulate ideas. The third place to go is your own research and development programme. To provide a client with confidence in your ability to deliver a new design, you probably have to demonstrate an ongoing programme of design work at concept and full-development level, and this will add to your body of knowledge to draw on.
Can you characterise the dominant uncertainty, in other words, the key feature of any proposed idea that once determined, tends to dictate the other aspects of the design?
Rather than ‘dominant uncertainty’, we’d use the term ‘driving factors’. Each ship is different, and an important part of the early stage of the design process is to determine what are going to be the driving factors. Examples could include weight distribution, or congestion on the upper deck, or the minimum crew size capable of fighting a fire or flood. We sometime use the term “ilities” to describe whole boat characteristics (stability, vulnerability, manoeuvrability, make-ability, etc) which might be a useful expression of several of the likely drivers.
What tends to inspire the ideas you conceive of?
An ongoing programme of concept and design work is important, but so too is team make-up. The right balance of imagination, experience and challenge is important to develop a realistic but exciting set of ideas.
Developing and choosing ideas
When developing an idea, in what format do you first express those ideas?
We express the key characteristics and some form of product visualisation either as drawings, CAD models or, at least for small sub-systems, 3D visualisations.
What are the common sorts of models you need to develop and test an idea?
Because we are talking about a very complex system, which has to work first time without full prototype development, we use a wide variety of modelling. For example, computer/mathematical structural and hydrodynamic modelling, supported by scale models as the number of solutions is narrowed down. Full-scale modelling of machinery systems is undertaken using shore facilities both to demonstrate and refine the designs.
What sorts of models do you need to collaborate with others in interdisciplinary design teams?
The principal tool for collaboration is the design, that needs to be developed using CAD suites that are able to exchange information reliably.
What models do you use for communicating ideas with others?
On the whole the client is likely to have a significant technical capability and able to engage using the outputs of the CAD design model. The client is likely to be interested to witness demonstrations using the other tools and models mentioned above.
What are the most important tests that tend to determine whether or not an idea meets the brief?
Tests of the key characteristics, including the “ilities” (stability, vulnerability, manoeuvrability, make-ability, etc). However, the reality is that issues like the maturity of technology, the set of products that are readily available from our supply chain, the risk appetite of the client and the design organisations, and other things like this, tend to be greater drivers of the early design stages than the intrinsic characteristics like user-interface, number of moving parts, power density etc.
When are bad decisions made in the design of complex mechanical systems?
When they are able to externalise the risks, including where a designer does not have control (and hence responsibility) for a part of the design.
To what extent are key decisions codified?
Design decisions are routinely recorded, and major design decisions, for example the selection of main propulsion machinery, are subject to formal decision conferences, which are recorded.
What is the consequence of making a bad decision in your domain of design?
Anything from re-work o the design and associated project delays to a catastrophe involving multiple loss of life, environmental damage and financial losses.
When carrying out a design in your sector of engineering, what are first the three to five steps you would take?
- Go and talk to people who have done something similar before.
- Prepare a design strategy that implicitly improves understanding of customer requirements, uses iterative methods to converge on an optimal solution, and distributes appropriate design packages according to a coherent work breakdown structure.
- Put someone in charge of weight control from day one, particularly for submarines.