Week 6 - Systems Engineering
and Analysis
Buede ch 9 and Wasson ch 41 –
Operational Architecture
“Operations systems” are a whole category of software, in the world
of running complex systems. They are the part that makes decisions
about all the rest, and/or enables humans to do that. How much do
the humans do, of that control? Hmmm… good question!
Here we see NASA’s “Operations systems” in action, with humans!
From http://www.nasa.gov/centers/ames/research/technologyonepagers/mission_ops_risk_mngt_prt.htm.
1
Major Activities
1.
Allocate functions and system-wide requirements
to physical subsystems
•
•
•
Allocate functions to components
Derive ‘internal’ requirements
‘Flowdown’ system-wide requirements to system and
derive requirements
2. Model and simulate functional activation and
control structure – (define some of the ‘when’)
3. Conduct performance and risk analysis
4. Document architectures and obtain approval
5. Document subsystem specifications
2
The Big Picture
Li
fe
Ph -Cy
as cle
e
Inputs &
Outputs
External
Systems
Diagram
Operational
Concept
St
ak
eh
o
ld
er
s
Complete
Inputs &
Outputs
Validation &
Acceptance
Test Scenarios
Inputs &
Outputs
St
Objectives
Hierarchy
ak
eh
o
ld
er
s
Functional
Architecture
Operational
Architecture
Li
fe
Ph -Cy
as cle
e
Originating
Requirements
Objectives
Derived
Requirements
and Flowdown
Physical
Architecture
State
Transition
Diagram
Interfaces
Risk Analysis
and
Documentation
3
Buede Ch 9 starts here. Wasson Ch 41 starts on Slide 24.
Operational Architecture
• Completes the functional to physical
transition.
• Benefit of making major design decisions
early : manageable blocks, chance of
success, rapid development.
• Leave time for redesign, rework.
4
Operational Architecture
Provides a complete description of the
system design including :
– Functional Architecture allocated to the
Physical Architecture
– Derived I/O, Tech and Sys Wide, Trade Off,
and Qualification requirements for each
component
– Interface Architecture
– Complete Documentation
5
Functions
Allocate
Functions to
Components
Components
f1
f2
c2
c1
f3
f5
Components
f1
f3
f5
c2
f6
f7
f8
c5
Integral
Components
f1
f2
c2
c1
f3
f4
c4
c5
Functions
c3
Onto, but not one-to-one
function for the allocation
of functions to components
Figure 9.3
c4
Function for the allocation
of functions to components
c1
f4
c3
f5
Relation for the allocation
of functions to components
c1
f3
c5
Functions
c2
f4
c4
Components
f1
f2
c3
f4
f2
Functions
c3
c4
f5
c5
One-to-one and onto
function for the allocation
of functions to components
Modular
6
Allocation Is Multi-objective
Optimization Problem
• Maximize the fundamental objectives
• Minimize the number and complexity of
interfaces – modularization
• Maximize early critical testing
opportunities - risk minimization
– Equalizing risks
– Localizing risks
7
Allocating Functions to Components
Using IDEF0
USED AT:
George Mason
Univ.
AUTHOR: Dennis Buede
PROJECT: Elevator Case Study
DATE: 05/24/99
REV:
x
NOTES: 1 2 3 4 5 6 7 8 9 10
In IDEF0 the
mechanisms show
the allocation of
functions to
components.
Request for
Emergency
Support &
Emerency
Message
Request for
Elevator
Service &
Entry support
Request for
Floor &
Exit Support
Structural
Support,
Alarm Signals
& Building
Environment
ModifiedElevator
Configuration
& Expected
Usage Patterns
Acknowledgment
that Request Was
Recieved & Status
Information
Emergency
Support
A1
Electric Power
& Emergency
Communication
Response
DATE CONTEXT:
READER
Emergency
Communication
ACCEPT
PASSENGER
REQUESTS &
PROVIDE
FEEDBACK
Digitized
Passenger
Requests
Configuration
Controls
CONTROL
ELEVATOR
CARS
Electric
Power
WORKING
DRAFT
RECOMMENDED
PUBLICATION
A2
Assignments
for Elevator
Cars
Temporary
Modificatin to
Elevator
Configuration
Elevator
Position &
Direction
MOVE
PASSENGERS
BETWEEN
FLOORS
Passenger
Characteristics
Passenger
Environment
Elevator
Entry/Exit
Opportunity
A3
Electric
Power
Sensed
Malfunctions
Service, Tests
& Repairs
A4
Elevator Control
Component
Passenger
Interface
Component
Elevator Cars
Component
Elevator System
NODE:
Figure 9.5
A0
ENABLE
EFFECTIVE
MAINTENANCE
& SERVICING
TITLE:
PROVIDE ELEVATOR SERVICES
Diagnostic &
Status Messages
Diagnostic
Queries
Maintenance & Service
Component
NUMBER:
P. 3
8
Derive Internal Input/Output Requirements
• For each internal item in functional architecture,
derive 2 internal I/O requirements
– The elevator system shall produce digitized passenger
requests.
– The elevator system shall consume digitized passenger
requests.
• Associate each derived I/O requirement to the
appropriate function
9
Trace System-wide Requirements
and Derive Subsystem-wide Requirements
• Trace system-wide/technology
requirements to system
• For each system-wide/technology
requirement, derive subsystem-wide
requirements for each subsystem
• Trace each derived subsystem
requirement to the appropriate subsystem
10
Technology and System-Wide
Requirements and ‘Flowdown’
• We may have the following technology and
system-wide requirements:
– The system shall be blue,
– The system shall weigh 100 Newtons,
– The system shall achieve a top speed of 80 kph.
• How are these applied to subsystems ??
11
Methods of Flowdown
– Equivalence is a simple flowdown technique that
causes the subsystem requirement to be the
same as the system requirement
– Apportionment spreads a system-level
requirement among the system’s subsystems of
the system, maintaining the same units, e.g.,
cost, reliability
– Synthesis addresses those situations in which
the system-level requirement is comprised of
complex contributions from the subsystems,
causing the subsystem requirements that are
flowed down from the system to be based upon
some analytic model
12
Trace Trade-off Requirements and
Derive Subsystem Trade-off Requirements
• Trace trade-off requirements to the
system
• Derive subsystem trade-off requirements
based on tracing of appropriate I/O and
subsystem-wide/technology requirements
13
Trace Qualification Requirements and Derive
Subsystem Qualification Requirements
• Trace qualification requirements to system
• Derive qualification requirements for each
subsystem
• Define at what point qualification will take place
• More on qualification later
15
Circuit
Board
Testing
Qualification an Afterthought
16
Circuit
Board
Testing
Qualification planned and designed
17
Define and Analyze Functional Activation
and Control Structure
• Build Executable Simulation of Operational
Architecture
– Use Behavior Modeling Techniques in Chapter 12
– Investigate Performance & Timing Issues Related to
Requirements
•
Possible Timing Concerns
–
–
–
–
Deadlock - activity halts because various activities are holding or utilizing
resources needed by other activities (see Wait for Resource Graph)
Livelock - resources are being routed in cycles (oscillating) while waiting for
the proper allocation of resources to enable the completion of necessary
activities
Starvation - function needs a particular resource for execution, but the
resource is always allocated to other functions
Surge or race - components are competing with each other to perform a task
C1
C2
C4
C3
Wait-forResource
Graph
Depicting
Deadlock
Figure 9.8
18
Conduct Performance and Risk Analyses
• Risk analysis examines the ability of the divergent
concepts to perform up to the needed level of
performance across a wide range of operational
scenarios
• Performance analyses are for the purpose of
discovering the range of performance that can be
expected from a specific design or a set of
designs that are quite similar
• Trade study focuses on finding ways to improve
the system’s performance on some highly
important objective while maintaining the system’s
capability in other objectives
19
The Big Picture
Li
fe
Ph -Cy
as cle
e
Inputs &
Outputs
External
Systems
Diagram
Operational
Concept
St
ak
eh
o
ld
er
s
Complete
Inputs &
Outputs
Validation &
Acceptance
Test Scenarios
Inputs &
Outputs
St
Objectives
Hierarchy
ak
eh
o
ld
er
s
Functional
Architecture
Operational
Architecture
Li
fe
Ph -Cy
as cle
e
Originating
Requirements
Objectives
Derived
Requirements
and Flowdown
Physical
Architecture
State
Transition
Diagram
Interfaces
Risk Analysis
and
Documentation
20
Exercise
: Class Discussion
• Review the Operational Architecture for
the Elevator problem.
• Review the Operational Architecture for
the ATM problem.
21
Price’s Functional Allocation Principles
1. Allocation is part of design - allocation is one part of a larger process.
2. Allocation is invention - there is no formula for allocation, imagination is crucial to
the success of the process.
3. Allocation can be systematized - the inclusion of imagination and invention does
not preclude formalizing allocation as a rational decision process, combining
invention and systematization yields a superior result.
4. Make use of analogous technologies - building upon allocation decisions and their
resulting successes and failures expands our allocation expertise.
5. Consider future technology - allocation decisions cannot be based on what exists
now but must address expected advances of technology.
6. Consider human optimization (realistic system implementation) - allocation cannot
be based upon idealistic expectations of how the system will be realized but
should be based upon the likely capabilities of the system in its environment.
Table 9.3
22
:
Class Discussion
Exercise
• Review the
Originating
Requirements
Document Outline.
Originating Requirements Document
1.0 System Overview
2.0 Applicable Documents
3.0 Requirements
3.1 Development Phase (Programmatic) Requirements
3.1.1 Input/Output Requirements for Development
...
3.1.4 Qualification Requirement for Development
3.2 Manufacturing Phase Requirements
...
3.3 Deployment Phase Requirements
...
3.4 Training Phase (if present) Requirements
...
3.5 Operational Phase Requirements
3.5.1 Input/Output Requirements for Operations
3.5.1.1 Input Requirements for Operations
3.5.1.2 Output Requirements for Operations
3.5.1.3 External Interface Requirements for Operations
3.5.1.4 Functional Requirements for Operations
3.5.2 System-wide/Technology Requirements for Operations
3.5.3 Trade-off Requirement for Operations
3.5.4 Qualification Requirement for Operations
3.6 System Improvement/Upgrade Phase Requirements
...
3.7 Retirement Phase Requirements
...
3.8 Overall Trade-Off Requirement
Appendix A. Operational Concepts by Phase
Appendix B. External System Diagrams by Phase
23
Wasson ch 41 – component
selection and development
• Wasson’s key questions for making these
real, final design choices:
24
Making the make/buy decision:
25
Extra Slides
• Don’t forget to look at the slide with
“Fitts’ List”!
26
Fitts’ List: Men Are Better At,
Machines Are Better At
Humans appear to surpass present-day
machines with respect to the following:
1. Ability to detect small amounts of
visual or acoustic energy.
Present-day machines appear to surpass
humans with respect to the following:
1. Ability to respond quickly to control signals
and to apply great force smoothly and
precisely.
2. Ability to perceive patterns of light or 2. Ability to perform repetitive, routine tasks.
sound.
3. Ability to improvise and use flexible
procedures.
3. Ability to store information briefly and
then to erase it completely.
4. Ability to store very large amounts of
information for long periods and to
recall relevant facts at the
appropriate time.
4. Ability to reason deductively, including
computational ability.
5. Ability to reason inductively.
5. Ability to handle highly complex operations,
i.e., to do many different things at once.
6. Ability to exercise judgment.
Table 9.1
29
Taxonomy of the Distribution of Responsibility
between Human and Computer (after Sheridan and
Verplanck [1978])
1. Human does all planning, scheduling, optimizing, etc. and turns task over to computer merely
for deterministic execution.
2. Computer provides options but the human chooses between them, plans the operations, and
then turns task over to computer for execution.
3. Computer helps to determine options, and suggests one for use, which human may or may not
accept before turning task over to computer for execution.
4. Computer selects option and plans action, which human may or may not approve, computer
can reuse options suggested by human.
5. Computer selects action and carries it out if human approves.
6. Computer selects options, plans, and actions and displays them in time for human to
intervene and then carries them out in default if there is no human input.
7. Computer does entire task and informs human of what it has done.
8. Computer does entire task and informs human only if requested.
9. Computer does entire task and informs human if it believes the latter needs to know.
10. Computer performs entire task autonomously, ignoring the human supervisor who must
completely trust the computer in all aspects of decisionmaking.
Table 9.2
30
Price’s Functional Allocation Principles-2
7. Use cycles of hypothesis and test - like any other part of system design, we are
not smart enough to do it right the first time, so build in stages of and time for
iteration.
8. Provide interaction - there are three design decisions that cannot be completely
separated. The engineering decision of what the physical resources of the system
are, the functional allocation of which functions will be performed by each system
resource, and the detailed design decision that implements the allocation. There
must be interaction among these decisions during the design process.
9. Provide iteration and decomposition - do not make the allocation final too quickly.
10. Develop tools of cognitive analysis. (human-machine allocation only).
11. Assure interdisciplinary communication - involve experts from all relevant fields
in the allocation process.
Table 9.3
31