You are on page 1of 10

3URFHHGLQJVRI(X6(&

,6%1 KDUGFRS\  &'520

The Satellite Design Office at Astrium - A Success


Story of an Industrial Design Center Application
Rolf Mager, Ralf Hartmann
System Engineering Division, Astrium GmbH
88039 Friedrichshafen, Germany
rolf.mager@astrium-space.com
ralf.hartmann@astrium-space.com

oriented MuSSat. The objective was to establish a


Abstract. The paper describes the introduction
tool, which supports a higher degree of understanding
process of the Satellite Design Office (SDO) at
and maintainability for a system of interconnected
Astrium GmbH in Friedrichshafen. The SDO is a
spreadsheets.
Concept Design Center for the establishment of early
The examples of The Aerospace Corporation and
design concepts and binding proposals for satellite
JPL together with the availability of MuSSat inspired
systems by application of a so-called integrated
the establishment of the “Satellite Design Office”
concurrent engineering approach. This paper tries to
(SDO) at Dornier Satellitensysteme GmbH in
highlight the specific issues and experiences instead
Friedrichshafen mid of 1998.
of giving an overall description and feature
explanation, which would be a repetition of what Two major differences between the SDO and the
already has been said many times for Concept Design CDC and PDC should be mentioned. At first the
Centers. First the initial vision of the SDO will be focus of the SDO was put on satellite system design
presented followed by a description of the specific instead of overall space mission design. Secondly the
activities and experiences in the different phases: SDO was from the very beginning a pure industrial
build-up phase, first application and nominal initiative with the following aspects:
operations. At the end a final conclusion is provided œ A very quick demonstration of feasibility and
on the success of the SDO and its introduction success was required with a very low initial
process. budget.
œ The scope of the SDO was enhanced beyond the
INTRODUCTION establishment of concept design studies to the
The idea of Integrated Concurrent Engineering and establishment of firm fixed price binding
Concept Design Centers has been defined and proposals.
successfully demonstrated for space mission design œ The kick-off took place in February 1999 where
by The Aerospace Corporation and Jet Propulsion the initial vision and the preliminary planning
Laboratory (JPL) since mid of the 1990. The basic was presented. The meeting was supported by a
principles of these design centers are: short keynote speech of a member of the board of
œ Establish a team of experienced specialty directors.
engineers with additional systems engineering œ
and soft skills
œ Let this team execute a well defined process THE INITIAL VISION OF SDO
which consists of the alternation of homework General. The major objectives of the SDO were to:
phases with half day integrated team sessions œ Establish concept studies and binding proposals
œ Support the integrated team session with a four times faster with half the budget and better
multimedia collaboration environment which with respect to overall consistency, number of
makes expert tools and databases available in alternatives considered, tracability and
real-time. The information flow between team reproducibility of the process.
members is controlled by a comprehensive œ Solve the problem of “team building” by
system of interconnected spreadsheets ensuring the availability of experienced people as
The division of astronautics at the Technical a well trained process oriented team instead of
University of Munich (LRT) has put an emphasis on putting together a group of individuals,
systems engineering in education and research since a œ Solve the problem of obtaining overall
couple of years. One outcome of this research was the consistency and controllability of the generation
development of a system modeling and analysis tool of “the solution” without tracability ending up in
(MuSSys). This tool has been further developed close a “surprise” and the end of the process with very
co-operation with the former Dornier limited capability to redirect.
Satellitensysteme GmbH to the space application

±
Beyond all this we wanted to create an environment A macro process representing a playbook for the
to develop new ways in collaboration and in the overall study/proposal preparation (see figure 1)
application of state of the art IT technologies. œ A micro process as a guideline for the
organization of the ½ day integrated team
sessions providing a sequence of discussion (see
Team. The starting point for the establishment of the
figure 2) and a guideline how to use the elements
SDO team was the idea to generate a virtual
of the supporting infrastructure along the
organization, which attract people to contribute by
activities.
interest and motivation. Nevertheless the initial driver
and process owner was the systems engineering œ A role internal approach how to generate the
division. The following basic teaming principles have necessary results out of the available inputs on
been formulated: the basis of a set of standard solutions, selection
guidelines, equipment databases supported by the
œ Recruitment according to skills only – no
real-time availability of the necessary
constraints from the existing organizational units
engineering tools. (see figure 3)
œ Maximum size of 15 members per study team
œ Availability of 2 persons per role during the
build-up phase
œ 4 redundant persons per role during the
operational phase.
œ Combination of roles as far as possible to
optimize the overall team size. (e.g. Facility
Administrator and Documentarian represented by
one person)
œ Slight fluctuation accepted during the operational
phase to serve as a training center for system
engineering capabilities
œ No hierarchy – self organizing mini teams for
each of the 15 roles maintain communication
with the relevant engineering departments

Process. The team started with the understanding that


the process to be followed during SDO operations
consists of three cascaded workflows:

0RQGD\ 7XHVGD\ :HGQHVGD\ 7KXUVGD\ )ULGD\


 RUN +RPH:RUN
+RPH:    
+RPH:RUN

$UUDQJHPHQW 
Q
ZLWK
 RUN RUN  , LRQ W  
 RUNQHPH Q
Ä&XVWRPHU³ +RPH: : DUDW +RPH:
L
3UH
S 5HI QDWL YHV 
$OWHU

0RQGD\ 7XHVGD\ :HGQHVGD\ 7KXUVGD\ )ULGD\


 RUN
+RPH:   +RPH:
+RPH:RUN  RUN
(GLWRULDO
L QJ 
 RUN 3ODQQ LVN $GDSWDWLRQRI
+RPH:
5 'RFXPHQWDWLRQ
&RVW  2IIV 
7UDGH
Figure 1. The macro process representing a playbook

±
'HVLJQ6XSSRUW 'HVLJQ6XSSRUW
IRUVSHF5ROHV IRUVSHF5ROHV  
0RGHOVIRU
%XGJHWV
:RUN&RVW
5LVN6FKHGXOH

&XVWRPHU
5HTX $OWHUQDWH
&RPSRQHQW
6\VWHP
'DWDEDVH
'HVLJQV
6WDQGDUGL]HG
6HTXHQFHDQG,QWHUIDFLQJ
EHWZHHQ5ROHV
6\VWHP
'HYHORSPHQW
'HVLJQ6XSSRUW 'HVLJQ6XSSRUW 3URSRVDO
IRUVSHF5ROHV IRUVSHF5ROHV

Figure 2. The micro process

6LJQLILFDQW
3DUDPHWHUV
,QSXW 2XWSXW
3DUDPHWHUV  EHSHUIRUPHG
&KHFNOLVWRIWDVNVWR  3DUDPHWHUV

6HOHFWLRQ*XLGHOLQHVIRU
5HIHUHQFH6ROXWLRQV

'HVLJQ
'HVFULSWLRQ
&RPSRQHQW 5HIHUHQFH
'DWDEDVH 5ROH6SHFLILF 6ROXWLRQV
2IIOLQH7RROV

Figure 3. The discipline specific role within the SDO process

œ Meeting room with 15 PCs connected via a


Facility and Tools. The SDO facility represents the
network to the standard company servers and to
most visible part of the whole SDO. It consists of the
the SDO data server
collaborative working environment on one hand -
which is also extremely useful outside the context of œ SDO dedicated network data server accessible by
the SDO- and the specific tools needed to support the the team members from the SDO facility as well
SDO team and the contribution of the individual as from each PC in the company
roles. œ 2 video projectors which can present the content
of the displays of either PC in the facility
The major elements of the collaborative working œ a smart board, which allows to operate a PC by
environment are: finger tip (very effective for introduction and

±
training of computer tools) and to serve as an As a consequence the following 3 types of interfaces
intelligent electronic flip chart (very effective to between the disciplines have been defined:
collect he minutes of the integrated team sessions œ Direct: Main stream information flow
and for sketching and discussing ideas) between disciplines, which is always needed
and which can be clearly expressed
The major assumed elements for the team and role
(formally supported by tools)
specific tools were:
œ Checklist: issues, questions and constraints
œ MuSSAT as a core element to manage all
to be clarified with other disciplines, which
technical and cost data as well as the related
are not always needed and which needs
documentation and to support the quick
explanation or discussion (will be formally
generation of alternative concepts and the
supported by tools)
establishment of trade-offs
œ Diskussion: Everything else (incl. everything
œ All necessary expert tools connected to MuSSAT
forgotten above) to be clarified and
œ Database containing all required product data
discussed during the SDO team session
(technical, financial, programmatic)
œ Cost estimation tools directly coupled to the Facility and Tools. A core part of the facility has
company ERP tools (SAP/R3) already been set up in advance and has been used as
location for the kick-off meeting with the initial team.
During the buildup phase the facility has been
THE SDO BUILT-UP PHASE completed to its full capabilities except the
General. At the beginning it was necessary to teleconferencing functionality, mainly consisting of:
prepare the team for later SDO operations, to define œ Collaborative working environment with
the process to be followed and to establish the work and meeting tables
infrastructure. Furthermore the build-up phase was œ Network with 15 PC‘s
used to communicate and to advertise the SDO œ Special Server for SDO Data and S/W
concept to attract more team members on one hand œ Standard Company Server for User-
and on the other hand to create awareness and Administration, Standard -S/W and
expectations at the future customers. Peripherals
œ „Teacher-Student-System“
Team. At the kick-off meeting 20 people from 16
œ 2 Video beamer
different organizational units formed the initial team.
œ Large projection screen
From the beginning the team met at least once a week
for information exchange, decision making and for œ “SmartBoard”
continuous refinement and development of the œ Scanner
common understanding of the SDO process. During œ Printer
the 4 months lasting build-up phase the team size has The team started to identify and to install the
been increased to about 30 people. discipline specific tools. In parallel some of the
Process. The major emphasis during the build-up disciplines got an introduction into MuSSat and
phase was put on the definition of roles and their started to test the tool leading to a set of additional
interdependencies as a basis for later process requirements. MuSSat has then be updated and
definition and tool implementation. further developed accordingly.
We started bottom up. The representatives of
each discipline defined all inputs they will need for
THE ‘SDO-PREMIERE’, OUR FIRST
concept definition and all outputs they will provide
APPLICATION
either as final result or as input to other disciplines.
Different level of detail and different General. After the long phase of preparatory work
understanding of the roles characterized this first and never ending theoretical discussions the SDO-
draft. As a next step it was necessary to harmonize team looked forward to the first application. All team
the data. We set up a small team of 2 to 3 people to members got tired of this kind of work with virtual
generate an overall philosophy. After that this team processes and projects. It seemed not to be feasible to
talked to representatives of all disciplines to achieve go with the top-down approach into more detail for
an agreed set of data and a common understanding. the preparation of all predefined tools and processes.
During this activity the emphasis was put on the So we decided to continue in a more pragmatic way,
definition of input data. we wanted to test the whole concept and some of the
The next step was to discuss and decide in the many new ideas in the first project.
presence of the whole team which disciplines had to It was clear that only fundamental elements had
provide the required inputs leading to a consistent set been defined up to now, namely the role of the
of input output relationships. different disciplines, the macro-process and the
During the work it became obvious that it was product in form of the SDO-Report.
difficult to express anything in formal relationships. :H RIIHUHG WR VXSSRUW D WHFKQLFDO SURSRVDO IUHH
At this time we introduced the concept of checklists. RI FKDUJH DV GU\ UXQ IRU 6'2 7KH JRDO RI RXU ILUVW

±
SURMHFW ZDV WR GHILQH D WHFKQLFDO EDVHOLQH ZLWK D essential for the success of a project
URXJKFRVWHVWLPDWHIRUDVPDOOGDWDOLQNVDWHOOLWH2XU œ for reviewing the progress of the different
FXVWRPHU DFFHSWHG WKDW WKH WLPHVFDOH DQG RXWFRPH disciplines in the context of the whole system
ZDV XQGHU FRQWURO RI 6'2 ,Q ZRUVW FDVH KH KDG WR œ harmonizing of the interfaces
FRQWLQXHKLVSURSRVDOZLWKDFRQYHQWLRQDOWHDP œ definition of the system-baseline
But the result was very satisfactory. We achieved œ identification of potential options and trade-offs
our goal within time. So this first project was a œ defining the next step of the process
successful validation of our ideas especially of the
following key-elements. One element of the predefined macro-process, the
SDO-Report, was not considered in this first project.
The Process $OO WHDP PHPEHUV ZHUH YHU\ H[FLWHG But everybody agreed that writing a report is an
1RERG\ NQHZ FRPSOHWHO\ ZKDW he has to do and activity well known from conventional projects and
when. The overall SDO-process has been discussed in there was no need for a validation in principal.
detail, but each colleague was uncertain that he Also areas for optimization were identified. A
understood it correctly. Additionally all disciplines major aspect was that the customer requirements had
had to work out their concepts in a short time in a been defined preliminary and so several changes had
new environment. to be taken into account during the different sessions.
So it is clear that discussions and explanations It was found to be more effective when a sub-group
about the SDO-processes have interrupted technical clarifies the status of requirements and constraints
work. In practice we learned that we had a different before the whole team starts to operate. So the SDO-
understanding about SDO in the past. But in this first team decided that for future projects a small
project the virtual ideas became reality and as a document has to be established together with the
consequence this kind of problems came in sight. customer in which
One of the major uncertainties was how to deal œ the major technical requirements and constraints,
with assumptions. Due to the short time-scale in
œ programmatic aspects and constraints,
which a technical baseline has to be developed all
œ list of available information and documents
disciplines have to work out their concepts based on
œ and the goal of the SDO-activities is specified.
no or only a limited number of defined inputs. This
So in later projects the SDO process started with
was new and sounds not to be very effective. The
the kick off session based on this document.
experience from the conventional approach especially
of the more detailed design phase oriented SDO- The so-called micro-process was discussed in the past
members was to start with a list of well defined intentionally to be implemented in MUSSAT. Up to
requirements and constraints. now MUSSAT is under development so we had no
Additionally it became visible that the first tool to control our processes. Most input/output had
customer defined system requirements had been been transferred by communication without
assumptions only and had to be changed during this controlled documentation. This worked fine but it
SDO-project. was identified that a minimum formal documentation
So everybody was surprised about the first would be useful. So the second major outcome of this
results. Most of the preliminary concepts could be first study was to implement an EXCEL worksheet to
used without or with minor modifications for the document the most important outputs of all
system baseline. We learned that the SDO approach disciplines like mass and power budgets, dimensions,
gives us opportunities we never had before. development status, availability and cost information
of all hardware and software elements of the project.
After the long period of theoretical discussions on
processes and tools we have learned that the team, is This worksheet is called ‘Product-Tree’ tree, but in
contradiction to conventional product trees it is only
the most important element of SDO. The team has to
broken down into three levels.
control the process to assure
œ a high flexibility to react on changing system The Team is found to be the most important element
level requirements introduced by customer of SDO as mentioned before. It is nice to have a
œ fast and certain identification of system non- sophisticated environment with a lot of machines
compliance configured with all software you need. But also
œ a pragmatic progress to a preliminary baseline assuming you are able to define and implement a
definition clear process with all branches you can think about, it
œ a fast and certain identification of risk areas and seems not to be feasible to implement human
design driver intelligence into robots.
œ short term decisions on potential options in Especially missions for Earth Observation or
brainstorming trade-offs without detailed Science Application require always custom-made
analysis designs. No investigator wants to study the same
objective with the same performance anybody did
So this first application of SDO was a successful before. The experience of more than a quarter of a
validation of the defined macro-process. It was century is that no newly required mission results in an
feasible to define a technical baseline for a satellite already established design. So the technical process is
system within 10 days. The periodical sessions are

±
never the same, especially taking detailed technical œ Presentations can be controlled from each PC
experiences of past projects into account. directly or using the so called ‘Smart Board’ as
But what are the real incentives of SDO? The an sophisticated human-machine interface with
answer is not easy to find because it is based on ‘soft on-line documentation of all modifications.
facts’, which are normally hidden for technical people œ All disciplines are able to work in parallel to the
like us. So some of our colleagues may sneer because actual discussions using their dedicated tools,
most of the answers seem to be simple and obvious, e.g. for an on-line actualization of their analysis.
but nevertheless we try to explain. œ All results of discussions or decisions can be
œ ,Q 6'2 WKH WHDP KDV WKH FRPPRQ JRDO WR ILQG electronically documented on-line directly
WKH EHVW WHFKQLFDO VROXWLRQ PDNLQJ WKH FXVWRPHU visible to all participants for reviewing.
KDSS\
œ $OOWHFKQLFDOGLVFXVVLRQVDUHFDUULHGRXW LQ IURQW So the SDO facility satisfies all our needs since the
RIWKHWHDPZLWKRXWDQ\OLPLWDWLRQRUFRQVWUDLQW first session.
œ $OO GLVFLSOLQHV DUH DOORZHG WR SUHVHQW WKHLU The Tools. In the first SDO project we used tools
FRQFHSWV DQG UHVXOWV LQGHSHQGHQW RI WKH OHYHO RI œ commonly for operating the facility
GHWDLOZLWKRXWUDWLQJRIWKHSHUVRQ œ the company ‘Standard’ applications
œ $OOµQRQH[SHUW¶TXHVWLRQVDUHDOORZHGUHVXOWLQJ œ discipline dedicated applications.
LQ D PRUH FRPPRQ XQGHUVWDQGLQJ RI WKH V\VWHP
DVPLQLPXPEXWVRPHWLPHVDOVRLQDQLPSURYHG Most of these tools have been applied in several
EDVHOLQH conventional projects and there was no need for
œ $ VLPXOWDQHRXV FRPPXQLFDWLRQ EHWZHHQ DOO further verification. So in this first project no specific
FRQFHUQHG GLVFLSOLQHV IRU DQ\ GLVFXVVLRQ deficiency was identified.
EHFRPHVIHDVLEOH But as mentioned before the process was
œ $OO WHDP PHPEHUV DUH LQYROYHG LQ WHFKQLFDO generally controlled by our team-leader, not as
GHFLVLRQV LQGHSHQGHQW LI KLV GLVFLSOLQH LV foreseen by our tool MUSSAT dedicated developed
HIIHFWHG RU QRW 6R D FRPPRQ DVVRFLDWLRQ ZLWK for SDO. Starting with the first project new aspects
WKHJRDORIWKHSURMHFWLVLQWKHIRUHJURXQG and questions arose with respect to MUSSAT, which
are presently not answered.
6XPPDUL]HGLQRQHVKRUWVHQWHQFHµZHFUHDWHGRXU œ Can we really use a tool to control our processes?
RZQFXOWXUHFDOOHG6'2¶ œ Has such a tool the flexibility to realize this kind
%XW ZH IRXQG DOVR RSWLPL]DWLRQ DVSHFWV ZLWK UHVSHFW of projects with always different requirements
WR WKH WHDP Basically it was not foreseen to and goals which requires dedicated processes?
implement an Overall System Engineer. The role of œ How can we start MUSSAT based on the first
the team-leader was to moderate the sessions and to assumptions?
control technical system aspects in parallel. But œ Can such a tool support our work or is it rather
especially due to the fact that it is not feasible to hindering?
follow a fixed predefined course in SDO-sessions the It is our goal to continue the development of
moderator has to control the process continuously. MUSSAT and to verify it in future but presently the
This task was underestimated in the past. To control answers to these aspects are still open.
the processes, moderate all technical discussions and
to make clear technical decisions in parallel seemed
not to be feasible anymore.
So the discipline ‘System Engineering’ has been THE ‘NOMINAL’ OPERATIONS
added. In SDO the system will be defined in co-
operation of all disciplines. But the System Engineer General. The success of the first project provoked
got the responsibility of all general system aspects that within our company most of the following
like proposals were prepared by SDO. The SDO
œ the control of the product tree operations became more routine and additional
aspects appeared.
œ the monitoring of the system design compliance
The first application was mainly focusing on the
with the system requirements
definition of a technical baseline of a satellite and a
œ the identification of options on system level
rough cost estimation. The following projects
œ the moderation of discussions in case of interface generally had different goals and constraints and so
conflicts we got a bright bandwidth of experience. The main
œ and generally the technical communicator and aspects we identified are related to
moderator for all disciplines between the œ Different project status as starting point
sessions.
œ Different goals and programmatic constraints
œ Personal assignment
The SDO Facility. The facility dedicated developed
œ Non-nominal SDO support for proposal
for SDO is found to be a major advantage of our
preparation
concept. This technical environment is strongly
supporting all sessions because:

±
Additionally we tried to improve SDO work based on For phase-A activities the presently defined SDO-
our experience with the first project by processes without detailed and formalized interfaces
œ Documentation of all results in our SDO report between the disciplines was already very satisfying
œ Establishment of our so called ‘Product Tree’ all parties. Especially a high flexibility is given for
the customer and the SDO-team.
The Process. As mentioned before SDO But for a preparation of a Phase-B/C/D project
distinguishes between the macro- and micro-process. we identified the need for a more detailed and a more
The macro-process is divided into three phases now. formal controlled process. The required level of
In the first phase two or three system oriented SDO specification and documentation is obviously higher
members are preparing the SDO project together with and so there is a strong potential for optimization of
the customer. General aspects like the SDO-process.
œ the goal of the SDO activities Generally a Phase-B/C/D proposal supported by
œ given technical, programmatic or cost constraints SDO has two crucial points. One is the establishment
œ results and supporting information about existing of a technical baseline in detail and its
studies, analyses and specifications documentation. Therefore SDO is generally well
œ involvement of non SDO colleagues prepared and efficient. But the other is to establish a
precise cost estimation based on a design,
œ will be discussed and documented for the SDO
development and verification planning’, also taking
team. Also the files for the product-tree and the
the different responsibilities and constraints of the
SDO-report will be implemented on the
involved companies into account. For that reason the
commonly used server.
normal process for C/D proposals is to write detailed
The second phase is the main phase were the specifications of the requirements on the potential
complete SDO team is working in parallel. It starts subcontractors and implementation of the
with the kick-off session and is finalized with the subcontractors cost inputs in the overall cost
baseline review in the last session. Up to now the estimation.
broken down standardized process, the micro- One of such a B/C/D proposal in which other
process, is only defined for establishing the ‘product companies had been involved was supported by SDO.
tree’ and the SDO-report. Fact is that the always A new approach was applied in which the main
different requirements on SDO are interfering SDO- requirements only had been defined in a set of
activities in a way that each project results in a specifications. The proposals of the customer had
dedicated process. So no common micro-process has been reviewed and taken into account.
been found up to now useful to be applied generally. For B/C/D proposals with interactivity of
During and between the sessions the product-tree external companies extended processes have to be
will be build up and maintained. Implementation of developed by the SDO in the future.
additional information like the heritage and
The Team. The nominal SDO-operations became
availability of hardware and software items have
more and more a challenge for the team. Most SDO
improved it. So the product-tree is now also used as
members are intentionally working for SDO in
main input for parametric cost estimations.
parallel to their main functions in operational
Additionally the SDO-report will be prepared in
projects. So a transfer of actual experience into SDO
parallel to the technical work. So during the sessions
is assured. But the disadvantage is the limited
all disciplines can document new aspects and
availability for SDO projects.
constraints directly into this ‘living’ document and
have direct access to the information given by other œ So it was decided to increase the number of
disciplines. members for each discipline.
The experience also shows that it is necessary to œ If necessary SDO-external colleagues supported
have four sessions included the kick-off as minimum. SDO-projects.
At the beginning the inputs for some disciplines are œ In some cases people selected for the future
defined on a low level of detail. E.g. it is not useful to project-team had been involved, required by the
start with the satellite configuration based on customer.
assumptions concerning the mass, dimensions and It became visible that the ‘normal’ SDO-process
accommodation rules of the different units. became slower. Colleagues newly involved in SDO
The third phase starts with the last session, the had to learn the process resulting in recurrent
baseline review. The SDO-report and the cost explanations and discussions. Additionally they were
estimation will be finalized and reviewed. Both forms not familiar with discipline specific tools, which are
the formal SDO-output for the customer. not standardized within the company. But they also
brought additional experiences from other projects
All presently realized projects can be classified in into SDO. It is noticed that potential SDO-members
œ Feasibility studies (Phase A) and phase A have to be trained and more involved in general
proposals SDO-activities for preparation of future SDO-
œ Full development (Phase B/C/D) proposals projects.

±
Most of the technical aspects growing in a project are was very successful and in the meantime several
completely covered by the defined disciplines. But proposals have been prepared applying the new
for specific aspects external support by specialist is method. The main characteristics of the SDO
needed, e.g. for harness, EMC, PA and cleanliness. compared with the ‘conventional’ approach for
Together with these specialists it has to be defined proposal preparation are:
how and at which time they will be involved in the œ the team which is trained in all aspects of SDO
process. work,
The great success of SDO became more public in our œ the process which drives and controls the
company. Most of the team members are in conflict development,
of interests of SDO, their operational project œ and the environment, facility and tools which are
activities and the interests of their product centers. strongly supporting the communication and
There is a implicit danger that team-members are technical work within the team.
using SDO for acquisition of work packages for their The following major issues have been experienced:
product centers. Generally the acquisition of projects
is the goal of SDO, but in specific cases it endangers œ A fully integrated tool environment is not the
the process finding the best technical solution for the most important element at the beginning. A team
required system. of excellent members having the required soft
But this aspect is more hindering projects in skills, which follows a well-defined process in a
which the conventional approach is applied. SDO supportive collaborative working environment is
assures that the customer gets a well-harmonized the key to success.
system design in a short time frame. By involving œ The team must own the process! It is not possible
SDO for a proposal he avoids the time consuming to confront the team members with processes and
period of forming a new team dedicated for his tools they have not defined/adapted themselves.
proposal including the inefficient discussions on Such a definition phase is needed to make a team
responsibilities and processes. Also due to a moderate out of a group of individuals.
communication between the different members the
progress of conventional projects is mostly slower. œ It is very important to have clearly defined
SDO guarantees the customer a team with well- objectives for a SDO study and to follow the
defined responsibilities, trained in communication process with high discipline. Since a high effort
and technical proposal preparation. is spent in a short timeframe the danger of
wasting money without progressing is very high.
The Facility. The facility was already verified in the
Therefore a moderator is needed for the team
first project and no deficiency has been identified, but who is not involved in technical work. The
limitations. We had been in the situation that two overall team success is very sensitive to the
concurrent projects required SDO involvement and it effectiveness of the moderator.
was decided that both had to be processed in parallel.
Clearly this situation was the biggest challenge for œ The work as a member of the SDO team has
the SDO team since the beginning, but it showed also turned out to be the most efficient training
limitations of the facility. In SDO we found that the towards an overall system understanding. The
development of two projects in parallel is the limit for density of learning during the integrated team
the facility and team, than also an increase of co- sessions is very high and has never been
ordination activities has to be taken into account. experienced before. This is an essential factor of
motivation for the team together with the fact
that there is basically no hierarchy within the
CONCLUSIONS virtual SDO team.
At Astrium GmbH in Friedrichshafen the idea of the
Integrated Concurrent Engineering and Concept
Design has been realized in the shape of the Satellite BIOGRAPHY
Design Office. The development was influenced
Rolf Mager. In 1988 Rolf was graduated in
strongly by
Mechanical Engineering at the University of Aachen.
œ the goal to design a satellite system together with
Since 1989 Rolf is with Astrium GmbH (former
the binding cost estimation for proposals,
known as Dornier Satellitensysteme). From the
œ the goal to minimize the costs and risk by beginning he was involved as System Engineer in all
considering as much as possible of the actual development phases of the project SCIAMACHY,
company experience presently he has the technical lead for preparation of
œ the very low initial budget for development of the Commissioning Phase. In parallel to these project
SDO compared to other examples. activities he also had been involved in a lot of
As a consequence an approach has been applied ‘conventional’ proposal activities.
which is more pragmatic with less initial effort spent Rolf has been member of the SDO since the
on integrated tools and models used in similar establishment of the first team, optionally active as
centers. Nevertheless the first introduction of SDO payload engineer, system engineering or team leader.

±
Ralf Hartmann. Ralf received a M.S. degree in
Electrical Engineering from the University of
Karlsruhe.
Since 1987 Ralf is with Astrium GmbH in
Germany. He has been Project Manager and System
Engineer for a number of smaller space projects and
he is now head of System Engineering Processes.
Ralf is actively involved in process improvement
initiatives at Astrium GmbH and the initiator and
team leader of the Satellite Design Office.
He is co-chair of the Modeling and Tools
Technical Committee of the International Council on
Systems Engineering (INCOSE) and the president of
GfSE -German Chapter of INCOSE.

±
±

You might also like