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.
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 . In addition,
it furnishes a successful and tested answer to meta-data
description as requested in , improving team coordi-
nation in contexts where a different framework is
already applied .
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: http://cer.sagepub.com
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 . 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
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
.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 . 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
150 D. DIDOMIZIO AND P. GAUDENZI
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
.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
, 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
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
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
152 D. DIDOMIZIO AND P. GAUDENZI
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 -
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.
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
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.
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,
Figure 2. System class diagram.
Figure 3. Payload class diagram.
154 D. DIDOMIZIO AND P. GAUDENZI
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,
Figure 5. Data handling class diagram.
Figure 6. Data handling collaboration diagram.
156 D. DIDOMIZIO AND P. GAUDENZI
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
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) .
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
.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
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
.An optional set of Activity diagrams which document
the actions undertaken to exchange data (in
FINGERSAT case these are the functions used in
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.
158 D. DIDOMIZIO AND P. GAUDENZI
6. (Gary) Chen, S.-J. (2005). An Integrated Methodological
Framework for Project Task Coordination and Team
Organization in Concurrent Engineering, Concurrent
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
`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 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
Model for Preliminary Design Procedures of Satellite Systems 159