Spl. Independe ntei 313, 060042 Bucuresti Romania www .aero.pub .ro Str. Gh. Polizu 1 -5 tel: (+40)21 402 3812 inginerie.aerospatiala@upb.ro „Elie… [619452]

1

University
Politehnica
of
Bucharest Faculty
of
Aerospace
Engineering Air Navigation
Spl. Independe ntei 313, 060042
Bucuresti Romania www .aero.pub .ro Str. Gh. Polizu 1 -5
tel: (+40)21 402 3812
[anonimizat]
„Elie Carafoli” Aerospace Sciences Department
A System Engineering Approach for an Aircraft
Life Cycle Design
BEng Final Project
Author: Golu Mihai -Alexand ru
Supe rvisor(s): Prof. Dr. Ing. Ion Fuiorea (UPB)
Session: July 2017
1

2
2 Anti-Plagiarism Declaration

I the undersigned _____Mihai -Alexandru Golu_________________, student: [anonimizat], Faculty of Aerospace Engineering declare herewith and certify that this
final project is the result of my own, original, individual work. All the external sources of
information used were quoted and included in the References. All the figures, diagrams, and
tables taken from external sources include a reference to the source.

Date: _________ Signature: __________________________

3
List of figures

Fig. 1.1.1 – Three Activities of Systems Engineering Management
Fig. 1.2.1 – Simple schematic of the design process
Fig. 1.2.2 – Development Phasing
Fig. 1.2.1.2 – Breakdown of the aircraft into system components
Fig. 1.2.2.1.1. – Increasing numbers of design parameters.
Fig. 1.2.2.4.1. – Simplified system schematic
Fig. 1.3.1.1. – System flexibility, change and time
Fig. 1.3.1.2. – System flexibility
Fig. 1.3.2.1.1 – Loss of cost control over the life cycle.
Fig.1.3.2. 1.2 – Systems engineering process model.
Fig. 1.3.3.1 – Systems engineering model for acquisition costing.
Fig. 1.3.3.1.1 – Integrating disciplines that drive design at various levels of definition.
Fig. 1.3.3.1.2 – Matrix of cost estimating techniques.
Fig. 1.3.3.3 – The genetic -causal costing model.
Fig. 1.3.3.2.1. – Modelling design cost using high level cost drivers.
Fig. 1.3.3.2.2 -Modelling production cost at a cost component level.
Fig 1.3.3.2.3 .3 – Predictions for procured cost based on neural net and regression techniques.
Fig. 1.3.3.2.3 .4 -Typical breakdown of operating cost for a regional jet.
Fig. 2.1 – System operational and maintenance flow
Fig. 2.1.1 – The basic elements of logistics
Fig. 2.1.2. – System support infrastructure
Fig. 2.2.1 – The system life -cycle phases
Fig. 2.2.2 – The interrelationships of the life -cycle phases in a system development
Fig. 2.2.3 – The major steps in system design and development
Fig. 2.2.4 – The interface relationships between basic design and logistics functi ons
Fig. 2.3.1. – Total cost visibility
Fig. 2.3.2 – Opportunity for impacting logistics and system cost -effectiveness
Fig.2.3.3. – The consequence of not addressing supportability from the beginning
Fig. 3.13.1 – Basic Ingredients of cost -effectiveness

4
Acronyms

ABC =Activity Based Co sting
AC/CBR = Analogous Costing and Cas e Based Reasoning
CAD= Computer -aided design
CALS= Continuous Acquisition and Life -Cycle Support
CDR= Critical Design Review
CIMM =Computer -aided Integrated M aintenan ce Management
CM=Confi guration Management
DE=Detailed Estimating
DOC =Direct Operating Cost
DOD=Department of Defense
GCC= Genetic Causal Costing
ILS= Integrated logistic support
MADS =Maintenance Analysis Data System
MDO =Multi -Disciplinary Optimization
MLA =Maintenance Level Analysis
MTA =Maintenance Task Analysis
NN/FL=Neural Networks and Fuzzy Logic
PE=Parametric Estimating
SA=Supportability Analysis
SE=System Engineering
TPM =Total productive maintenance
TQM =Total Quality Management

5
Executive Summary

The main purpose of this thesis is to present a system engineering approach t o the life -cycle of an aircraft,
showing and developing the entire aircraft cycle to the aim of broadening up the view on how to think
about the acquisition an of aircraft, what a re the implications of such a purchase and how its cost will
unwind during its lifecycle.

Of course, every model has its own implications, costs maintenance philosophy and necessities , so this
paper is a general representation of how to unravel and use t he notions for that specifi c final product and
manage it during its life -cycle. The goal is to create a core understanding of how this concept s are applied
and to get acquainted with the unfolding stages of such a system.

Actually, system engineering invo lves the integrated and coordinated efforts of many different design
and related disciplines, applied as part of a top -down/bottom -up process, evolving from the point when a
consumer need is first identified, through development, construction and/or produc tion, distri bution,
utilization and support and the ultimate system retire ment.
To achieve this, we are faced with a demand for an interdisciplinary effort throughout the system design
and development process such that all design objectives are to be met in an effective manner. This requires a
complete understanding of the many differ ent design disciplines and their interrelationships, particularly
for large projects such as a commercial aircraft in a dynamic company environment.
The system engineering process itself has a strong element of risk management built in the design
process. However, much of the estimating task remains in the domain of specialist engineers and their
technical knowledge of the modes of failure of a given e lement. There are software tools which can
estimate risk but these are oriented towards software and are not integrated tightly with the design
process, so the character of predictions it is indeed approximated, but can never be certain. For example, a
schedule maintenance is often delayed and the operating hours pushed to the limit in a fast -growing
company environment for profit , but as a result they can lead to more complicated maintenance
operations due to overload or even to breakdown.
The technical ar chitecture and tools mentioned here can provide some capability to have elements of risk
assessment linked with the design synthesis process but again this topic has yet to be an integral part of
the design process.
To this point, it is the design environ ment which is the key focus of attention. However, the physical
construction of the product and its subsequent life are more important in the end. The current tight
economic circumstances are driving the need for more effective and efficient design approac hes and
awareness of customer requirements and their impact on design. The integrated tools can now be
combined with the latest digital manufacturing and costing tools to produce information on the
production, cost and life -cycle impact of the product.
In terms of mission fulfillment, system effectiveness and total life -cycle cost one must keep an eye on the
producibility as a measure of the relative ease and economy of producing a system or a product. The
characteristics of design must be such that an ite m can be produced eas ily and economically, using
conventional and flexible manufacturing methods and processes without sacrificing function,
performance, effectiveness, or quality.

6
All in all this project is also focused on getting the reader familiar to the estimative cost of fabrication,
assembly, and test of operatio nal systems, production models and associate initial logistic support
requirements as for example test and support equipment development, spare parts provisioni ng, technical
data development . Further on, as continuous improvement is seen as a more frequent practice it is
emphasized as applying to engineering, production, and support processes. The objective is to seek
improv ement on a day -to-day basis, rather than the often imposed last minute struggle to comply with a
standard.

7

Rezumat

Scopul principal al acestei teze este de a prezenta o abordare prin prisma inginerie sistemelor a l ciclului
de viață al unei aeronave, prezentând și dezvoltând intregul ciclu al aeronavei, pentru a extinde punctul de
vedere asupra modului de a gândi la achiziționarea de aeronave, ce implicații O achiziție și modul în care
costul acesteia se va relaxa pe durata ciclului de viață.
Desigur, fiecare model are propriile implicații, filosofia mentanantei, a costurilor și necesitățile, astfel
încât această lucrare este o reprezentare generală a modului în care urmeaza să se descopere și să se
utilizeze noțiunile pentru produsul specific și să se gestioneze intreg ciclul de viață. Scop ul este de a crea
o înțelegere de bază a modului în care aceste concepte sunt aplicate și de a se familiariza cu etapele de
desfășu rare ale unui astfel de sistem.
Pentru realizarea obiectivului menționat mai sus, au fost urmate mai multe etape:
De fapt, ingineria sistemelor implică eforturile integrate și coordonate ale diferitelor discipline de
proiectare și conexe aplicate ca parte a unui proces de sus în jos / de jos în sus, evoluând de la punctul în
care un consumator este identificat pri n dezvoltarea , construcția si p roducția, distribuți a, utilizarea și
susținerea și disponibilizarea sistemului final.
Pentru a realiza acest lucru, ne confruntăm cu o cerere a unui efort interdisciplinar pe tot parcursul
procesului de proiectare și dezvoltare, astfel în cât toate obiectivele de proiectare să fie îndeplinite într -un
mod eficient. Acest lucru necesită o înțelegere completă a numeroaselor discipline de proiectare diferite și
a interrelațiilor lor, în special p entru proiectele mari, cum sunt aeronavele și mod elul ciclului lor de viață .
Procesul de inginerie a sistemului are un element puternic de management al riscului, integrat în procesul
de proiectare. Cu toate acestea, o mare parte din sarcina de estimare rămâne în domeniul inginerilor
specializați și cuno ștințele lor tehnice privind modurile de eșec al unui element dat. Există instrumente
software care pot estima riscul, dar acestea sunt orientate către software și nu sunt integrate strâns cu
procesul de proiectare, astfel încât caracterul predicțiilor poa te fi într -adevăr foarte apropiat, dar nu poate
fi niciodată sigur. De exemplu, o mentenanta programata este adesea supusa întârzierii , iar ciclii de
functionare dusi la limita într-un companie cu o creștere rapidă, pentru profit, dar în consecință pot
conduce la operații de întreținere mai complicate din cauza suprasolicitarii.
Arhitectura tehnică și instrumentele menționate aici pot oferi o anumită capacitate de a avea elemente de
evaluare a riscurilor legate de procesul de sinteză a designului, dar din n ou acest subiect nu trebuie să facă
parte integrantă din procesul de proiectare.
În acest moment, mediul de proiectare este centrul atenției. Cu toate acestea, construcția fizică a
produsului și viața sa ulterioară sunt mai importante în cele din urmă. Con dițiile economice stricte actuale
determină necesitatea unor abordări de design mai eficiente și mai eficiente, precum și conștientizarea
cerințelor clienților și a impactului lor asupra desi gnului. Instrumentele integrate pot fi acum combinate
cu cele mai recente instrumente digitale de fabricație și de calcul pentru a produce informații despre
impactul produsului, costul și ciclul de viață al produsului.

8
În ceea ce privește îndeplinirea misiunii, eficiența sistemului și costul total al ciclului de viață, trebuie să
țineți cont ca productivitatea este o măsură de relativă ușurință și economie a producerii unui sistem sau a
unui produs. Caracteristicile proiectului trebuie să fie astfel încât un element să poată fi produs ușor și
economic utilizând metode și procese de fabricare convenționale și flexibile, fără a sacrifica funcția,
performanța, eficiența sau calitatea.
In concluzie, acest proiect se concentrează si pe familiarizarea cititorului cu estimarea costurilor de
fabricație, asamblare și testare a sis temelor operaționale, a modelelor de producție și a cerințelor logistice
de suport logice asociate, cum ar fi dezvoltarea echipam entelor de testare și suport, furnizarea pieselor de
schimb, dezvoltarea datelor tehnice. În continuare, deoarece continua îmbu nătățirea este văzută ca o
practică din ce in ce mai frecventă, se subliniază că se aplică proceselor de inginerie, producție și supor t.
Obiectivul este de a căuta performanta in fiecare zi , mai degrabă decât a cauta lupta de ultim m oment
pentru a fi in conform itate cu un standard.

9
Content

Anti-Plagiarism Declaration ………………………….. ………………………….. ………………………….. ……………………. 2
List of figures ………………………….. ………………………….. ………………………….. ………………………….. ……………. 3
Acronyms ………………………….. ………………………….. ………………………….. ………………………….. …………………. 4
Executive Summary ………………………….. ………………………….. ………………………….. ………………………….. …… 5
Rezumat ………………………….. ………………………….. ………………………….. ………………………….. …………………… 7
Introduction ………………………….. ………………………….. ………………………….. ………………………….. …………….. 11
1. System Engineering ………………………….. ………………………….. ………………………….. ………………………. 12
1.2 Systems Engineering Management ………………………….. ………………………….. ………………………….. … 12
1.2.1. Basic aircraft design ………………………….. ………………………….. ………………………….. …………….. 16
1.2.2. Integration of design and analysis into SE ………………………….. ………………………….. ……………. 18
1.2.2.1. Conceptual design ………………………….. ………………………….. ………………………….. ………….. 18
1.2.2.2 Preliminary design ………………………….. ………………………….. ………………………….. ………….. 19
1.2.2.3. Detail design ………………………….. ………………………….. ………………………….. …………………. 20
1.2.2.4 General engineering design ………………………….. ………………………….. ………………………….. . 21
1.3. Rethinking the analysis and design process ………………………….. ………………………….. ………………… 23
1.3.1. Parameters versus Constrains ………………………….. ………………………….. ………………………….. …. 24
1.3.2. Economics and digital manufacturing ………………………….. ………………………….. ……………………… 26
1.3.2.1. Cost and SE ………………………….. ………………………….. ………………………….. ………………………. 27
1.3.3. Relationship back to design: Cost related life cycle view ………………………….. ……………………….. 29
1.3.3.1. Cost integrated design ………………………….. ………………………….. ………………………….. ………… 30
1.3.3.2. Cost modelling at various stages of the life cycle ………………………….. ………………………….. .. 33
2. Logistics ………………………….. ………………………….. ………………………….. ………………………….. ……………… 36
2.1. Elements of logistics ………………………….. ………………………….. ………………………….. …………………… 37
2.2 Logistics in the system Life Cycle ………………………….. ………………………….. ………………………….. …. 40
2.3. Need for Logistic Engineering ………………………….. ………………………….. ………………………….. ……… 46
2.4 Terms and definitions ………………………….. ………………………….. ………………………….. ………………….. 49
2.4.1 System Engineering ………………………….. ………………………….. ………………………….. ………………. 49
2.4.2. Concurrent Engineering ………………………….. ………………………….. ………………………….. ………… 50
2.4.3. Integrated Logistic Support ………………………….. ………………………….. ………………………….. ……. 50
2.4.4. Logistic Engineering ………………………….. ………………………….. ………………………….. …………….. 51
3. Maintenance ………………………….. ………………………….. ………………………….. ………………………….. ………… 55
3.1. Maintenance level ………………………….. ………………………….. ………………………….. ………………………. 55

10
3.2. Maintenance concept ………………………….. ………………………….. ………………………….. ………………….. 55
3.3. Maintenance plan ………………………….. ………………………….. ………………………….. ……………………….. 55
3.4. Total Productive Maintenance (TPM) ………………………….. ………………………….. ……………………….. 56
3.5. Human Factors ………………………….. ………………………….. ………………………….. ………………………….. . 56
3.6. Software engineering ………………………….. ………………………….. ………………………….. ………………….. 57
3.7. Producibility ………………………….. ………………………….. ………………………….. ………………………….. ….. 57
3.8. Disposability ………………………….. ………………………….. ………………………….. ………………………….. …. 57
3.9. Total Quality Management (TQM) ………………………….. ………………………….. ………………………….. .. 58
3.10. Configuration Management ………………………….. ………………………….. ………………………….. ……….. 58
3.11. System effectiveness ………………………….. ………………………….. ………………………….. …………………. 59
3.12. Life -Cycle Cost (LCC) ………………………….. ………………………….. ………………………….. ……………… 59
3.13. Cost -Effectiveness (CE) ………………………….. ………………………….. ………………………….. …………….. 60
Conclusion ………………………….. ………………………….. ………………………….. ………………………….. ……………… 61
Acknowledgements ………………………….. ………………………….. ………………………….. ………………………….. ….. 62
Biography ………………………….. ………………………….. ………………………….. ………………………….. ……………….. 63

11
Introduction

Simply stat ed, a syst em is an int egration of p eople, products and proc esses that provid e a capability to
satisfy a stat ed need or obj ective.

Broadly defined, syst em engineering is the effective application of sci entific and engineering efforts to
transform an op erational n eed into a d efined syst em configuration through th e top-down it erative process
of requirements analysis, functional analysis, allocation, synth esis, d esign opti mization, t est and
evaluation . The system engineering proc ess, in it’s evolving of functional d etail and d esign r equirements,
has as its goal th e achievement of the proper balanc e between operational , economic and logistic factors.
[2]
System engineering is th e application of sci entific engineering efforts to:
 Transform an op erational n eed into a d escription of syst em performanc e param eters and a syst em
configu ration through th e use of an it erative process of d efinition, synth esis, analysis, d esign, t est
and evaluation;
 Integrate related technical param eters and ensure compatibility of all physical, functional and
program int erfaces in a mann er that optimiz es the total syst em definition and d esign;
 Integrate reliability, maintainability, saf ety, human, supportability, producibility, disposability
and oth er such factors into th e total engineering effort to m eet cost, sch edule and t echnical
performanc e objectives.
The system engineering proc ess is inh erent within th e overall syst em lif e cycle:
The initial emphasis is on a top -down, int egrated, lif ecycle approach to syst em design and
developm ent. This includ es probl em definition and th e identification of custom er needs, the conductanc e
of feasibility analysis, th e developm ent of op erational r equirements allocation and oth er proc esses which
will b e furth er investigat ed. Subs equently, th ere is the iterative process of ass essment and syst em
validation, and th e incorpora tion of chang es for product/proc ess improv ement.
Although th e process is mor e directed to th e early stag es of syst em design and d evelopm ent,
maintaining awar eness of the activiti es in th e latter phas es of th e construction/production, operational
use, and system maint enanc e and support is essential for und erstanding th e consequences of earlier
decisions and th e establishm ent of b enchmarks for th e futur e. In oth er words, th e feedback loop is critical
and an int egral part of th e system engineering proc ess. [2]
The application of syst ems engineering (S E) to comm ercial aircraft pr esents a s et of r equirements
and proc esses uniqu e to the comm ercial aircraft industry. S E can b e appli ed to n ew, derivativ e, and
chang e-based aircraft d esign. Th e conc ept of an aircraft syst em extends b eyond th e aircraft its elf. Th e
hierarchy of th e aircraft archit ecture is embedded in pr esent-day proc esses.
Aircraft lif e-cycle functions follow th e classical lif ecycle functions. Th e aircraft -level functions
can b e flowed to airc raft and subsyst em level functions and r equirements. R equirements which r eceive
more attention than oth ers includ e performanc e, safety, cost, r eliability, and w eight, not n ecessarily in that
order. Economic r equirements includ e both mark et-driven and particular custom er requirements.
Certification guid elines for th e aircraft, including its softwar e, incorporat e SE principl es. Strong S E
manag ement is r equired for th e successful d evelopm ent of comm ercial aircraft. [5]

12
1. Syst em Engin eering

Systems engineering consists of two significant disciplin es: the technical knowl edge domain in which th e
systems engineer operates and syst ems engineering manag ement.
In practic e, this proc ess driv es the design d evelopm ent in many a erospac e compani es and in wid er
engineering industry. It brings in consid eration of many issu es beyond the technical d esign chall enge.
Issues such as risk, d erivation of th e functional and physical archit ecture of the product com e to the fore
and d esign synth esis becomes a supporting t echnolo gy helping to mak e the decisions support th e
developm ent of th e system archit ecture of the product.

Three commonly us ed definitions of syst ems engineering ar e provid ed by th e best known t echnical
standards that apply to this subj ect. Th ey all hav e a common th eme:
 A logical s equence of activiti es and d ecisions that transforms an operational n eed into a
description of syst em performanc e param eters and a pr eferred syst em configuration. [1]
 An int erdisciplinary approach that encompass es the entire technical effort, and evolves into and
verifies an integrated and lif e cycle balanc ed set of syst em people, products, and proc ess solutions
that satisfy custom er needs. [1]
 An int erdisciplinary, collaborativ e approach that d erives, evolves, and v erifies a li fe-cycle
balanc ed syst em solution which satisfi es custom er expectations and m eets public acc eptability. [1]

1.2 Syst ems Engin eering Manag ement

As illustrat ed by Figur e 1-1, syst ems engineering manag ement is accomplish ed by int egrating thr ee major
activiti es:
 Developm ent phasing that controls th e design proc ess and provid es bas elines that coordinat e
design efforts
 A syst ems engineering proc ess that provid es a structur e for solving d esign probl ems and tracking
requirements flow through th e design effort
 Life cycle integration that involv es custom ers in th e design proc ess and ensures that th e system
developed is viabl e throughout its lif e.

Each on e of these activiti es is n ecessary to achi eve proper manag ement of a developm ent effort. Phasing
has two major purpos es: it controls th e design effort and is th e major conn ection b etween the technical
manag ement effort and th e overall acquisition effort. It controls th e design effort by d eveloping d esign
baselines that gov ern each l evel of d evelopm ent. It int erfaces with acquisition manag ement by providing
key events in th e developm ent proc ess, wh ere design viability can b e assessed. Th e viability of th e
baselines developed is a major input for acquisition manag ement Milestone (MS) decisions. [1]
As a r esult, th e timing and coordinatio n between technical d evelopm ent phasing and th e acquisition
schedule is critical to maintain a h ealthy acquisition program.

13
Figur e 1-2.1 Three Activiti es of Syst ems Engin eering Manag ement

The systems engineering proc ess is th e heart of syst ems engineering manag ement. Its purpos e is to
provid e a structur ed but fl exible process that transforms r equirements into sp ecifications, archit ectures,
and configuration bas elines. Th e disciplin e of this proc ess provid es the control and traceability to develop
solutions that m eet custom er needs. Th e systems engineering proc ess may b e repeated one or mor e times
during any phas e of the developm ent proc ess.

Life cycle integration is n ecessary to ensure that th e design solution is viabl e throughout th e life of the
system. It includ es the planning associat ed with product and proc ess developm ent, as w ell as th e
integration of multipl e functional conc erns into th e design and engineering proc ess. In this mann er,
product cycl e-times can b e reduced, and th e need for r edesign and r ework substantially r educed.

Developm ent phasing

SE is incr easingly b eing appli ed in comm ercial practic e. For exampl e, discuss th e principl es of S E as
appli ed to aircraft d evelopm ent. Th e purpos e of this pap er is to show how th e uniqu e aspects of
comm ercial aircraft d evelopm ent would b e appli ed within th e SE process.

14
Developm ent usually progr esses through distinct l evels or stag es:
 Conc ept level, which produc es a syst em conc ept description (usually d escrib ed in a conc ept
study);
 System level, which produc es a syst em description in p erformanc e requirement terms; and
 Subsyst em/Compon ent level, which produc es first a s et of subsyst em and compon ent product
performanc e descriptions, th en a set of corr esponding d etailed descriptions of th e products’
charact eristics, essential for th eir production.

Fig. 1.2.2 Simpl e schematic of th e design proc ess

The systems engineering proc ess is appli ed to each l evel of syst em developm ent, on e level at a tim e, to
produc e these descriptions commonly call ed configuration bas elines. This results in a s eries of
configuration bas elines, one at each d evelopm ent level. Th ese baselines become more detailed with each
level.
In the Departm ent of D efense (DoD) th e configuration bas elines are called the functional bas eline for th e
system-level description, th e allocat ed bas eline for th e subsyst em/compon ent performanc e descriptions,
and th e product bas eline for th e subsyst em/compon ent detail d escriptions.
Figur e 1-2.2 shows th e basic r elationships b etween the baselines. Th e triangl es represent bas eline control
decision points, and ar e usually r eferred to as t echnical r eviews or audits.

It is cl ear that th e current industrial environm ent has significantly expand ed the remit and expectations
placed on d esigners. It is no long er suffici ent to provid e a high p erformanc e product that satisfi es strict
technical r equirements. Th e inclusion of r equirements d efinitions and lif e-cycle issues, through to
eventual d ecommissioning, has r esulted in a much broad er definition of multi -disciplinarity and now
encompass es non -technical disciplin es which oft en do not hav e analytical mod els.

15
Figur e 1.2.2 D evelopm ent Phasing
New mod els for th ese disciplin es are needed but equally th ere is a n eed for a broad er fram ework within
which th ese models may b e embedded. Th e design proc ess then requires a new paradigm in which
analysis and d esign synth eses are tightly int egrated with S E to facilitat e the wider life-cycle issues. Th ese
are difficult enough, but th e global natur e of aerospac e and th e vast mon etary sums r equired to d evelop
products r equires that d esign t eams ar e multi -national and th e products ar e designed in collaboration
across what is known as th e ‘Virtual Enterprise’ [8].

16

1.2.1. Basic aircraft d esign
Figur e 1.2.1.1 – Aircraft mod el
The airplan e is describ ed by a s et of param eters, in th e category: g eometry, p erformanc e limits, engines,
operational conditions. Mor e specifically, th e model consists of:
1. Geometry deck. This is divid ed into its major subsyst ems: a fus elage, wing, wingl et, horizontal and
vertical tail plan e, engines, pylons, flaps, slats, ail eron, rudd er, elevator, landing g ear group. A typical
input fil e is mad e of arrays of coordinat es for each group d erived from thr ee-views (top, sid e, front),
generally with th e airplan e on th e ground.
2. Structural and limitation param eters. These are: critical w eights, fu el capacity, d esign rang e, maxim um
operating Mach numb er, center of gravity rang e, pass engers, seating, cr ew, etc. The structural param eters
are required to run th e code, but th e limitation param eters are not. In particular, th e model itself cannot
predict th e maximum op erating Mach numb er or th e service ceiling, b ecause additional constraints
intervene (for exampl e, structural loads or supplying minimum cabin pr essure). Furth ermor e, the CG
position and rang e are fixed data, b ecause in most cas es the arm of th e fuel tanks and th e arm of th e
payload ar e not known.
3. Operational param eters: required rang e, required payload, flap position at tak e-off and landing, lift
coefficient in tak e-off and landing configuration, Auxiliary Pow er Unit (APU) fu el consumption, etc.
4. Atmosph eric param eters: airport altitud e at departur e and arrival, winds at tak e-off, cruis e, descent and
landing (only tail – and h ead-winds ar e consid ered), temperatur es abov e or below th e standard day, runway
conditions (dry, w et, icy, etc.).
5. User settings : climb and d escent sch edule, cruis e flight l evels, baggag e/pax, w eight of on -board
services/pax, etc.

17
6. Aerodynamic mod el, as d escrib ed separat ely in S ection 2.2.
7. Engine model, as d escrib ed separat ely in S ection 3.
8. Nois e model, as d escrib ed separat ely in S ection 4.

Fig. 1.2.1.2 Br eakdown of th e aircraft into syst em compon ents

18
1.2.2. Int egration of d esign and analysis into S E

It is us eful to first consid er the more traditional approach and ass ess how it can b e used mor e
effectively before describing how d esign synth esis can b e integrated with S E.

1.2.2.1. Conc eptual d esign

The conc eptual d esign phas e addresses the highest level questions about th e propos ed aircraft. In
particular, th e main r equirements and d esired functions ar e consid ered, and normally a numb er of
potential configurations ar e outlin ed which will und ergo a trade-off. [3]
The solution which b est match es the requirements will b e chosen. Lik e any d esign proc ess this phas e is
highly it erative, but it t ends to b e the most op en and unconstrain ed phas e of aircraft d esign so th e largest
numb er of d esign solutions can b e tried here. The result of th e conc eptual phas e should b e a configuration
with th e basic siz e and arrang ement of its main asp ects, such as th e wing, empennag e, engines, fus elage,
control surfac es, etc. [3]
These data ar e built from a f ew initial equations and empirical data that provid e a starting point for th e
design to proc eed. In this traditional approach for pow ered aircraft two k ey equations dominat e the design
and th ese relate to the initial estimat e of weight, and th e range equation which provid es for th e lift to drag
ratio and fu el efficiency co efficient. [3]

Eq. (1) provid es an estimat e of W 0 based on th e weight of cr ew (W crew), payload (W payload), fuel weight
(W f), and th e empty w eight (W e)

Eq. (2) provid es an estimat e of the range, R, based on th e lift to drag ratio ( L/D), the velocity ( V) and th e
specific fu el consumption ( C), and w eight ov er the cruis e segments.

This basic data can th en be used for initial sizing of th e fuselage, wing and tail, and furth er empirical
equations can guid e key dim ensions thus providing estimat es of th e areas, lengths and positions. Th e
conc ept of volum e coefficients in combination with mom ent arms provid es this, and is us eful th en in

19
iterating to b etter estimat es. It is notabl e now that as th e design proc eeds mor e values are being fix ed and
the design spac e is being gradually r educed.
How ever, at th e same time the numb er of d esign param eters is incr easing.
Fig. 1.2.2.1.1. Incr easing numb ers of d esign param eters.

Compl etion of th e conc eptual phas e occurs wh en a satisfactory l evel of functionality and m eeting of th e
requirements is achi eved. At this point suffici ent data exist for basic sizing of th e internal structur e and a
better definition of a erodynamic surfac es, etc. Th e probl em has now b een sufficiently constrain ed for
these to hav e meaningful solutions, and so th e preliminary d esign phas e may b egin.
Of cours e in practic e, especially in th e large comm ercial a erospac e compani es, the procedure is mor e
compl ex and follows a mor e rigorous S E approach, how ever the basic st eps and data ar e essentially th e
same.

1.2.2.2 Pr eliminary d esign

Once the conc ept has b een acc epted and th e design spac e is suffici ently w ell defined, or constrain ed,
preliminary d esign may proc eed. Each major syst em of th e aircraft is now consid ered again and mor e
detailed estimat es of siz e, thickn ess, mat erial, etc. ar e made. In terms of th e airfram e this may b e each
major s ection. For exampl e, the fuselage skin thickn ess, numb er of string ers, fram es will b e given initial
values. Estimat es of int ernal structural loads will th en be obtain ed using finit e element mod els. [3]
Much compl exity and difficulty h ere can com e from th e many load cas es needed in practic e, which can
numb er in hundr eds. Obtaining an acc eptabl e solution which cov ers the worst cas es without b eing ov er
designed for normal in -service conditions is a significant chall enge, even with today’s t echnology. [3]
Typical airfram e loads mod els hav e approximat ely 200,000 d egrees of fr eedom. At this point in the
design conn ections, local cut -outs and oth er such d etails hav e not b een establish ed, but even so th e
numb er of param eters has escalat ed again. For exampl e, the fuselage now has a l ength, radius, skin
thickn ess, fram e spacing, string er spacing and each of these has areas and thickn esses as w ell. [3]

20
1.2.2.3. D etail d esign

***Succ essful r eview and acc eptanc e of the preliminary d esign allows th e detail d esign phas e to proc eed.
The design t eam now expands by an ord er of magnitud e and work b egins on d eveloping th e detailed
drawings to enable the aircraft to b e manufactur ed. How ever, design and analysis continu es through
detailed analys es, such as str essing of th e final shap e and form of th e compon ents.

Fig. 1.2.2.3.1 Detailed design

21
1.2.2.4 General engin eering d esign

The basic d esign proc edure describ ed here has many variations d epending on th e accepted practic e in a
given company and th eir capabiliti es. Many follow a S E approach wh ere there is continual it eration
between the phases and s everal design r eviews to ensure the work proc eeds as smoothly as possibl e.
There are differences when the role of Concurr ent Engineering and Int egrated Product T eams is
consid ered, sinc e these bring som e issues from production and op eration to th e early d esign phas es. But,
in general this approach is still valid, and mor eover, is common across th e engineering and d esign s ector.
The current approach to aircraft (or any) d esign can b e summariz ed as b eing bas ed on conv entional
configurations using empirical m ethods at th e highest level suppl emented by sophisticat ed
multidisciplinary simulations at mor e detailed levels. Because this cor e approach has not chang ed in
many y ears and it cannot b e easily adapt ed to nonstandard aircraft, or easily account for th e impa ct of
new designs, proc esses or mat erials which ar e needed to addr ess the grand chall enges in aircraft d esign.

Gaps in th e proc ess
Fig. 1.2.2.4.1. Simplifi ed syst em sch ematic

Although in taking such a high l evel view of both d esign proc esses it is easy to see analogi es and fit, th e
implementation of such compl ex proc esses in practic e clouds th e issue, and m eaningful linkag es are more
difficult to s ee. For exampl e, analysis of som e detailed areas may b e necessary to h elp support th e system
definition at a higher level, and in g eneral it is analysis which provid es the metrics us ed to m easure the
system performanc e. Thus, d esign mod els may cut across or includ e many syst ems or sub syst ems, and
conv ersely the measurement of a giv en syst em may n eed several dif ferent analys es depending on cont ext.
The simpl e schematic in Fig. 1.2.2.4.1. illustrat es this for simplifi ed airfram e and propulsion syst ems. [3]
The airfram e is brok en down into its major sub -systems, such as th e wing, and similarly th e propulsion
system is brok en down into its major sub -systems. Although th ese are separat e systems th ey are linked in
design and analysis. For exampl e, som e loads for th e wing ar e provid ed by th e engine thrust and fu el

22
weight; and th e geometry of th e wing and nac elle are affected by th e engine choic e. From th e airfram e
design p erspective, the design mod el is usually a finit e element loads mast er mod el which will
incorporat e elements of all th ese systems involv ed. It th erefore cuts across many syst ems and analysis
uses param eters from all of th ese. This rais es the issue that optimi zations may b e either over constrain ed,
or may r esult in local optima which cannot b e achieved in practic e because remote param eters are being
separat ely op timiz ed as part of th eir study. It is difficult to control such issu es without constraining th e
probl em furth er.
Closer insp ection of even this simpl e exampl e shows that d etail is add ed to th e system archit ecture in a
different way than th e analysis mod els which always focus on th e physical ( i.e. geometry) instantiation of
the design. It is th e system archit ectures which driv e the eventual manufactur e of the aircraft, with
analysis us ed to support th e decisions mad e. Thus, to m easure and d efine system function, many analysis
types are needed which hav e different information and l evels of d etail. Traditionally, syst ems int egration
is seen as th e domain of th e individual company sinc e it is so tightly associa ted with th e final product, but
analysis m ethods are more generic and cut across syst ems views. [3]
This l eads to th e core of the probl em. The two approa ches are not quit e in synch. As d etail is added to th e
systems archit ecture it is not necessarily add ed to the design mod els. Th e natural consequence of this has
been to focus on th e final geometry of th e ‘as manufactur ed’ product as b eing the closest representation of
the real product. Everyone then draw s on this bas eline for th e core information. But f or int egration this
raises som e immediate questions.
Firstly, th e final g eometry is not known until t he design is compl ete, so it is unclear as to how early and
intermediate designs should b e handl ed. Secondly, each disciplin e requires different views or
idealizations, so sophisticat ed tools ar e needed to abstract id ealized mod els from d etailed geometry. This
is compound ed by curr ent efforts to broad en the disciplin es used in early d esign to includ e others, such as
manufacturing and economics, wh ere models tend to b e different (for exampl e, a statistical mod el) and
their fidelity may not easily match th e other disciplin es. [3]
This is still on e of the major bottl enecks in analysis and d esign. Thirdly, th e final g eometry as an absolut e
does not n ecessarily show th e key design param eters. In fact, th ey are often hidd en or mask ed in th e
model building proc ess with individual d esigners adding local param eters as appropriat e for th eir design
problem.
Finally, th e geometry do es not r epresent a uniqu e map of th e systems archit ecture and th erefore systems
interfaces and int eractions ar e not transpar ent. Int erfaces are specified by th e designer but int eractions
may emerge as a cons equence of this. [3]

23
1.3. Rethinking th e analysis and d esign proc ess

The preceding discussion provid es one view of a commonly r ecogniz ed probl em which has spawn ed
several att empts at providing int egrated design environm ents which us e param etric mod els and
multidisciplinary optimiz ation. Th e comm ercially availabl e tools provid e capability to link analysis
models and th e design can d efine the analysis s equence and proc ess. That is, th ey provid e functionality
and naturally this is us ed within existing d esign proc esses. But this do es not solv e the probl em of
integration. By consid ering th e process by which mod els are built and th e consequences of this it has b een
propos ed that in bringing tog ether SE and traditional analysis tools opportuniti es for progr ess in d esign
synth esis using multi -disciplinary analysis mod els app ear.
The design of aircraft b egins with conc ept sk etches of basic configuration and layout. Th ese basic
configurations ar e normally of k ey lines or surfac es, representing a sk eleton of th e structur e or simply its
key features. Initial analys es are often carried out for ord er of magnitud e assessments of behavio r, e.g.
stiffn ess, str ength. Th e design th en evolves or d evelops from th ese key lines and features, until it r eaches
a point wh ere it is suffici ently w ell advanc ed for a 3D CAD mod el to be developed. At this point th e
design mov es onto the preliminary d esign phas e where the conc ept is taken to a g reater level of d etail and
understanding. [3]
Once the basic CAD mod el is in plac e details, such as joint configurations, ar e added as knowl edge of the
design evolves in th e detail d esign phas e. Between each o f these phases there is a br eak or disjoint in the
process, and th ere are several consequences to this. Firstly , the CAD mod el is th e core, from which
developm ent teams extract and share their data, but it has not n ecessarily b een directly conn ected to th e
original conc eptual mod els, and so f eedback is not always straightforward. Secondly, t eams from
different disciplin es take the relevant data from th e CAD mod el for th eir probl ems and work using this.
How ever, as th e design is evolving th ey will only updat e as their own probl em is aff ected. Thus, a
divergence in the data b eing us ed by diff erent disciplin e teams occurs. The final cons equence is that
integration and multidisciplinary simulations b ecome difficult to manag e since the divergence of models
and data m eans that the interfaces between the models are more difficult to manag e. [3]
One logical cons equence is that th e conc eptual model is us ed to driv e the design through all phases
conc eptual, pr eliminary and d etail. Th e CAD syst em is no long er the pivotal element and takes its plac e
alongsid e the analysis disciplin es. Th e geometry is th en simply on e view (th e geometric view) of th e
product data, just as a finit e element model is an id ealized view of th e structural configuration of th e
product.
Automation is entirely possibl e and v ery detailed airfram e models can b e produc ed in conjunction with
the relevant analysis mod els. This approach is entirely consist ent with th e SE approach es describ ed in th e
previous s ection, and claims a st ep cha nge in the ability to trad e-off designs and produc e more reliable
concept evaluations at an early stag e before requirements and product archit ectures are fixed. The
previous s ections highlight ed major issu es which n eed to b e addressed in an int egrated, SE environm ent.
The compl exity of many of th e issues arising when detail is consid ered mak es it difficult to tackl e these
individually. A singl e approach addr essing all th ese simultan eously has b een developed recogniz ing that
much of th e probl em is proc ess ori ented rath er than t echnology ori ented. [3]
Starting with the premise that th e SE fram ework is a soun d basis for aircraft d esign and manufactur e, then
the task can b e refocus ed on bringing existing techno logy can b e brought within this fram ework. If the
model building proc ess is bas ed on th e SE approach and d evelops in synch with th e systems archit ectures,

24

then many of th e probl ems can b e overcom e, at least to th e point wh ere new technology is n eeded to
move forward. Th e resulting process is capa ble of starting with a f ew bas e requirements or param eters,
and th en adding d etail as th e system archit ecture develops.

1.3.1. Param eters versus Constrains

The issue of the impact of d esign param eter chang es rais es oth er probl ems. In particular, th e effect of
constraints as th ey flow down through th e system. Having too many or tight constraints r estricts th e
solution domain, but having too f ew wh ere every param eter is a variabl e can l eave the design spac e too
open. This l eads to th e concept of syst em flexibility which is important particularly for syst ems which
have a long lif e and will b e subject to chang e over tim e. For exampl e, curr ent compl ex engineering
systems ar e being d esigned for incr easingly long er design lif etimes. In most instanc es, incr easing a
system design lif etime is driv en by (and oft en justifi ed by) traditional economic analysis, but this logic
ignor es the effects of rapid t echnology advanc ement, and syst ems b ecoming obsol ete long b efore they are
due for retirement. In many cas es, the initial circumstanc es from which th e original syst em requirements
were derived hav e chang ed or b een modifi ed, and as such fl exibility is a k ey prop erty which should b e
embedded in so -called ‘high -value’ assets.
Flexibility is und erstood as th e ability to r espond to chang e, but although this is essential, it is not a
property which is distinguishabl e from robustn ess wh en describ ed in this mann er. Flexibility is a
subjective description, which is particular to th e system und er consid eration, but th ere are some key
features which can b e used to d escrib e the system flexibility . There should b e an und erstanding of th e
time reference associat ed with th e chang e (when it is happ ening during th e life-cycle of the system); a
charact erization of th e mann er in which th e system is changing (th e environm ent, th e system its elf or the
custom er needs); and finally, and most importantly in th e context of this study, th e ability to rank
different designs according to th eir flexibility through m etrics.

Fig. 1.3.1.1. Syst em flexibility, chang e and tim e
Fig 1.3.1.1 indicat es the relationship which exists between the three major syst em conc erns of tim e,
uncertainty and fl exibility. If th e system lif e cycle has an incr eased lifespan, th en it must b e capabl e of
coping with unc ertainty and chang e in ord er to b e accepted as ‘fl exible’. In ord er to d esign for fl exibility,
it is n ecessary to consid er flexibility as a prop erty of th e system which allows it to r espond to chang es in
its initial obj ectives and r equirements, occurring aft er the system design has b een initializ ed. In ord er to

25
distinguish b etween robustn ess and fl exibility, th e relationship b etween the environment in which th e
system exists, and th e objectives of th e system needs to b e consid ered. Th e optimiz ed design is on e in
which th e environ ment is known and th e objectives are unchanging – the most common approach for short
lifespan, low valu e products. Th e distinction b etween robust and fl exible design com es within th e system
objectives – a syst em design capabl e of meeting its obj ectives within a non -static environm ent is t ermed
‘robust’, wh ereas in ord er to cop e not only with changing environm ental issu es, but also changing
objectives, the system must b e flexible. This r elationship b etween flexibility and robustn ess of a d esign as
a function of th e system obj ectives and enviro nment can b e depicted graphically ( fig 1.3.1.2 ).

Fig. 1.3.1.2. Syst em flexibility
Given this, th e developm ent of a fl exible frame-work must incorporat e both th e capability to adapt to both
changing r equirements and a changing environm ent, leading to a r equirement to d evelop m ethodologi es
which enable engineers to pr edict wh ether a syst em is capabl e of fulfilling th ese requirements.
Quantitativ e methods for pr edicting th e ability of a syst em to cop e with chang e has pr eviously b een
consid ered in d etail in the realm of softwar e engineering, with suit es of applicabl e metrics id entified in
order to m easure identified charact eristics of fl exible systems.
The general ar ea of chang e manag ement has b ecome more topical in r ecent years and a body of work is
beginnin g to emerge on how to incorporat e system chang es and d eal with th e consequence. This
capability will b e needed in particular for futur e applications on v ery long liv ed syst ems as aircraft ar e
now b ecoming.
As stat ed previously compl ex syst ems exhibit b ehavio rs, which non e of their subsyst ems hav e, due to the
interaction of thos e subsyst ems. These additional b ehavio rs are sometimes necessary for th e functioning
of a syst em, but oft en emergent behavio rs are unplann ed and und esired. Th ere does not app ear to be a
formal approach to addr essing this probl em within th e aircraft d esign ar ena, oth er than what is availabl e
through robust d esign m ethods. This is a difficult chall enge since by th eir natur e they are unpredictabl e.

26
How ever, it is possibl e to at l east identify wh ere limitations of knowl edge are, by having th e capability to
trace the bounds of param eters and functions. This is a possibl e avenue for progr ess. This b etter definition
of the design and op erating spac e reduces unc ertainty and will facilitat e testing syst em respons e to
unexpected inputs and syst em chang es.
The SE process has a strong element of risk manag ement embedded in th e design proc ess. How ever,
much of th e estimating task r emains in th e domain of sp ecialist engineers and th eir technical kn owledge
of the modes of failur e of a giv en element. Th ere are softwar e tools which can estimat e risk but th ese are
oriented towards soft ware and ar e not int egrated tightly with th e design proc ess. Th e technical
archit ecture and tools m entioned here can provid e some capability to hav e elements of risk ass essment
linked with th e design synth esis proc ess but again this topic has y et to b e an int egral part of th e design
process.
Much existing work on syst em measurement and control r elates to having a given syst em archit ecture in
place. However, it is now wid ely recogniz ed that ov er a lif e-cycle that archit ectures behave dynami cally,
chang ing in th eir natur e and b ehavio r. This is tru e even for quit e fixed products as it is for mor e obvious
dynamic syst ems, such as d efense forces. It is int eresting that much work focusing on charact erizing
dynamic syst ems to obtain b etter under-standing of th eir behavio r over tim e, with conc epts relating to
how to add or r emove system elements and what aff ect this has on the system. Int eraction tools and s et-
based approach es hav e a role to play h ere in that it is n ecessary to fix an archit ecture. Interaction tools can
identify physical and func tional int erfaces, and therefore specify th e archit ecture at any giv en instant.
This s ection has h ighlight ed som e of the interesting work ongoing in S E with particular r eference to how
this is b eing appli ed to d esign. It app ears that although th ere is a body of work in softwar e engineering th e
application to aircraft d esign is still s parse. Mor e work is n eeded to provid e the encompassing int egration
fram ework n eeded for aircraft d esign.

1.3.2. Economics and digital manufacturing

Up to this point it is th e design environm ent which has b een the key focus of att ention. How ever, the
physical construction of th e product and its subs equent lif e are more important in th e end. Th e current
tight economic circumstanc es are driving th e need for mor e effective and efficient design ap proach es and
awar eness of custom er requirements and th eir impact on d esign. Th e integrated tools d escrib ed previously
can now b e combin ed with th e latest digital manufacturing and costing tools to produc e information on
the production, cost and lif e-cycle impact of th e product. Virtual factori es can b e viewed alongsid e virtual
product mod els to r eveal ass embly and maint enanc e issues before the configuration is finaliz ed.

The main b enefits of this ar e the introduction of manufacturability and cost consid erations into th e design
arena early in th e product d evelopment cycl e. The potential th en exists for th e definition, valida tion,
manag ement and d elivery of fully optimiz ed, cost effective manufacturing solutions to pro duction
environm ent quickly and efficiently. In addi tion, it will allow th e tracking of manufacturing and
compon ent costs as production n etworks d evelop from th e earliest conc eptual d esign stag e. The
corresponding impact on risk for th e manufactur ers is major, with many issu es being resolved before
production even begins. Th e paper addr esses the need for an approach to cost mod elling that will

27
facilitat e the developm ent of analysis tools that can op erate in compl ex interdisciplinary environments,
which ar e increasingly b eing d eveloped with a S E philosophy.

1.3.2.1. Cost and S E

The importanc e of int egrating cost into th e developm ent proc ess is highlight ed in 1.3.2.1.1 , which illustrat es
the increasing difficulty in influ encing both production and lif ecycle costs. Alr eady at th e end of th e
conc eptual d esign phas e, typically 70% of lifecycle cost is d etermin ed whil e the opportunity to furth er
reduce costs is only 35%. To provid e design synth esis, th e approach n eeds to incorporat e technical cost
drivers that flow -down to th e required design l evel and physical configuration but must a lso cop e with lif e
cycle issues relevant to acquisition cost and custom er requirements. This includ es a wid e range of elements
such as non -recurring d evelopm ent costs, r ecurring production costs (in cluding amortiz ed non -recurring
elements), and th e recurring op erations costs. [3]

Fig. 1.3.2.1.1 – Loss of cost control ov er the life cycle.

The custom er requirements d etailed in fig. 1.3.2.1.2 provid e the main input to th e SE process, which th en
feeds into th e requirements loop that it erates between Requirements Analysis, and Functional Analysis
and Alloca tion. Th e result of th e requirements loop is a functional archit ecture, with id entified interfaces
between all of th e identified performanc e and oth er limiting r equirements. A supporting syst ems
engineering costing (S EC) m ethodology must first b e able to op erate at this l evel. Th e functional
archit ecture then feeds into th e design loop which it erates between Functional Analysis and Allocation,
and D esign Synth esis. Th e design loop s ees the functional archit ecture transform ed into a physical
archit ecture with conc epts b eing d efined along with configuration it ems, syst em elements and physical
interfaces; and th e preferred product and proc ess solutions b eing s elected. Th erefore, the SEC
methodology must also b e able to op erate at this l evel and pr eferably, to b e recursiv e in natur e for data
continuity and to maintain th e integrity of th e cost br eakdown structur e (CBS) b etween levels.

28
Fig.1.3.2.1.2 – Systems engineering proc ess mod el. [2]

The archit ectural mak e-up or analysis fram ework of th e system has a dir ect influence on th e emergent
behavio rs which it exhibits, and that is tru e also of cost. In th e case of all archit ectural mod elling for
system design, th e interactions b etween compon ents give rise to the ‘sum is gr eater than th e whol e’
property obs erved in th e majority of syst ems, and in most cas es, it is this emergence which is d esigned
for. On th e flipsid e, how ever, this emergence may also manif est itself in und esirabl e behavio rs (so -called
side-effects), l eading to a n eed to establish m ethodology which will effectively identify, and eventually
control and driv e system developm ent to produc e more cost effective, stabl e system designs, with
instanc es of r edesign du e to limit ed unanticipat ed emergent behavio r.

29
1.3.3. Relationship back to d esign: Cost r elated life cycle view

Fig. 1.3.3.1 – Systems engineering mod el for acquisition costing.

Fig 1.3.3.1 illustrat es the conc eptual mod el of how cost analysis and control can b e integrated into a lif e
cycle view of th e SE methodology. Th e product lif e cycle is brok en down into four main phas es, with
major mil estones associat ed with th e passing from on e stage to the next. It can b e seen that th e core
activiti es of S E, as shown in Fig. 1.3.3.1, ar e appli ed sequentially during each phas e of the life cycle. In
addition, th e costing that occurs during th e design phas e is illustrat ed as a top down proc ess that matur es
in compl exity and fid elity as th e design d efinition b ecomes fully compl ete at the Critical D esign R eview
(CDR). [3]
The design phas e is also associat ed with a flow -down of th e requirements that ar e then allocat ed within
the functional archit ecture. Subs equent to th e CDR, th e verification phas e is illustrat ed as a bottom -up
process wh ere parts and compon ents ar e fabricat ed and int egrated into ass emblies and sub -systems that
ultimat ely, ar e tested, verified and validat ed at an op erational syst ems level. [3]
This r elates directly to th e need for th e additional t echnical archit ecture as th e integration of quantitativ e
modelling, e.g. for cost in this cas e, requires that multi -fidelity cost mod els are required to facilitat e the SE
approach in ord er to enable the coupling to th e other multi -fidelity mod els that charact erize the multi –
disciplinary syst em design spac e. [3]

30
1.3.3.1. Cost int egrated design

Cost is an important attribut e of any product and highly r elevant to th e engineering d esign proc ess. The
custom er affordability, product quality and mark et timeliness are the three key elements of comp etitiveness.
There are two funda mental engineering approach es to controlling cost: nam ely, (1) d esigning for cost and
(2) costing for d esign. Although the definition of the Design For Cost (DFC) m ethodology i s being driv en
by man agement impos ed cost targ ets, this is usually r eferred to sp ecifically as D esign To Cost (DTC );
implying that a cost targ et has to b e met and adhered to. DFC is g enerally tak en to m ean that th e design
process is mindful of cost.
Many now b elieve that imposing strict targ et costing on engineering d esign, as for DTC, is not effective as
it tends to r esult in inf erior d esign that still ov ershoots th e poor cost estimat es used as th e initial guidanc e.
It is mor e important to giv e designers supportiv e costing tools that facilitat e the product d efinition proc ess
by linking d esign d ecisions to estimat ed cost impact.
In general, this approach can b e traced back to much of th e classic r esearch within th e aerospac e industry
into param etric optimiz ation: the identification of k ey design param eters that driv e performanc e and which
can b e optimi zed wh en combin ed in math ematical formula. Much of th e current mainstr eam research is
focus ed on Multi -Disciplinary Optimiz ation (MDO), wh ether at a high l evel or a low er level that links
discr ete computational mod els. MDO in link ed to Lif e Cycl e Analysis by d efining high l evel obj ective
functions that encompass th e life cycle needs of aircraft, support ed by n ecessary disciplinary mod els which
facilitat e the optimiz ation process through a linkag e that is d efined by an obj ective function .
There are various Dir ect Op erating Cost (DOC) mod els availabl e, which t end to b e of a param etric natur e,
which allow th e trade-off of d esign param eters and which can b e linked to manufacturing mod els to coupl e
the impact on production.

Fig. 1.3.3.1.1 Int egrating disciplin es that driv e design at various l evels of d efinition.

31

Fig. 1.3.3.1.1 illustrates the multi -level, multi -fidelity framework being developed to achieve design and
cost synthesis. On the left -hand side of the figure the aircraft structural design is first assessed through a
simple frame analysis, which then is used to develop solid models to represent a more realistic g eometric
definition. The solid models can then be used to carry out more accurate analysis of structural integrity and
cost, etc., to be fed iteratively into the sizing procedure. Further levels of abstraction can be imposed down
to localized detailed mode lling, depending on the maturity of the design process in the development stages
following the process illustrated in Fig. 1.3.3.1.1 .

Approach es to cost mod elling

Fig. 1.3.3.1.2 – Matrix of cost estimating t echniqu es.
Various alt ernativ e approach es to c ost mod elling exist. Bottom -up or Detailed Estimating (DE) is th e least
formulat ed costing t echniqu e and entails th e gathering of all cost information that can b e directly attribut ed
to th e final articl e, to b e cumulat ed into a highly d etailed mod el. Analogous Costing and Cas e Based
Reasoning (AC/CBR) ar e techniqu es that principally r ely on th e similarity and diff erentiation of lik e-
products to ensure that th e cost estimat e is comparativ e to a pr evious instanc e. An automat ed form of
analogous -type costing us es Neural N etworks and Fuzzy Logic (NN/FL) to formulat e relations that link
independent product -related attribut es to th e dependent costs und er consid eration.
Param etric Estimating (PE) typically entails th e linking of cost to high -level product param eters through
probabilistic analysis in ord er to establish estimating r elations that will combin e into a cost estimating
model. Comm ercial v ersions, such as PRIC E-H and S EER-DFM, off er a facilitating environm ent and
functionality that allows an organi zation to calibrat e the model with th eir own historical data in ord er to
tailor it to th eir specific financial n eeds and busin ess environm ent. How ever, as w ell as historical data, th e
calibration proc ess requires expert judgm ent, assumptions and opinion.
Finally, th ere are financial accounting t echniqu es, such as Activity Bas ed Costing (ABC), which r ecord th e
use of resourc es in d etermining a mor e accurat e estimat e of th e total cost, including ca pital cost rat es and
overheads.

32
It has b een establish ed that ideally, any facilitating costing m ethodology should b e able to op erate and
interface at various l evels and during all stag es of th e life cycle. This has b een a fundam ental driv er in th e
developm ent of a g eneric approach t ermed Genetic Causal Costing (GCC ), which is shown in Fig. 27 in
application throughout th e life cycle.
This is conc eptualiz ed in fig. 1.3.3.3 where the causal d efinition of th e relation of cost to d esign driv ers is
seen in th e context of product famili es. Th e model adopts th e scientific principl e of cat egorization but also
incorporat es the scientific r equirement of utilizing causal r elations. Essentially, th e generic m ethodology
has th e following principl es:

1. Genetic principl e: Cost is classifi ed into famili es according to product and proc ess, to id entify lik ely
commonality through shar ed cost driv ers.
2. Causality principl e: Cost is formulat ed into a r elation as a function of th e design attribut es which giv es
rise to a cost pot ential, using: w eights, part counts, sizing, and mat erial s election, etc.

Fig. 1.3.3.3 – The genetic-causal costing mod el.
The conc ept of using th e Causal principl e to establish r elations with a strong sci entific basis is cl ear,
however, not w ell practic ed in cost estimating wh ere statistical significanc e is oft en used as th e primary
requirements. This entails a high d egree of risk as th ere is rar ely an att empt to d efine the range of application
of th e model or its s ensitivity to d esign and manufacturing chang e, relative to the historical data us ed to
establish th e statistical r elation. In t erms of th e Genetic principl e: within a erospac e, design t ends to b e
derivativ e and th ere-fore, the costing blu eprint can b e seen in pr evious aircraft. Engineering manufacturing
costs can b e classifi ed according to mat erials, fabrication proc esses and ass embly, whil e additional costs
can b e group ed according to support, quality and insp ection, and g eneral factory ov erheads. Th ere is also a
large distinction b etween recurring and non -recurring costs.
A broad er life cycle analysis should consid er the non-recurring cost of th e developm ent proc ess plus
additional company r ecurring ov erheads, all of which should b e reflected in th e acquisition cost. How ever,

33
the key asp ect to this und erstanding of cost is that it is g enetically inh erited and that it originat es through
the engineering d esign d efinition, which dictat es the materials to b e processed and ass embled into som e
product configuration. Environm ental factors, such as machining rat es and labou r rates, can b e assum ed to
be fixed at th e product d efinition stag e, although logistics and supply chain manag ement introduc e a
realistic varianc e.

1.3.3.2. Cost mod elling at various stag es of th e life cycle

Developm ent cost
Developm ent cost is larg ely treated as a non -recurring element, i. e. a on e-off effort that is not r epeated,
although in practic e design modification do es occur during th e production stag e as th e manufacturability
of th e design solution b ecomes evident. Fig. 1.3.3.2.1 presents som e data relating to th e non-recurring
design effort r ecorded for fus elage sections. [3]
The design hours, as th e dependant variabl e, are being mod elled as a function of both part count and w eight.
It is highlight ed that th ere is a minimal 15% d elta in th e cost b eing pr edicted depending on th e independent
variabl e. In t erms of th e Genetic-Causal approach, d esign cost is id entified as a cost family or cat egory
while the independent variabl es should b e of a causal natur e. It is w ell known that w eight is a good indicator
of cost and is oft en used in param etric cost analysis .
How ever, it is r ecomm ended that part count also b e consid ered as a mor e causal driv er. For exampl e, weight
is mor e loosely coupl ed to cost in th e fact that ‘mor e stuff is lik ely to cost mor e’, i.e. mor e material requiring
more design effort in ord er to d efine it. How ever, in this instanc e part count, even with a slightly low er
statistical significanc e (R2 ¼ 0.92 as oppos ed to R2 ¼ 0.93 with w eight as th e independent variabl e), is
assessed to b e more causal as it r elates directly to th e numb er of drawings to b e generated to d efine the
assembly configuration. [3]
Fig. 1.3.3.2.1. Mod elling d esign cost using high l evel cost driv ers.

34
Production cost: in -hous e
Following th e Genetic-Causal principl e, cost can b e disaggr egated into famili es according to mat erial,
treatments, fabrication, and ass embly; each of which can b e furth er brok en down as r equired. Th e plots to
the left on Fig. 1.3.3.2.2 show th e make cost (fabrication) b eing r elated simply to string er length, for a
particular family of string ers.
The regression analysis of th e data r equires both a constant and a slop e in ord er to charact erize the relation
to some linear approxima tion, shown in th e upper and low er graphs, r espectively. Subs equently, th e
distributions (unc ertainty charact erization) for th ese statistical compon ents can b e utiliz ed through Mont e
Carlo analysis in ord er to mod el the likely variation in cost du e to the varianc e observed (or impos ed relative
to som e criteria), th ereby producing a mor e robust cost estimat e. This is illustrat ed to th e right wh ere both
distributions hav e been used by th e Mont e Carlo analysis to provid e the rigorous ass essment of th e likely
distribution of cost. [3]

Fig. 1.3.3.2.2 Mod elling production cost at a cost compon ent level.
Production cost: procur ement
Currently, 70 –80% of a erospac e parts ar e pro-cured from th e supply chain. Procur ement cost mod elling is
charact erized by th e analysis of larg e data banks of part pric es and oft en only v ery basic information
regarding th e manufactur e, that b eing too s ensitiv e or propri etary in th e opinion of th e suppli er.
Fig 1.3.3.2.3 .3 shows som e results obtain ed from various t echniqu es of linking th e procur ed cost for th e
causal driv ers identified, using both r egression analysis and n eural n etworks to d evelop th e formulation.
The RMS E value shown can b e interpreted as th e non-dimensional error, wh ere Group Numb ers or l evels
6 and 7 r epresent the much small dat a bins for a particular part family, machin ed bulkh eads in this cas e.
Group 5 analysis is r eturning an accuracy l evel of approximat ely 5–10% for all th e parts consid ered in
that larg er bin, whil e Groups 6 and 7 show that machin ed bulkh eads ar e not a particularly w ell mod elled

35
sub-category. This r educed accuracy is du e to the lack of d esign instanc es and to th e wide variation in
design d efinition, r elative to the bulk of parts consid ered in Group 5. [3]

Fig 1.3.3.2.3 .3 Predictions for procur ed cost bas ed on n eural n et and r egression t echniqu es. [3]

Operations cost
Fig. 1.3.3.2.3 .4 presents a pie chart d etailing th e proportional contribution, with own ership b eing th e
financing of th e acquisition cost at 54%. Th e engineering effort expending in the early d evelopment stag es
influ ences own ership, maint enanc e (13%) and fu el costs (15%), whil e crew (13%), landing f ees (2%) and
insuranc e (3%) ar e largely ind ependent. It is striking that th e chart supports th e view that mor e effort is
required in r educing acquisition cost as it has ov er 3 tim es the influ ence of performanc e (fuel burn). [3]
Fig. 1.3.3.2.3 .4 – Typical br eakdown of op erating cost for a r egional j et.

36
2. Logistics

The elements of a syst em includ e a combination of r esourc es in the form of mat erials, equipment,
softwar e, faciliti es, data, s ervices and p ersonn el integrated in such a mann er as to m eet a sp ecific
requirement. Inh erent within th e context of syst ems ar e the functions of mat erial procur ement and flow,
distribution of products and s ervices and th e sustaining maint enanc e and support of a syst em throughout
its int ended period of utilization. Th ese initial product distribution and sustaining maint enanc e and
support functions ar e includ ed within th e conc ept of logistics.
In addressing th e elements of logistics, on e should comm ence with a good und erstanding of th e overall
operations, maint enanc e and support infrastructur e.
Referring to Figur e 2.1, there is an outward flow of activiti es where materials and s ervices are provid ed,
evolving from th e sourc e of supply to th e point wh ere the system is b eing utiliz ed by th e custom er/user
and a reverse flow wh en items ar e returned for maint enanc e.

Figur e 2.1 – System op erational and maint enanc e flow [2]

37
Planning is initiat ed, system/product d esign and d evelopm ent are accomplish ed, items ar e produc ed with
suppli ers providing th e needed mat erial, syst em elements ar e install ed at th e user’s op erational sit e(s) and
the system is th en utiliz ed throughout its plann ed life cycle. Thro ughout this proc ess, th ese are activiti es
involving th e initial provisioning and procur ement of compon ents, mat erial handling and proc essing,
transportation and distribution, war ehousing, and so on.
As th e system is b eing utiliz ed, there is an on -going maint enanc e and support capability that n eeds to b e
install ed and in -place to ensure that th e system continu es to b e availabl e when required. As failur es occur,
faulty it ems will b e returned as n ecessary for int ermediate-level or d epot/prod ucer level maint enanc e.
Additionally, th ere are scheduled/preventive maint enanc e requirements that may b e necessary to k eep the
system in an op erational stat e.
At th e same time, there is a forward flow of p ersonn el, test equipm ent, spar es and r epair parts,
consumabl es, docum entation, and th e like, necessary to support thos e scheduled and also unsch eduled
maint enanc e actions that ar e common durin g the lifecycle of an aircraft.

2.1. Elements of logistics

The categories presented here represent only an exampl e of how on e may wish to br eak down th e
resourc es required for th e system maint enanc e and support of an airc raft. Although th e particular category
descriptors may vary from on e organization to th e next, th e critical issu e is to ensure that all th e
applicabl e resourc es requirements ar e includ ed som ewhere.
Figur e 2.1.1 – The basic elements of logistics [2]

38
1. Maint enance and support planning

This includ es all planning and analysis associat ed with th e establishm ent of r equirements for th e
overall support of a syst em throughout its lif ecycle. Maint enanc e planning constitut es a sustaining
level of activity comm encing with th e developm ent of th e maint enanc e conc ept and continuing
through th e accomplishm ent of supportability analysis during sy stem design and d evelopm ent, th e
procur ement and acquisition of support it ems, th e system utilization phas e when an ongoing
maint enanc e support and capability is r equired to sustain op erations, and during th e retirement phas e
when mat erials ar e being recycled or phas e-out for disposal. Maintenance planning should result in
the integration of the various facets, to support one another, with the first mission to relate the
elements of the system and lead to the definition and development of the infrastruct ure as follows:

fig. 2.1.2. – System support infrastructure [2]
2. Supply Support
This includes all spares (repairable units, assemblies, modules, etc.), non -repairable components,
consumables (lubricants, liquids, disposable items), special supplies and equipment, computer software,
test and support equipment, transportation and handling equipment, training equipment, etc. Included are
the provisions and procurement activities, documentation regarding material acquisition, handling,
distribution, recycli ng and disposal.
3. Maintenance and support personnel.
Personnel required for the installation, sustaining maintenance and support of the system, its prime
mission -related elements and the other elements of support (e.g., test equipment, transportation and
handling equipment, facilities ), are included in this cate gory. This includes personnel at all levels (refer to
Figure 2.1.2), mobile te ams and operators at test facilities and calibration laboratories.

39
4. Training and training support.
This includes all personnel, equipment, facilities data/documentation, and a resources necessary for the
training of system operational and maintenance personnel, to i nclude both initial and replen ishment
training. Training equipment (e.g. simulators , mockups, special devices) data and software are developed
and utilized as necessary to support both the informal day -to-day training and that of a more forma l
nature.
5. Test, measure ment, h andling, and support equipment
This category includes all tools, condition monitoring equipment, diagnostic and checkout equipment,
special test equipment, metrology and calibration equipment, maintenance fixtures and stan ds and special
handling equ ipment required to support all scheduled and unscheduled maintenance actions associated
with the system. Test and support equipment requirements at each level of maintenance must be
addressed as well as the overall requirements for test traceability t o a secondary standard and ulti mately to
a primary standard of some type .
6. Packaging, handling, storage and transportation.
This e lement of logistics includes all materials, equipment, special provisions, containers reusable and
disposable), and supplies nec essary support the packaging, preser vation, storage, handling, and/or
transporta tion of the prime mission -related ele ments of the system, personnel, spares and repair parts, test
and support equipment, technical data, software, and mob facilities. This cat egory basically covers the
initial and sustaining transportation re quirements in support of the dis tribution of materials and personnel
and the maint enan ce cycle illustrated in figure 2 .1 (i.e. , the outward and reverse flows described earlier).
The primary modes of transportation include air, highway, railway, waterway, and pipeline .
7. Maintenance facilities.
This category includes al facilities required to support scheduled and unscheduled maintenance actions at
all levels (see Figure 2.1.2) Physical pla nt, portable buildings, mobile vans, housing, intermediate -level
main – calibration laboratories, and special repair shops (depot, overall, material suppliers) must be
considered. Capital equipment and utilities (heat, power, energy requirements, environmen tal control,
communications, etc.) are generally included as part of facilities.
8. Computer resources (hardware and software). Th is covers all computers, associ ated software,
interfaces, and the networks necessary to support scheduled and unscheduled acti vities at each level of
maintenance. This may include condition monitoring programs, diagnostic tapes, and associated
requirements for the implementation of a computer -aided integrated maintenance management (CIMM)
capability
9. Technical data, informatio n systems, and database structures. Technical data may include system
installation and checkout procedures, operating and maintenance instructions, inspection and calibration
procedures , overhaul instructions, facili ties data, modification instructions, en gineering design data
(specifications drawings, materials and parts lists, digital data), supplier data, and logistics pro – visioning
and procurement data that are necessary in the performance of system development, production,
operation, maintenance, and retirement functions Such data should not only cover the prime missi on-
oriented elements of the sys tem but the other elements of the support infrastruct ure as well (i.e., test and
support equipment, transportation an d handling equipment, training e quipment , and facilities). Included
within this category are the information system capabilities and associated databases, that allow for the

40
implementation of effective electronic data interchange (EDI) processes and the requ irements associated
with contin uous ac quisition and life cycle support (CALS).
The objective is to provide the right balance of resources applied throughout the system support
infrastructure illustrated in Figures 2 .1 and 2.1.2. A cost -effective approach reached wh ich will require
the proper m ix of best commercial practices, supplemented by new developmental items where necessary
and when justified technologies are introduced and current processes are improved, the specific resource
requirements at each level may shift somewhat. For example, th e need for pair parts inventories may not
be required as transportation times and decline. The availability of over -night express, combined with
good communica tion processes, can help to solve the high -cost large -inventory problem. The need for
(e.g., tech nical manuals, at each maintenance location reduced with the advent of new EDI data formats
and processes. The development of computer -based information systems provides for faster and more
accurate infor mation visibility relative to the type and location of various assets at a given point in time,
and the decision -making and communications processes may be enhanced accordingly. Through the
supportability analysis (refer to Chapter 4), numer ous trade -off studies are conducted involving various
mixes and combinations of the logistics elements identified herein which, hopefully, wi ll lead to the
design and devel opment of an effective support infrastructure .

2.2 Logistics in the system Life Cycle

Logistics in the context of a system involves planning, analysis and design, testing and evaluation,
production and/or construction, distribution and the sustaining maintenance and support of a system all
the way through its period of utilization and later during retiremen t as materials are sorted out, recycled or
disposed. For the purpose of illustration, the essential stages of a system cycle are presented in Figure
2.2.1. Logistic activities are inherent within each phase.

Figure 2.2.1 – The system life -cycle phases

41
In the development of systems, the basic phases must be addressed at the same time as follows:

Figure 2.2.2 – The interrelationships of the life -cycle phases in a system development [2]
Given that there is a need for a new system, one must evolve through the design and development of the
prime mission -related elements of the system, the production of multiple quantities of these items (or the
construction of a single entity), distribution and installation if the system and its components at the
designed user sites, utilization and the sustaining maintenance and support of the system through the
planned life cycle and retirement and material phase -out. As the prime elements of the system ar e being
development, consideration must be given to the incorporation of production capacity, supportability and
disposability characteristics into the design. This leads to the design of the production capability (2nd life
cycle), design of the maintenanc e and support infrastructure (3rd life cycle) and the design of the material
recycling and disposal capability (the 4th life cycle). Moreover, there are feedback effects, as the outcomes
of the design of the 2nd,3rd and 4th life cycles can have a positive or detrimental impact.
Referring to Figure 2.2.2, the emphasis throughout this text is on the first and third life cycles. The prime
mission -related elements of the system must be designed for supportability and the maintenance and
support infrastructure must be designed to be compatible with the overall functional objectives of the
system in question. This actu ally becomes an integrated "back -and-forth" process of evolutionary
development.

42
In the intere st of simplification, Figure 2.2.3 identifies the major steps within the overall system
development process, along with the necessary feedback provisions for contin uous product/process
improvement.
Figure 2.2.3 – The major steps in system design and development [2]
Figure 2.2.3 provides a n example of the interface relationships that often exist between the basic
mainstream design activities and the major logistics functions, all of which are inherent within the
process illustrated in Fig ure 2.2.3. The basic steps in Figure 2.2.4 are highl ighted subsequently.

43
Figure 2.2.4 – The interface relationships between basic design and logistics functions [2]
Given a specific need, the system operational characteristics, mission profiles, deployment, utilization,
effectiveness figures of merit, main tenance constraints, and environmental requirements are defined.
Effectiveness figures of merit may include factors for cost effectiveness, availability, dependability,
reliability, main tainability, supportability and so on. Using this i nformation, the sy stem mainte nance

44
concept is defined, and a system -level specification is developed. Operational requirements and the
maintenance concept are the basic determi nants of logist ic support resources (Figure 2.2.4 , blocks 1
and 2).
Major operational, test, produ ction, and support functions are identified, and qualitative and
quantitative requirements for the system are allocated as design criteria (or constraints) for significant
indenture levels of the prime mission7 related elements as well as applicable elemen ts of support (i.e.,
test and support equipment, facilities, etc.). Those requirements that include logistics factors also form
boun daries for the design (Figure 2.2.4 , blocks 3 and 4).
Within the boundaries established by the design c riteria, alternative prime ele ment and support
configurations are evaluated through trade -off studies, and a preferred approach is selected. For each
alterna tive, a preliminary supportabil ity analysis is accomplished to determine the anticipated
required resources associated w ith that alternative. Through numerou s trade study iterations, a chosen
prime system architecture and support p olicy are identified (Figure 2.2.4 , blocks 5 and 6 ).
The chosen prime system configuration is evaluated through a supportability analysis effort which leads
to the gross identification of logistics resources. The system configuration (prime mission equipment
and support elements) is reviewed in terms of its expected overall effectiveness and compliance with the
initially specified qualitative and q uantitative requirements (i.e., its capability to cost-effectively satisfy
the statement of need). The ultimate output leads to the generation of subsystem specifications (and
lower -level specifications) forming the basis for detail design (Figure 2.2.4, b locks 7 and 8).
During the design process, direct assistance is provided to design engineering per sonnel. These tasks include
the interpretation of criteria; accomplishment of special studies; participation in the selection of
equipment and suppliers; acc omplishment of predictions (reliability and maintainability); participation in
progressive formal and informal design reviews; and participation in the test and evaluation of engi neering
models and prototype equipment. An in -depth supportability analysis, based on released design data,
results in the identification of specific support requirements in terms of tools, test and support equipment,
spare/repair parts, per sonnel quantities and skills, training requirements, technical data, facilities, trans –
portation, packaging, and handling requirements. The supportability analysis at this stage provides (a) an
assessment of the system design for supportability and poten tial cost/system effectiveness, and (b) a basis
for the provisioning and acquisition of spe cific support items (Figure 2.2.4, blocks 9 to 12).
Provisioning and acquisition refer to the process of source coding, identification of potential suppliers
preparing the procurement package and establishing a contractual arrangement, receiving and inspec tion
of materials and the ultimate distribution of items to the desired locations
The prime mission -related elements of the system are produced and/or con structed, tested, and
distributed or phased into full -scale operational use. Logis tic support eleme nts are acquired, tested,
and phased into operation on an as-needed basis. Throughout the operational life cycle of the system,
logistics data are collected to provide (a) an assessment of system/cost effectiveness and an early
identification of operating or maintenance problems, and (b) a basis for the re -provisioning of support
items at selected times during the life cycle (Figure 2.2.4, blocks 13 to 16).
As obsolescence occurs and elements of the system are retired and material items are phased out of th e
inventory, the appropriate processes must be engaged where such material items can either be recycled for
other uses or disposed of in such a way as not to cause any degradation on the environment. The
supportability analysis is updated to cover the supp ort resources that are necessary for system retirement
and material phase -out (Figure 2.2.4, block 17).

45
Consideration of the basic steps in Figure 2.2.4 is essential in the development of any system . However,
the extent and level of activity within each block is "tailored" to the specific requirement (e.g., type of
system, extent of development, associated risks, mission and operational needs, etc.). The
presentation in the figure represents a "thought process" in which logistic support considerations are
presented in the context of system engineering requirements.
As one proceeds through the system life cycle, which is based on the need to per form a designated
function over time, there may be addition al logistics requirements associated with design changes and the
modification of a system for one reason or another.
Referring to Figure 2.2.4 , the projected life cycle for selected technologies may be of limited duration and
shorter than the life cycle o f the system overall. Thus, the system will require modification with the
insertion of replacement Technologies A to C at the points indicated. Depending on the system
architecture (and whether an "open -architecture" approach has been incorporated into the design), the
modification proces s may be rela tively simple or highly complex. In any event, the supportability analysis
must be updated to r eflect any system modifications*
*it is not uncommon in today's environment to extend the life of a system and to a ccomplish the
necessary reengineering, upgrading, modification, etc ., with the replacement of obsolete technologies as
neces sary. The system life cycle may be extended over a 15 – to 30 -year period; yet, many of the
technologies initially selected in the de sign process may have life cycles of only 3 to 5 years (if that long).
Thus, it is important to be able to plan for future growth. In any event, the requirements for logistics
throughout the system life cycle are continuous and the posture is highly "dynam ic”.

Figure 2.2.5 – System life cycle with new technology insertions.

46
2.3. Need for Logistic Engineering

Experience in recent years has indicated that the complexity and the costs of systems, in general, have
been increasing. A combination of introducing new technologies in response to a constantly changing set
of performance requirements, the increased external social and political pressures associated with
environmental issues, the requirements to reduce the time that it takes to develop and deliver a new
system to the customer and the requirement to extend the life cycle of systems already in oper ation
constitutes a major challenge. Further, many of the systems currently in use today are not adequately
responding to the needs of the user, nor are they cost -effective in terms of their operation and support.
This is occurring at a time when available resources are dwindling and international competition is
increasing worldwide.
In addressing the issue of cost -effectiveness, one often finds that there is a lack of total cost visibility, as
illustrated by the "iceberg" in Figure 2.3.1 For many systems, the costs associated with design and
development, construction, the initial procurement and installation of capital equipment, production, etc.,
are relatively well known. We deal with, and make decisions based on, these costs on a regular basis.

Figure 2.3 .1. – Total cost visibility

47
However, the costs associated with utilization and the maintenance and support of the system
throughout its planned life cycle are somewhat hidden. This has been particularly true through the past
decade or so when systems have been modified to include the "latest and greatest technology," without
first having considered the cost impact downstream. In essence, we have been relatively successful in
addressing the short -term aspects of cost, but have not been very responsive to the long-term effects.
At the same time, it has been indicated that a large percentage of the total life -cycle cost for a given
system is attributed to operating and maintenance activities (e.g., up to 75% for some systems). When
addressing "cause -and-effect" relationships, one often finds that a significant portion of this cost stems
from the consequences of deci sions made during the early phases of advance planning and conceptual
design. Deci sions pertaining to the selection of technologies, the selection of materials, the design of
a manufacturing process, equipment packaging schemes and diagnostic routines, the accomplishment of
functions manually versus the incorporation of automation, the design of maintenance and support
equipment, etc., have a great i mpact on the "down stream" costs and, hence, life -cycle cost.
Additionally, the ultimate maintenance and support infrastructure selected for a system throughout its
period of utilization can sig nificantly impact the overall cost -effectiveness of that sys tem. Thus, including
life-cycle considerations in the decision -making process from the beginning is critical.
Referring to Figure 1.10, although improvements can be initiated for cost reduction purposes at any
stage, it can be seen that the greatest impac t on life -cycle cost (and hence, main tenance and support
costs) can be realized during the early phases of system design and development. In other words,
logistics and the design for supportability must be inherent within early system design and
developme nt process if the results are to be cost-effective.
Figure 2.3.2 – Opportunity for impacting logistics and system cost -effectiveness [2]

48
Through the years, logistics has been considered "after -the-fact," and the activi ties associated with
logistics have not been very popular, have been implemented downstream in the system life cycle, and
have not received the appropriate level of management attention. Experience has indicated that these
prevailing practices have been detrimental in many ins tances and the results have been costly, as
conveyed in Figure 2.3.1. Although much has been accomplished in considering logistics in the design
process, such coverage is still occurring rather late.
Figure 2.3.3 provides a rough com parison showing the e ffects of early life -cycle planning as compared
to programs that address supportability issues later on. Hence, it is imperative that for future system
design and development (and/or reengineering) efforts emphasis should be placed on :

Figure 2.3.3. – The consequence of not addressing supportability from the beginning
(1) improving our methods for defining system requirements as related to true customer needs, early
in the conceptual design phase, and addressing performance, effec tiveness, and all essen tial
characteristics of the system on an integrated basis (to include the specific requirements for logistics);
(2) addressing the total system, its prime mis sion-oriented components and its elements of support
from a life -cycle perspective;
(3) organizi ng and integrating the appropriate and necessary logistics -related activities into the
mainstream system design effort, concurrently and in a timely manner; and
(4) establishing a disciplined approach, with the necessary review, evaluation, and feed back p rovisions
to ensure that logistics (and the design for supportability) is adequately considered in the overall system
acquisition process.

49
In summary, logistics (and the design for supportability) must be considered as an integral part of the
engineering p rocess. By identifying and defining the proper requirements in the beginning, a good
foundation should be established.

2.4 Terms and definitions

With the objective of further clarifying the field of logistics and its many interfaces, it seems appropriate
to direct some attention to the language. A few terms and defini tions are discussed to provide the
reader with the fundamentals necessary to better understand the m aterial presented in this text.

2.4.1 System Engineering

Broadly defined, system engineering is "the effective application of scientific and engi neering efforts to
transform an operational need into a defined system configuration through the top -down iterative pr ocess
of requirements and functional analysis, allocation, synthes is, design optimization, test, and evaluation."
The system engineer ing process, in its evolving of functional detail and design requirements, has as its
goal the achievement of the proper balance between operational (i.e., performance), eco nomic, and
logistics factors.
A slightly different definition (and one that is preferred by the author) is "the application of scientific and
engineering efforts to (a) transform an operational need into a description of system performance
parameters and a system config uration through the use of an iterative process of definition, synthesis,
analysis, design, test, and evaluation; (b) integrate related technical parameters and ensure compatibility
of all physical, functional, and program interfaces in a manner that optim izes the total sys tem definition and
design; and (c) integrate reliability, maintainability, safety, human, supportability, producibility, disposability
and other such factors into the total engi neering effort to meet cost, schedule, and technical perfor mance
objectives."14
Basically, system engineering is good engineering with certain designated areas of emphasis, a few of
which are noted:
A top -down approach is required, viewing the system as a whole. While engi neering activities in the past
have very adequately covered the design of various system components, the necessary overview and an
understanding of how these components effectively fit together have not always been present.
A life-cycle orientation is required, addressing all phases to include sy stem design and developm ent,
production and/or construction, distribution, operation, su staining support, and retirement and phase -out.
Emphasis in the past has been placed primarily on system design a ctivities, with little (if any)
consideration of their impact on production, operations, and logistic support.
A better and more complete effort is required relative to the initial identification of system requirements,
relating these requirements to specific design goals, the development of appropriate design criteria, and the
follow -on analysis effort to ensure the effectiveness of early decisions in the design process. In the past,
the early front -end analysis effort, as applied to many new systems, has been mini mal. This, in turn, has

50
required greate r individual design efforts downstream in the life cycle, many of which are not well
integrated with other design activities and require later modification.
An interdisciplinary effort (Or team approach) is required throughout th e system design and develop ment
process to ensure that all design objectives are met in an effective manner. This necessitates a complete
understanding of the many differ ent design disciplines and their interrelationships, particularly for large
projects .
When referring to the syst em life cycle, one should view not only the prime mis sion-oriented elements of
the system (e.g., a radar set, a communications network), but the applicable production process, the
support infrastructure, and the retirement and material disposal process as well. Basically, the four life
cycles presented in Figure 2.2.2 must be addressed concurrently, as the interactions between the four
categories of activity are numerous. As the prime equipment design materializes, the key questions are
the following: Is t he design configuration producible? Is it supportable? Is it dis posable? Is the approach
economically feasible?
In su mmary, system engineering is not to be considered as being an engi neering discipline in the same
context as electrical engineering, mecha nical engineer ing, reliability engineering, or any other design
specialty area. Actually, system engineering involves the integrated and coordinated efforts of many
different design and related disciplines, applied as part of a top -down/bottom -up process, evolving from
the point when a consumer need is first identified, through development, construction and/or production,
distribution, utilization and support, and the ultimate system retire ment.

2.4.2 . Concurrent Engineering

Recognizing some of the cur rent trends in system acquisition, the Department of .Defense introduced the
concept of concurrent engineering, which is defined as "a sys tematic approach to the integrated,
concurrent design of products and their related processes, including manufacture and support. This
approach is intended to cause the developers, from the outset, to consider all elements of the product life
cycle from con ception through disposal, including quality, cost, schedule, and user requirements. The
objectives of concurrent eng ineering include (1) improving the quality and effec tiveness of systems/
products through a better integration of requirements, and (2) reducing the system/product
development cycle time through a better integration of activities and processes. This, in t urn, should
result in a reduction in the total life -cycle cost for a given system.

2.4.3. Integrated Logistic Support

Integrated logistic support (ILS) is basically a management function that provides for the initial planning,
funding, and controls which help to assure that the ultimate cus tomer (or user) will receive a system that
will not only meet performance requirements, but one that can be expeditiously and economically
supported throughout its pro grammed life cycle. A major objective of ILS is to assure that the prime
mission -related elements of the system are designed to be supportable, and that the elements of the
support infrastructure are designed to be compatible with the prime system elements and with each
other.

51
2.4.4. Logistic Engineering

Logistics engineering includes those basic design -related functions, implemented as necessary to meet
the objectives of ILS. This may include
1. The initial definition of system support requirements (as part of the requirements analysis task in
systems engi neering)
2. The development of criteria as an input to the design of not only those mission -related
elements of the system but for the support infrastructure as well (input to design and procurement
specifications)
3. The ongoing evaluation of alternative design configurations through the accom plishment of trade –
off studies, design optimization, and formal design review (i.e., the day -to-day design
integration tasks pertaining to system supportability)
4. The determination of the resource requirements for support b ased on a given design
configuration (i.e., personnel quantities and skill levels, spares and repair parts, test and
support equipment, facilities, transportation, data, and computer resources)
5. The ongoing assessment of the overall support infrastructure w ith the objective of
continuous improvement through iterative process of measurement, evalua tion, and
recommendations for enhancement (i.e., the data collection, evaluation, and process improvement
capability)
Although the overall spectrum of logistics in cludes many additional functions (e.g., procurement,
distribution, transportation, maintenance, and so on), the emphasis here is on the design for supportability.

Acquisition logistic
Acquisition logistics, a term currently being emphasized in the defense sector, can be defined as "a
multifunctional technical management discipline associated with the design, development, test,
production, fielding, sustainment, and improvement modi fications of cost -effective systems that achieve
the user's peacetime and w artime readi ness requirements. The principal objectives of acquisition logistics
are to ensure that support considerations are an integral part of the system's design requirements, that the
system can be cost effectively supported throughout its life cycl e, and that the infra structure elements
necessary to the initial fielding and operational support of the sys tem are identified and developed and
acquired." [8]

Supportability Analysis (SA)
The supportability analysis (SA) is an iterative analytical process by which the logistic support necessary for a
new (or modified) system is identified and evaluated.
The SA constitutes the application of s elected quantitative methods to:
(1) aid in the initial determination and es tablishment of supportability criteria as an input to design;
(2) aid in the evaluation of various design alternatives;

52
(3) aid in the identification, provision ing, and procurement of the various elements of maintenance and
support;
(4) aid in the final assessment of the system support infrastructure throughout the utilization phase. The SA
constitutes a design analysis process, which is part of the overall system engineering analysis effort, applied
during the early phases in the life cycle and often includes the maintenance task analysis (MTA), level of
repair analysis (LORA), FMECA/FTA, reliability -centered maintenance (RCM) analysis, transportation
analy sis, life -cycle cost analysis (LCCA), and logistics modeling.
Through the years, there have been m any different terms used to describe to the same level of effort.
These include the logistics support analysis (LSA), a concept initiated in 1973 and still being applied on
many programs today. Additionally, what is currently being defined within the scope of the SA has been
covered in the past under a maintenance engineering analysis (MEA), maintenance level analysis
(MLA), ;maintenance task analysis (MTA), maintenance engineering analysis record (MEAR), maintenance
analysis data system (MADS), and so on In dependent of what it is called, the concepts and principles
remain th e same.

Continuous Acquisition and Life -Cycle Support (CALS)
CALS pertains to the application of computerized technology to the entire spectrum of logistics. Of
particular emphasis in re cent years is the development and processing of data, primarily in a digital format,
with the objectives of reducing preparation and processing times, eliminating redundancies, shortening the
system acquisition process, and reducing overall program costs. Specific applications thus far have included
the automation of technical publications, the preparation of digital data for spares/repair parts provisioning
and procurement, and in the development of design data defining products in a digital format.

Reliability (R)
Reliability can be defined simply as the probability that a system or product will per form in a satisfactory
manner for a given period of time when used under specified operating conditions. This definition s tresses the
elements of probability, satisfactory performance, time, and specified operating conditions. These four
elements are extremely important, since each plays a significant role in determining system/product reliability.
Probability, the first elem ent in the reliability definition, is usually stated as a quantitative expression
representing a fraction or a percent signifying the number of times that an event occurs (successes), divided
by the total number of trials. For instance, a statement that th e probability of survival (Ps) of an item for 80
hours is 0.75 (or 75%) indicates that we can expect that the item will function properly for at least 80
hours, 75 times out of 100 trials.
When there are a number of supposedly identical items operating und er similar conditions, it can be expected
that failures will occur at different points in time; thus, failures are described in probabilistic terms. In
essence, the fundamental definition of reliability is heavily dependent on the concepts derived from
probability theory.
Satisfactory performance, the second element in the reliability definition, indi cates that specific criteria
must be established that describe what is considered to be satisfactory system operation. A combination of
qualitative and quanti tative factors defining the functions that the system or product is to accomplish,
usually presented in the context of a system specification, are required.

53
The third element, time, is one of the most important since it represents a mea sure against which the degree
of system performance can be related. One must know the "time" parameter in order to assess the
probability of completing a mission or a given function as scheduled. Of particular interest is being able to
predict the proba bility of an item surviving (without failure) for a designated period of time (sometimes
designated as R or P). Also reliability is frequently defined in terms of mean time between failure (MTBF),
mean time to failure (MTTF), or mean time between main tenanc e (MTBM); thus, the aspect of time is
critical in reliability measurement.

The specified operating conditions under which we expect a system or product to function constitute the
fourth significant element of the basic reliability definition. These condit ions include environmental
factors such as geographical location where the system is expected to operate, the operational profile, the
transportation profile, temperature cycles, humidity, vibration, shock, and so on. Such factors must not
only address the conditions for the period when the system or product is operating, but the conditions for
the periods when the system (or a portion thereof) is in a storage mode or being transported from one
location to another. Experience has indicated that the transpor tation, handling, and storage modes are
sometimes more critical from a relia bility standpoint than the conditions experienced during actual
system operational use.
The four elements discussed above are critical in determining the reliability of a system o r product.
System reliability (or unreliability) is a key factor in the frequency of maintenance, and the maintenance
frequency obviously has a significant impact on logistic support requirements. Reliability predictions and
analyses are required as an input to the supportability analysis.
Reliability is an inherent characteristic of design. As such, it is essential that reli ability be adequately
considered at program inception, and that reliability be addressed throughout the system life cycle.

Maintaina bility (M)
Maintainability, like reliability, is an inherent characteristic of system or product design. It pertains to the ease,
accuracy, safety, and economy in the performance of maintenance actions. A system should be designed
such that it can be maint ained with out large investments of time, cost, or other resources (e.g., personnel,
materials, facil ities, test equipment) and without adversely affecting the mission of that system.
Maintainability is the ability of an item to be maintained, whereas mai ntenance con stitutes a series of
actions to be taken to restore or retain an item in an effective oper ational state. Maintainability is a design
parameter. Maintenance is a result of design.
Maintainability can also be defined as a characteristic in desi gn that can be expressed in terms of
maintenance frequency factors, maintenance times (i.e., elapsed times and labor -hours), and maintenance
cost. These terms may be presented as dif ferent figures of merit; therefore, maintainability may be defined
on the basis of a com bination of factors, such as:
A characteristic of design and installation which is expressed as the probability that an item will be
retained in or restored to a specified condition within a given period of time, when maintenance is
performed in accordance with prescribed procedures and resources.
A characteristic of design and installation which is expressed as the probability that maintenance will not be
required more than x times in a given period, when the system is operated in ac cordance with prescribed

54
procedures. This may be analogous to reliability when the latter deals with the overall frequency of
maintenance.
A characteristic of design and installation which is expressed as the probability that the maintenance
cost for a sys tem will not exceed y dollars per designated period of time, when the system is operated
and maintained in accordance with prescribed procedures.
Maintainability requires the consideration of many different factors involving all aspects of the system,
and the measures of maintainability often include a combination of the following:

1. MTBM: mean time between maintenance, which includes both preventive (scheduled) and
corrective (unscheduled) maintenance requirements. It includes consideration of reliability
MTBF and MTBR. MTBM may also be considered as a reliability parameter.
2. MTBR: mean time between replacement of an item due to a maintenance action (usually
generates a spare part requirement).
3. M1: mean active maintenance time (a function of Met and Mpt).
4. Met: mean corrective maintenance time. Equivalent to mean time to repair (MTTR).
5. Mpt: mean preventive maintenance time.
6. Met: median active corrective maintenance time.
7. Mpt: median active preventive maintenance time.
8. MTTR g: geometric mean time to repair.
9. Mmax: maximum active corrective maintenance time (usually specified at the 90% and 95%
confidence levels).
10. MDT: maintenance downtime (total time during which a system is not in condi tion to perform
its intended function). MDT includes active maintenance time (M), logistics delay time (LDT),
and administrative delay time (ADT).
11. MLH/OH: maintenance labor hours per system operating hour.
12. Cost/OH: maintenance cost per system operating hour.
13. Cost/MA: maintenance cost per maintenance action.
14. Turnaround time (TAT): t hat element of maintenance time needed to service, repair, and/or
check out an item for recommitment. This constitutes the time that it takes an item to go through
the complete cycle from operational installation through a maintenance shop and into the spa res
inventory ready for use.
15. Self-test thoroughness: the scope, depth, and accuracy of testing.
16. Fault isolation accuracy: accuracy of system diagnostic routines in percent.
Maintainability, as an inherent characteristic of design, must be properly consid ered in the early phases
of system development, and maintainability activities are applicable throughout the life cycle. [9]

55
3. Maintenance

Maintenance includes all actions necessary for retaining a system or product in, or restoring it to, a
service able condition. Maintenance may be categorized as corrective maintenance or preventive
maintenance.
1. Corrective maintenance: includes all unscheduled maintenance actions per formed, as a result of
system/product failure, to restore the system to a specif ied condition. The corrective maintenance cycle
includes failure identification, local ization and isolation, disassembly, item removal and replacement or
repair in place, reassembly, checkout and condition verification. Also, unscheduled main tenance may occur
as a result of a suspected failure, even if further investigation indicates that no actual failure occurred.
2. Preventive maintenance: includes all scheduled maintenance actions performed to retain a system
or product in a specified condition. Scheduled maintenance includes the accomplishment of periodic
inspections, condition monitoring, crit ical item replacements, and calibration. In addition, servicing
requirements (e.g., lubrication, fuel ing, etc.) may be included under the general category of sched uled
maintenance.

3.1. Maintenance level

Corrective and preventive maintenance may be accomplished on the system itself (or an element thereof)
at the site where the system is used by the cus tomer, in an inter mediate shop near the customer's
operational site, and/or at a depot, supplier or man ufacturer's plant facility. Maintenance level pertains to
the division of functions and tasks for each area where maintenance is performed. Task comple xity,
personnel -skill-level requirements, special facility needs, economic criteria, and so on, dictate to a great
extent the specific functions to be accomplished at each level. In support of fur ther discussion,
maintenance may be classified as organiza tional, intermediate, and depot.

3.2. Maintenance concept

The maintenance concept constitutes a series of statements and/or illustrations defining criteria covering
maintenance levels (i.e., two levels of maintenance, three levels of maintenance, etc.), major functions
accomplished at each level of maintenance, basic support policies, effectiveness factors (e.g, MTBM, Mct,
MLFT/OH, cost/MA, etc .), and primary logistic support requirements. The mainte nance concept is
defined at program inception and is a prerequisite to system/product design and development. The
maintenance concept is also a required input to the sup portability analysis.

3.3. Maintenance plan

The maintenance plan (as compared to the maintenance concept) is a detailed plan specifying the
methods and procedures to be followed for system support throughout the life cycle and during the

56
utilization phase. The plan includes the identification and use of the required ele ments of logistics
necessary for the sustaining support of the sys tem. The maintenance plan is developed from the
supportability analysis (SA) data, and is usually prepared during the detail design phase.

3.4. Total Productive Maintenance (TPM)

Total productive maintenance (TPM) is a Japanese concept involving an integrated, top -down, system life –
cycle approach to maintenance, with the objective of maximizing productivity. TPM is directed primarily to
the commercial manufacturing environment, utilizing many of the principles inherent within the TLS
concept. More specifically, TPM:
1. Aims to maximize overall equipment effectiveness (to improve overall efficiency).
2. Establishes a complete preventive maintenance program for the entire life cycle of equ ipment.
3. Is implemented on a team basis and involves various departments, such as engi neering, production
operations, and maintenance.
4. Involves every employee, from top management to the workers on the floor, Even equipment
operators are responsible for ma intenance of the equipment they operate.
5. Is based on the promotion of preventive maintenance through motivational management
(autonomous small -group activities).
TPM, often defined as productive maintenance implemented by all employees, is based on the pr inciple that
equipment improvement must involve everyone in the orga nization, from line operators to top
management. The objective is to eliminate equip ment breakdowns, speed losses, minor stoppages, and so
on. It promotes defect -free production, just -in-time (JIT) production, and automation. TPM includes
continuous improvement in maintenance.

3.5. Human Factors

Human factors pertain to the human element of the system and the interface(s) between the human
being, the machine, facilities, and associated software. The objec tive is to assure complete compatibility
between the system physical and functional design features and the human element in the operation,
maintenance, and support of the system. Considerations in design must be given to anthropometric factors
(e.g., the physical dimensions of the human being), human sensory factors (e.g., vision and hear ing
capabilities), physiological factors (e.g., impacts from environmental forces), psy chological factors (e.g.,
human needs, expectations, attitude, motivation), and their interrelationships. Human factors (like
reliability and maintainability) must be con sidered early in system development through the
accomplishment of functional analy sis, operator and maintenance task analysis, error analysis, saf ety
analysis, and related design support activities. Operator and maintenance personnel requirements (i.e.,
personnel quantities and skill levels) and training program needs evolve from the task analysis effort.
Maintenance personnel requirements are also identified in the sup portability analysis.

57
3.6. Software engineering

With today's trends and the continuing development of computer technology, software is becoming (if
not already) a significant element in the configuration of many systems. Current exp erience indicates that
software considerations are inherent in more than 50% of the system design and development efforts in
being. Software may be viewed in three areas.
Software that is included as a mission -related component of the system and is require d for the operation of
that system. From a logistics perspective, there is a requirement to maintain this software throughout its
planned life cycle.
Software that is required to accomplish maintenance functions on the system (e.g., diagnostic routines,
condition monitoring programs). A logistics engineer ing function includes the initial development and the
subsequent maintenance of this software.
Software that is required in support of program -oriented activities (e.g., the soft ware associated with
variou s computer -based models used for design analyses, the software associated with the preparation
and processing of various categories of design data such as required to meet the requirements for
CALS).
The development of software must be properly integrated with the development of the hardware, human,
and other elements of the system. Further, these activities, as logistics engineering.

3.7. Producibility

Producibility is a measure of the relative ease and economy of producing a system or a product. The
characteristics of design must be such that an item can be produced eas ily and economically, using
conventional and flexible manufacturing methods and processes without sacrificing function,
performance, effectiveness, or quality. Simplic ity and flexibility are the underlying objectives, and it is
the goal to minimize the use of critical materials and critical processes, the use of proprietary items, the
use of spe cial production tooling and facilities, the application of unrealistic tolerances in fabri cation and
assembly, the use of special test systems, and the use of high personnel skills in manufacturing.
Additionally, production and procurement lead times should be min imized to the extent possible.
Producibility objectives should apply to the elements of logistic support, as well as to the main
components of the system.

3.8. Disposability

Disposability pertains to the degree to which an item can be recycled for some other use or disposed of
without causing any degradation to the environment; i.e. the gener ation of solid waste, toxic substances
(air pollution), water pollution, noise pollution, radiation, and so on. Should this area not be addressed in

58
the design, the requirements for logistics may turn out to be rather extensive and costly in ord er to comply
with the environmental re quirements currently being impos ed.
For example, a large incinera tion facility may be required for material decomposition. This, in turn,
may include large amounts of capital equipment which requires maintenance and could be very costly
to support.

3.9. Total Quality Management (TQM)

Total quality management (TQM) can be described as a total integrated management approach that
addresses system product quality during all phases of the life cycle and at each level in the overall system
hierarchy. It provides a before -the-fact orientation to quality, and it focuses on system design and
development activities, as well as pro duction, manufacturing, assembly, construction, logistic support, and
related functions. TQM is a unification mechanism linking human capabilities to engineering, produc tion,
and support processes. Som e specific characteristics of TQ M are noted.

Total customer satisfaction is the primary objective, as compared to the practice of accomplishing as little
as possible in conforming to the minimum requirements.
Emphasis is placed on the iterative practice of "continuous improvement" as applied to engineering,
production, and support processes. The objective is to seek improvement on a day -to-day basis, as
compared to the often -impose d last minute single thrust initiated to force compliance with a standard.
In support of item 2, an individual understanding of processes, the effects of vari ation, the application of
process control methods, and so on, is required. If indi vidual employees are to be contributors relative to
continuous improvement, they must be knowledgeable of the various processes and their inherent
characteristics.
TQM emphasizes a total organizational approach, involving every group in t he organization, not just the
quality control group. Individual employees are moti vated from within and are recognized as being key
contributors to meeting T QM objectives.
As part of the initial system design and development effort, consideration must be given to (1) the design
of the processes that will be used to produce the system and its components, and (2) the design of the
support capability that will b, used to pro vide the necessary ongoing Maintenance and support for that
system. As illustrated in Figure 2.2.2, these facets of program activity interact, and the results (in terms
of ulti mate customer satisfaction) will depend heavily on the level of quality attained.

3.10. Configuration Management

CM is a management approach used to identify the functional and physical character istics of an item in
the early phases of its life cycle, control changes to those charac teristics, and record and report change
processing and implementation status. CM involves four functions to include (1) configuration
identification, (2) configuration control, (3) configuration status accounting, and (4) configuration

59
audits. CM is base line management (i.e., the planning, design, and providing logistic support for a system
with a given and known baseline configuration versus attempting to provide a support infrastructure for many
different and constantly changing baselines which can be very expensive as conveyed in Figure 1.11). The
big issue is the control and justification of changes. CM is a major factor in the impl ementation of system
engineering require ments and functional, allocated, and product baselines are usually established as the
system design and development effort evolves.

3.11. System effectiveness

System effectiveness can be expressed as one or more fi gures of merit representing the extent to which
the system is able to perform the intended function. The figures merit used may vary considerably
depending on the type of system and its mission requirements, and should consider the following:
System performance parameters, such as the capacity of a power plant, range or weight of an airplane,
destructive capability of a weapon, quantity of letters processed through a postal system, amount of
cargo delivered by a transporta tion system, and the accuracy of a radar capability.
Availability, or the measure of the degree a system is in the operable and commit table state at the
start of a mission when the mission is called for at an unknown ran dom point in time. This is often called
operational readiness. Availability is a function of operating time (reliability) and downtime
(maintainability/supportability).
Dependability, or the measure of the system operating condition at one or more points during the
mission, given the system cond ition at the start of the mission (i.e., availability). Dependability is a
function of operating time (reliability) and downtime (maintainability/supportability).
A combination of these (and perhaps other) measures represents the technical characteristics of a
system, as opposed to cost and the economic aspects. By inspection, one can see that logistics affects the
various elements of system effectiveness to a sig nificant degree, particularly with regard to availability
and dependability. System oper ation is highly dependent on support equipment (handling equipment),
operating personnel, data, and facilities. Maintenance and system downtime are based on the availability
of test and support equipment, spare/repair parts, maintenance personnel, data, and fac ilities. The effect of
the type and quantity of logistic support is measured through the parameters of system effectiveness.

3.12. Life -Cycle Cost (LCC)

LCC involves all costs associated with the system life cycle, to include the following:
Research and development (R&D) cost. The cost of feasibility studies; system analyses; detail design
and development, fabrication, assembly, and test of engi neering models; initial system test and evaluation;
and associated documentation.
Production and construction c ost. The cost of fabrication, assembly, and test of operational systems
(production models); operation and maintenance of the pro duction capability; and associated initial
logistic support requirements (e.g., test and support equipment development, spare/repair parts

60
provisioning, technical data development, training, entry of items into the inventory, facility construc –
tion, etc.).
Operation and maintenance cost. The cost o f sustaining operation, personnel and maintenance support,
spare/repair parts and related inventories, test and support equipment maintenance, transportation and
handling, facilities, modifications and technical data changes, and so on.
System retirement a nd phase -out cost. The cost of phasing the system out of the inventory due to
obsolescence or wear out, and subsequent equipment item recy cling, disposal, and reclamation as
appropriate.
Life-cycle costs may be categorized many different ways, depending o n the type of system and the
sensitivities desired in c ost-effectiveness measurements.
3.13. Cost -Effectiveness (CE)

The development of a system or product that is cost -effective, within the constraints specified by
operational and maintenance requirement s, is a prime objective. Cost -effectiveness relates to the measure
of a system in terms of mission fulfillment (system effectiveness) and total life -cycle cost. Cost –
effectiveness, which is similar to the stan dard cost -benefit analysis factor employed for decision –
making purposes in many industrial and business applications, can be expressed in various terms (i.e.,
one or more figures of merit), depending on the specific mission or system parameters that one wishes
to measure.
The prime ingredients of cos t-effectiveness are illustrated in Figure 2.5.13.1.

Fig. 3 .13.1 – Basic Ingredients of cost -effectiveness [2]

61
Conclusion

By now we have a basic knowledge about system engineering and the concept of life -cycle design and
their relevance in aviation . We have seen that o ne of the most significant challenges in conceptual design
is managing the trade space of potential architectures, choosing which design to pursue aggressively,
which to keep on the table and which to leave behind. This thesis provides a fr amework for managing a
trade space for system engineering not through traditional effectiveness measures like cost and
performance, but instead through a quantitative analysis of the embedded uncertainty in each pot ential
space of system engineering .
Cost and performance in this approach remain central themes in decision making, but uncertainty serves
as the focal lense s to identify potentially powerful combinations of architectures to explore concurrently
in further design phases. Presented is an approach to identify, assess, a nd quantify the system engineering ,
as well as a means to manage it using portfolio theory and optimization. Perhaps best known to
economists and investors, portfolio theory is based around the objective of maximizing return subject to a
decision maker's risk aversion.
The many new challenges emerging in the aerospace industry today are resulting in new initiatives and
insights to the role of engineering design and analysis and in particular the need for collaborative multi –
disciplinary approaches to solving the problems ahead. It is evident that major gains will be difficult to
achieve even with step changes in a single technology. It is the integrated approach that will permit the
exploration of new design spaces. Within this paper the state of the art in system engineer ing and the
integration of traditional analysis disciplines in this framework were reviewed .
There is no question that in design synthesis and analysis within system engineering the integration of
aerodynamic structures manufacturing and CAD for reduced co st/reduced lead -time can be performed at
least to first -order accuracy. However, the whole life cycle modelling of an aircraft within the context of
SE, for performance, cost, environment, safety is at an infant stage as the integration is highly complex
involving additionally people, product and processes which do not fit easily with engineering analyses.
The major challenge is to provide this environment such that technical details can be accounted for
appropriately, without overwhelming the high level des ign challenges and where the influence of data and
parameters throughout and across systems is clearly understood.
On a final note, although this thesis is aviation oriented, the information found in this paper can be as
easily applied to any workspace or e ven used for personal evolution in spite of the fact that system
engineering is an integrator of multiple disciplines and its resourcefulness can come in handy as a
insightful approach in many case studies.

62

Acknowledgements

I would l ike to acknowl edge my advisor, Prof. Dr. Ing. Ion Fuiorea . In his capacity as my research
supervisor Prof. Fuiorea afforded me the freedom to explore my interests in system engineering and life
cycle design that served as the basis for this research. His continuous s upport and encouragement made
this thesis possible.

63

Biography

[1] Systems Engineering Fundaments, January 2001 , UPPLEMENTARY TEXT PREPARED BY THE
DEFENSE ACQUISITION UNIVERSITY PRESS FORT BELVOIR, VIRGINIA 22060 -5565
[2] Logistics Engineering and Management Fifth Edition – Benjamin S. Blanchard Prentice Hall
International Series in Industrial and System Engineering
[3] An integrated systems engineering approach to aircraft design M. Price, S. Raghunathan, R. Curran
Centre of Excelle nce for Integrated Aircraft Technologies, School of Mechanical and Aerospace
Engineering, Queen’s University Belfast, Belfast BT9 5AG, UK
[4] – Comprehensive analysis of transport aircraft flight performance Antonio Filippone School of
Mechanical, Aerospac e and Civil Engineering, The University of Manchester, George Begg Building,
P.O. Box 88, Manchester M60 1QD, UK
[5] – SYSTEMS ENGINEERING FOR COMMERCIAL AIRCRAFT – Scott Jacksonouglas Aircraft
Company 3855 Lakewood Blvd. Long Beach, California 90846
[6] S AAB – Model Based Systems Engineering for Aircraft Systems – How does Modelica Based Tools
Fit. Ingela Lind Henric Andersson SAAB Aeronautics SE -581 88 Linköping, Sweden
[7] – Lifecycle cost engine – A Systems Engineering Approach to Aero -Engine Life Cycl e Costing James
S. Wong*, James P. Scanlan and Murat H. Eres Computational Engineering Design Group, University of
Southampton, Southampton, Hampshire, SO17 1BJ, U.K.
[8] M1L -HDBK -502, "Department of Defense Handbook —Acquisition Logistics," May 1997
[9] 'B lanchard, B. S., D. Verma, and E. L. Peterson, Maintainability: A Key to Effective Serviceability
and Vaintenance Management, John Wiley & Sons, Inc., New York, N.Y., 1995.
[10] Nickol C. Conceptual design shop. In: Presentation to conceptual aircraft des ign working group
(CADWG21), September 2004.
[11] Hoult DP, Meador CL, Deyst J, Dennis M. Cost awareness in design: the role of data commonality.
SAE technical paper, Number 960008, 1996.
[12] Sheldon DF, Huang GQ, Perks K. Design for cost: past experience and recent development. J Eng
Des 1991
[13] Dean EB, Unal R. Elements of designing for cost. In: Proceedings of AIAA 1992 Aerospace Design
Conference, Irvine, CA, February 1992.
[14] Jameson A. Re -engineering the design process through co mputation. AIAA J Aircraft 1999
[23] Price M, Early JM, Curran R, Benard E, Raghunathan S. Identifying interfaces in engineering
sy15 ems. AIAA J 2006
[16] Department Of Defence (DoD). Parametric estimating handbook, 2nd ed. DoD; 1999.

64
[17] MIL -HDBK -226, Military Handbook, Application of Reliability -Centered Maintenance to Naval
Aircraft, Weapon Systems, and Support Equipment, Department of Defense, Wash ington, D.C.
[18] MIL -HDBK -502, DOD Handbook: Acquisition Logistics, Department of Defense, Wash ington,
D.C., May 1997.
[19] MIL -PRF-49506, Performance Specification, Logistics Management Information, Depart ment of
Defense, Washington, D.C., November 1996.
[20] MIL -STD -1388 -1A, Military Standard, Logistic Support Analysis, Department of Defense,
Washington, D.C.
[21] MIL -STD -1388 -2B, Military Standard, Department of Defense Requirements for a Logistic
Support Analysis Record, Department of Defense, Washington, D.C.
[22] MIL -STD -1840A, Military Standard, Automated Interchange of Technical Information,
Department of De fense, Washington, D.C.
[23] http://theopenacademy.com/content/aircraft -systems -engineering – Jeffrey Hoffman. MIT
[24] http://forum.kerbalspaceprogram.com/index.php?/topic/47818 -basic -aircraft -design -explained –
simply -with-pictures/