The Spacecraft Design Process

How is this methodology of spacecraft design played out in an industrial setting? The process is very people-intensive, and as such some might observe that it is not quite as objective as you might expect, particularly in the early stages when feasibility and preliminary design issues are addressed. However, we will come back to this perhaps slightly contentious statement later. It is important to set the design method that we have discussed so far in the context of the overall spacecraft development. Spacecraft project activities are traditionally divided into a number of phases, as listed in Table 7.2, taking us from preliminary design through to orbital operations.

Most of what we have said so far falls into phase A, preliminary design, and we do not get much beyond that phase in this book. To get a feeling for how this part of the design is done in a real spacecraft project situation, let's suppose that a company has landed a contract for the phase A study for a particular spacecraft. The process of preliminary spacecraft design that takes place in this phase is sometimes referred to as spacecraft system engineering. Definitions of what this means vary, but one possibility is along the lines of "The science of developing an operable spacecraft capable of meeting the mission objectives efficiently, within imposed constraints, such as mass, cost, and schedule.'' This sounds complicated, but the main job is to design the spacecraft as a collection of subsystems in such a way that, when

Table 7.2 The design and development phases of a spacecraft project


Duration Activities

Preliminary design and feasibility

Detailed design

Development, manufacture, integration, and test

Flight operations

6 to 12 Creation of a preliminary spacecraft design, and months project plan in terms of schedule and cost; the identification of the key technology areas that may threaten feasibility

12 to 18 Conversion of the preliminary design into a months baseline technical solution, including detailed system and subsystem designs; development of a detailed program for subsequent phases

3 to 5 Development and manufacture of flight years hardware; integration of spacecraft, and extensive ground testing

Orbital Delivery of spacecraft to launch site; launch lifetime campaign; early orbit operations; mission orbit operations; end-of-life disposal from mission orbit

Note: The phase A to D durations are estimates, and vary according to the type of spacecraft.

they are integrated, they produce a total spacecraft design that can efficiently (or even optimally) achieve the objectives of the mission.

Space system engineering is a discipline that differs from spacecraft system engineering. One of the key issues about any kind of system engineering is where you draw the boundary. The focus of this book is concerned with the design of the spacecraft itself (although we do briefly get into launch systems), so we draw a boundary around the spacecraft and focus on it as the system. Space system engineering, on the other hand, draws a wider boundary, not only around the spacecraft but also around all the other parts of the project, such as the ground stations involved in operating the spacecraft and receiving its data. The following discussion does not address these other parts, focusing firmly on the spacecraft.

Returning to the process of spacecraft system engineering, the means of doing this involves forming a design team or committee composed of subsystem engineers, usually with a system engineer as the team leader or chairperson. Each of the spacecraft's subsystems is represented by one or more engineers who are experts in that particular part of the spacecraft. The team leader does not have the same depth of knowledge in any particular subsystem as the team members, but as a system engineer he or she has a breadth of knowledge across the whole system to help in the integration of the overall design.

The traditional method of progressing the design involves lots of off-line analysis and design work by the subsystem engineers, punctuated by numerous meetings of the design team, in which results are discussed and designs are progressed and integrated (it seems odd to be talking about "traditional" methods in spacecraft design, but it is justified by the fact that the space age is half a century old now). This latter aspect is very important. Clearly, each subsystem specialist could work in isolation to produce the most wonderful design solution for his or her own particular corner of the spacecraft. But if it does not integrate with everyone else's subsystem designs, then it is effectively useless.

The team members soon realize that this is design by committee, and that compromise is required by everyone to achieve success at the end of the day, in terms of an integrated spacecraft design. My earlier comment about the objectivity of the process is relevant here. Given how people-intensive it is, spacecraft system engineering could be redefined as the science (and art) of developing an operable spacecraft. This work can be a bit of an art form at times, as the outcomes are governed by the dynamics of the team and the interaction among its members. The subsystem specialists have to accept that their own designs will be influenced and modified (perhaps not to their liking!) by inputs from other subsystem or payload specialists.

The other important aspect of this design process is that it is iterative. The design team will arrive at an initial design for the spacecraft, but the review of the design will point to areas of the design that can be improved upon considerably, or that may be problematic. The design process is then reviewed—iterated—to overcome these issues in a new design. But the new design may have problems too, and so the process continues until it converges in an acceptable final design.

Over the past decade or so, this traditional method has been transformed by the introduction of computer technology into the process. The basic underlying structure of the design team is still there, but now the team is collocated for the duration of the phase A study in a purpose built design studio equipped with computer work stations. It looks like a miniature version of mission control! Figure 7.2 shows a plan view of such a facility at ESTEC (the European Space Agency's technical head quarters in the Netherlands). Each of the workstations is dedicated to the design of a particular spacecraft subsystem, and as such is loaded with appropriate software to allow operators to do whatever analysis they need to do to

Figure 7.2: A schematic of the computer workstation layout of the European Space Agency's concurrent engineering design facility at ESTEC in the Netherlands. The development of the facility began in 1998. (Backdrop image courtesy of European Space Agency [ESA].)

develop the design. The subsystem engineers comprising the team are now seated at the workstations; for example, the mission analyst sits at the mission analysis workstation, the power engineer at the power workstation, and so on, with the team leader controlling the process from his or her own workstation. The technique is called concurrent engineering design (CED), and is being used not just in the space industry but across a broad range of industries involved in the design of complex machines, such as automobiles and airplanes.

At the heart of the process is a central computer database that holds the current design of the spacecraft in memory. Every time team members update the design of their subsystem, the update is relayed to the central database. The details of this change are then available immediately to the other team members, and the impact of the change on the design of the other subsystems can be assessed quickly. The main benefits of this technique are the speeding-up of the process of design iteration that we mentioned above, and an improvement in the process of design integration. The use of CED has typically shortened the time it takes to perform a phase A study of a spacecraft from 6 months or more to 1 or 2 months. However, the introduction of computers into the process has not replaced the need for excellent subsystem engineers as design team members. They are still vital in the CED facility to check that the computer output makes sense, and to guide the process to a successful conclusion.

Was this article helpful?

+2 0

Post a comment