Architecting & Designing
Air Transportation Systems
Prof. John-Paul Clarke
Massachusetts Institute of Technology
16.899
March 4, 2004
System Architecture Framework
Source: Crawley and de Weck
System
architecture
Regulation
Corporate
strategy
Competition
Market Data
Where?
form
Manufacturing,
Operations,
Illities*
Structure
Why ?
needs
What ?
goals
Purpose Performance
Requirements
How ?
function
concept
+constraints
Behavior
When?
timing
Action
Who?
operator
Users
Market
Strategy
Training
Technology
Customer(s)
Outbound
marketing
strategy, Sales,
Distribution
can be
*Reliability, Servicability, Environmental Impact, Upgradeability, Flexibility,etc…
What is architecture?
† Logical and physical embodiment of a
system
† Mechanism that
È Shapes the functional and physical boundaries
of the system
È Governs the behavior and structure of the
system
Why is architecture important?
† The “right” architecture can:
È Maximize system robustness
È Maximize system flexibility
È Minimize system complexity
È Enable desirable behavior
È Deter undesirable behavior
† Example(s):
È An electrical circuit breaker limits the
undesirable behavior that would result from a
surge in the supply voltage
How do we determine architecture?
† Synthesis
† Discovery
† Chance
Synthesis
† Combining existing systems to satisfy
stated needs
† Requires logic and complete (or near
complete) knowledge of existing systems
† Example(s):
È Designing a mechanism to support a person
who wants to cross “over” a river or stream
Key question(s) for synthesis?
† What functions do I need to get the job
done?
† Is there a way to combine existing systems
to do the desired functions without having
too many extra functions and too much
extra form?
† What rules do I have to apply to do this?
Discovery
† Using knowledge of existing architecture to
“discover” new architecture
† Requires knowledge of existing systems
and pattern recognition, analysis and
abstraction skills
† Example(s):
È Man learning how to fly
È Disease and drug pathways
Key question(s) for discovery?
† Is there some analogous system in another
domain?
† What are the properties of a given
architecture that makes it perform so well
(or poorly)?
† Are there similar (or better) ways to perform
those functions?
Chance
† Observing “nature” and recognizing
“events”
† Requires pattern recognition skills and lots
of luck
† Example(s):
È Discovery of synthetic rubber
È First “cave woman” to observe that two rocks
struck together produces fire
Key question(s) for chance?
† What activity should I be doing to maximize
the likelihood of a concept developing?
È Should I be drinking coffee at Starbucks of
tinkering in the lab?
Are they mutually exclusive?
† No!
† Most of the processes we use to determine
architecture combine the three approaches
† Example(s):
È Chance->Discovery->Synthesis
È Synthesis->Discovery&Chance
How do I know the best architecture?
† Selection process
È Natural selection
È Artificial selection
† Goals and metrics
Robustness
† Ability of a system to “perform” under
various operating conditions
† Robustness can be measured
È Range of operating conditions (both internal and
external) over which the performance of a
system is within an acceptable “distance” of its
peak performance
È Ex: Frequency response of a control system
Flexibility
† Flexibility is the means though which we
achieve robustness
† Flexibility can be measured
È Number of different modes or states in which
system can be successfully operated
È Ease with which the operating mode or state
can be changed
† Ex: Humans
† Flexibility leads to complexity
Complexity
† Complexity is the degree to which the set of
possible states of a system exceeds the set
of desired states
† Complexity can be measured
È Information required to describe all the
components, their interconnections and their
interactions
È Number of homogeneous/dissimilar elements,
homogeneous/dissimilar interconnections, and
ways components are organized
Complexity
† Complexity is subjective
È Influenced by user perception and presentation
scheme
È Ex: cruise control system in automobiles
• Low apparent complexity as presented to
drivers: knobs, buttons
• High apparent complexity if you include
physical parts such as electromechanical
components or logics such as control laws
Complexity
† Complexity can be decomposed
È Essential complexity: minimum level of
complexity that is essential to deliver system
function
È Gratuitous complexity: additional complexity
beyond essential complexity
Architecture and Complexity
† Architecture determines the parts and their
interaction (form and function)
† Different architectures have different levels
of robustness, flexibility and complexity
È Ex: cruise control system vs. driver as a control
and feedback mechanism
† Characteristics of good architecture
È Actual complexity is close to essential
complexity
È Enhances system behavior by improving
system predictability
Analogy between Entropy and Complexity
† Complexity has a lower limit i.e. actual
complexity is always greater or equal to
essential complexity
† Complexity is a property to engineered
systems as entropy is to thermodynamic
systems
† These generalities cannot be expressed
qualitatively, but their importance can be
demonstrated with specific examples
Analogy between Entropy and Complexity
Thermodynamic domain:
System Engineering domain:
∫
(Sgenerated )1→2 ≡ (S2 – S1) -
2
1
⎛ δQ ⎞ > 0
⎜
⎟
T
⎝
⎠ irrev
• Objective is to minimize entropy
generation or irreversibility
• Limited by physical laws and practical
considerations on the rate energy at
which energy can be extracted
• Flow systems are energy conversion
devices to minimize entropy generation
Cgratuitous ≡ Cactual – Cessential > 0
• Objective is to minimize gratuitous
complexity
• Limited by physical laws and practical
considerations on the rate at which
information can be shared
• Integrated product teams are the
equivalent of “flow systems”
Examples Problem
† How can we reduce the noise impact of
aircraft (during approach) on communities
near airports without losing capacity?
Motivation
† Noise is an important factor in the siting
and operation of airports
È Negative reaction by community to noise from
aircraft
È Community agreement required for increase in
number of operations, airport expansion or
airspace changes
È Lengthy environmental studies required for
approval and federal mitigation funding
È Significant reduction in number of new runways
built
Motivation (2)
120
B-52
Turbojet
720
CV990A
CV880-22
Noise Level (EPNdB)
(1500 ft Sideline)
707-100
Comet 4 DC8-20
110
DC9-10
737-100
737-200
DC8-61
707-300B
Caravelle
100
BAC-111
First Generation
Turbofan
727-100
727-200
Second Generation Turbofan
747-100
MD-80
747-200
DC10-10
737-400 A321
747-300A310-300
747-400
767-200
A330
767-300
737-500
757-200
737-700
737-300
(est.)
A340
BAe-146-200
777
MD-11 MD90-30
A300B2-101
DC10-30
L-1011
90
1950
1960
1970
A320-100
1980
1990
Year of Initial Service
Normalized to 100,000 Ib thrust
Noise level are for airplane/engine configurations at time of initial service
1995
Motivation (4)
† Operational procedures can provide
significant additional noise reductions
È Thrust management strategies redistribute
noise impact during departure and reduce
impact during approach
È Lateral deviations direct aircraft away from
populated areas during departure and approach
È Applied only at airports with severe noise
restrictions
È Limited in applications because of flight
guidance technology limitations
Motivation (4)
† Advanced flight guidance technologies may
be used to improve the applicability and
effectiveness of noise abatement
procedures
È GPS will be the base of the future primary
navigation system in the United States [FAA,
1996]
È Flight procedures are being re-examined as part
of the transition to satellite navigation
È Area Navigation (RNAV) using position
information from the Global Positioning System
(GPS) enables flexible trajectories
Background
† Noise impact determined by 3 components
È Source Characteristics
• Intensity, frequency content, & directivity
È Path Characteristics
• Attenuation, diffraction
È Receiver Characteristics
• Population distribution, time of day
Background (2)
† Components interdependent
È Thrust & speed determine source
characteristics
È Thrust, aerodynamics, & atmospheric
conditions determine aircraft performance
È Speed & atmospheric conditions determine
maximum thrust available
† Provides opportunities for operational
modifications that reduce noise impact
NOISIM
† Methodology for developing noise
abatement procedures
† Combines Flight Simulator, Noise Model,
and Geographic Information System (GIS)
† Simulates realistic aircraft operation (737200 & 767-300)
† Evaluates critical components
simultaneously
† Rapid prototyping and evaluation of noise
abatement procedures
Critical Components
† Aircraft Performance and Trajectory
† Noise Generated by the Aircraft
† Population Distribution and Density
† Flight Safety and Pilot Acceptance
† Guidance and Navigation Requirements
† Local Atmospheric Conditions
NOISIM
MCP Status
Clock
EADI
Speed
V/S
HDG
016
SPD
2470
0619.6z
180
WINDSHEAR
AHEAD
COURSE
GPWS
PULL UP
WINDSHEAR
185
GND
Windscreen
IAS/MACH
HEADING
ALTITUDE
VERT SPEED
5300
PROX
A/T
IDLE
DISPLAY
CMD
VNAV
LNAV
Marker
Beacons
PRECIP
-200
EHSI
8.9 NM
0623.7z
TRK
OUTER
M
030
3
MID
6
36
INNER
WENNY
NOSE
KCOS
LEFT
RIGHT
5
1
UP
10
CAGER
Gear Status
15
FCS
FLOTS
20
30
CONTROL DISPLAY UNIT
25
Flap Status
CONTROL
STICK
MODE CONTROL PANEL
(MCP)
Vertical
Speed
Altitude
GS 193
ALT
5000
17
CAGER
PILOT'S CHAIR
WENNY
WATKI
EKR
036 / 16.9
060 / 23.5
076 / 17.4
35000 / 350
30000 / 300
25000 / 250
20000 / 250
SPEED BRAKES, THROTTLES,
FLAPS, GEAR
(Courtesy of John-Paul Clarke. Used with permission.)
COURSE
ILS Approach
È Glide Slope intercepted
from below
È A/C flies along
extended centerline for
much of approach (final
and intermediate
segments)
IAF
È Low altitude
maneuvering
IF
Join glide path and
commence final
descent
FAF
Alt. 1200 ft
Alt. 300 ft
Runway
Localiser
transmitter
Glide path transmitter
Outer Marker
Middle Marker
ft
3000
3.9 n
m
Alt. 2500 ft
aircra
ft trac
k
ILS Approach (JFK 13L)
† Approach Chart
† Noise Impact
(Image removed due to copyright considerations.)
(Courtesy of John-Paul Clarke. Used with permission.)
3° Decelerating Approach
È Single segment
È Aircraft intercepts segment at high alt. & speed
È Aircraft decelerates during descent at idle thrust
È Achieves approach speed at 500-1,000 ft AGL
È Does not require additional displays
(Image removed due to copyright considerations.)
3° Decelerating Approach (JFK 13L)
† 3° decelerating
approach implemented
to reduce noise
associated with low
altitude vectoring
† Lateral trajectory of
decelerating approach
similar to ILS
approach to avoid
traffic of other airports
(Courtesy of John-Paul Clarke. Used with permission.)
Noise Benefit (JFK 13L)
† Population impacted
by noise greater than
60 dBA reduced from
252,734 (ILS) to 79,851
† 3° decelerating
approach can be used
in Instrument
Meteorological
Conditions (IMC)
Population Impacted by Peak Noise
in 10 dBA Ranges
† 3° decelerating
approach has
equivalent noise
impact to Canarsie
approach
180000
60-70
70-80
80-90
90-100
160000
140000
120000
100000
80000
60000
40000
20000
0
ILS Approach
Canarsie VOR
Approach
Curved 3°
Decelerating
Approach
300000
250000
200000
ILS Approach
Canarsie VOR
Approach
Curved 3° Decelerating
Approach
150000
100000
50000
0
60
70
80
Peak Noise (dBA)
90
100
What is the Product of an Architect? (1)
† Building or system?
È Relationship is indirect: the system is built by
the developer!
† Architect connects
È Problem domain concepts of client AND the
solution domain concepts of builders
† System cannot be built unless architect has
a mechanism to communicate visions and
track construction against it
† Architect provides models of the system!
Source: The Art of Systems Architecting, Maier & Rechtin
What is the Product of an Architect? (2)
† Individual models are point-in-time
representations of a system
È Treat each model as a member of one of several
progressions
First models =>
Concept
Satisfactory
?
Detailed, technology=>
specific models
Source: The Art of Systems Architecting, Maier & Rechtin
Civil Architecture Analogy
† Building pleases client aesthetically,
functionally, financially
Model
Purpose
Physical scale model
Convey look & site placement
Floor plans
Ensure building performs desired
functions
External renderings
Convey look of building
Budgets, schedules
Meet client’s financial performance
objectives
Construction
blueprints
Communicate design req. and
construction criteria to builders
Source: The Art of Systems Architecting, Maier & Rechtin
Models
† Models
È Means of communication with clients, builders,
and users
È Language of architect
È Important for constructing system and
describing and diagnosing its operation
È Can be classified by their roles or content
Source: The Art of Systems Architecting, Maier & Rechtin
Models (2)
† Terminology (IEEE standard):
È Model: approximation, representation, or
idealization of … a real-world system.
È View: representation of a system from the
perspective of related concerns or issues
È Viewpoint: template, pattern, or specification for
constructing a view
Source: The Art of Systems Architecting, Maier & Rechtin
Models (3)
† In other words:
È A Model is a representation of something
È A View is a collection of models that share the
property that they are relevant to the same
concerns for a system stakeholder.
È A Viewpoint is an abstraction of view across
many systems.
Source: The Art of Systems Architecting, Maier & Rechtin
Models (4)
† 6 common views
È Should be complete and “mostly” independent
È System can be projected into any view, possible
in many ways
Purpose/Objectives
Behavior
(functional)
Data
The system
Form
Managerial
View
Performance
Description
Purpose/Objective
What client wants
Form
What the system is
Behavioral or functional
What the system does
Performance objectives
How effectively the system does it
Data
The information retained in the
system and its interrelationships
Managerial
Process by which system is
constructed and managed
Source: The Art of Systems Architecting, Maier & Rechtin
Models (5)
† Integrated modeling method
È A system of representation that links multiple
views
È Consists of a set of models for a subset of
views and a set of rules or additional models to
link the core views
È Most are domain specific
Source: The Art of Systems Architecting, Maier & Rechtin
Integrated Modeling Methodologies
Method
Domain
Hatley/Pirbhai(H/P)
Computer-based reactive or event-driven systems
Quantitative quality function
deployment (Q2FD)
Systems with extensive quantitative performance objectives
and understood performance models
Object modeling technique (OMT)
Large-scale, date-intensive software systems, especially
those implemented in modern object languages
ADARTS
Large-scale, real-time software systems
Manufacturing system analysis (MSA)
Intelligent manufacturing systems
Source: The Art of Systems Architecting, Maier & Rechtin
Integrated Modeling Methodologies
† Quantitative QFD
È Performance objectives are most important to
the client
È Performance-centered approach to system
specification, decomposition, and synthesis
È Japanese-originated method for visually
organizing the decomposition of customer
objectives
Source: The Art of Systems Architecting, Maier & Rechtin
Integrated Modeling Methodologies
† Quantitative QFD-based approach:
1. Identify a set of performance objectives of
interest to the client. Determine appropriate
values or ranges for meeting these objectives
through competitive analysis.
2. Identify the set of system-level design
parameters that determine the performance for
each objective. Determine satisfaction models
that relate the parameters and objectives.
Source: The Art of Systems Architecting, Maier & Rechtin
Integrated Modeling Methodologies
† Quantitative QFD-based approach:
3. Determine the relationships of the parameters
and objectives, and the interrelationships
among the parameters. Which affect which?
4. Set one or more values for each parameter.
Multiple values may be set, for example,
minimum, nominal, and target. Additional slots
provide tracking form detailed design activities.
Source: The Art of Systems Architecting, Maier & Rechtin
Integrated Modeling Methodologies
† Quantitative QFD-based approach:
5. Repeat the process iteratively using the system
design parameters as objectives. At each stage
the parameters at the next level up become the
objectives at the next level down.
6. Continue the process of decomposition on as
many level as desired. As detailed designs are
developed, their parameter value can flow up
the hierarchy to track estimated performance for
customer objectives.
Source: The Art of Systems Architecting, Maier & Rechtin
Quantitative QFD
Customer
Objectives
Design
Parameters
Subsystem Allocation
And Refinement
Interaction
Matrix
Satisfaction
Models
Design
Parameters
Customer
Objectives
Parameters Budgets
Interaction
Matrix
Satisfaction
Models
Parameters Budgets
Backward Flow of
Current Design Status
Source: The Art of Systems Architecting, Maier & Rechtin
CDIO
† Concept View
È Combination of Purpose and Form Views
È Question(s)
• What functions does the customer want?
(now & in the future)
• What functions does the customer need?
(now & in the future)
CDIO
† Design View
È Combination of Behavior and Performance
Views
È Question(s)
• What vehicles and systems do you think will
fulfill these wants and needs?
• How would these vehicles and systems fit
together?
• How well would the system perform?
CDIO
† Implementation View
È Combination of Data and Management Views
È Question(s)
• How would you build the system?
• What physical resources are required?
• What financial resources are required?
• What socio-political resources are required?
CDIO
†Operations View
ÈCombination of Management View and the
Business Case
ÈQuestion(s)
• How would you operate the system?
• What physical resources are required?
• What financial resources are required?
• What sociopolitical resources are required?
• Will all stakeholders profit from this deal?