ArticlePDF Available

Abstract and Figures

The article describes a model for satellite systems preliminary design based on European Space Agency concurrent design approach. Space systems preliminary design aspects based on a concurrent engineering methodology are first briefly illustrated. A general description of a typical space system and its subsystems is provided and sizing criteria are provided for each subsystem. The design procedure is formalized according to Unified Modeling Language formalism. A description of the implementation of the model and some conclusive remarks are then included.
Content may be subject to copyright.
CONCURRENT ENGINEERING: Research and Applications
A Model for Preliminary Design Procedures of Satellite Systems
Davide Di Domizio and Paolo Gaudenzi*
`di Roma La Sapienza, Dipartimento di Ingegneria Aerospaziale e Astronautica
Via Eudossiana 18, 00184 Rome, Italy
Abstract: The article describes a model for satellite systems preliminary design based on European Space Agency concurrent design
approach. Space systems preliminary design aspects based on a concurrent engineering methodology are first briefly illustrated. A general
description of a typical space system and its subsystems is provided and sizing criteria are provided for each subsystem. The design procedure
is formalized according to Unified Modeling Language formalism. A description of the implementation of the model and some conclusive
remarks are then included.
Key Words: Space systems, space sub-systems, concurrent design, system engineering, design procedures.
1. Introduction
Since 1998, the European Space Agency (ESA) has
been developing preliminary studies for new space
missions using the Concurrent Design Facility (CDF)
as described in Bandecchi et al. [1, p. 1,2; 2, p. 1–3].
Concurrent Design (CD) is a methodology that allows
the parallel design of several subsystems, managing their
mutual interactions, which are then assembled to form
an engineering system. The use of this methodology is
particularly useful in aerospace engineering, where the
design is challenged by the presence of very complex
engineering systems. ESA has adopted this methodology
for the early stage of the design of space systems,
following the example of other space agencies, like
NASA, and aims to promote the use of this approach,
also for more advanced design phases, in the frame of
the European Space Industry.
The success of this approach is witnessed by the great
reduction of the time needed to produce reports for
preliminary analyses of very complex missions – like
science or exploration missions – keeping or improving
the high level of design and the quality of studies and
even facilitating the communications between designers
and customers. In ESA, the duration of a pre-Phase A
analysis is now between 3 and 6 weeks against 6–9
months about 10 years ago.
In the context of space engineering the adoption of
CD approaches generated a series of advantages: time
savings, reduced errors in sizing, better cost prediction,
and a better compliance to mission requirements;
however, the performances of the CDF are the most
interesting aspect. The success of CDF approach dwells
in the cutback of the time to produce a pre-Phase A
study. The space system is divided into several
subsystems assigned to specialized engineering units
which manage the design of each part; obviously the
design of each subsystem is strictly correlated with the
others: an information flux is necessary. In these
preliminary phases, each subsystem can be characterized
by a series of ‘design parameter’, which describe its most
relevant physical and technical properties. Design
parameters are the information exchanged during CDF
session among engineering units.
This design approach requires hardware and software
resources, as implemented by ESA in the CDF releases
in the European Space Research and Technology
Centre, but before that a clear description of the
system and of the sizing and dimensioning criteria has
to be adopted for the overall system, for the payload,
and for each bus subsystem. Since the design develops in
a concurrent framework, all the interactions among
subsystems are required to be well documented too. An
effective data modeling will produce clear interactions
during the design phases and an easier and more
efficient exchange of information [3, p. 2000], solving
the problems encountered in data transfer among
different areas, as already discussed in [4]. In addition,
it furnishes a successful and tested answer to meta-data
description as requested in [5], improving team coordi-
nation in contexts where a different framework is
already applied [6].
The aim of the present article is to describe the model
for satellite systems preliminary design developed at
´di Roma La Sapienza in the frame of the
professional Master Course in satellites and based on
*Author to whom correspondence should be addressed.
Figures 1–7 appear in color online:
Volume 16 Number 2 June 2008 149
1063-293X/08/02 0149–11 $10.00/0 DOI: 10.1177/1063293X08092488
ßSAGE Publications 2008
Los Angeles, London, New Delhi and Singapore
ESA concurrent design approach. The study is focused
on radar Earth Observation missions. In fact there is the
need to focus on a certain class of satellite systems with
well-defined requirements to obtain a formal complete
description of the model for preliminary design.
However, this has not to be considered as a limitation
to the generality of the present work illustrated which is
focused on the procedure followed during the design.
Therefore, a general description of the design and of the
design variables is provided along with their mutual
interactions in the dimensioning and sizing schemes
provided for each subsystem and implemented accord-
ing to Unified Modeling Language (UML) formalism.
In the following paragraphs all the steps followed to
accomplish the design are described. First of all, the
common approach to space systems design is briefly
illustrated, followed by a slight description of the case
study use as reference in this work. A concise explana-
tion of the instruments used to document the design
procedure is then provided. The section entitled
‘Modelling the design procedure with UML diagrams’
represents the core of the present effort: each diagram
produced in the design phase is shown and described. A
description of the implementation of the model and
some conclusive remarks are then included.
2. The Pre-Phase A Design Process
of a Satellite System
A space mission can be described in terms of space,
ground and launch segment [7]. The space segment (the
spacecraft) consists of a payload and a bus, composed
by several subsystems. Payload is the set of instruments
used to meet the objective of the mission: observing the
Earth, broadcasting communications, or analyze the
atmosphere. The bus has several aims concerning with
the functionality, operating survival, and the efficiency
of the payload in the space environmental conditions.
Ground segment must interact from ground with the
spacecraft both for the payload and for the bus purposes
and is responsible of actions like:
.Receiving and analyzing the telemetries of the space-
craft to monitor its operating status
.Send commands to the spacecraft when needed
.Receive payload data transmitted from the spacecraft
or, conversely, transmit data to the spacecraft pay-
The ground segment also operates during the launch
phase, a very critical phase of the spacecraft life.
The activities of the launch segment are related to the
phases of a space mission that safely takes the spacecraft
from the earth surface to the final orbit. The space
transportation system is very complex and comprehends
both the launch vehicle and the launch basis, connected
with the ground segment.
The procedure proposed in this work is focused on the
preliminary design of the space segment.
During the first stage of the process of spacecraft
design, mission team analyzes mission requirements and
produces system and payload constraints for system and
payload specialists. These requirements regard the choice
of orbit properties, the lifetime, operations, and the main
features of the instruments (e.g., resolution or revisiting
time in earth observation or link budget in communica-
tion). Clearly, this first step establishes a series of
requirements and goals to be met for the payload and
also sets the operational conditions to be performed by
the bus, to allow the mission to be performed in an
effective way.
A very synthetic description for the classes of functions
to be performed by the bus can be illustrated as follows:
.Support the payload mass and all the masses onboard
the spacecraft
.Provide the propulsion needed for orbital man-
oeuvres and corrections
.Provide attitude control to the spacecraft and point
the payload correctly
.Keep the payload (and the entire spacecraft) at the
proper temperature conditions
.Provide electric power
.Provide on board data storage and elaboration
.Establish a link to ground for transmitting telemetry
and receiving commands
It is usual in space system engineering to associate these
functions to one subsystem of the spacecraft [7]. A typical
list of subsystems can be defined as follows: payload,
Attitude and Orbital control (AOCS), structure, propul-
sion, data handling, thermal, power, Telemetry Tracking
and Command (TT&C). In general, each subsystem is
designed by an engineering unit composed by skilled
staffs. A system engineering unit should also be
considered with the aim of coordinating all the others,
managing the system budgets (e.g., mass, power, link)
and respecting the constraints that derive both directly
from the requirements or from the mission analysis.
Each engineering unit, corresponding to a subsystem,
the payload, or the system itself, has to follow simple
sizing rules relevant to a specific discipline. In this effort,
optimal values for the design parameter are obtained
thanks to basic trade off criteria that most of the time
optimize the required performance with respect to
weight, power, and link budget.
All the engineering units of the list proposed above –
also including one Mission unit that is responsible for
the characteristics of the mission to be realized – are the
main players of the design phases. Each unit aims to
design a subsystem, characterizing it by a series of
design parameters: factors describing a specific feature of
the unit. At the end of the design process a specific value
will be assigned to all design parameters. Examples for
design parameters are the following.
.System: Dry mass of the spacecraft, Mass of each
subsystem, etc.
.Payload: Band of the Synthetic Aperture Radar (SAR)
Antenna, Digital data rate of acquired data, etc.
.Structure: Structural mass, Body height, etc.
Some parameters belong entirely to a single subsystem
and are used only for internal evaluations of subsystem
design; other design parameters, since a concurrent logic
is assumed, are typically exchanged among subsystems:
the computations of one subsystem are the input for the
analysis of features of another one. (e.g., The design
parameter digital data rate produced by payload is an
input for data handling which has the aim to store data
coming from payload).
The present model of satellite design aims to describe
the interaction among the design units and allows a
contextual evaluation of the effects that a change of a
parameter adopted in a single subsystem could produce
in another one. As an example, if the number or
locations of batteries are modified, then the structural
system needs to update its structural loading require-
ments while AOCS has to verify the new centre of
gravity position and the new inertial rigid body
characteristics. Moreover, for both units, a new value
for the design parameters (and relevant geometries,
material, component) could be necessary. The number
of the design parameters, limited at a preliminary phase
of the project, is assumed to grow along with the level of
detail of the project.
As stated in ECSS publications
[8], from the Mission
analysis (Phase 0) to Feasibility (Phase A) there are
different aims to be satisfied, therefore there is a
requirement for more details that is directly translated
in a higher number of design parameters. The increasing
need for more detail is also characteristic in the next two
phases (B and C): preliminary definition and detailed
definition. In the present article the application of the
CD approach is limited to the first two phases (pre-
Phase A study); however, the procedure described in this
article could be valid to describe the relations among the
components of a single subsystem when the design has
entered more specific stages.
In the present work, the design procedure described
before is implemented for to the pre-Phase A design of
a spacecraft and applied to the specific space
mission proposed in the next paragraph. At this
preliminary design level it is important to choose the
set of design parameters that, at the same time, are
limited in number but effective in describing the system
at the level of detail needed.
In the modeling effort, a special role is to be assigned
to a database of components, where the information
collected are the basis for giving a precise value to many
design parameters. The efforts in design strategies
developed by subsystem designer can have a real
confirmation only from the support coming from the
properties of existing components. Each designer has
access to a database of components relevant for the
topics that his subsystem deals with. Each of these
databases is based on the following information:
company, component type, performance, dimensions,
and operational constraints.
3. Modeling Assumptions and Criteria
3.1 Case of Study and Design Strategy
Although the logic and the modeling procedure could
be made very general, in this article an application is
presented nearby the design procedure itself. The general
method has been applied to the design of an Earth
Observation Radar satellite. This system is a suitable
architecture for a SAR remote sensing satellite mission,
to be operated in a Sun synchronous orbit. The orbit
requested was Sun Synchronous at 619 km and 97.878.
Table 1 [9, p. iii] summarizes the main requirements
of the mission – the focus of design example. The design
methodology takes advantage of teamwork activities
performed during the editions of Master Course in
Satellites of the Universita
`di Roma La Sapienza.
Although the choices made during this example are
very specific and lead to a precise design output, the
logic and the modeling procedure could be considered as
very general. Specifically, the Earth Observation (EO)
space system has the aim to retrieve images and send
them to the users following the requirements stated
above, but while the design phase of each subsystem is
oriented to achieve this aim, the design procedure is
quite independent from the actual system, and could be
generalized to other type of missions.
As described previously, the satellite in the example is
divided in to several units and a specific engineering unit
is assumed to be present. The complete list of units is:
mission, system, payload, structure and configuration,
power, AOCS, propulsion, thermal, TT&C, data hand-
ling, payload-data handling, and transmission.
The strategy that is followed during the various
phases of the preliminary design is managed by the
ECSS (European Cooperation for Space Standardization) Standards documents are intended to be applied together for the management, engineering and product
assurance in space projects and applications. ECSS is a cooperative effort of the European Space Agency, National Space Agencies, and European industry associations
for the purpose of developing and maintaining common standards.
Model for Preliminary Design Procedures of Satellite Systems 151
system designer that has the principal aim to respect the
requirement on the driving budgets.
Therefore, budgets are the summary descriptors of the
entire system and usually can consist of mass, power,
telemetry, propellant, pointing, or reliability budget.
Mass budget is the most effective driving budget, because
it directly influences the mission costs and is the one that
influenced the example presented in this article. During
the steps of the analysis, the system designer controls the
mass values and the mass evolution of the entire system
and of each subsystem. The design is assumed to be
compliant with the requirements on mass budget when
system and subsystems mass are stable and further
iteration steps will not modify their values. In the case
study, a name was assigned to a possible satellite
complying with mission requirements: FINGERSAT
(First Idea of a New Generation Earth observation
Remote sensing Satellite).
3.2 UML Methodology and Diagrams
The documentation of the design procedure is a
necessary support to the analysis describing the interac-
tions between subsystems and the activities performed by
designer during the design sessions. This documentation
uses UML formalism, implementing static, collaboration
and activity diagrams [10,11]. In this article, UML dia-
grams are then used to describe the Concurrent Design
approach to the preliminary analysis of a spacecraft.
A class diagram describes the types of objects
in the
system and the various kinds of static relationships that
exist among them. Class diagrams typically show the
properties (attributes) and operations (methods) of a
class and the constraints that apply to the way objects
are connected (associations). The relationships among
classes may be of several types: generalization, aggrega-
tion, composition and generic associations.
In the next paragraph, each subsystem is documented
by a specific class diagram and occasionally some
functions are detailed by activity diagrams, while the
interactions among subsystems are depicted in colla-
boration diagrams. The structure of class diagrams is
fixed in this work. The central part of the diagram
contains a class representing the subsystem that is
intended to be described (payload in Figure 3). This is
the general part of the subsystem; it may have some
attributes and methods. Below this main class there are
several other classes that are linked to it with associa-
tions one-to-one. These classes, named with the stereo-
type ‘data exchange’
represent the part of the subsystem
that exchanges values with other subsystems – the
interface to other subsystems. Each main class may have
several ‘data exchange’ classes, one for each subsystem
that has to exchange data with (I.E. ‘Payload_Power’
interface class contains attributes that payload shares
with power subsystem and methods that permits pay-
load to evaluate these attributes – Figure 3).
A collaboration diagram (Figure 6) is a special class
diagram that shows what happens to the objects when
they are instantiated.
The links between entities repre-
sent messages, data, or actions exchanged among them.
Activity diagrams are a technique to describe proce-
dural logic, business process, and work flow. In many
ways, they play a role similar to flowcharts, but the
principal difference between them and flowchart notation
is that they support parallel actions.
4. Modeling the Design Procedure
with UML Diagrams
In this paragraph, the most relevant diagrams of the
design procedure are shown: their structure and organi-
zation are a feature of the procedure while the data
contained depends on the example mission considered in
this work.
All class diagrams are presented: one for each
subsystem. This set gives a complete description of the
‘A budget is a numerical list of the components of any overall system parameter. Thus, the total spacecraft weight budget would consist of the weights assigned to the
payload instruments, the various subsystems, the propellant required, and typically some margin for growth’ (4, paragraph 10.3).
Objects and classes are part of the common idiom used in OO-design, it can be easily translated to other fields of applications: in the Figure 1 the class ‘Payload
Component’ is though as the classifier for all the components of the payload (objects): antennas, RF components, cables, etc.
A stereotype is a further description of a particular set of classes.
In the present case, the instantiation of a class occurs during the CDF session when the data are really exchanged among subsystems.
Table 1. Mission Requirements for the required satellite system.
Description Values Description Values
Min observation angle 208Bus voltage min/max 23/38 V
Max observation angle 508PDHT downlink frequency 8.1 GHz
Ground resolution 3 m Pointing accuracy 0.00288
Image mode STRIPMAP TT&C uplink frequency 2050 MHz
SAR frequency 9.65 GHz Downlink data rate 155 Mbps
Minimum swath 40 Km SAR duty cycle 10%
Min no. images per day 450 Operative life 5 years
Polarization HH,VV,HV,VH Revisit time Day
CPU architecture Integrated Operative autonomy 24 h
static view of the entire system. Two examples of
dynamic diagram are reported.
A collaboration diagram describes the sequence of the
activities and the involved subsystem of the data handling
engineering unit. An activity diagram depicts the detailed
procedure used by payload data handling and transmis-
sion for mass memory sizing.
The dynamic diagrams presented work at a different
level: the collaboration one is an inter - subsystem
document diagram, while the activity diagram is an intra -
subsystem diagram.
4.1 Mission
The mission analysis engineering unit represents the
part of the system that make the first analysis and
translates the system requirements, shown in Table 1, in
specific requirements for each subsystems. Therefore, in
this diagram (Figure 1) there are not input labels
because Missions generates only outputs and basically
is not receiving inputs from other units.
4.2 System
The diagram that describes the activities of system
designer is quite composite as it has to show the intera-
ctions with all the other subsystems (Figure 2).
Therefore, the principal feature of this diagram is the
presence of interfaces with all other subsystems. The
common data that all subsystems exchange with the
system designer is the mass budget. The system designer
gives a mass budget to each subsystem, the latter has to
develop the design respecting this constraint, and at the
end of each CD step, gives the results to system designer
in terms of mass budget and eventually mass margin.
Another common datum that system engineering unit
receives from all subsystems is estimated the estimated
power need.
Besides, there are more specific data that characterize
the interaction with other subsystems. In this
domain, system gives to payload engineering unit
information on pointing accuracy and on the range of
power that can be furnished, while it passes to structure
basic mass properties; it gives to data handling
information on ground station and on the telemetry
budget, to TT&C the requirements on error rates, and to
propulsion the data on propellant mass. Power engi-
neering unit receives from system the requirements on
bus properties while AOCS gets some pointing require-
ments. Finally, thermal needs specific values of dis-
sipated power on the various operating modes of the
The inputs to system are essentially mass budgets data
except for mission that gives some information on the
launcher and the chosen ground stations. Other more
specific properties are given by other subsystems, as
reported in Figure 4.
4.3 Payload
The payload engineering unit receives inputs from
mission (orbital parameters, requirements on the EO
mission) and from system (Budgets and pointing
This special kind of subsystem has some character-
istics (the name of the apparatus and redundancy
Figure 1. Mission class diagram.
Model for Preliminary Design Procedures of Satellite Systems 153
concept) and there are many functions developed to
evaluate some instruments features (Figure 3).
Then Payload also outputs many data. To system,
as all other subsystems, it gives the payload mass and
power budgets; for data handling (DH) it evaluates
the data rate needed to collect imagery data, for
power it calculates the power supply required by the
Payload is composed by several components. Each
component has some thermal, power, and structural
properties: i.e., operational temperatures, dimensions,
and masses.
Figure 2. System class diagram.
Figure 3. Payload class diagram.
4.4 Structure
The structure subsystem unit includes also the config-
uration aspects, that sometimes are considered as a
separate field of expertise for the complexity that the
geometry of arrangements and interfaces among all the
parts of the spacecraft could reach. This unit receives
inputs from all other subsystems. The properties received
are in the following category: dimensions, mass, position
suggested, and denied during the configuration phase.
Obviously, structure not onley gives information the to
system, but also to other subsystems: to AOCS satellite
dimensions and its inertia properties, to thermal satellite
dimensions and to Power the requirements for the solar
wings. Structure is composed by several elements that are
designed using the appropriate functions and is described
in the corresponding component class (Figure 4).
4.5 Data Handling
From the observation of this diagram (Figure 5) it is
immediately clear that the data handling subsystem
receives the classical data from system engineering unit:
mass and power budgets. Besides, some more informa-
tion is given: the name of the ground station, which data
handling will transmit data to, the so-called telemetry
budget (that is the number of telecommand and
telemetries to be managed by DH subsystem and that
will furnish information on the status of all other
subsystems during the mission operational phases).
Data handling receives from the mission engineering
unit the bus characteristics and the architecture to be
used for the processing units. The AOCS features are
also essential: frequency and data rate of all sensors
drive the choice of processors and buses. In the output
area, data handling behaves as other subsystems giving
thermal, structural, and power properties of components
to the corresponding units (Figure 7).
4.6 Data Handling Collaboration Diagram
This diagram (Figure 6) shows the actions when the
concurrent design process is in active phase, when the
design parameters are exchanged among subsystems,
and engineering units make their design choices.
Each arrow indicates a flux of information between
objects. The numbers give a possible sequence of the
actions. Each action is represented by a function whose
complexity is unpredictable, it depends on the design
parameter it has to calculate. As an example, the
function ‘Calculate Processor Frequency()’ can be very
complex considering many variables: Update rate of
the sensors, historical information, availability of
existing central process unit (CPU), etc. ‘Define CPU
Architecture()’, instead, could be a simple choice made
by an expert designer.
5. Implementation of the Model
The model described by the set of diagrams presented
in the previous paragraph has been used for the whole
design of the satellite system, responding to the
requirements stated in section 3.1. The design has
Figure 4. Structure class diagram.
Model for Preliminary Design Procedures of Satellite Systems 155
followed the methodology used in ESA CDF [1, p. 2–5;
2, p. 1–3]:
.the software model developed by ESA for the
exchange of data among the subsystems/engineering
.a set of MS Excel Workbooks, one for each
engineering unit, to calculate or choose the most
proper values for the design parameters
Figure 7 shows the architecture of the ESA software
adapted to FINGERSAT design [1, p. 6].
The MS Excel Workbooks (composed by
inputs, outputs, calculation, and presentation sheets)
were created by ESA for the design of each
subsystem. Some of them are independent from
the current project and can potentially be reused
for other case studies (propulsion, data handling,
system, etc).
Figure 5. Data handling class diagram.
Figure 6. Data handling collaboration diagram.
The choice of correct values for the design parameters
is supported by the presence of a database of components
in each workbook. Then each engineering unit was able
to find the components necessary for the subsystem it was
designing. The database presents an amount of several
elements with different properties, allowing a definition
of the real value of the design parameters, not only a
theoretical one.
During the process the diagrams presented in the
previous section constituted a roadmap for:
.the system engineering unit managing the interactions
among the subsystems;
.all other engineering groups giving the complete
overview of the interfaces of data exchanges from the
subsystem to all the others.
Besides, the presence of activity diagrams explains the
logic used during the subsystem design as depicted in the
example presented in the previous paragraph.
The results of the design phases are described deeper
in the teamwork report presented in partial fulfillment
of the requirements for the Master degree in ‘Satellites
and Orbiting Platforms’ of Sapienza, Universita
Roma, (year 2005/06) [7].
6. Conclusions
Spacecraft design is a typical concurrent design
activity where quite different disciplines cooperate
to achieve a composite final aim. In the present
work, based on ESA development in the field, a
possible concurrent design procedure for the
preliminary design of spacecraft has been developed,
implemented and tested, producing results in the
following areas:
.Analysis of dimensioning criteria and identification
of design parameters for an earth observation SAR
satellite (case study) and for all subsystems.
.Definition of the relations among subsystems:
exchange of design parameters.
.Documentation of the static model of the design
procedure using a series of UML class diagrams
(described in section 4).
.Implementation of the criteria in Workbooks, pro-
grammed ad hoc for the case study using MicrosoftÕ
Office Excel (Copyright ß1985–2003 Microsoft
.Documentation of the interactions among the
Workbooks and description of the principal functions
with the use of UML dynamic diagrams (collabora-
tion and activity).
.Creation and loading of a database to finalize the
design procedure with real components.
This article emphasizes the two documentation phases
which give a formal description of data exchange, both
static and dynamic, put into practice applying the
presented UML model.
An entire definition of all the information needed
to complete a pre-Phase A study is achieved using
the presented UML model. The design phases of
a satellite system, from phase A (preliminary) to
phase D (detailed) design, are well described in terms
of the set of requirements pertaining to each phase.
The European space standards (ECSS) documents
contain this piece of information. The level of detail
required for phase A is compatible with the
tools &
MS excel
Presentation sheets
Outputs sheet
Inputs sheet
Calculation sheets
Figure 7. The architecture of European Space Agency Concurrent Design Facility software.
Model for Preliminary Design Procedures of Satellite Systems 157
system description used in the frame of the present
One of the most important result of the implementa-
tion of concurrent engineering procedure in the real
practice is the reduction of time-to-market by means of
the reduction of design time. In order to achieve this
results in the present case, a key issue is a clear description
of the design variables of the space system as a whole and
in terms of all its subsystems and the set up of the relevant
design procedures used in the design process. In a
complex system as an EO satellite, these procedures
touch in most cases different areas of expertise, while in
some cases the sizing of a component only refers to a
specific discipline. The class diagrams illustrated in the
article allow to properly describe the attribution of the
design variables to the proper areas of expertise, in such a
way preparing the way for setting up effective design
procedure either among different areas of expertise or in
the context of a single competence. The design model set
up in this way will shorten the design time by limiting
the design iteration and by making evident, since the
beginning of the design process, all the conceptual links
that are present in the different areas of expertise of the
design. This will allow each member of the design team,
with a specific skill, to coordinate his effort in a well-
defined teamwork design process.
In fact, with a class diagram, a member of a CD team
completely knows what data are of interest for his
subsystem and whoever is concerned with that. With an
activity diagram, as well, he knows what actions to do for
exchanging the aforementioned data (an action can be a
software procedure, a bibliographical research, a market
analysis, a Matlab routine, a meeting with other CD
team members, etc.). Finally, a detailed description of
these actions is achieved using activity diagrams, one
for each action.
Moreover, even if the model presented is tailored to
the FINGERSAT case study, the generality of the
procedure is assured by the use of:
.A set of class diagram giving the static photography
of the data exchange giving an answer to the
questions: what each subsystem has to share with
others and what can receive from the others.
.A set of Collaboration diagrams to describe the active
interaction among subsystems (what happens during
CDF sessions).
.An optional set of Activity diagrams which document
the actions undertaken to exchange data (in
FINGERSAT case these are the functions used in
the workbooks).
The presented model definitively is able to provide a
multidisciplinary and concurrent design environment for
spacecraft design, as demonstrated by the diagrams
shown in the previous pages which document with the
same approach quite heterogeneous subsystems: space
mission analysis, satellite structure, SAR payload, data
handling subsystem. Its use is then naturally linked with a
teamwork effort of design with a widespread scenario of
competences well represented in the members of the team
and cannot be used as a standalone one-man-only design
effort. Moreover, during the practical CDF sessions, the
presence of these diagrams gave to team coordinator and
to each member of the team a huge capability to solve
very rapidly (with only one diagram!) the outcome of
inter-teams communication lacks, rapidly identifying
which data are to be exchanged. This improves the
team management effort and will lead to a reduced time-
The model is also very useful for educational and
training purposes in space system engineering both in
the academic and at the industrial environment.
The authors are indebted to Massimo Bandecchi who
is responsible for ESA CDF, for his support during the
to the Universita
`di Roma La Sapienza for the purposes
of research and education, and for some basic kernel
models of the procedures developed by ESA. The present
study was part of a team effort of all the classses of the
fourth edition of the Master in Satelliti of La Sapienza,
the members of which are gratefully acknowledged:
Rosaria Barca, Alessandro Cricenti, Salvatore D’Addio,
Federico Letterio, Daniela Pilotti, Silvia Sabatini,
Daniele Scaranari, Claudio Scotognella, Stefano Serva,
Manuela Sternativo, Valerio Tarantini. Also the authors
are indebted with the members of all the previous classes
of the Master, and in particular to Massimiliano Di Pace
and Giovanni Falcucci, who formalized the study
performed in the third edition of the Master.
1. Bandecchi, M., Melton, B. and Ongaro, F. (1999).
Concurrent Engineering Applied to Space Mission
Assessment and Design, Published in ESA Bulletin Nr. 99,
2. Bandecchi, M., Melton, B. and Gardini, B. (2000). The ESA/
ESTEC Concurrent Design Facility, EuSEC2000 September.
3. Bacchetti, M., Garutti, A. and Haines, J.E. (2001).
Spacecraft Electrical Power Subsystem Design Utilising
the ESA-ESTEC Concurrent Design Facility, IEEE.
4. Vergeest, J.S.M. and Horva
´th, I. (1999). Design Model
Sharing in Concurrent Engineering: Theory and Practice,
Concurrent Engineering,7(2): 105–113.
5. Prasad, B., Morenc, R.S. and Rangan, R.M. (1993).
Information Management for Concurrent Engineering:
Research Issues, Concurrent Engineering,1(1): 3–20.
6. (Gary) Chen, S.-J. (2005). An Integrated Methodological
Framework for Project Task Coordination and Team
Organization in Concurrent Engineering, Concurrent
Engineering,13(3): 185197.
7. Larson, W.J. and Wertz, J.R. (2005). Space Mission
Analysis and Design, 3rd edn, Chapters 9,10, Microcosm
Press and Kluwer Academic Publishers.
8. ECSS Secretariat ESA–ESTEC (1996). ‘ECSS–M–30A’,
Requirements & Standards Division Noordwijk,
pp. 23–28, The Netherlands, 19 April.
9. Master course in ‘Satellite and orbiting platforms’ team
(2006). CDF Technical Report – FINGERSAT Project,
`di Roma La Sapienza, April.
10. Fowler, M. (2003). UML Distilled: A Brief Guide to the
Standard Object Modeling Language,3rd edn, Chapters 1,
3, Addison Wesley.
11. Rumbaugh, J., Jacobson, I. and Booch, G. (1999). The
Unified Modelling Language Reference Manual, Chapters
3,4,7,8, Addison Wesley.
Davide Di Domizio
Davide Di Domizio was
born on July 12, 1974, in
Italy. He earned a degree
in Computer Science engi-
neering at the University
‘Federico II’ of Naples
(1998), a Master Course in
‘Systems Design’ at
University ‘RomaTre’ of
Rome (2003) and a Master
Course in ‘Satellites and
Orbiting Platforms’ at
Sapienza, Universita
`di Roma (2006). Until 2005, he
was the database administrator and a software project
manager at the Italian Air Force Logistic Information
Center. Since 2005, he has been teaching the ‘Oracle
Database Applications’ course at Italian National
Reasearch Council (CNR). He attended the regular
courses for officers at Italian Air Force Academy (1993–
1998), and Captain since 2001. He is now employed in
Italian Air Staff dealing with Italian Defence Spatial
Programmes, test ranges, and UAVs.
Paolo Gaudenzi
Paolo Gaudenzi is full
professor of aerospace
structures and director of
the Master course in
Satellites and orbiting plat-
forms at Sapienza,
`di Roma. He is
author of more than 100
papers, 35 of which pub-
lished in international refer-
eed journals and is member
of numerous journals edi-
torial boards and scientific committees. His main
research interest cover space systems, aerospace struc-
tures, smart structures, computational mechanics, and
cost engineering. He was responsible of research projects
funded by Italian and European bodies like ESA, the
Italian Ministry for University, and research and by
private companies.
Model for Preliminary Design Procedures of Satellite Systems 159
... Due to the challenging mission requirements and the strict constraints, in particular imposed by the harsh environmental conditions encountered during the flight, a collaborative approach of concurrent engineering (CE) has been used for the preliminary feasibility study. By means of a greater and efficient exchange of information [2,3] and thanks to a very flexible and effective CE tool for the real-time design, sizing and visualization of the space system [4], the CE approach has proved to be very helpful in meeting these tight mission demands and at the same time considerably reducing the design time and the inter-subsystems conflicts. In the following paragraphs, after a brief introduction of the CE tool used for the preliminary design, the mission is illustrated by pointing out its objectives, the mission analysis and the spacecraft configuration, which will be studied in deep in the system budgets section. ...
... Generally, the initial phases of a project, and especially of a space mission project, are crucial since they influence greatly the ensuing steps. Indeed, feasibility assessment at early stages brings to time and cost reductions [2,3]. ...
... There are several definitions of CE, but the one that best explains the concept is the following: "Concurrent Design is a methodology that allows the parallel design of several subsystems, managing their mutual interactions, which are then assembled to form an engineering system" [3]. According with this definition, some advantages of the CE can be easily underlined, comparing it with traditional methods: the design process become faster and more integrated thanks to the possibility of an almost near real-time exchange of information among the disciplines involved in the project. ...
Full-text available
The early stages of a space mission design are crucial for the development of the whole project because they strongly influence the ensuing design phases. Moreover, feasibility assessment at early stages brings to time and cost reductions and strongly determines the overall performances of proposed solutions. Concurrent Engineering (CE) is a systemic and systematic design strategy that employs real-time interdisciplinary activities for products development. The advantage of the CE approach is particularly noticeable in the study of systems of high complexity, as space exploration systems do. The aim of this work is to show how a Concurrent Design approach can be very profitable in the development of a pre-phase A study of an interplanetary space mission, by means of a greater and effective exchange of information, enlarging the solutions tradespace, highlighting system criticalities and solving inter-subsystems conflicts. The case study, TRIton Tomography Orbiter (TRITO), is conceived as a mission to investigate the Neptune planetary system and its main moon Triton, which is of scientific interest due to its geological activity and the possible presence of subsurface oceans. The possibility of a pre-science phase in orbit around Neptune has been considered, giving the opportunity of precise measurements of its gravitational and magnetic field, together with its upper atmosphere composition. Therefore, a complex suite of instruments composed of magnetometers, laser altimeters, cameras and spectrometers, constitutes the payload, supported by a spacecraft able to face challenging environmental conditions during its whole spaceflight, ending with an aerocapture manoeuvre within the Neptune atmosphere. The collaborative approach, through the use of a modern CE design tool, is demonstrated to be very helpful not only in finding solutions meeting the strict constraints imposed by the harsh environmental conditions, but also for the individuation of optimum solutions related to mission analysis and mass budget aspects according to the system criticalities. The CE approach has been demonstrated to be an unavoidable design methodology for the development of systems showing a high level of subsystems interconnections and simultaneous interactions of different engineering domains, permitting to manage the growing design complexity.
... Following the model-based approach the disciplines share a common system model. During the conceptual design the parametric models for the all the system's parts are used, and form so called system budgets that allow to determine overall concept's feasibility [12,13]. ...
... In order to collaborate on a conceptual design, an integrated model is built that includes all the necessary discipline perspectives. Each discipline contributes to the integrated model with a domain specific sizing model based on design parameters [12]. Some of the disciplines are responsible for the conceptual design of a physical subsystem (e.g., propulsion, communications), while other disciplines are concerned with nonphysical, or transversal issues (ed. ...
This work presents a model of the process of conceptual design studies which use the concurrent engineering approach. Concurrent conceptual design is an integrated system development approach, to rapidly explore feasible design solutions by parallelizing the work of experts. This approach is characterized by a multidisciplinary team of experts collaborating in a co‐located manner. Albeit the conceptual design phase requires creative problem solving, teamwork requires coordination, and would profit from a shared understanding of the design process. Based on a survey among experts from 15 different organizations, and practice documented in literature, we propose a model of the underlying design process. This work extends our previous work on a coordination method for concurrent design and provides validation of the process model via case studies and expert interviews. The proposed process model is formalized in SysML diagrams. It can be used to help program coordinators and train engineers of different disciplines on the methodology of concurrent conceptual design, as well to serve as a baseline for implementing the methodology in new organizations.
... The classical book "Space Mission Analysis and Design" by Wertz and Larson [40] propose a well-adopted example of such satellite design process. References [3,22,23,62,67] are further similar examples of processes to design satellites. All these methodologies provide a formalized process implementing a satellite configuration workflow to satisfy mission objectives and requirements. ...
Conference Paper
Full-text available
Designing spacecraft such as satellites is known as an extremely difficult problem. It requires complex decision-making at different concerns from mission requirements to system architectures. Such complexity might lead to design system architectures that are not feasible in practice or do not fulfill the requirements. Moreover, the lack of automation to assess high-level designs reduce the benefits of the early design phases by missing more suitable designs and increasing the design time. In this paper we discuss potential research directions and propose a potential framework that aims to i) drive the engineers in the different design steps ii) capture the feasible system architectures regarding the requirements and constraints, iii) refine and assess selected architectures through simulations. Our framework is model-driven and built on two complementary modules. The first module is a configurator based on attributed features models that support engineers in the design process of system architectures. Second, a simulation engine refines and assess automatically the selected system architectures with respect to the requirements.
... The components of a satellite receive budgets [38] from the mission requirements. System engineers define different budgets(mass budget, power budget and link budget) and distribute them to the sub-systems and equipment. ...
Requirements engineering plays an important role both in software and systems engineering. It is the process of defining, documenting, and maintaining requirements. Requirements traceability is a branch of requirements engineering, which establishes relationships between requirements and design artifacts, implementation artifacts, and test cases. Traceability provides several benefits both in software and systems engineering, one of them is to provide change impact analysis. When a particular requirement changes, it is implied that the artifacts related with the requirement should also change. In this thesis, we provide a new methodology for requirements management and traceability. Although the methodology is applicable for different systems engineering domains, space mission requirements and spacecraft models are the main focus of this thesis. The methodology consists of three parts. In the first part, we cover traceability between requirements and model artifacts. Unlike existing traceability approaches, our methodology provides automatic validation. In the second part of the methodology, we introduce modeling on the basis of requirements. The last part of the methodology covers requirements-based artifact reuse. Besides our theoretical contribution, we provide a prototype tool implementation which includes the features of the methodology. In our evaluation, we demonstrate our contribution by integrating our tool with Virtual Satellite, a spacecraft modeling software developed by German Aerospace Center (DLR).
... Consequently, this process of heat exchange in the FC is complex (conjugate) which simultaneously involves mechanisms of heat conduction, convection, and radiation. There is a need to set and solve problems associated with a creation of computational and mathematical models for the fluid circuit of control systems arises in the process of developing modern layout schemes for instrument compartments of spacecraft [6]. Current existing mathematical models developed for circulating thermal control systems do not take into account specifics of complex conjugate heat transfer and do not allow the use of optimization procedures. ...
Full-text available
This paper considers the development of a mathematical model for spacecraft thermal control fluid circuit systems. The need to take into account the complex mode of heat exchange in a fluid circuit model reflects relevance of the paper. Basic equations of heat exchange model in the circuit are given. A procedure for the numerical solution is described. Obtained calculation results are presented and analyzed. The developed model allows numerical studies to assess an impact on characteristics of the circuit of various design and operating parameters.
... Commonly, parametric models are used to map design parameters onto performance characteristics. For the case of sizing a satellite, a data model was describe in [18]. A more generic data model was elaborated by European space agencies and companies. ...
... [5] The European Space Agency (ESA) once stated a reduction of design time from 6-9 months down to 3-6 weeks. [6] 2. ...
Conference Paper
Concurrent Engineering (CE) and Model Based Systems Engineering (MBSE) have increased the efficiency of spacecraft, and satellite design in particular. Early design of satellites in Concurrent Engineering Centers (CEC) has almost become business as usual. However, such progress has still to be achieved for the design of launchers. Applying the same approaches as used for satellites has not led to the same amount of improvement, yet. To address this, DLR initiated the project Concurrent Launch Vehicle Analysis (CLAVA) to investigate the shortcomings and to improve the efficiency of conceptual launcher design and analysis. From an MBSE point of view, investigations show that concurrent modelling requires new Conceptual Data Models. In contrast to designing satellites, they are focused on a much more physical abstraction rather than a functional one. Regarding simulations, it has become clear that the conceptual design phase of launchers requires far more computationally intense simulations in a sequential order. With this knowledge, it is possible to outline a new process for CE studies allowing for concurrent design phases and sequential simulation phases. For this, an adjusted architecture of tools is required as well. The data model used for satellite studies within DLR's Concurrent Engineering Facility (CEF) does not fit to the requirements of launcher design and has been adapted. Additionally, DLR's aeronautics divisions have already made substantial progress in increasing the efficiency of their simulations. They employ automated simulation workflows using a parametric model for information exchange between integrated tools. This approach has been adopted and integrated. This paper outlines how this approach is combined with CE and MBSE concepts used for satellites and addresses the specific requirements of launcher design. It provides details about the database used during CE sessions, and how its information is transferred into the parametric data model used to run the required simulations. The conceptual data model of this database has been adapted to the physical representation of launchers; these changes will also be discussed. Furthermore, the general idea of the workflow and the design of the parametric model will be presented. The paper concludes by providing an outlook of how DLR intends to continue on this work, and further refine the developed tools and processes into daily CE and CEF application.
... [10]. In its traditional use, concurrent design is used to reduce development cost and schedule in integrated product development [11]. Concurrent design leverages multidisciplinary teams of experts collaboratively working on a system design study in a shared workspace, equipped with tools and processes to facilitate collaboration, along with a common data exchange tool for modeling. ...
Conference Paper
Corporate research and technology (R&T) management needs reliable information for strategic planning. A commonly used tool are technology roadmaps, since they describe vision and corporate strategy for technology evolution. The process of creating a technology roadmap involves experts from engineering, product development and all support functions evaluating and comparing opportunities for incremental as well as disruptive innovation. This work describes an approach, where experts build and run models in a concurrent design environment allowing the evaluation of potential product architectures according to a defined set of figures of merit and at different time horizons. This mapping of the landscape can then inform the planning of technology investment and development. The process is illustrated using the example of a solar-electric aircraft technology roadmap.
Full-text available
The (XURSHDQ 6SDFHH $JHQF\ (ESA) performs pre-Phase-A assessment studies as part of the definition of future space missions. To evaluate the benefits of the Concurrent Engineering (CE) approach to these studies an experimental design facility was created in the ESA Research and Technology Centre (ESTEC) at the end of 1998 and used to perform the assessment of several missions. This article describes the adopted approach, the experience gained during the studies performed and highlights the benefits of the application of the concurrent engineering approach to space mission assessment and design.
Full-text available
ESA performs pre-Phase-A assessment studies as part of the definition of future space missions. To evaluate the benefits of the 'concurrent engineering' approach to these studies, an experimental design facility was created in ESTEC and used to perform an assessment of the Italian Space Agency's CESAR (Central European Satellite for Advance Research) mission. This article describes the approach adopted and the experience gained during the study, and draws preliminary conclusions on this new approach to space-mission assessment and design.
Full-text available
The development of products in large industrial organizations involves numerous engineers from different disciplines working on interdependent components Objectives are sometimes in conflict The need for overall coordination, consistency, control, and integrity of data, design ideas, and design rationale is critical The information generated by each designer must be viewed in the context of information generated by other designers, the enterpnse historical data, and the organization as a whole. The paper outlines major requirements facing concurrent engineering (CE) It focuses on the ability of collaborating designers to proceed independently, correlate interdependency, use existing information (data, knowledge, and processes), and negotiate conflicts arising from design inconsistencies To provide information-based support for such environments a concept of design schemata is introduced to support the concurrent, collaborative, and historical aspects of CE environments from an enterprise perspective. The need for a data dictionary that supports these schemata and its different dimensions is also recognized The dictionary provides conceptual centralization of design information relative to the enterprise. This includes data, as well as its definition (meta-data), and must allow the design process to evolve in a global enterprise perspective These discussions lead to a series of research issues that must be addressed by the CE research community.
Full-text available
Complex products or projects with long development times always involve multiple disciplines and a great deal of effort. Especially in concurrent engineering, the design needs to simultaneously consider various downstream activities throughout the entire product life cycle. To accomplish this, tasks in the concurrent engineering environment generally involve multifunctional teams in which team members from different functional departments interact in every phase of development tasks. However, as products become more complex, so do the design process and the project teams. This will inevitably degrade team performance when the team size becomes too large to handle. Moreover, to ensure a successful multifunctional team, it is also important to understand the characteristics of team members that affect team performance. Thus, an efficient multifunctional team can be established with all the right team members being assigned. The objective of this research is to develop an integrated methodological framework for project task coordination and team organization from the concurrent engineering perspective in order to assign the right team members to the right tasks. The framework includes three models: (1) a project task model to understand the complex task structure of the project; (2) a team member model to provide a quantitative representation of three important team member characteristics; and (3) a task-member assignment model to accomplish the research goal - assign the right team members to the right tasks. The effectiveness of this framework is demonstrated by an illustrative example. The result shows that the proposed integrated framework is capable of coordinating the project tasks and helpful in organizing project teams.
The goal of this second edition is siniflar to the first: to allow you to begin with a blank sheet of paper'' and design a space mission to meet a set of broad, often poorly defined, objectives. You should be able to define the mission in sufficient detail to identify principal drivers and make a preliminary assessment of overan performance, size, cost, and risk. The emphasis of the book is on low-Earth orbit, unmanned spacecraft. However, we hope that the principles are broad enough to be applicable to other n-dssions as well. We intend the book to be a practical guide, rather than a theoretical treatise. As much as possible, we have provided rules of thumb, empirical formulas, and design algorithms based on past experience. We assume that the reader has a general knowledge of physics, math, and basic engineering, but is not necessarily familiar with any aspect of space technology. This book was written by a group of over 50 senior space engineers. It reflects the insight gained from this practical experience, and suggests how things might be done better in the future. From time to time the views of authors and editors conflict, as must necessarily occur givenmore » the broad diversity of experience. We believe it is important to reflect this diversity rather than suppress the opinions of individual authors. Similarly, the level of treatment varies among topics, depending both on the issues each author feels is critical and our overan assessment of the level of detail in each topic that is important to the preliminary mission analysis and design process. The book is appropriate as a textbook for either introductory graduate or advanced undergraduate courses, or as a reference for those already working in space technology.« less
The communication of design model data between participants of an engineering team is a fundamental subprocess in concurrent engineering (CE). The problems encountered in data transfer are abundant. It is understood that data transfer should be enhanced toward knowledge transfer. Although it is possible to define what knowledge transfer is in general terms, it is crucial to specify it at the subprocess level; only then loss-less data communication can be implemented in practice. We therefore need to specify the conditions for successful data transfer subprocesses. In this paper we investigate which conditions are specific for CE. They are then formulated using the finite automaton formalism. From these conditions it can be concluded which measures should be taken in order to avoid data exchange problems and hence to support knowledge sharing. Examples are provided and an outlook to further applications is discussed.
Conference Paper
ESA's general definition for the term 'concurrent engineering' is as follows: development of an engineering design team covering all relevant disciplines as from the initiation of a project; with the team working and communicating in a single environment, to establish a system design within a short period of time and in a more consistent way with respect to other approaches. This design approach offers distinctive gains due to greater consistency over a shorter time period. This article describes the above-mentioned approach applied in the area of the spacecraft electrical power systems design