Date

18 July 2023

Category

Collaborative Engineering

No comments

RHEA’s experts have been using concurrent design for nearly two decades to accelerate the early phases of complex engineering projects such as space programmes, defence systems, factory design and luxury yachts.

In this blog series, they share their insights into how you can ensure concurrent design sessions are rigorous and the outcomes are high quality.

By Gwendolyn Kolfschoten, Concurrent Design Expert

Catch up with last month’s post: How to manage the interfaces between subsystems

10. How to manage trade-offs and infeasible aspects

In the early design phase of a complex project, many details are still undecided and open. However, in order to validate high-level requirements, we need to get a first impression of both critical performance metrics and key constraints.

Identifying anything that is potentially not feasible, and classifying the risk and uncertainty associated with each one, is an important issue in quality assurance.

Is it a trade-off? Or simply not feasible?

A key objective of a high-level design is to identify those aspects that present a trade-off between requirements – do we optimize for range or speed, for instance? We also need to look for those elements that are technically infeasible, or that cannot meet other constraints, such as budgets.

Being aware of the aspects of the design that will require an innovative solution is also important, because these have an associated risk; if the solution does not fulfil all the requirements, the system may not function, or may perform less well.

Team of people looking down at something on a tableThe earlier we identify these issues, the more time there is to solve them. Any budget for research and innovation is best spent on those issues that increase the feasibility or performance of the design the most; the earlier these aspects are identified, the better.

However, finding the trade-offs also means uncovering areas where the engineers may have to convince the client or user that what they want may not be possible. This is, of course, a difficult discussion, especially when commercial or political interests play a role.

Concurrent design is a rational approach to decision-making; ultimately, technical feasibility is usually very clear – it fits or it does not; it flies or it fails to get off the ground; it sails or it sinks. Therefore, revealing those aspects that are infeasible is about being realistic.

Tips to help identify trade-offs and infeasible aspects

How can we identify these trade-offs and infeasible aspects? These tips may help:

  • Interfaces often are a source of design challenges. Critical interfaces in particular are likely to present some trade-offs.
  • The goal of the design in terms of “What do we optimize this system for?” is not always clear, so make sure this is addressed in one of the first sessions of the study. While some design drivers are obvious, like mass and power usage, others should be deliberated; for instance, is speed more important than endurance?
  • Do a brainstorm to design the ‘system of the future’. The key aspects that the experts improve or make ‘futuristic’ in such a brainstorm will be the most challenging in the current system.
  • Explore previous or competing designs, and find out what the key design challenges were for those projects.
  • Identify where a current/previous system lacks performance, and what key systems contribute to that aspect.

Find out more

In this series of blog posts on concurrent design, we present techniques to improve rigour and quality. These offer a toolbox for concurrent design team leads to support their teams effectively in improving and testing the design. We cover aspects such as how to handle validation when working with rough estimates, how to capture the wisdom of the whole team of experts, and how to keep the team on track and motivated.

Follow RHEA Group on LinkedIn to be alerted to new posts in this series.

Catch up with our previous blog series on 10 Success Factors for Collaborative Design.