Date
30 March 2022
Category
Blog, Collaborative Engineering, Concurrent Design, Engineering, Media Updates
No commentsRHEA’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. Now, in this blog series, they share 10 key factors that contribute to the success of the approach.
By Gwendolyn Kolfschoten, Concurrent Design Expert
5. Take an Iterative Approach
Concurrent design supports (technically) complex problems. To approach these problems logically and productively, it is important to regularly zoom in to look at specific subsystems and then zoom back out again. This is a cyclical process, with the team focussing on a key subsystem in each iteration and then assessing how any changes will impact the overall system.
When this happens, domain experts are invited to explain the key design choices they propose for their specific subsystem. The team then studies the impact of those choices on the overall system, including the interfaces between the subsystems – this is a critical step.
During this process, we identify important interdependencies: that is, aspects where (sub)systems are affected by other (sub)systems. This approach reveals different angles, letting the team view the outcomes both from the perspective of the various subsystems and those aspects that run through the entire system.
Through these cycles, we work the solution out in more detail and the design gets more comprehensive. The initial requirements and the designed solution start to ‘grow towards’ each other, closing the gap between them. Furthermore, the ‘chain reactions’ in the system – the interdependencies that have the most impact on the whole – are revealed and better understood.
The iteration process
An iteration starts with a short presentation from a ‘driver’ – the domain expert on the topic – that includes a clear proposal to enhance or improve the design. Ideally this includes a visual explanation of the solution, as well as quantification of the impact on key parameters of the design.
Next, all key domain experts are asked to reflect on the proposal, give feedback, identify risks and issues, and explore any interactions with their own subsystems. These discussions offer valuable insights into the challenges in the design and ensure that proposed changes are well analyzed from all angles. In this way, we make sure that we are optimizing the entire system and not just for the proposed change or a specific subsystem in isolation.
After each presentation it is important to synthesize the results. This means that after zooming in on a subsystem or aspect of the system, we zoom back out to assess the impact on the system as a whole. In studies where we use COMET™, we do this by revising system-level ‘budget’ reports. Budget reports are overviews in which the performance of the overall system is compared with the requirements. Examples are the mass budget (is the system too heavy?), the power budget (does the system need more power than the engine can generate or the battery can supply?) and the cost budget (is the system within budget?).
When the study is not driven by a quantitative model – for instance when the objective is to create a lifecycle plan that ensures high availability of a system – we still need to ensure the results are assessed in terms of the impact of any proposal on the overall system performance. (In this case, an example would be the impact of the maintenance strategy for parts on the availability of the overall system.)
Topic iterations have value
Often a design challenge that has been identified will require an iteration. The driver will present the solution and then the team has a discussion that leads to new insights and a revision of the proposed solution.
When the domain expert has worked out this revision, it is important that they present the resulting iteration to the team. Often this does not need to be a complete presentation, but instead it may be an update on open issues and revisions, with time for questions and answers to review the improvement.
Document everything
To ensure design decisions are rigorous, it is critical that both each iteration and the risks and concerns identified by different domain experts are well documented. COMET is ideal for this as it allows the team to save iterations of the design and mark specific stages in it, and then circle back to them later on as needed.
Our tips
- Zoom in and out regularly to explore the impact of subsystem changes on the overall system.
- Ensure iterations are revised by the entire team.
- Document iterations to mark specific stages of the design.
