Week 6 - Systems Engineering
and Analysis
Buede ch 8 & Wasson ch 40 –
Physical Architecture
Believe it or not – we’ll even apply
this topic to the “Newton free”
world of software!
Image of “Second Life” from
http://secondlifetalk.com/.
1
Buede starts here – for Wasson, see slide 47!
Functional vs. Physical
Functional
• What the system must do.
Physical
• How the system will do it.
2
Physical Architecture
• Provides system resources for every
function in the Functional
Architecture
Resource types :
– Hardware
– Software
– Facilities
– People
– Procedures
3
Physical Architecture-2
• Must be a Physical Architecture for each
system associated with the system life
cycle.
• Two types of Physical Architectures :
– Generic and Instantiated.
4
Physical Architecture-3
For software:
• We are used to having a design experience
that feels free of physical limitations!
Don’t like the way the world
actually looks? Add/change/delete
your own features!
Image from
http://www.indiamike.com/india/cha
i-and-chat-f73/nasa-world-windsoftware-t12187/
5
Physical Architecture-4
For software:
• “Physical” means “real” – like:
– What families of components would we choose?
– What “bottom up” characteristics would fit?
• Without going all the way to naming those pieces
• But this is systems engineering, and we also
can learn from design work that does have
some physical reality…
6
Elevator System
Generic
Physical
Architecture
for Elevator
USED AT:
George Mason
Univ.
DATE: 09/29/1999
REV:
AUTHOR: Dennis Buede
PROJECT: Elevator Case Study
x
NOTES: 1 2 3 4 5 6 7 8 9 10
Up Service Request,
Floor Request
Comm. about
Emergency,
Passenger Weight
Characteristics,
Sensed Passenger
Heat Loss/Gain
Up Service Request,
Floor Request,
Request to Extend
Entry support
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Fire Alarm Signal
Signal for Partial Maint. Mode,
Signal for Full Op'g Mode
Request to Extend
Entry support
ACCEPT
PASSENGER
REQUESTS &
PROVIDE
FEEDBACK
Feedback:
Service Request Recieved,
Floor Request Received,
Car On Way,
Door Opening,
Door Closing,
Floor Where Stopped,
About Emergency;
Fire Alarm
Operating
Mode
A2
Electric
Power
MOVE
PASSENGERS
BETWEEN
FLOORS
Relayed Info
about Emergency,
Electric Power,
Sensed Building
Heat
Elevator
Position &
Direction
Entry/Exit Opp'y
Ending Signal;
Capacity
Exceeded Signal
Electric
Power
NODE:
A0
Sensed Malfunctions,
Diagnosis &
Test Responses
Destination
Control
Component
CONT EXT :
Feedback:
Service Request Recieved,
Floor Request Received,
Car On Way,
Door Opening,
Door Closing,
Floor Where Stopped,
About Emergency;
Fire Alarm;
Entry/Exit Opp'y
Ending Signal;
Capacity
Exceeded Signal
Elevator Entry/Exit
Opportunity,
Information about
Emergency,
Elevator Heat
Loss/Gain
ENABLE
EFFECTIVE
MAINTENANCE
& SERVICING
A4
Malfunction
Signal
Diagnosis Response,
Test Response
Diagnosis Signals,
Maint. Action,
Repairs,
Test Signals
TITLE:
Figure 8.2
PROVIDE ELEVATOR SERVICES
Door
Control
Component
Emergency
Component
Phone
Component
Elevator
Car/Shaft
Component
Car Component
Cab
Component
Interior Door
Component
Ventilation
& Lighting
Component
Control
Component
Shaft Structural
Component
Hardware
Component
Exit Component
& Controls
Software
Component
Maintenance
& Self-Test
Component
Shaft Switch
Component
Floor Stop
Component
Leveling
Component
Drive/Brake
Component
Emergency
Comm'n
A3
Maint. Action,
Diagnosis Signals,
Repairs,
Test Signals
Car Control
Component
A-0
A1
CONTROL
ELEVATOR
CARS
Elevator Call
Announcement
Component
DATE
Temporary
Modificatin to
Elevator
Configuration
Assignments
for Elevator
Cars
Digitized
Passenger
Requests
READER
Passenger
Interface
Component
NUMBER:
P. 3
Normal
Drive/Brake
Component
Emergency
Braking
Component
7
Elevator First Level Functional Model
USED AT:
George Mason
Univ.
DATE: 09/29/1999
REV:
AUTHOR: Dennis Buede
PROJECT: Elevator Case Study
x
NOTES: 1 2 3 4 5 6 7 8 9 10
Up Service Request,
Floor Request,
Request to Extend
Entry support
Up Service Request,
Floor Request
Comm. about
Emergency,
Passenger Weight
Characteristics,
Sensed Passenger
Heat Loss/Gain
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Fire Alarm Signal
Signal for Partial Maint. Mode,
Signal for Full Op'g Mode
Request to Extend
Entry support
ACCEPT
PASSENGER
REQUESTS &
PROVIDE
FEEDBACK
DATE
Fire Alarm
A1
CONTROL
ELEVATOR
CARS
Operating
Mode
A2
Electric
Power
MOVE
PASSENGERS
BETWEEN
FLOORS
Relayed Info
about Emergency,
Electric Power,
Sensed Building
Heat
Elevator
Position &
Direction
Entry/Exit Opp'y
Ending Signal;
Capacity
Exceeded Signal
Maint. Action,
Diagnosis Signals,
Repairs,
Test Signals
NODE:
A0
Sensed Malfunctions,
Diagnosis &
Test Responses
Feedback:
Service Request Recieved,
Floor Request Received,
Car On Way,
Door Opening,
Door Closing,
Floor Where Stopped,
About Emergency;
Fire Alarm;
Entry/Exit Opp'y
Ending Signal;
Capacity
Exceeded Signal
Elevator Entry/Exit
Opportunity,
Information about
Emergency,
Elevator Heat
Loss/Gain
Emergency
Comm'n
A3
Electric
Power
CONT EXT :
A-0
Feedback:
Service Request Recieved,
Floor Request Received,
Car On Way,
Door Opening,
Door Closing,
Floor Where Stopped,
About Emergency;
Temporary
Modificatin to
Elevator
Configuration
Assignments
for Elevator
Cars
Digitized
Passenger
Requests
READER
ENABLE
EFFECTIVE
MAINTENANCE
& SERVICING
A4
Malfunction
Signal
Diagnosis Response,
Test Response
Diagnosis Signals,
Maint. Action,
Repairs,
Test Signals
TITLE:
PROVIDE ELEVATOR SERVICES
NUMBER:
P. 3
8
Functional Allocation: 1-1 and ‘Onto’
Functions
f1
f2
Components
c2
c1
f3
f4
f5
f3
f5
c2
f8
f1
f2
c5
Components
c2
c1
f3
f4
c4
c5
Functions
c3
Onto, but not one-to-one
function for the allocation
of functions to components
Figure 8.4
c3
c4
Function for the allocation
of functions to components
c1
f4
f6
f7
Components
c1
f3
f5
Relation for the allocation
of functions to components
f1
Components
c2
f4
c5
Functions
f1
f2
c3
c4
f2
Functions
c3
c4
f5
c5
One-to-one and onto
function for the allocation
of functions to components
9
Functional Allocation Goal
• Allocate Functions  Components.
• There is great advantage to having
Functional and Physical Architectures
match (one-to-one and onto).
10
Functional Allocation Goal
• There is great advantage to having
Functional and Physical Architectures
match (one-to-one and onto).
– When does this happen ??
– When does this not happen ??
Product or system architecture decisions ??
11
12
Two Levels of Physical
Architecture
• Generic physical architecture: description of the
partitioned elements of the physical architecture
without any specification of the performance
characteristics of the physical resources that
comprise each element
• Instantiated physical architecture: generic
physical architecture to which complete
definitions of the performance characteristics of
the resources have been added
13
The Process
• Generic Physical Architecture provides ‘common
designators’ for physical resources. (No real
physical items).
• Morphology Box to create and list instantiated
architectures – options for choice.
• Create many alternate instantiations to choose
from.
14
Morphological Box for Hammer
Handle
Size
Handle Material
Striking Element
Weight of
Hammer
Head
Nail Removal Element
8 inches
Fiberglass with
rubber grip
1-inch diameter flat
steel
12 oz.
Steel claw at nearly a
straight angle
22
inches
Graphite with
rubber grip
1-inch diameter
grooved steel
16 oz.
Steel claw at a 60 degree
angle with handle
Steel with rubber
grip
1.25-inch diameter
flat steel
20 oz.
Steel I-beam
encased in plastic
with rubber grip
1.25-inch diameter
grooved steel
24 oz.
Wood
(Top row – generic components, 320 possible combinations)
Table 8.3
15
Morphological Box
for Auto Navigation Support System
Other System
Interfaces
Localization
Processor
User I/O
Map &
Database
None
None
Regular
Cell Phone
None
Map, Database,
Routing Algorithm
Direction
Sensor
Vehicle’s
Processor
Special
Cell Phone
Horn
Staffed
Control Center
Electro
Gyros
32-bit
Processor
4” LCD
Lights
Automated
Control Center
GPS
Transponder
Portable
PC (486+)
6” LCD
Car Door
Locks
Direction
Support
6” LCD &
Touch Screen
Full GPS
Support
Acura Navigation System
Cadillac’s OnStar
Button &
Key Panel
BMW Navigation System
Lincoln’s RESCU
Joy Stick
Oldsmobile Guidestar
RETKI
Emergency
Signal
Air Bag
Control Knob
Voice Output
Figure 8.5
16
We can use morphological
boxes with software, too
Image from http://hcil2.cs.umd.edu/trs/2004-17/2004-17.html
17
Pairwise Infeasible Combinations
within a Morphological Box
Handle Length
Striking Feature
8 inches
Hammer
Example
Nail Removal
Feature
22 inches
1 inch
grooved
1 inch
flat
Angled
1.25 inch
grooved
1.25 inch
flat
Straight
12 Oz.
Wood
Steel
I-beam
Fiberglass
24 Oz.
16 Oz.
Steel
20 Oz.
Graphite
Handle Material
Figure 8.6
Weight of Hammer Head
18
Elevator System
Passenger
Interface
Component
Elevator Call
Announcement
Component
Elevator
Car/Shaft
Component
Car Component
Control
Component
Shaft Structural
Component
Hardware
Component
USED AT:
Car Control
Component
Destination
Control
Component
Door
Control
Component
Emergency
Component
Phone
Component
Cab
Component
Interior Door
Component
Ventilation
& Lighting
Component
Exit Component
& Controls
Shaft Switch
Component
Floor Stop
Component
Matches first level
Functional decomposition
Maintenance
& Self-Test
Component
Software
Component
George Mason
Univ.
DATE: 09/29/1999
REV:
AUTHOR: Dennis Buede
PROJECT: Elevator Case Study
x
NOTES: 1 2 3 4 5 6 7 8 9 10
Up Service Request,
Floor Request,
Request to Extend
Entry support
Up Service Request,
Floor Request
Comm. about
Emergency,
Passenger Weight
Characteristics,
Sensed Passenger
Heat Loss/Gain
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Fire Alarm Signal
Signal for Partial Maint. Mode,
Signal for Full Op'g Mode
Request to Extend
Entry support
ACCEPT
PASSENGER
REQUESTS &
PROVIDE
FEEDBACK
DATE
Fire Alarm
A1
CONTROL
ELEVATOR
CARS
Operating
Mode
A2
Electric
Power
MOVE
PASSENGERS
BETWEEN
FLOORS
Relayed Info
about Emergency,
Electric Power,
Sensed Building
Heat
Elevator
Position &
Direction
Entry/Exit Opp'y
Ending Signal;
Capacity
Exceeded Signal
Electric
Power
Maint. Action,
Diagnosis Signals,
Repairs,
Test Signals
NODE:
A0
Sensed Malfunctions,
Diagnosis &
Test Responses
ENABLE
EFFECTIVE
MAINTENANCE
& SERVICING
A4
Emergency
Braking
Component
Elevator Entry/Exit
Opportunity,
Information about
Emergency,
Elevator Heat
Loss/Gain
Malfunction
Signal
Diagnosis Response,
Test Response
Diagnosis Signals,
Maint. Action,
Repairs,
Test Signals
TITLE:
PROVIDE ELEVATOR SERVICES
NUMBER:
Drive/Brake
Component
Normal
Drive/Brake
Component
Feedback:
Service Request Recieved,
Floor Request Received,
Car On Way,
Door Opening,
Door Closing,
Floor Where Stopped,
About Emergency;
Fire Alarm;
Entry/Exit Opp'y
Ending Signal;
Capacity
Exceeded Signal
Emergency
Comm'n
A3
Leveling
Component
CONT EXT :
A-0
Feedback:
Service Request Recieved,
Floor Request Received,
Car On Way,
Door Opening,
Door Closing,
Floor Where Stopped,
About Emergency;
Temporary
Modificatin to
Elevator
Configuration
Assignments
for Elevator
Cars
Digitized
Passenger
Requests
READER
Compare lower levels to
functional decomposition
Is it 1-to-1 ??
19
P. 3
Block Diagrams of Physical Architecture
(Most common graphical representation)
Aircraft
Device
Sensors
Actuator
Controller
Crew
Command
Sensors
Aircraft
Devices
(e.g.,
flaps,
ailerons)
...
Crew
Command
Devices
(e.g.,
throttle,
pedals)
Actuator
Central
Controller
Actuator
Controller
Actuator
Aircraft Control Component
Figure 8.7
20
Block diagram for software
Image from http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=hdwr&db=bks&fname=/SGI_EndUser/RASC_UG/ch04.html.
21
Issues in Physical Architecture
Development
• Functional performance, availability (cost, safety,
fault tolerance), and other system-wide traits.
• Commercial and ‘product line’ factors.
• Operational architecture finishes this process.
•
Looking ahead – physical architecture elements are added as mechanisms on
the Functional Architecture to produce the Operational Architecture.
22
Vehicle Theft Deterrence
• It’s fairly easy to understand conceptually
how an effective system could work…
See https://www.youtube.com/watch?v=Ee3L9BQQ4Gs
23
Example- Vehicle Theft
M. Clarizia
User needs
Provide criminal activity
Confirm arm/disarm,
panic, test
Provide User
Services
A1
Maintenance
Required
signal
Request Panic Alarm
Request arm/disarm
Status of vehicle sensors
Provide Vehicle
Security
Request audible alarm
A0
Disable vehicle signal
System armed indication
Provide Vehicle
Services
A2
Input Opportunity
Input Commands
Audible Alarm
Power
Feedback Commands Accepted
Feedback Monitor Status
Request Theft Signals
Provide Robber
Activity
Suspicious and Theft Activity
Theft Signals
Theft Deterrent Signals
Theft Deterrent Commands
Feedback Alarm Status
A3
Provide criminal activity
Input Opportunity
Input Commands
NODE:
Feedback Commands Accepted
A1
Owner / User
TITLE:
Security Alarm
Vehicle
Vehicle Anti-Theft System
Theif
NO.:
Feedback Monitor Status
Power
Thief
NODE:
Vehicle
TITLE:
Deterrent
System
Operating Scenario for Vehicle Theft Deterrent System
Vehicle
User
NO.:
24
Vehicle Theft Example
Request Arm/Disarm
Request panic test
M. Clarizia
User interface
requests
Provide User
Interface
A1
Vehicle status
Criminal
Activity
Disable vehicle
Accept Inputs/
Provide Outputs
Audible alarm
Arm/Disarm & Alarm confirmation
Maintenance required signal
A2
Input request
Provide data
processing
Power
Output response
A3
Provide Diagnostic
Capability
Maintenance required
NODE:
A0
TITLE:
Vehicle Anti-theft System - 1st Level Decomposition
A4
NO.:
25
Major Concepts
for Physical Architecture
• Centralized vs. Decentralized
• Modular vs. Integral
• Standardization, Serviceability
• ‘COTS’ components
26
Mostly Software Example :
FBI Fingerprint Identification System
• IAFIS: Integrated Automated Fingerprint
Identification System
– ITN/FBI: Identification Tasking and
Networking segment – focus of this case study
– III/FBI: Interstate Identification Index
segment
– AFIS/FBI: Automated Fingerprint
Identification System segment
27
ITN/FBI: Identification Tasking
and Networking
• RFP identified subelements
• TPS: Ten-print Processing Subelement was key
– Processed paper cards with 10 fingerprints
– Organized as work stations within a workgroup
(distributed system)
– Processed ~ 30,000 per day
– Scanned, converted to binary data, and analyzed
– Images had to be compressed by at least 10 to 1
– Average time to perform a fingerprint image comparison
was 60 seconds
– Time allowed for display of human-machine interface was
1 second from time of request
28
Critical Design Issues for TPS
• Implementation of wavelet scalar
quantization (WSQ) algorithm (hardware
vs. software)
• Workstation capabilities
• Server capabilities
• Workflow management capabilities
• Communications interface
29
Alternate Design Allocation Options Studied
Alloc ate
Algorithm
Ethernet LAN 100 Mbps
Bas ic W orks tation
RISC/6000 Model 22W
32MB RAM
400MB DASD
SPECint92 20.4
SPECfp92 29.1
Software Alloc ation
Server
?
W orks tation
Software
?
Hardware
Enhanc ed W orkgroup S erver
RISC/6000 Model 970B
512MB RAM
5GB DASD
SPECint92 58.8
Local
SPECfp92 108.9
W orkgroup
W orkflow
Server Only
Workstation Only
Server w/ Any Workstation
Server w/ Local Workstation
Ethernet LAN 100 Mbps
Ethernet LAN 10 Mbps
Bas ic W orkgroup Server
RISC/6000 Model 570
256MB RAM
2GB DASD
SPECint92 48.4
SPECfp92 97.0
Local
W orkgroup
W orkflow
Enhanc ed W orks tation
RISC/6000 Model 340
64MB RAM
2GB DASD
SPECint92 48.1
SPECfp92 83.3
Ethernet LAN - 100 Mbps
Bas ic W orkgroup Server
RISC/6000 Model 570
Bas ic W orks tation
256MB RAM
RISC/6000 Model 22W
2GB DASD
32MB RAM
SPECint92 48.4
FDDI Ring
400MB DASD
SPECfp92 97.0
SPECint92 20.4
SPECfp92 29.1
Hardware Alloc ation
Enhanc ed W orkgroup S erver
RISC/6000 Model 970B
512MB RAM
Enhanc ed W orks tation
5GB DASD
RISC/6000 Model 340
SPECint92 58.8
64MB RAM
SPECfp92 108.9
Enterprise
2GB DASD
W ide
SPECint92 48.1
W orkflow
SPECfp92 83.3
Cus tom LSI Chip
On Co-proc es s or Card
Ethernet LAN - 100 Mbps
Bas ic W orkgroup Server
Bas ic W orks tation
RISC/6000 Model 570
RISC/6000 Model 22W
256MB RAM
32MB RAM
2GB DASD
400MB DASD
Enterprise W ide
SPECint92 48.4
SPECint92 20.4
W orkflow
SPECfp92 97.0
SPECfp92 29.1
Ethernet LAN 100 Mbps
Server Only
Server
?
W orks tation
Enhanc ed W orkgroup S erver
RISC/6000 Model 970B
512MB RAM
Bas ic W orks tation
5GB DASD
RISC/6000 Model 22W
SPECint92 58.8
32MB RAM
SPECfp92 108.9
400MB DASD
Local
SPECint92 20.4
W orkgroup
SPECfp92 29.1
W orkflow
Ethernet LAN 10 Mbps
Bas ic W orkgroup Server
RISC/6000 Model 570
256MB RAM
2GB DASD
SPECint92 48.4
SPECfp92 97.0
Bas ic W orks tation
RISC/6000 Model 22W
32MB RAM
400MB DASD
Local
SPECint92 20.4
W orkgroup
SPECfp92 29.1
W orkflow
Workstation Only
Figure 8.8
30
Morphological Box
of Instantiated Design Option
Workstation
Server
Software
Basic Workstation
RISC/6000 Model 22W
32MB RAM
400MB DASD
SPECint92 20.4
SPECfp92 29.1
(b, c, e, f) (g, h)
Basic Server
RISC/6000 Model
570
256MB RAM
2GB DASD
SPECint92 48.4
SPECfp92 97.0
(a, c, e) (g, h)
Enhanced Server
RISC/6000 Model
970B
512MB RAM
5GB DASD
SPECint92 58.8
SPECfp92 108.9
(b, d, f)
No WSQ
Algorithm
Enhanced Workstation
RISC/6000 Model 340
64MB RAM
2GB DASD
SPECint92 48.1
SPECfp92 83.3
(a, d)
LSI
Chip
None
Communications
(a, b, d, e, f)
(g)
(a, e)
Ethernet LAN
(100BaseT) – 100
Mbps
Ethernet LAN
(10BaseT) - 10 Mbps
(a, b, c, d)
(e, f)
(g, h)
WSQ
Algorithm
WSQ on
LSI Chip
Enterprise Wide
Workflow
(a, b, c, d)
(d, e)
(g, h)
(c)
(h)
2 new alternatives (g & h) identified
Table 8.5
Workflow
Management
Local Workgroup
Workflow
(b, d, f)
(g)
FDDI WAN - 100 Mbps
(c) (h)
31
Use of Redundancy
to Achieve Fault Tolerance
• Hardware: adds extra hardware to enable
detection of and recovery from errors
• Software: N-version
– N different software developers for same routine
– Comparison of results via voting
– Seldom used due to expense of software development
• Information: adding extra bits of information to
enable error detection
• Time: replaces hardware or software redundancy
when there is slack processing time - recalculation
32
Hardware Redundancy A crucial choice for software
• Passive: extra hardware operating concurrently using voting
– Errors are masked or hidden (system unaware)
– Approaches
• N-modular redundancy (NMR)
– Triplicated: TMR – masks 1 error
– 5MR – masks 2 errors
• Triplicated NMR
• Active: detects errors, confines damage, recovers from
errors, & isolates/reports fault
– Duplication with comparison: extra hardware with comparison,
not voting
– Hot standby: extra hardware, only one reporting, monitor of
outputs to detect error
– Cold standby: extra hardware inactive until error detected
– Pair-and-a-spare: Duplication with comparison & hot standby
– Hybrid: combinations of the above
33
TMR & Triplicated TMR
Input 1
Component 1
Input 2
Component 2
Input 3
Component 3
Voter
Output
Voter is single point of failure
Triple Modular Redundancy (TMR)
Issues with Voting
Figure 8.9
Input 1
Component 1
Voter
Output 1
Input 2
Component 2
Voter
Output 2
Input 3
Component 3
Voter
Output 3
Triplicated TMR
34
Software Implementation
of Triplicated TMR
Input 1
Sampler
Two-port
Memory
Processor
Two-port
Memory
Input 2
Sampler
Two-port
Memory
Processor
Two-port
Memory
Input 3
Sampler
Two-port
Memory
Processor
Two-port
Memory
Figure 8.10
35
Active Hardware Redundancy:
Duplication with Comparison
Component 1
Input
Output
Comparator
Agree/
Disagree
Component 2
Figure 8.11
36
Hot Standby Sparing, N-1 Replicas
Component 1
Error
Detection
~
~
Error
Detection
N to 1
Switch
Output
...
Input
...
Component 2
Component N
Error
Detection
Figure 8.12
37
Pair-and-a-spare
Component 1
Error
Detection
Output
~
~
Error
Detection
Component N
Error
Detection
Figure 8.13
N to 2
Switch
Compare
...
Input
...
Component 2
Agree/
Disagree
38
Practicality of Redundancy
• How practical is redundancy ?
– In your car.
– In an airplane.
39
Redundancy Warning
• Redundant components and systems
must truly be independent systems.
• Often a ‘single point of failure’ takes
out all ‘redundant’ systems.
– Space Shuttle Challenger (o-rings)
– Genesis space vehicle (g-switches)
– UA 232 Sioux City (hydraulic systems) (P.242)
40
Discussion Q1
• The physical architecture for
the hammer :
– what does the functional
architecture look like
41
Discussion Q2
• For the drink machine functional
architecture, does Hatley Pirbhai or
‘Energy, Materials, Signal Flows’ ‘work
better’ with respect to giving a functional
architecture that produces a ‘more
realistic’ physical architecture.
42
Discussion Q3
• For the ATM machine, develop an external
systems diagram and a first level function
decomposition for the Acme ATM Company
– a manufacturer and seller of ATM
machines.
• Consider the possible uses of the
functional model and physical
implementations of the system.
43
44
Discussion Q4
•
Given the first level decomposition for
the ATM machine:
1. Sketch the generic physical architecture
2. Sketch a morphological box and some possible
instantiated physical implementations
45
USED AT:
George Mason
University
AUTHOR: SYST 520 Student
PROJECT: Automatic Teller Machine
x
DATE: 08/07/00
REV:
NOTES: 1 2 3 4 5 6 7 8 9 10
Employee General ID,
ID Code Unique ID
Americans with
Disabilities Act
Safety
Regulations
Customer
Valid
Provide
Access to
ATM
Cust Activity,
Cust A/C Type,
Deposit Entered,
Cust Amount,
Trans Source,
Trans Dest,
Paymt Source,
Payment Entered,
Cancel Entered,
Choice Entered
Accept
Customer
Requests and
Provide
Feedback
ID Received
Request for
Unique ID
Choice, ATM Reset,
Apology, Request
for Paymt Source
Employee
Valid
ID Validation
A2
Need for Fmax,
Trans Complete,
Receipts<25
Determine
ATM
Responses
DATE CONTEXT:
READER
Request for Activity,
Request for Account Type,
Request for Deposit Type,
Physical Means for Insert,
Receipt, Request for Amount,
Request Denied, Cust Cash,
Request for Source Account,
Request for Dest Account
Banking
Policies
Calculations
for
Withdrawal
A1
Activity Selection,
Account Type,
Deposit Type,
Deposit of Funds,
Trans Amount,
Source Account,
Dest Account,
Source of Payment,
Payment on Account,
Request to Cancel,
Choice to End
Clim
WORKING
DRAFT
RECOMMENDED
PUBLICATION
No Input Device,
Request for ID #2,
Request for ID #3,
Customer Alert
Request for Unique ID,
Request for Activity,
Request for Account Type,
Request for Deposit Type,
Physical Means for Insert,
Receipt, Request for Amount,
Request Denied, Cust Cash,
Request for Source Account,
Request for Dest Account
Choice, ATM Reset,
No Input Device,
Request for ID #2,
Request for ID #3,
Customer Alert, Apology,
Request for Paymt Source
Account
FMax
Main Menu
Input not
Available
Creq>Cleft
Account Balance
Request to Open,
ATM Cash,
Blank Receipts,
Initialization,
Diagnostic Test,
ATM Fixes,
Request to Close
Cust Status Inf..,
Fmax
A3
Transaction,
Request for Fmax,
Request for Status Inf..,
Input Not Working,
Request for Funds,
Request for Receipts,
Break-in Attempted
Communicate
with Bank
Computer
A4
Balance Inf.,
Paymt Source Entered,
Payment Received,
Ptrns>Fmax,
Cancel Received,
Choice Received
Break-in
Attempt
Activity Selected,
A/C Type Entered,
Deposit Type Entered
Deposit Received,
Amount Entered,
Source A/C Entered,
Dest A/C Entered,
Ftrns>Fmax
Access Opportunity,
ATM Opened,
Cust Deposits,
Cust Payments,
Test Results,
Fixes Applied
ATM Closed
Enable
Re-Supply and
Maintenance
Need to Open,
Paymts Inserted,
Deposits Inserted,
Diagnostics,
Fixes to ATM
Need to Close
A5
Respond to
Hostile
Situations
A6
Audible
Alarm,
Operation
Terminated
Attempted Break-in
NODE:
A0
TITLE:
Provide ATM Services
NUMBER:
P. 3
46
Wasson’s Ch 40
• Let’s look at Wasson’s recommended methodology:
47
Wasson’s “Domain solution
challenges” (Sec 40.6)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Solution space validation
Technical design integrity
Multi-domain solution agreement
Risk identification and mitigation
Environment, safety and health
System solution stability
System support
Interfaces
System optimization
Phases and modes of operation
48
Step 2 – Allocate capabilities
49
Extra Slides
• See the last slide!
50
Example - F-22 Physical Architecture
F-22 Weapon System
Vehicle
Avionics
Systems
Utilities &
Subsystems
Electronic
Warfare
Figure 8.1
Cockpit
Systems
Vehicle
Management
System
Controls
&
Displays
Navigation,
Identification
Radar
Support
Training
Processing
Inertial
Reference
System
Stores
Management
51
Work Breakdown Structure - WBS
• MIL-STD-881B : WBS for defense
material items.
• WBS is often similar to Physical
Architecture – work organized along lines of
resources for development or procurement.
• Examples – Aircraft system (10 elements, 17
resource categories)
•
(See Blanchard and Fabrycky Section 18.2.)
52
WBS Elements and
Related Life Cycle Phases
WBS Elements
Air vehicle
Systems engineering/Program management
System test and evaluation
Training
Data
Peculiar support equipment
Common support equipment
Operational/site activation
Industrial facilities
Initial spares and repair parts
Table 8.1
Life Cycle Phase
Operational
Development
Development
Training
Manufacturing and refinement
Operational
Operational
Deployment
Manufacturing
Operational
53
Resource Categories for Generic Air Vehicle
Airframe
Propulsion
Air vehicle application software
Air vehicle system software
Communications/Identification
Navigation/Guidance
Central computer
Fire control
Data display and controls
Table 8.2
Survivability
Reconnaissance
Automatic flight control
Central integrated checkout
Antisubmarine warfare
Armament
Weapons delivery
Auxiliary equipment
54
Development Process for the Physical
Architecture
USED AT:
GMU Systems
Engineering
Program
AUTHOR: Dennis Buede
PROJECT: Engineering Design of a System
NOTES: 1 2 3 4 5 6 7 8 9 10
x
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE CONTEXT:
Originating & System
Requirements,
Objectives Hierarchy,
Boundary & Qualification
System Requirements
System-level
Functional
Architecture
System-level
Operational
Concept
DATE: 05/24/99
REV:
Candidate
Generic
Physical
Architectures
Brainstorm and
Select a Generic
Physical
Architecture
A1131
Generic
Physical
Architecture
Physical
Architecture
Changes
Generate a
Morphological Box
for Alternate
Instantiated Physical
Architecture
A1132
Morphological
Box
System-level
Physical
Architecture
Select
Alternate
Instantiated
Physical
Architecture
A1133
NODE:
Figure 8.3
A113
TITLE:
Design System Physical Architecture
NUMBER:
Candidate
Physical
Architectures
P. 8
55
Functional Allocation: 1-1 and onto
Functions
f1
f2
Components
c1
c2
f3
f4
Functions
f1
f2
c2
f4
f5
Functions
f1
f2
c5
Function for the allocation
of functions to components
Components
c2
c1
f3
f4
c3
c4
f5
c5
Relation for the allocation
of functions to components
c1
f3
c3
c4
Components
c3
c4
f5
c5
One-to-one and onto
function for the allocation
of functions to components
Figure 8.4
56
Option Creation Techniques
Brainwriting and Brainstorming Categories
Brainwriting I - an individual works alone to create a list of ideas.
Brainwriting II - a group of individuals separated in space
generates ideas separately and the ideas are collected but not
shared
Brainwriting III - a group of individuals separated in space
generates ideas separately, the ideas are shared, and additional
ideas are generated
Brainwriting IV - a group of individuals working in the same room
generates ideas separately and the ideas are collected but not
shared and no discussion takes place
Brainwriting V - a group of individuals working in the same room
generates ideas separately; all of the ideas are shared but none
are discussed; additional ideas are generated
Brainstorming I - a group of individuals generates ideas via verbal
discussion, no defined procedure is used
Brainstorming II - a group of individuals generates ideas via verbal
discussion within the bounds of predefined procedures
Brainwriting/Brainstorming I - a group of individuals generates
ideas via predefined written and verbal procedures
Table 8.4
Examples
Analogy, attribute listing,
people involved
Collective notebook
Delphi method
Nominal group technique
Brainwriting pool
Unstructured group
discussion
Classical brainstorming
Brainwriting game
57