Transcript Slide 1

Principles of
Engineering System Design
Dr T Asokan
[email protected]
Principles of
Engineering System Design
Lecture 4:
System Design Process
Dr T Asokan
[email protected]
044-2257 4707
T Asokan
•• FFocus
ocus of
ofSSys
ystems
tems
EEngineering
ngineering
–– FFrom
romOOriginal
riginalNeed
Need
–– TTooFFinal
inalPProduct
roduct
•• TThe
heWhole
Whole
SSys
tem
ys tem
•• TThe
heFFull
ullSSys
ystem
tem
LLife
ifeCCycle
ycle
Need
Operations Concept
Functional Requirements
System Architecture
Allocated Requirements
••FFocus
ocus of
ofCComponent
omponent
EEngineering
ngineering
••OOnnDDetailed
etailedDDes
esign
ign
••And
AndImplementation
Implementation
• What needs are we trying to fill?
• What is wrong with the current s ituation?
• Is the need clearly articulated?
• Who are the intended us ers ?
• How will they us e our products ?
• How is this different from the pres ent?
• What s pecific capability will we provide?
• T o what level of detail?
• Are element interfaces well defined?
• What is the overall plan of attack?
• What elements make up the overall approach?
• Are thes e complete, logical, and cons is tent?
• Which elements addres s which requirements ?
• Is the allocation appropriate?
• Are there any unneces s ary requirements ?
Detailed Design
• Are the details correct?
• D o they meet the requirements ?
• Are the interfaces s atis fied?
Implementation
• Will the s olution be s atis factory in terms
of cos t and s chedule?
• C an we reus e exis ting pieces ?
Test & Verification
• What is our evidence of s ucces s ?
• Will the cus tomer be happy?
• Will the us ers ’ needs be met?
N
• •
e
e
•
d
F F oo c c uu s s oo f f
S S y y s s t te e m m s s
E E n n g g i ni n e e e e r ri ni n g g
––
––
•
•
F F r ro o m m
O O r ri gi g i ni n a a l l
NN e e e e d d
O
p
C
e
o
r a t i o
n
n
c e p t
•
s
•
•
T T oo
F F i ni n a a l l
P P r ro o d d u u c c t t
• • T T hh e e
WW
h h o o l el e
S S y y s s t te e m m
F
e
R
u
q
n c t i o
u i r e m
n
a
e
•
l
n
t s
•
•
• • T T hh e e
F F u u l ll l
S S y y s s t te e m m
L L i fi fe e
C C y y c c l el e
S
r c
A
y
h
s t e
i t e c
•
m
t u
r e
•
•
A
R
e
q
l l o c a
t e
d
u i r e m
e n
•
t s
•
•
• • F F oo c c uu s s
oo f f
C C o o mm p p o o n n e e n n t t
E E n n g g i ni n e e e e r ri in n g g
• • OO n n
D D e e t ta a i li el e d d
D D e e s s i gi g n n
• • AA nn dd
I Im m p p l el e m m e e
n n t ta a t ti oi o n n
D
e
D
t a
e
i l e
s
i g
•
d
•
n
•
I m
p
l e
m
e
n
t a
t i o
n
•
•
T
V
e
e s
r i f i c
t
a
&
t i o
•
n
•
•
W
h
a
t
n
w
e
t r y i n
W
h
a
t
i s
w
i t h
t h
e
s i t u a
t i o
I s
t h
e
n
a
r t i c u l a
W
h
o
i n t e n
H
o w
o u r
p
H
o w
d i f f e r
p r e s e
W
c
p
T
d
A
i n
d
h
a
p
r o
o
e t
r e
t e
e f
W
a
d
r e
I s
a
p
A
r
u n
r e
h
t
e
d
s
a
r e
t o
f i l l ?
r o
n g
u r r e
n t
w
c
n ?
e e
d
t e d ?
m
e
?
s
e
n
w
i s
t h e
f
a
t t a
t
e l e m
e
u p
t h
a
l l
a
p
p
t h
e s e
p l e t e ,
l
c o
n s i s
d
i l l
t h
s a
t
r m
s
f
c o
s
c h e d
a
n
w
x i s t i n
e
l e
p e
c i f i c
i t y
w
i l l
?
t
l e v e
l
t
e
a
r l y
t
u
e
r a
e
r o
a
c
h
e
?
t s
o g
i c a
t e n
t ?
t a
e
n
e
n
h
?
o
u
?
s
l l
?
l ,
t s
n
?
i l s
e
t
t h e
t s ?
r f a
c e
s
a
n
d
l e
?
e
r e u
g
p i e
u
o
f
v
k
n
s o l u t i o
f a
c t o r y
W
h
a
t
i s
o
e v i d
e n c e
s u c c e s s ?
W
i l l
t h e
c
b e
h a
p p y
W
i l l
t h e
u
n e e
d s
b e
e
o
o
c
e l e m
e
s
w
h i c
m
e
n t s
a
l l o c a
t i
p r i a
t e ?
e r e
a
n
y
e s s a
r y
e m
e
n t s
e
i s
w
l l
s
e
A
r e
t h
e
d
e
c o r r e c t ?
D
o
t h e y
m
r e q u
i r e m
e
A
r e
t h
e
i n t
s a
t i s f i e d
?
W
b
t e
o
s
C
e
c
o
i c h
r e
u
i r
t h
e
p
r o
e
t h
n
e c
q u
i r
q
g
a
r e
t h
e
d e d
u
s e r s ?
w
i l l
t h e
y
u
s e
r o
d u c t s ?
i s
t h i s
e n
t
f r o
m
t h e
n t ?
a
t
s
a
b i l
v i d e
w
h a
a
i l ?
e
l e
r f a
c
i n
e d
W
h
a
p l a
n
W
h
a
m
a
k
o v e r
A
r e
c o m
a
n d
e
s
c
r
s
e
m
e
e
n
s
i n
?
f
t o
m
r s ’
e t ?
e
r
Six functions of Design Process
1. Define system level design problem :
Originating requirements development
2. Develop the system functional architecture
3. Develop the system physical architecture
4. Develop the system operational architecture
5. Develop the interface architecture
6. Define the qualification system for the system
Define
Requirements
Retirement,
Disposal &
Replacement
Retirement,
Disposal &
Replacement
Operation,
Maintenance
& Evaluation
Define
Requirements
The system
life cycle
The system
life cycle
Integration
& Test
Operation,
LifeMaintenance
cycle
& Evaluation
Investigate
Alternatives
Full-Scale
Design
Investigate
Alternatives
Implementation
Full-Scale
Design
deployment
Development phase, manufacturing phase,
phase, training phase, operation or maintenance phase,
refinement, retirement
phase.
Integration
& Test
Implementation
Define System Level Design Problem
•
•
•
•
•
•
Operational Concept
External Systems
Originating Requirements
Objectives hierarchy
Documentation
Requirement management
1. Define System Level Design Problem
Major Input: Stake holders’ inputs
Major output: Originating requirements,
Operational concept
• An operational concept is a vision for what the system
is (in general terms). It is a statement of mission
requirements, and a description of how the system will
be used.
It includes:
•Information about how the system will be developed,
operated and retired (from the perspective of the system’s
stakeholders).
•A collection of scenarios.
•Systems interaction with other systems.
Operational concepts for landing
on the moon
T Asokan ED309
Operational Concept ScenarioExample: Passenger lift
Scenario 1
Passengers (including mobility, hearing, visually challenged)
request up service, receive feed back that their request was
accepted, receive input that the elevator car is
approaching, and then that an entry opportunity is
available, enter elevator car, request floor, receive feedback
that their request was accepted, receive feedback that the
door is closing, receive feedback about what floor the
elevator is stopping, receive feedback that an exit
opportunity is available, and exit elevator with no physical
impediments.
T Asokan ED309
Scenario 2
Emergency
situation
Scenario 3
Fire
Auto-close
Scenario 4
Breakdown
Overload
Scenario 5
maintenance
Scenario Description
Input/Output Trace
Passenger
Elevator
Up service request
feedback
Floor request
T Asokan ED309
Input/output
trace for
scenario 1
Exit
opportunity
External Systems Diagram
It is the Model of the interaction of the system with other
systems (external) in the relevant contexts, thus providing
a definition of the system’s boundary in terms of the
system’s inputs and outputs.
Purpose: Explicitly define the systems boundary and
needed interfaces.
T Asokan ED309
Systems/Mechanisms
System Function
1. Elevator System
Provide elevator services
2. Passengers
Request and use elevator services
3. Maintenance personnel
Maintain elevator services
4. Building
Provide structural support
External Systems Diagram
Building regulations
Request
Elevator
Services
Use Elevator
Services
Passengers
Provide
Elevator
Services
Elevator
system
Maintain
Elevator
Services
Provide
structural
support
Maintenance Building
Personnel
T Asokan ED309
Objectives Hierarchy
The hierarchy of objectives that are important to the
system’s stakeholders in a value sense.
• Stakeholders would be willing to pay to obtain
increased performance on any of these objectives.
• Developed by defining the natural subsets of the
fundamental objectives
T Asokan ED309
• Usually has two to five levels. Additional information
like value weights, value curves etc. are added for
each objective.
• Acts as a corner stone for trade-off studies
• To be developed for each phase of the life cycle of
the system.
• An important tool in the decision making process
T Asokan ED309
Requirements categories
Originating requirements (OR):
Derived from operational needs, operational requirements
are those top-level statements defined in language that is
understandable to stakeholders, leaving substantial room
for design flexibility.
Derived requirements
Defined by system engineering team in engineering terms
during the design process.
Mission
requirements
Originating
requirements
T Asokan ED309
Implied Requirements
Requirements not specifically identified in the OR but can
be inferred based upon the available information.
Emergent Requirements
Requirements that are not even hinted at in the OR
but whose presence is made known by stakeholders
later in the system engineering process.
Configuration Item
Requirements
Derived
requirements
System
Requirements
Component
Requirements
Mission
requirements
Originating
requirements
Configuration Item
Requirements
Derived
requirements
System
Requirements
Component
Requirements