THE FUNCTION AND THE DESIGN PROCESS
Robbert J. Hamann
Fokker Space B.V.
PO Box 32070
2303 DB Leiden
The Netherlands
E-mail: R.Hamann@fokkerspace.nl
Paper presented at the
th
15 International Cost Engineering Congress
April 20-22 1998
Rotterdam
INTRODUCTION
In our projects at Fokker Space we are often, if not continuously, confronted with the following
issues:
• The actual design and development cost is greater than the one estimated at the beginning
of the project,
• The development time is longer than anticipated,
• The product sometimes is not performing according to expectation.
All three issues result in a more expensive product than desired.
Over the years we have found, that these undesired phenomena can be better managed, when
more attention is paid to the product’s functions, as seen from the (internal and external) user’s point
of view, and when the product’s functions are used to direct the design and development process and
the design choices made in the course of the project.
This paper has been written based on experience in development programs for space applications
(satellites, launchers). The observations made, however, are equally applicable to products intended
for use in our “earthly” environment, certainly if the product is complex or innovative or the project
team developing it is large in size.
THE ROLE OF FUNCTIONAL ANALYSIS IN THE DESIGN PROCESS
Definitions
For the purpose of this paper the following definitions are used:
A function is a task or activity to be performed by people, equipment, hardware or software.
A function relates to the intended use of a product.
Design is the activity to convert a Mission Need Statement or a set of User Requirements into
a product, which meets the stated needs or requirements.
A design is materialised in system elements, like personnel, hardware and software.
The user is either the end user of the product or the entity paying for (the development of) the
product (customer).
User and customer may both be present in a project, but may have (very) different User
Requirements.
Where to start a design
The justification of a product lies in its use, however abstract that use may be (e.g. the use of a car
to boost a driver’s image); the product has no right of existence in itself. In this context it is important
to note that the physical appearance of a product is only one of the many possible design
implementations of the set of functions it is supposed to perform.
The purpose of the design activity is to define a product that performs these functions as well as
possible within the constraints of cost, (development) time and performance (quality), and the design
problem to be solved is how to accomplish this.
15th ICEC; 1998; Rotterdam; the Netherlands
-1-
The necessary condition to be fulfilled prior to the start of the design activities proper is to know,
what the user’s intended use of the product will be:
• What he wants to do with the product (so its desired functions),
• How well he wants these functions performed and why,
• Which functions are the crucial ones.
Especially the last item is of importance, as it is the source for the set of criteria to be used in
taking design decisions.
During the design process the design team must continuously check whether the chosen design
implementation meets the requirements from the user’s point of view. To be able to do this, product
characteristics must be linked back to the functions the product has to perform. Also, when choosing
between design alternatives the key functions, in addition to the major constraints the product has to
comply with, again deliver the criteria to screen and rank the alternatives.
In the following sections we will illustrate these principles with a number of examples.
EXAMPLES OF INCORRECT OR INCOMPLETE FUNCTIONAL ANALYSIS
Huygens SM2 test model - Overspecified product performance
Huygens is a probe destined to descend in the atmosphere of Titan, one of the moons of Saturn.
As it is not possible to monitor and command the descent operation in real-time, it is of utmost
importance to thouroughly verify the correct functioning of this mission phase. To this purpose a
special test model has been constructed (the SM2), which has been submitted to a droptest from an
stratospheric balloon at 40 km altitude. Figure 1 shows the Huygens SM2 under the balloon gondola.
The Huygens SM2 test model specification required a Inertial Guidance Package as part of the test
model’s instrumentation. This package was a major cost driver (multi-Mfl) and the purpose of it was
unclear.
After lengthy discussions with the customer it was found out that the only essential function was to
enable trajectory reconstruction, other functions being covered by other types of sensors. The
prescribed implementation was a personal preference of the customer, allowing to obtain far more
detailed information of the parachute
Figure 1
The Huygens SM2 test model under the balloon gondola
15th ICEC; 1998; Rotterdam; the Netherlands
-2-
package behaviour, which had already been covered by other tests. The performance required for
the SM2 test has been achieved with a GPS differential mode sensor package at 1/20th of the cost.
The lesson learned is: Don’t jump to design implementation before a thorough functional analysis.
AR5 Main Engine Frame - Forgotten functions
The primary function of the Ariane 5 Main Engine Frame is to transfer the total thrust load of 115
tons during launch. The frame has a diameter of 5.4 m and a height of 3.5 m. Its mass is 1500 kg.
Far in the development phase, when full compliance to the specified loads had already been
proven, it appeared that the dimensioning load case was not during launch, but during horizontal
assembly. Such an event is typically the consequence of an incomplete functional analysis of the
(intended) product; both customer and contractor were too much concentrated on primary functions,
and did not consider sufficiently other life cycle phases.
EXAMPLES OF GOOD FUNCTIONAL DEFINITION
European Robotic Arm
The Mission Need Statement for the European Robotic Arm (ERA) at a certain time of its life cycle
was:
Demonstrate the use of robotic means to perform unmanned spacecraft capture, external
servicing and supply under ground supervision using an Automatic Transfer Vehicle (ATV)
and a dedicated target spacecraft.
The first steps toward design were made by analysing the operational functions, which ERA had to
perform. An example of part of the function series is shown in Figure 2.
1.
2.0
3.0
4.0
5.0
6.0
8.0
Transport ERA to
Check-out and
Launch and insert
Phase orbit and
Check-out ATV and
Perform extensive
Kourou
integrate ATV/ERA
ATV in orbit
insert in target
qualify RVC
ERA check-out
composite
G
9.0
Demonstrate
Demonstrate
Inspection
ORU Exchange
orbit
7.0
G
Perform
contingency
actions
11.
Demonstrate
Re-berthing
10.
12.
Demonstrate
Relocation
O
13.
14.
15.
16.
Demonstrate
Demonstrate
Evaluate
Complete ERA
Demonstrate ATV
Capture
Berthing
demonstration
demonstration
departure, de-orbit
results
mission
and disposal
17.
G
Perform
contingency
actions
9.1.
9.2.0
Move to ORU
9.3.0
Approach ORU
9.4.0
Grapple
9.5.0
Detach ORU
9.6.0
Extract ORU
9.7.0
Retract
9.8.0
Move with ORU
Aproach ORU
destination
9.9.0
Insert ORU
9.10.
Attach ORU
9.11.
Release ORU
9.12.
Retract ERA
A
Figure 2
AND
O
OR
G GO
G NO-GO
ERA function series
As a next step the functions may be assigned to personnel, equipment, hardware and software in
general terms. Figure 3 shows such an allocation for function 9.0, “Demonstrate Orbit Replaceable
Unit (ORU) exchange”.
15th ICEC; 1998; Rotterdam; the Netherlands
-3-
no.
9.1.0
9.2.0
function
Move to ORU
Approach ORU
9.3.0
Grapple ORU
9.4.0
9.5.0
9.6.0
9.7.0
9.8.0
Detach ORU
Extract ORU
Retract
Move with ORU
Approach ORU destination
9.9.0
9.10.0
9.11.0
Insert ORU
Attach ORU
Release ORU
9.12.0
Retract ERA
Figure 3
hardware or software allocation
Manipulator Joint Subsystem; Environment Data Base
Manipulator Joint Subsystem; Proximity Sensor (End Effector
Camera)
End Effector Grapple Mechanism; Grapple Fixture Presence
Sensor
Integrated Servicing Tool
Manipulator Joint Subsystem; Torque Force Sensor
Manipulator Joint Subsystem; Environment Data Base
Manipulator Joint Subsystem; Environment Data Base
Manipulator Joint Subsystem; Proximity Sensor (End Effector
Camera)
Manipulator Joint Subsystem; Torque Force Sensor
Integrated Servicing Tool
End Effector Grapple Mechanism; Grapple Fixture Presence
Sensor
Manipulator Joint Subsystem; Environment Data Base
ERA function allocation
Although no detailed design decisions are taken yet, a concept in general terms emerges, and,
even more important, the system level functions, which will have to be reflected by the hardware and
software characteristics, are clearly identified. This is a sound basis on which the further design can
be developed.
MIPAS Focal Plane Subsystem
MIPAS is an instrument on ENVISAT, an earth observation satellite, and is destined to generate
infra-red spectra of the erth atmosphere. The instrument images part of the atmosphere by means of
azimuth and elevation mirrors and generates an interferogram by means of a Michelson
interferometer. The two resulting beams are sized by a A-Focal Reducer (AFR) and projected on
eight detectors in the Focal Plane Inner Structure & Optics (FIS), which is to be kept on low (70 K)
temperatures to suppress undesired detector noise. The instrument is very sensitive to
contamination.
FPS>
Interferometer
Telescope
Photon flux
"Object Selection"
A-Focal Reducer (2x)
FIS Optics
Photon flux
"Amplitude Modulation;
Modulated
"Concentration
Modulated
"Matching incoming
Modulated
1 channel
Modulation frequency
photon flux
Photon Flux
photon flux
Photon Flux and
photon flux
is function of
2 channels
by a factor of 5"
2 channels
Detector Area"
2 channels
Wavelength"
"Reduction Parasitic
Photon Fluxes
[Key
[Transmission
[Conversion spectral
[Transmission]
performance
photon flux]
resolution to modulation
[Flux concentration]
parameters]
[Pointing accuracy]
frequency resolution]
[Matching]
<FPS
SPE/Ground Segment
PAC/PAW
Detector (8x)
Dichroic N (6x)
[Transmission]
Modulated
"Transmit Spectral
Spectral band from
"Conversion Photon
Modulated
"Pre-Amplification
Modulated
"Modulation Frequency
photon flux
Band Detector N"
modulated photon flux
Flux to Electron
electron flux
of Electron Flux"
electron flux
Determination; Wavelength
2 channels
"Reflect Remaining
8 channels
Flux"
8 channels
8 channels
Determination; Spectral
Resolution 4cm-1"
Photon Flux"
[Transmission and
[Detectivity (signal intensity)]
[S/N ratio]
reflection characteristics]
[Responsivity (modulation frequency)]
[Gain stability]
[Conversion modulated electron
flux to wavelength spectrum,
with intensity]
Figure 4
MIPAS components, main functions and key performance parameters
Figure 4 shows the functional block diagram for this process, where the criterion for the functional
analysis is “physical quantities flowing through (and being trasformed by) the system”. Although the
contract was only for the Focal Plane Subsystem (FPS) the analysis is done for the full instrument in
order to better understand the impact of FPS characteristics on the total process. Also, the key
performance parameters for each transformation step are identified. In this way the figure contains in
a very condensed form all essential functions of the instrument.
To obtain a more complete view on the MIPAS instrument figure 5 shows a functional break-down
of the Focal Plane subsystem. It shows the FPS components in logical groupings. A main distinction
15th ICEC; 1998; Rotterdam; the Netherlands
-4-
is made between snesor functions (the essentials), spacecraft functions (which must be present to
allow the sensor to function) and ground support functions (which are needed to produce the system).
Picturing the product in this way allows to introduce constraints and interfaces in the functional
model.
Focal P lane
S ubsystem
S ensor
Functions
O ptical P ath
B eam
R eduction
B eam
A lignm ent
S pectral
S eparation
Transm ission
C leanliness
S pacecraft
Functions
C ryogenics
FD IR
H eat Balance
E lectrical S ensors
E nvironm ental
M onitoring
R edundancy
O ptical
M echanical
E lectrical
Therm al
M echanical
O ther E nv. Effects
E MC
D ata H andling
A rchitecture
H arness
P ow er
P hoto-sensitive
D evices
S ignal
P rocessing
P re-am plification
Figure 5
G round S upport
E q. Functions
P ow er
Interfacing
MIPAS Focal Plane Subsystem functional break-down
The combination of the two views in figures 4 and 5 gives us a functional structure to which we can
attach detailed specified requirements, minimising the risk of overlooking aspects to be specified.
ARAFOM - Choosing and presenting the preferred solution
The Advanced Ridged Array for Olympus-type Missions (ARAFOM) was a qualification program for
a 2 to 7 kW family of solar arrays, primarily ment for telecommunication satellites. Main drivers for
the program were cost and production time reduction at equal performance. Basically a solar array
consists of the following elements (see Figure 6):
• Solar cells,
• Honey comb structure with a conducting Carbon Fiber Reinforced Plastic (CFRP) skin,
• Kapton foil between cells and structure for electrical isolation.
Solar Cell
Contact pads
Kapton foil
Carbon Fiber Reinforced Plastic
Honeycomb structure
Figure 6
Typical solar array construction
The design issue at stake was to find a solution for an electrical short of solar cells to CFRP skin,
which occurred on a previous mission. Fokker Space’s solution was to increase the thickness of the
15th ICEC; 1998; Rotterdam; the Netherlands
-5-
Kapton film to 50 micrometer, while the customer had a preference to replace CFRP with Kevlar,
which is an intrinsic isolator.
Two other possible solutions were offered. In an objective trade-off all design options have been
compared against the same, key driving requirements: development cost, development risk, isolation
performance and mass performance. The relative weight of these criteria have been set beforehand
as well as the success criteria. Results of the trade have been presented in a simple way (see Figure
7). In this figure the weiight of the criteria is presented by the column width, while the success
criterion is presented by a colour ranging from red for “unacceptable” to green for “exceeds
requirements”.
CRITERION
Isolation
performance
Mass
performance
Dev.
Cost
Development
Risk
CFRP skins + 50 µm
Kapton film
(current baseline)
CFRP skin +
alternative film
good
(no anomalies)
nominal
no risk
very good
(TBC by tests)
nominal
Kevlar composite skin
very good
13 % heavier
Kevlar composite skin
+ CFRP doubler
Better than
baseline
(not proven)
5 % heavier
zero
delta
cost
slight
delta
cost
high
delta
cost
high
delta
cost
OPTION
Figure 7
product not yet
developed
routine space
development
possible
delamination
Excellent; exceeds requirements
Correctable deficiencies
Good; meets requirements
Unacceptable
Presentation of trade-off results
This very compact presentation convinced the customer in a very efficient way, that the proposed
baseline was the optimum choice.
OVERVIEW OF TOOLS FOR FUNCTIONAL AND OPERATIONAL ANALYSIS
Many tools are available to support functional and operational analysis, ranging from simple multipurpose office tools to more sophisticated specific integrated tools. Figure 8 gives an overview of
tools and their major advantages and disadvantages.
Tool and use
Block diagram drawing S/W (e.g.
Visio) for functional flows, breakdown
S/W development packages for
functional analysis (e.g. System
Architect)
Spreadsheet for operational
timelines (e.g. EXCEL)
Advantage
Cheap; easy to use; can be
customized; generally good
presentation
Relatively easy to use; good
consistency
Small Systems Engineering S/W
packages (e.g. CASETS)
Cheap; incorporate many
functional and operational analysis
functions; good consistency
Big Systems Engineering S/W
packages (e.g. RDD-100)
Integrate functional and
operational analysis with many
quantitative aspects; good
Cheap; flexible in applications;
allow easy incorporation of
quantitative data
15th ICEC; 1998; Rotterdam; the Netherlands
-6-
Disadvantage
No other logics behind it than the
designer’s; bad consistency
Difficult to customize; rigid
reporting; allow no exceptions;
rather expensive
No relation with functional or
operational analysis; underlying
algorithms difficult to read for nonproject people
Bad presentation; inflexible in use;
rather difficult to work with;
sometimes difficult to map on the
company’s design processes and
practices
Expensive; require expert
knowledge to use; sometimes
difficult to map on the company’s
Tool and use
Figure 8
Advantage
consistency
Disadvantage
design processes and practices
Comparison of tools for functional and operational analysis
The choice of a tool for functional and operational analysis will always depend on the character and
size of the project and the company’s way of working.
THE POTENTIAL OF FUNCTIONAL ANALYSIS IN DIRECTING THE DESIGN
Advantages
Advantages of defining a product by means of functions are:
• It forces the designer to examine the intended use of the product critically and hence to
understand his customer or user well.
• It prevents solving the problem (designing the product) before the problem (intended use)
is known.
• It allows to choose from all possible (design) implementations the one that answers best
the intended use of the product.
• It allows the identification and definition of modular functions (that is: functions with
“clean” interfaces), promoting the definition of modular hardware and software
components.
• It sponsors the probability for real innovation, as it (temporarily) fences off the rush into
re-use of established solutions.
Disadvantages
There are also some disadvantages:
• There is a danger to remain abstract, when thinking in functions.
• Engineers like to make something (it is their function), not to be their customer’s shrink.
• It may seem superfluous (and costly) to go through this phase when well proven design
implementations exist.
DO’S and DON’TS
Our past experience has led us at Fokker Space to formulate explicitly some guidelines for our
design teams:
− Even when the design implementation seems straight forward, take the time to establish
• the product’s desired functions,
• the product’s key functions and resulting (quantified) performance requirements,
• all options likely to answer to the desired functions.
− Rationally select the better design amongst the alternatives using (key) functional performance
requirements as a selection criterion.
− Keep an open eye for the product’s undesired functions: emerging properties (e.g. a car, designed
to provide individual transportation, produces pollution as a by-product).
− When developing the design, continuously check its performance against the key functional
performance requirements to obtain a compliant product, which the user wants, and to avoid suboptimization on the total by optimizing the detail.
There are also a number of “deadly sins”, which we also canvas in the company:
− When choosing for existing design don’t forget to examine the extent up to which the design
complies with the intended functions and identify undesired properties of the design for the
intended use.
− Don’t accept prescribed design implementations without investigating why they are prescribed
(what is their intended function); propose your customer alternatives, comparing them to their
preferred solution.
− Don’t limit yourself to one functional view of your product; the (relatively small) effort of analyzing
your system from different functional points of view considerably improves your understanding of
the product.
CONCLUSIONS
15th ICEC; 1998; Rotterdam; the Netherlands
-7-
Traditionally engineers tend to start their design implementation activities before they understand
their customer’s real problem (hence his real need), which their design is intended to solve. The
paper identifies some reasons why this occurs so often.
A powerful means to prevent this happening is to spend time, especially early in the design
process, in analysing the intended use of the product.
The functional and operational analysis plays an important role in this and the primary functions
which are identified may be used as the guiding criteria and metrics for design decisions.
In summary we may conclude, that defining a product in terms of functions
• improves its usefulness,
• increases the chance on real innovation,
• supports a good rationale for design option selection,
• decreases the risk that the final design (unwantedly) does not meet the a priori
expectations.
ACRONYMS AND ABBREVIATIONS
EMC
Env.
FIDR
GPS
PAC
PAW
RVC
SPE
Electro-Magnetic Compatibility
Environmental
Fault Isolation, Detection and Recovery
Global Positioning System
Pre-Amplifier Cold
Pre-Amplifier Warm
Rendez-Vous and Coupling
Signal Processing Electronics
15th ICEC; 1998; Rotterdam; the Netherlands
-8-