Concurrent Engineering Applied on Mission Architecture Evolution

Kurzfassung

The Concurrent Engineering (CE) process is a means to tackle the design of systems which are complex regarding interdependencies of their sub-parts, have long development cycles and require expertise from several knowledge domains. In that way the CE-process has been used by the German Aerospace Center (DLR) in its Concurrent Engineering Facility (CEF) for more than 30 spacecraft design activities. These kinds of systems however are always part of a mission architecture that strongly influences their design and capabilities as well as their requirements. Therefore the layout of mission architectures is an important step in spacecraft design. Just as the spacecraft itself the mission architecture can be very complex and have many interdependencies of various aspects, e.g. a launcher’s payload capability for a mission strongly influences how many launches are required for a given launcher type. This in turn influences the launch strategy, launch windows, operations effort and costs. Consequently DLR has used the CEF for the design and evaluation of various mission architectures, e.g. for a crewed asteroid mission, a network of asteroid landers for solar observations and space debris mitigation, adapting the process for making trade-offs within the group regarding architecture options with various tools, e.g. mind-maps. In this paper it is explained how the process diverts from the original method as applied for spacecraft design, e.g. that the spacecraft is now only a component of the design space. We show how the design team identifies, trades and weights the various options for a mission architecture - by first collecting various alternatives and subsequently identifying the strengths and weaknesses of each option. In the end – e.g. with the help of a tree-like structure – a decision on the architecture can be made based on these strengths and weaknesses. The paper explains the tools used and the advantages of the CE approach in designing and evolving a given mission architecture. We further elaborate how requirements for the various mission components, e.g. the launcher, are derived. The paper concludes with the lessons learned from the process adaption.