The
Engineering
Design of
Systems:
Models and
Methods
Buede - Chapter 7
Functional Architecture
Development
Edited Mar. 2013, Jun 2015
Above – Notoriously, “Deconstructivist
Architecture” both reveals how it functions,
and also has weird, attention-getting
features to make you question that it does
what it should.
1
Process, rule based approach
Design, creativity,
derived material
2
Why do we need the functional
architecture ??
1.
ESD is good, but we need to provide more
detail to our model of the system.
2.
i.e. - What goes on inside the main function?
3.
Major functions provide a clearer view of
architecture and interfaces.
4.
Related to product architecture, modularity,
and integral/modular designs.
USED AT:
George Mason
Univ.
AUTHOR: Dennis Buede
PROJECT: Elevator Case Study
DATE: 09/27/1999
REV:
x
NOTES: 1 2 3 4 5 6 7 8 9 10
Up Service Request,
Floor Request,
Request to Extend
Entry support
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Signal for Partial Maint. Mode,
Signal for Full Op'g Mode
Fire Alarm Signal
Comm. about
Emergency,
Passenger Weight
Characteristics,
Sensed Passenger
Heat Loss/Gain
READER
DATE
Top
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
PROVIDE
ELEVATOR
SERVICES
Relayed Info
about Emergency,
Electric Power,
Sensed Building
Heat
CONT EXT :
Malfunction
Signal
Diagnosis Response,
Test Response
Maint. Action,
Diagnosis Signals,
Repairs,
Test Signals
Emergency
Comm'n
A0
Elevator Entry/Exit
Opportunity,
Information about
Emergency,
Elevator Heat
Loss/Gain
Elevator System
PURPOSE: To define boundary and architectures for the Operational Phase of the Elevator System
VIEWPOINT: Up & Down, Ltd. Systems Engineering Team
NODE:
A-0
Every system has an ‘architecture’ – sometimes it
is really good, sometimes really bad. M. Collins.
TITLE:
Provide Elevator Services
NUMBER:
3
P. 2
This is carving-up the system
“cloud,” top-down
• A simple example – it “controls lighting”:
4
Functional Architecture-1
• The logical/functional architecture defines what
the system must do - it is a decomposition or
partitioning of the system’s top-level function.
5
Functional Architecture-2
• A logical model of a functional decomposition plus the flow
of inputs and outputs, to which input/output requirements
have been traced to specific functions and items (inputs,
outputs, and controls)
• A logical model that captures the transformation of inputs
into outputs using control information. This definition adds
the flow of inputs and outputs throughout the functional
decomposition; these items that comprise the inputs and
outputs are commonly modeled via a data model (see Chapter
12).
• An IDEF0 model without any mechanisms is used as the
modeling technique in this chapter to represent the
functional architecture at this level of detail.
6
Like Kung Fu…
• This is a skill
and an art.
• This is where the systems engineer
really provides benefit and value.
Image from http://www.pathsatlanta.org/2009/04/10/is-kung-fu-a-martial-art/
7
Functional Architecture Process
USED AT:
GMU Systems
Engineering
Program
AUTHOR: Dennis Buede
PROJECT: Engineering Design of a System
DATE: 05/24/99
REV:
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
Operational
Concept
Create Simple
Functionalities
for Operational
Concept
A1121
Candidate
Generic
Physical
Architectures
Functional
Requirements,
Inputs, and
Outputs
Simple
Functionalities
Boundary Inputs,
Controls, and
Outputs
Boundary Inputs,
Controls, and
Outputs and
Objectives
Draft &
Evaluate
Functional
Model
A1122
Draft
Functional
Model
Input/Output
Requirements
Architecture
Issues
Draft Data
Model for
Functional
Model
Data
Model
A1123
Complete
Functional
and Data
Models
Functional
Architecture
Changes
A1124
Functional
and Data
Models
Trace
Input/Output
Requirements
to Functions
and Items
System-level
Functional
Architecture
A1125
NODE:
Figure 7.1
A112
TITLE:
Develop System Functional Architecture
NUMBER:
P. 7
8
Ok, how do we create this ??
Defining Functional Partitions
1.
Use operating modes
2.
Use outputs
3.
Use inputs & controls
4.
Use Hatley-Pirbhai
template – Slide 15
5.
6.
USED AT:
George Mason
Univ.
DATE: 09/27/1999
REV:
x
NOTES: 1 2 3 4 5 6 7 8 9 10
Up Service Request,
Floor Request,
Request to Extend
Entry support
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Signal for Partial Maint. Mode,
Signal for Full Op'g Mode
Fire Alarm Signal
Comm. about
Emergency,
Passenger Weight
Characteristics,
Sensed Passenger
Heat Loss/Gain
Ulrich and Eppinger –
‘Energy/Material/Signal
Flows’ – Slide 17
Use Miller “Living
Systems” template –
Slides 18 - 20
AUTHOR: Dennis Buede
PROJECT: Elevator Case Study
READER
DATE
Top
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
PROVIDE
ELEVATOR
SERVICES
Relayed Info
about Emergency,
Electric Power,
Sensed Building
Heat
CONT EXT :
Malfunction
Signal
Diagnosis Response,
Test Response
Maint. Action,
Diagnosis Signals,
Repairs,
Test Signals
Emergency
Comm'n
A0
Elevator System
Elevator Entry/Exit
Opportunity,
Information about
Emergency,
Elevator Heat
Loss/Gain
PURPOSE: To define boundary and architectures for the Operational Phase of the Elevator System
VIEWPOINT: Up & Down, Ltd. Systems Engineering Team
NODE:
A-0
TITLE:
Provide Elevator Services
NUMBER:
P. 2
9
Buede Guidelines
• Decomposition/Top Down – System is an
update or variation of an existing system.
• Composition – System is unprecedented or
radical departure of existing systems.
13
Basic Approaches or Templates
• Operating Modes – a function for each
operating mode ? (a software system?)
• Output – Input/Control – a function for
each ?
– Hatley-Pirbhai extends Input / Processing /
Output
– Adds user interface processing, maintenance
and self-testing processing
14
Hatley-Pirbhai Template
User Interface Processing
Process Model
Input
Processing
Control Model
Output
Processing
Maintenance, Self-Test,
and Redundancy
Management Processing
Figure 7.2
15
Hatley-Pirbhai Decomposition
Provide User Interface
Transform Inputs
into Outputs
Transform Inputs
into Outputs
Format
Inputs
Format
Inputs
Format
Outputs
Control Processing
Format
Outputs
Control Processing
Enable Maintenance,
Conduct Self-Test, and Manage
Redundancy Processing
Enable Maintenance,
Conduct Self-Test, and Manage
Redundancy Processing
Provide User Interface
Transform Inputs
into Outputs
Format
Inputs
Format
Outputs
Control Processing
Enable Maintenance,
Conduct Self-Test, and Manage
Redundancy Processing
Transform Inputs
into Outputs
Format
Inputs
Control Processing
Enable Maintenance,
Conduct Self-Test, and Manage
Redundancy Processing
Figure 7.4
Format
Outputs
Transform Inputs
into Outputs
Format
Inputs
Control Processing
Format
Outputs
Enable Maintenance,
Conduct Self-Test, and Manage
Redundancy Processing
16
Energy/Material/Signal Flows
Decomposition
Ulrich and Eppinger
17
Living Systems Template, #1
Subsystems that Process Both Matter-Energy and Information
1. Reproducer, the subsystem that is capable of giving rise to other systems similar to
the one it is in.
2. Boundary, the subsystem at the perimeter of a system that holds together the
components that make up the system, protects them from environmental stresses, and
excludes or permits entry to various sorts of matter-energy and information.
Biomimicry or biomimetics is the examination of nature, its
models, systems, processes, and elements to emulate or take
inspiration from in order to solve human problems.
Table 7.1
18
Living Systems Template, #2
Subsystems that Process Matter-Energy
3. Ingestor, the subsystem which brings matter-energy across the system boundary from the
environment.
4. Distributor, the subsystem that carries inputs from outside the system or outputs from its
subsystems around the system to each component.
5. Converter, the subsystem that changes certain inputs to the system into forms more useful for the
special processes of that particular system.
6. Producer, the subsystem that forms stable associations that endure for significant periods among
matter-energy inputs to the system or outputs from its converter, the materials synthesized being for
growth, damage repair, or replacement of components of the system, or for providing energy for moving
or constituting the system’s outputs of products or information markers to its suprasystem.
7. Matter-energy storage, the subsystem that retains in the system, for different periods of time,
deposits of various sorts of matter-energy.
8. Extruder, the subsystem that transmits matter-energy out of the system in the forms of products or
wastes.
9. Motor, the subsystem that moves the system or parts of it in relation to part or all of its
environment or moves components of its environment in relation to each other.
10. Supporter, the subsystem that maintains the proper spatial relationships among components of the
system, so that they can interact without weighting each other down or crowding each other.
Table 7.1
19
Living Systems Template, #3
Subsystems that Process Information
11. Input transducer, the sensory subsystem that brings markers bearing information into the system,
changing them to other matter-energy forms suitable for transmission within it.
12. Internal transducer, the sensory subsystem that receives, from subsystems or components within the system, markers
bearing information about significant alterations in those subsystems or components, changing them to other matterenergy forms of a sort which transmitted within it.
13. Channel and net, the subsystem composed of a single route in physical space, or multiple interconnected routes, by which
markers bearing information are transmitted to all parts of the system.
14. Decoder, the subsystem that alters the code of information input to it through the input transducer or internal
transducer into a “private” code that can be used internally by the system.
15. Associator, the subsystem that carries out the first stage of the learning process, forming enduring associations
among items of information in the system.
16. Memory, the subsystem that carries out the second stage of the learning process, storing various sorts of information
in the system for different periods of time.
17. Decider, the executive subsystem that receives information inputs from all other subsystems and transmits to them
information outputs that control the entire system.
18. Encoder, the subsystem that alters the code of information input to it from other information processing subsystems,
from a “private” code used internally by the system into a “public” code which can be interpreted by other systems in its
environment.
19. Output transducer, the subsystem that puts out markers bearing information from the system, changing markers within
the system into other matter-energy forms which can be transmitted over channels in the system’s environment.
Table 7.1
20
Some Examples !!
• Elevator
• Google
• Exercises:
–
–
–
–
Machine monitor
That pesky lawn mower
A few more examples
Your choice
21
Elevator Example - ESD
USED AT:
George Mason
Univ.
DATE: 09/27/1999
REV:
AUTHOR: Dennis Buede
PROJECT: Elevator Case Study
x
NOTES: 1 2 3 4 5 6 7 8 9 10
Passengers' Needs
Request
Elevator
Services
A-11
Comm. about Emergency,
Passenger Weight
Characteristics,
Sensed Passenger
Heat Loss/Gain
Repair
Parts
Relayed Info
about Emergency,
Electric Power,
Sensed Building
Heat
READER
DATE
Maintenance
Feedback:
Quality Standards
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
Up Service Request,
Floor Request,
Request to Extend
Entry support
Elevator Entry/Exit
Opportunity,
Information about
Emergency,
Elevator Heat
Loss/Gain
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Government
Regulations
Fire Alarm Signal
Fire Alarm
Provide
Elevator
Services
Signal for Partial Maint. Mode,
Signal for Full Op'g Mode
Malfunction Signal
Diagnosis Response,
Test Response
A0
Maint. Action,
Diagnosis Signals,
Repairs,
Test Signals
Maintain
Elevator
Operations
Relayed
Emer.
Comm.
Info. about
Emergency
A-13
Emergency
Comm'n
Provide
Structural
Support
Electrical
Power
Emergency
Messages
A-14
Passengers
NODE:
CONT EXT :
A-1
Elevator System
TITLE: External Systems Diagram for Operational Phase
Maintenance Personnel
Building
NUMBER:
P. 1
22
USED AT:
George Mason
Univ.
AUTHOR: Dennis Buede
PROJECT: Elevator Case Study
DATE: 09/27/1999
REV:
x
NOTES: 1 2 3 4 5 6 7 8 9 10
Up Service Request,
Floor Request,
Request to Extend
Entry support
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Signal for Partial Maint. Mode,
Signal for Full Op'g Mode
Fire Alarm Signal
Comm. about
Emergency,
Passenger Weight
Characteristics,
Sensed Passenger
Heat Loss/Gain
READER
DATE
Top
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
PROVIDE
ELEVATOR
SERVICES
Relayed Info
about Emergency,
Electric Power,
Sensed Building
Heat
CONT EXT :
Malfunction
Signal
Diagnosis Response,
Test Response
Maint. Action,
Diagnosis Signals,
Repairs,
Test Signals
Emergency
Comm'n
A0
Elevator System
Elevator Entry/Exit
Opportunity,
Information about
Emergency,
Elevator Heat
Loss/Gain
PURPOSE: To define boundary and architectures for the Operational Phase of the Elevator System
VIEWPOINT: Up & Down, Ltd. Systems Engineering Team
NODE:
A-0
TITLE:
Provide Elevator Services
NUMBER:
P. 2
23
Elevator Functional Decomposition
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
( ) around arrow head = tunneling (page 72)
NUMBER:
P. 3
24
How did we get here ?
• Create an IDEF0 block diagram with all the
H-P blocks
• Which ones do we need?
• Which ones to combine ?
• Do this mentally.
25
IDEF0 Page Structure
Page #’s
A-1
Function #’s
A-11
A-12
A-13
A0
A-0
A0
A1
A1, A3
A2
A11 A12 A13
A33
A3
A31 A32 A33 A34
A331 A332
Page Number(s)
A- 1
A- 0
A0
A1, A2, ...
A11, A12, ..., A21,
...
...
Figure 3.5; Table 3.2
A-0
A333 A334 A335
Page Content
Ancestor or external system diagram
Context or system function diagram (contains A0)
Level 0 diagram with first tier functions specified
Level 1 diagrams with second tier functions specified
Level 2 diagrams with third tier functions specified
…
26
27
Google
• Build it yourself.
• Do for everything:
–
–
–
–
–
–
Parallelize
Distribute to atomic level
Compress
Secure
Cache
Make redundant
28
The Exterior Picture
29
Physical Architecture
30
Data Center
31
Rack
32
O/S
33
The Interior Network
34
Major Glue
35
Google
• “Latency is evil”
• Slides from talk by Ed Austin, 2009:
http://www.slideshare.net/hasanveldstra/t
he-anatomy-of-the-google-architecturefina-lv11.
• See also http://highscalability.com/googlearchitecture for links
36
Exercise - Lawnmower
• Create two simple scenarios
– Start-up
– Cutting grass
• Create two system properties
– Convert from ‘customer wants’ to ‘engineering specifications’
via the House of Quality
• Create an ESD from the scenarios
• Create a first level decomposition using either
– Hatley-Pirbhai –or– Energy-Materials-Flows
38
39
How about – design it by
considering constraints?
Exercise
: Pick a System
• Create simple External Systems
Diagram
• Show top level function
• Create first level decomposition
• What’s a good software example
to use?
Try Energy/Material/Signal Flows?
40
Exercise
: Cooking Wok
• Use ‘Energy,
Materials, Signal
Flows’ to model the
wok.
41
Exercise
: ATM Manufacturing
• We work for the Acme ATM Manufacturing
Company. Develop a Systems Engineering
model for the manufacturing system for an
ATM.
• Identify a scenario, external systems, and
create the External Systems Diagram.
• Decompose one level.
42
Exercise
: Vehicle Security System
• Develop a Systems Engineering functional
model for a vehicle security system.
• Identify external systems and create the
External Systems Diagram and decompose
one level.
43
Input Opportunity
Input Commands
Feedback Commands Accepted
Feedback Monitor Status
Request Theft Signals
Suspicious and Theft Activity
Theft Signals
Theft Deterrent Signals
Theft Deterrent Commands
Feedback Alarm Status
Input Opportunity
Input Commands
Feedback Commands Accepted
Feedback Monitor Status
Power
Thief
NODE:
Vehicle
TITLE:
Deterrent
System
Operating Scenario for Vehicle Theft Deterrent System
Vehicle
User
NO.:
44
Checklist approach?
Evaluation of Functional Hierarchy
• Shortfalls – absence of functionality
– Absence of functionalities for input set
– Inability to produce desired output
– Insufficient feedback/control to produce desired output
• Overlaps – redundancy in functionality
• Evaluation technique – scenario tracing.
• Feedback needed ?
• Rules Followed ?
• BIST and Fault Tolerance functionality ?
45
Scenario Tracing, #1
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
Request for
Emergency
Support &
Emerency
Message
DATE CONTEXT:
READER
Top
Structural
Support,
Alarm Signals
& Building
Environment
Request for
Elevator
Service &
Entry support
Request for
Floor &
Exit Support
WORKING
DRAFT
RECOMMENDED
PUBLICATION
ModifiedElevator
Configuration
& Expected
Usage Patterns
Passenger
Environment
Passenger
Characteristics
Acknowledgment
that Request Was
Recieved & Status
Information
PROVIDE
ELEVATOR
SERVICES
Diagnostic &
Status Messages
Electric Power
& Emergency
Communication
Response
Emergency
Communication
Elevator
Entry/Exit
Opportunity
A0
Service, Tests
& Repairs
Emergency
Support
Elevator System
NODE:
Figure 7.7
A-0
TITLE:
Provide Elevator Services
NUMBER:
P. 2
46
Scenario Tracing, #2
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
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
Digitized
Passenger
Requests
Configuration
Controls
CONTROL
ELEVATOR
CARS
Electric
Power
DATE CONTEXT:
READER
Emergency
Communication
ACCEPT
PASSENGER
REQUESTS &
PROVIDE
FEEDBACK
Electric Power
& Emergency
Communication
Response
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 7.8
A0
ENABLE
EFFECTIVE
MAINTENANCE
& SERVICING
TITLE:
PROVIDE ELEVATOR SERVICES
‘Internal’ I/O become derived requirements
Diagnostic &
Status Messages
Diagnostic
Queries
Maintenance & Service
Component
NUMBER:
P. 3
47
Scenario Tracing, #3
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
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Request for
Floor &
Exit Support
Request for
Elevator
Service &
Entry support
Request for
Elevator
Service
Request for
Entry Support
Configuration
Controls
Digitized
Requests
from Waiting
Passengers
READER
Request for
Emergency
Support &
Emerency Acknowledgments
Message
& Status for
Waiting Passengers
Acknowledgment
that Request Was
Recieved & Status
Information
SUPPORT
WAITING
PASSENGERS
Elevator
Position &
Direction
DATE CONTEXT:
A11
Sensed
Floor-based
Malfunctions
Acknowledgments
& Status for
Riding Passengers
Digitiazed
Requests
from Riding
Passengers
SUPPORT
RIDING
PASSENGERS
Diagnostic
Queries
Digitized
Emergency
Requests
A12
Sensed
Car-based
Malfunctions
Nonemergency
Pass. Interface
Outside El. Cars
Nonemergency
Pass. Interface
Inside El. Cars
Acknowledgments
& Status for
Emergency
Passengers
NODE:
Figure 7.9
A1
TITLE:
Sensed
Malfunctions
Sensed
Emergency
Malfunctions
SUPPORT
PASSENGERS IN
EMERGENCY
Emergency
Communication
Emergency
Support
A13
Passenger
Interface
Component
Digitized
Passenger
Requests
Emergency
Pass. Interface
ACCEPT PASSENGER REQUESTS & PROVIDE FEEDBACK
NUMBER:
P. 4
48
Scenario Tracing, #4
USED AT:
George Mason
Univ.
AUTHOR: Dennis Buede
PROJECT: Elevator Case Study
DATE: 05/24/99
REV:
NOTES: 1 2 3 4 5 6 7 8 9 10
Request for
Elevator
Service
Diagnostic
Queries
x
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Configuration
Controls
DATE CONTEXT:
READER
Elevator
Position &
Direction
ACCEPT
PASSENGER
REQUEST
A111
Request
Alert
Passenger
Request
Digitized
Requests
from Waiting
Passengers
DIGITIZE
REQUEST
A112
Digitization
Successful
ACKNOWLEDGE
PASSENGER'S
REQUEST
Sensed
Floor-based
Malfunctions
A113
Acknoledgment
pf Request for
Elevator
Service
Nonemergency
Pass. Interface
Outside El. Cars
NODE:
Figure 7.10
A11
TITLE:
SUPPORT WAITING PASSENGERS
PROVIDE
STATUS
INFORMATION
FOR EACH CAR
A114
Acknowledgments
& Status for
Waiting Passengers
Status
Information
NUMBER:
P. 5
49
Scenario Tracing, #5
USED AT:
George Mason
Univ.
AUTHOR: Dennis Buede
PROJECT: Elevator Case Study
DATE: 05/24/99
REV:
NOTES: 1 2 3 4 5 6 7 8 9 10
Elevator
Position &
Direction
Digitized
Priority
Passenger
Requests
Digitized
Passenger
Requests
MONITOR
LOCATION
OF ALL CARS
Diagnostic
Queries
A21
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
Temporary
Modificatin to
Elevator
Configuration
Configuration
Controls
DATE CONTEXT:
ModifiedElevator
Configuration
& Expected
Usage Patterns
Sensed
Malfunctions
MONITOR
LOCATION AND
DIRECTION OF
ALL PRIORITY
WAITING
PASSENGERS
Digitized
Nonpriority
Passenger
Requests
A22
List of all
Cars with
Direction &
Location
x
List of all
Floors with
Waiting
Priority
Passengers
& Desired
Direction
MONITOR
LOCATION AND
DIRECTION OF
ALL
NONPRIORITY
WAITING
List of all
Floors with
Waiting
Nonpriority
Passengers
& Desired
Direction
A23
ALLOCATE
CARS TO
PASSENGER
PICK UP
STOPS A24
Assignments
for Elevator
Cars
Elevator Control
Component
NODE:
Figure 7.11
A2
TITLE:
CONTROL ELEVATOR CARS
NUMBER:
P. 6
50
Scenario Tracing, #6
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
DATE CONTEXT:
READER
Assignments
for Elevator
Cars
Configuration
Controls
Electric Power
& Emergency
Communication
Response
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Elevator
Entry/Exit
Opportunity
RECEIVE &
DISCHARGE
PASSENGERS
A31
Electric
Power
Sensed
Discharge
Malfunctions
Travel
Stopped
Message
Travel OK
Message
TRAVEL
TO NEXT
STOP
Passenger
Characteristics
Elevator
Position &
Direction
A32
Passenger
Weight
Passenger
Heat
Sensed
Travel
Malfunctions
PROVIDE
COMFORTABLE
ATMOSPHERE
Diagnostic
Queries
Sensed
Comfort
Malfunctions
Elevator
Car Door
Elevator Cars
Component
Figure 7.12
A3
Passenger
Environment
A33
Elevator Cab
& Door
NODE:
Sensed
Malfunctions
TITLE:
MOVE PASSENGERS BETWEEN FLOORS
Elevator Car
Sensors & Controls
NUMBER:
P. 7
51
Feedback & Control in
Functional Design
Basic Process
Process Input
into Output
Input
Output
Open-Loop Control of Process
Input
Desired
Output
Control
Process
Process Input
into Output
Control
Variable
Output
Closed-Loop Control of Process
Input
Desired
Output
Compare
Desired to
Actual
Control
Process
Delta
Process Input
into Output
Output
Control
Variable
Sense Output
Figure 7.5
52
Feedback Control in Operational
Architecture Development
AUTHOR: Dennis Buede
PROJECT: Engineering Design of a System
USED AT:
GMU Systems
Engineering
Program
DATE: 05/24/99
REV:
NOTES: 1 2 3 4 5 6 7 8 9 10
Originating & System
Requirements,
Objectives Hierarchy,
Boundary & Qualification
System Requirements
Candidate
Physical
Architectures
Allocate
Functions &
System-wide
Requirements
to Physical
Subsystems
Function to
Subsystem
Allocation
System-level
Functional
Architecture
Discrepancies in the
Specifications,
Interface Control,
and Acceptance
Test Plan
Define &
Analyze
Functional
Activation &
Control
Structure
A1142
Interface
Architecture
DATE CONTEXT:
READER
Suggested
Revisions
A1141
System-level
Operational
Concept
x
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Risk Analysis,
System Design
Document,
Operational
Architecture,
System Interface
Control Document
Document
Architectures
& Obtain
Approval
Alternative
System-level
Operational
Architectures
Analysis
Results
A1144
Architecture
Changes
Conduct
Performance
& Risk
Analyses
Operational
Architecture
A1143
System's
Qualification
System
Documentation
System-level
Architectures
Document
Subsystem
Specifications
A1145
NODE:
Figure 7.6
A114
TITLE:
Develop System Operational Architecture
NUMBER:
Subsystem
Design
Requirements,
Boundaries,
Missions,
Objectives
& Constraints
P. 9
53
Common Mistakes-1
1. Including the external systems and their functions. The
functional architecture only addresses the top-level function of
the system in question. The external system diagram establishes
the inputs, controls, and outputs for this function. A boundary has
been drawn around the system to exclude the external systems and
their functions.
2. Choosing the wrong name for a function. The function name
should start with an action verb and include an object of that
action. The verb should not contain an objective or performance
goal such as maximize, but should describe an action or activity
that is to be performed.
54
Common Mistakes-2
3. Including a verb phrase as part of the inputs, controls, or outputs
of a function. Verb phrases are reserved for functions.
4. Violating the law of conservation of inputs, controls, and outputs.
That is, every input, control, and output of a particular function must
appear on the decomposition of that function, and there can be no new
ones.
5. Creating outputs from thin air. The most common mistake is to
define a function that monitors the system’s status but that does not
receive inputs about the functioning or lack of functioning of other
parts of the system.
55
Common Mistakes-3
6. Creating a decomposition of a function that is not a partition of
that function. For example, a student once decomposed “A0: Provide
Elevator Services” into “A1: Transport Users,” “A2: Evaluate System
Status,” and “A3: Perform Security & Maintenance Operations.” “A1:
Transport Users” was then decomposed as follows: “A11: Provide
Access to Elevator,” “A12: Transport Users,” and “A13: Provide
Emergency Operations.” A12 cannot be a child of itself. The
subfunctions of a function should all be at the same level of
abstraction [Chapman et al., 1992].
7. Trivializing the richness of interaction between the functions that
decompose their parent. Consider many possible simple functionalities
that comprise the children of a parent function and then develop the
inputs, controls, and outputs that enable these simple functionalities to
exist, including the necessary feedback and control.
56
Finishing the Functional Architecture
• Inserting functionality to detect –
– Errors
– Failure Modes
• Inserting functionality for –
–
–
–
–
Built in self test
Testability
Maintainability
Serviceability
57
Definitions from Fault Tolerance
System: an identifiable mechanism that maintains a pattern of behavior at an interface
between the system and it environment [Anderson and Lee, 1981].
Failure: deviation in behavior between the system and its requirements. Since the
system does not maintain a copy of its requirements, a failure is not observable by the
system.
Error: a subset of the system state, which may lead to a failure. The system can
monitor its own state, so errors are observable in principle. Failures are inferred when
errors are observed. Since a system is usually not able to monitor its entire state
continuously, not all errors are observable. As a result, not all failures are going to be
detected (inferred).
Fault: a defect in the system that can cause an error. Faults can be permanent (e.g., a
failure of system component that requires replacement) or temporary due to either an
internal malfunction or external transient. Temporary faults may not cause a
sufficiently noticeable error or may cause a permanent fault in addition to a temporary
error.
58
Fault Tolerance Functions
• Error detection
•
•
•
•
– Data – range, type, structure
– Timing – real-time systems
– Physical errors
Damage confinement
Error recovery
Fault isolation and reporting
Built in self test - BIST
Examples ??
59
Examples from
Montronix
• Data – User input, range checking.
• Sensor Inputs – range checking.
• Memory – validity, checksums, check errors
on power up.
• Timing – A/D converter speed variations,
number of channels, algorithm complexity.
• BIST software, hardware functionality on
power up, loopback tests, test stations.
60
Traceability
• All I/O on scenarios must trace to
corresponding functional representations and
input/output requirements
• All ‘customer wants’ generally trace to
technology and system-wide requirements.
61
Tracing Requirements
Input/Output Requirements (A Sample)
Output Requirements
Input Requirements
Functions
0 Provide Elevator Services
1 Accept Passenger Requests + Provide Feedback
1.1 Support Waiting Passengers
The elevator
system shall
receive calls for up
and down service
from all floors of
the building.
X
X
X
The elevator
system shall
receive passenger
activated fire
alarms in each
elevator car.
X
X
The elevator
system shall
provide
adequate
illumination.
The elevator
system shall open
and close
automatically upon
arrival at each
selected floor.
X
X
Functional
Requirement
The elevator
system shall
control
elevator cars
efficiently.
External
Interface
Requirement
The elevator
system shall use
a phone line
from the
building for
emergency calls.
X
X
X
1.2 Support Riding Passengers
1.3 Support Passengers in Emergency
X
X
2 Control Elevator Cars
3 Move Passengers between Floors
X
3.1 Receive + Discharge Passengers
X
X
3.2 Travel to Next Stop
3.3 Provide Comfortable Atmosphere
X
4 Enable Effective Maintenance and Servicing
Figure 7.13
62
Tracing Requirements
x
x
x
x
x
x 1.2
1.3
x 2.2
x 2.3
x 1.10
x 2.1
x 2.13
x 3.2
x 3.3
The OnStar system shall accept verbal communication from the user.
The OnStar system shall accept notification of the user being locked out.
The OnStar system shall request assistance from local emergency services.
The OnStar system shall provide the location of the user's vehicle
The OnStar system shall accept a request for assistance from the user.
The OnStar system shall provide verbal communication with the user.
The OnStar system shall communicate with the user's friend or family member.
The OnStar system shall communicate with the phone system
The OnStar system shall provide verbal information to the user.
Analysis and
Simulation
I/O Requirements
Demonstration
Qualification
Instrumented Test
Equipment
Accident Assist
Remote Door
Unlock
User Case
x
x
x
x
x
x
x
x
x
Also, all I/O
requirements must
be qualified
From last time
63
Additional Decomposition
Examples
•ATM Machine
64
USED AT:
George Mason
University
AUTHOR: SYST 520 Student
PROJECT: Automatic Teller Machine
DATE: 09/28/99
REV:
x
NOTES: 1 2 3 4 5 6 7 8 9 10
Customer Needs
Main Menu
A-11
A-1
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
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
Customers
NODE:
Clim
Safety
Regulations
DATE CONTEXT:
READER
None
Banking
Policies
General ID,
Unique ID
Perform
Customer
Activities
Choice, ATM Reset,
No Input Device,
Request for ID #2,
Request for ID #3,
Customer Alert, Apology,
Request for Paymt Source
Americans with
Disabilities Act
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Transaction,
Request for Fmax,
Request for Status Inf..,
Input Not Working,
Request for Funds,
Request for Receipts,
Break-in Attempted
Employee
ID Code
Provide
ATM Services
Audible
Alarm,
Operation
Terminated
Provide Bank
Information to
ATM
A-0
Cust Status Inf..,
Fmax
A-12
Maintain ATM
A-13
Request to Open,
ATM Cash,
Blank Receipts,
Initialization,
Diagnostic Test,
ATM Fixes,
Request to Close
ATM System
TITLE: Operational Phase External Systems
Access Opportunity,
ATM Opened,
Cust Deposits,
Cust Payments,
Test Results,
Fixes Applied
ATM Closed
Bank
Computer
Rob
ATM
A-14
Break-in
Attempt
Bank
Employees
NUMBER:
Robber
P. 1
65
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
66