Functional Architecture Development

kitteninterestAI and Robotics

Nov 15, 2013 (3 years and 9 months ago)

67 views

1

The Engineering Design of Systems:
Models and Methods

Buede
-

Chapter 7

Functional Architecture

Development

Edited Mar. 2013


2

Process, rule based approach

Design, creativity,
derived material

3

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:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
Top
2
x
Elevator Case Study
Dennis Buede
George Mason
Univ.
09/27/1999
Provide Elevator Services
A-0
PROVIDE
ELEVATOR
SERVICES
A0
Up Service Request,
Floor Request,
Request to Extend
Entry support
PURPOSE: To define boundary and architectures for the Operational Phase of the Elevator System
VIEWPOINT: Up & Down, Ltd. Systems Engineering Team
Comm. about
Emergency,
Passenger Weight
Characteristics,
Sensed Passenger
Heat Loss/Gain
Relayed Info
about Emergency,
Electric Power,
Sensed Building
Heat
Maint. Action,
Diagnosis Signals,
Repairs,
Test Signals
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
Malfunction
Signal
Elevator Entry/Exit
Opportunity,
Information about
Emergency,
Elevator Heat
Loss/Gain
Emergency
Comm'n
Diagnosis Response,
Test Response
Fire Alarm Signal
Signal for Partial Maint. Mode,
Signal for Full Op'g Mode
Elevator System
Every system has an ‘architecture’


sometimes it
is really good, sometimes really bad. M. Collins.

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.


Like Kung Fu…


This is a skill

and an art.



This is where the systems engineer
really provides benefit and value.


6

Image from
http://www.pathsatlanta.org/2009/04/10/is
-
kung
-
fu
-
a
-
martial
-
art/


7

Functional Architecture Process

USED AT:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
Originating & System
Requirements,
Objectives Hierarchy,
Boundary & Qualification
System Requirements
System-level
Operational
Concept
Create Simple
Functionalities
for Operational
Concept
A1121
Draft &
Evaluate
Functional
Model
A1122
Complete
Functional
and Data
Models
A1124
Trace
Input/Output
Requirements
to Functions
and Items
A1125
Simple
Functionalities
Draft
Functional
Model
Functional
and Data
Models
Architecture
Issues
Boundary Inputs,
Controls, and
Outputs and
Objectives
Input/Output
Requirements
System-level
Functional
Architecture
Functional
Requirements,
Inputs, and
Outputs
Functional
Architecture
Changes
Candidate
Generic
Physical
Architectures
Draft Data
Model for
Functional
Model
A1123
Boundary Inputs,
Controls, and
Outputs
Data
Model
7
x
Engineering Design of a System
Dennis Buede
GMU Systems
Engineering
Program
05/24/99
Develop System Functional Architecture
A112
Figure 7.1

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

5.
Ulrich and Eppinger


‘Energy/Material/Signal
Flows’

6.
Use Miller “Living
Systems” template


USED AT:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
Top
2
x
Elevator Case Study
Dennis Buede
George Mason
Univ.
09/27/1999
Provide Elevator Services
A-0
PROVIDE
ELEVATOR
SERVICES
A0
Up Service Request,
Floor Request,
Request to Extend
Entry support
PURPOSE: To define boundary and architectures for the Operational Phase of the Elevator System
VIEWPOINT: Up & Down, Ltd. Systems Engineering Team
Comm. about
Emergency,
Passenger Weight
Characteristics,
Sensed Passenger
Heat Loss/Gain
Relayed Info
about Emergency,
Electric Power,
Sensed Building
Heat
Maint. Action,
Diagnosis Signals,
Repairs,
Test Signals
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
Malfunction
Signal
Elevator Entry/Exit
Opportunity,
Information about
Emergency,
Elevator Heat
Loss/Gain
Emergency
Comm'n
Diagnosis Response,
Test Response
Fire Alarm Signal
Signal for Partial Maint. Mode,
Signal for Full Op'g Mode
Elevator System
12

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

Maintenance, Self-Test,
and Redundancy
Management Processing
Process Model
Input
Processing
Output
Processing
User Interface Processing
Control Model
Figure 7.2

15

Hatley
-
Pirbhai Decomposition

Enable Maintenance,
Conduct Self-Test, and Manage
Redundancy Processing
Transform Inputs
into Outputs
Format
Inputs
Format
Outputs
Provide User Interface
Control Processing
Enable Maintenance,
Conduct Self-Test, and Manage
Redundancy Processing
Transform Inputs
into Outputs
Format
Inputs
Format
Outputs
Provide User Interface
Control Processing
Enable Maintenance,
Conduct Self-Test, and Manage
Redundancy Processing
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
Format
Outputs
Control Processing
Enable Maintenance,
Conduct Self-Test, and Manage
Redundancy Processing
Transform Inputs
into Outputs
Format
Inputs
Format
Outputs
Control Processing
Figure 7.4

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.


Table 7.1

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.

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 matter
-
energy 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

Some Examples !!


Elevator


Google


Exercises:


Machine monitor


That pesky lawn mower


A few more examples


Your choice




20

21

Elevator Example
-

ESD

USED AT:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
1
x
Elevator Case Study
Dennis Buede
George Mason
Univ.
09/27/1999
A-1
Provide
Elevator
Services
A0
Comm. about Emergency,
Passenger Weight
Characteristics,
Sensed Passenger
Heat Loss/Gain
Relayed Info
about Emergency,
Electric Power,
Sensed Building
Heat
Maint. Action,
Diagnosis Signals,
Repairs,
Test Signals
Up Service Request,
Floor Request,
Request to Extend
Entry support
Fire Alarm Signal
Signal for Partial Maint. Mode,
Signal for Full Op'g Mode
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
Malfunction Signal
Elevator Entry/Exit
Opportunity,
Information about
Emergency,
Elevator Heat
Loss/Gain
Request
Elevator
Services
A-11
Maintain
Elevator
Operations
A-13
Provide
Structural
Support
A-14
Passengers' Needs
Emergency
Messages
Emergency
Comm'n
Passengers
Elevator System
Maintenance Personnel
Building
Repair
Parts
External Systems Diagram for Operational Phase
Maintenance
Quality Standards
Government
Regulations
Diagnosis Response,
Test Response
Electrical
Power
Relayed
Emer.
Comm.
Info. about
Emergency
Fire Alarm
22

USED AT:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
Top
2
x
Elevator Case Study
Dennis Buede
George Mason
Univ.
09/27/1999
Provide Elevator Services
A-0
PROVIDE
ELEVATOR
SERVICES
A0
Up Service Request,
Floor Request,
Request to Extend
Entry support
PURPOSE: To define boundary and architectures for the Operational Phase of the Elevator System
VIEWPOINT: Up & Down, Ltd. Systems Engineering Team
Comm. about
Emergency,
Passenger Weight
Characteristics,
Sensed Passenger
Heat Loss/Gain
Relayed Info
about Emergency,
Electric Power,
Sensed Building
Heat
Maint. Action,
Diagnosis Signals,
Repairs,
Test Signals
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
Malfunction
Signal
Elevator Entry/Exit
Opportunity,
Information about
Emergency,
Elevator Heat
Loss/Gain
Emergency
Comm'n
Diagnosis Response,
Test Response
Fire Alarm Signal
Signal for Partial Maint. Mode,
Signal for Full Op'g Mode
Elevator System
23

Elevator Functional Decomposition

USED AT:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
A-0
3
x
Elevator Case Study
Dennis Buede
George Mason
Univ.
09/29/1999
PROVIDE ELEVATOR SERVICES
A0
ACCEPT
PASSENGER
REQUESTS &
PROVIDE
FEEDBACK
A1
CONTROL
ELEVATOR
CARS
A2
MOVE
PASSENGERS
BETWEEN
FLOORS
A3
ENABLE
EFFECTIVE
MAINTENANCE
& SERVICING
A4
Digitized
Passenger
Requests
Assignments
for Elevator
Cars
Elevator
Position &
Direction
Sensed Malfunctions,
Diagnosis &
Test Responses
Temporary
Modificatin to
Elevator
Configuration
Electric
Power
Electric
Power
Up Service Request,
Floor Request,
Request to Extend
Entry support
Relayed Info
about Emergency,
Electric Power,
Sensed Building
Heat
Comm. about
Emergency,
Passenger Weight
Characteristics,
Sensed Passenger
Heat Loss/Gain
Maint. Action,
Diagnosis Signals,
Repairs,
Test Signals
Diagnosis Response,
Test Response
Malfunction
Signal
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
Elevator Entry/Exit
Opportunity,
Information about
Emergency,
Elevator Heat
Loss/Gain
Fire Alarm Signal
Signal for Partial Maint. Mode,
Signal for Full Op'g Mode
Request to Extend
Entry support
Up Service Request,
Floor Request
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
Operating
Mode
Diagnosis Signals,
Maint. Action,
Repairs,
Test Signals
( ) around arrow head = tunneling (page 72)

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.


24

25

IDEF0 Page Structure

Page #’s Function #’s

A-1
A-0
A0
A1, A3
A33
A0
A1
A2
A3
A11
A12
A13
A31
A32
A33
A34
A331
A332
A333
A335
A334
A-0
A-12
A-11
A-13
Page Number(s)


Page Content


A
-

1


Ancestor or external system diagram


A
-

0


Context or system function diagram (contains A0)


A0


Level 0 diagram with first tier functions specified


A1, A2, ...


Level 1 diagrams with second tier functions specified


A11, A12, ..., A21,
...


Level 2 diagrams with third tier functions specified


...





Figure 3.5; Table 3.2


26

Google


Build it yourself.


Do for everything:


Parallelize


Distribute to atomic level


Compress


Secure


Cache


Make redundant

27

The Exterior Picture

28

Physical Architecture

29

Data Center

30

Rack

31

O/S

32

The Interior Network

33

Major Glue

34

Google


“Latency is evil”


Slides from talk by Ed Austin, 2009:
http://www.slideshare.net/hasanveldstra/t
he
-
anatomy
-
of
-
the
-
google
-
architecture
-
fina
-
lv11
.


See also
http://highscalability.com/google
-
architecture

for links

35

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

37


38

39

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


NODE
:
NO
.:
TITLE
:
Operating Scenario for Vehicle Theft Deterrent System
Thief
Vehicle
Deterrent
System
Vehicle
User
Input Commands
Feedback Commands Accepted
Input Opportunity
Feedback Monitor Status
Suspicious and Theft Activity
Theft Signals
Feedback Alarm Status
Theft Deterrent Commands
Input Opportunity
Feedback Commands Accepted
Feedback Monitor Status
Request Theft Signals
Power
Theft Deterrent Signals
Input Commands
44

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:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
PROVIDE
ELEVATOR
SERVICES
A0
Passenger
Characteristics
Electric Power
& Emergency
Communication
Response
Service, Tests
& Repairs
Request for
Emergency
Support &
Emerency
Message
Request for
Floor &
Exit Support
Request for
Elevator
Service &
Entry support
Structural
Support,
Alarm Signals
& Building
Environment
ModifiedElevator
Configuration
& Expected
Usage Patterns
Passenger
Environment
Acknowledgment
that Request Was
Recieved & Status
Information
Diagnostic &
Status Messages
Elevator
Entry/Exit
Opportunity
Emergency
Support
Emergency
Communication
Elevator System
Top
2
x
Elevator Case Study
Dennis Buede
George Mason
Univ.
05/24/99
Provide Elevator Services
A-0
Figure 7.7

46

Scenario Tracing, #2

USED AT:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
Passenger
Characteristics
Electric Power
& Emergency
Communication
Response
Service, Tests
& Repairs
Diagnostic &
Status Messages
Acknowledgment
that Request Was
Recieved & Status
Information
Passenger
Environment
Request for
Elevator
Service &
Entry support
Request for
Floor &
Exit Support
Request for
Emergency
Support &
Emerency
Message
Structural
Support,
Alarm Signals
& Building
Environment
ModifiedElevator
Configuration
& Expected
Usage Patterns
ACCEPT
PASSENGER
REQUESTS &
PROVIDE
FEEDBACK
A1
CONTROL
ELEVATOR
CARS
A2
MOVE
PASSENGERS
BETWEEN
FLOORS
A3
ENABLE
EFFECTIVE
MAINTENANCE
& SERVICING
A4
Digitized
Passenger
Requests
Assignments
for Elevator
Cars
Elevator
Entry/Exit
Opportunity
Emergency
Support
Elevator
Position &
Direction
Sensed
Malfunctions
Temporary
Modificatin to
Elevator
Configuration
Emergency
Communication
Electric
Power
Electric
Power
Elevator System
Passenger
Interface
Component
Elevator Control
Component
Elevator Cars
Component
Maintenance & Service
Component
Configuration
Controls
Diagnostic
Queries
PROVIDE ELEVATOR SERVICES
3
x
Elevator Case Study
Dennis Buede
George Mason
Univ.
05/24/99
A0
Figure 7.8

‘Internal’ I/O become derived requirements

47

Scenario Tracing, #3

USED AT:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
Request for
Floor &
Exit Support
Request for
Emergency
Support &
Emerency
Message
Request for
Elevator
Service &
Entry support
Acknowledgment
that Request Was
Recieved & Status
Information
Emergency
Support
Elevator
Position &
Direction
Sensed
Malfunctions
SUPPORT
WAITING
PASSENGERS
A11
SUPPORT
RIDING
PASSENGERS
A12
SUPPORT
PASSENGERS IN
EMERGENCY
A13
Request for
Entry Support
Request for
Elevator
Service
Digitized
Passenger
Requests
Emergency
Communication
Sensed
Floor-based
Malfunctions
Sensed
Car-based
Malfunctions
Sensed
Emergency
Malfunctions
Acknowledgments
& Status for
Waiting Passengers
Acknowledgments
& Status for
Riding Passengers
Acknowledgments
& Status for
Emergency
Passengers
Digitized
Emergency
Requests
Digitiazed
Requests
from Riding
Passengers
Digitized
Requests
from Waiting
Passengers
Passenger
Interface
Component
Nonemergency
Pass. Interface
Outside El. Cars
Nonemergency
Pass. Interface
Inside El. Cars
Emergency
Pass. Interface
Configuration
Controls
Diagnostic
Queries
4
x
Elevator Case Study
Dennis Buede
George Mason
Univ.
05/24/99
ACCEPT PASSENGER REQUESTS & PROVIDE FEEDBACK
A1
Figure 7.9

48

Scenario Tracing, #4

USED AT:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
Elevator
Position &
Direction
Request for
Elevator
Service
Acknowledgments
& Status for
Waiting Passengers
Sensed
Floor-based
Malfunctions
ACCEPT
PASSENGER
REQUEST
A111
DIGITIZE
REQUEST
A112
ACKNOWLEDGE
PASSENGER'S
REQUEST
A113
PROVIDE
STATUS
INFORMATION
FOR EACH CAR
A114
Passenger
Request
Request
Alert
Digitization
Successful
Acknoledgment
pf Request for
Elevator
Service
Status
Information
Digitized
Requests
from Waiting
Passengers
Nonemergency
Pass. Interface
Outside El. Cars
Diagnostic
Queries
Configuration
Controls
5
x
Elevator Case Study
Dennis Buede
George Mason
Univ.
05/24/99
SUPPORT WAITING PASSENGERS
A11
Figure 7.10

49

Scenario Tracing, #5

USED AT:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
ModifiedElevator
Configuration
& Expected
Usage Patterns
Assignments
for Elevator
Cars
Elevator
Position &
Direction
Sensed
Malfunctions
MONITOR
LOCATION
OF ALL CARS
A21
MONITOR
LOCATION AND
DIRECTION OF
ALL
NONPRIORITY
WAITING
A23
ALLOCATE
CARS TO
PASSENGER
PICK UP
STOPS
A24
Digitized
Passenger
Requests
List of all
Cars with
Direction &
Location
List of all
Floors with
Waiting
Nonpriority
Passengers
& Desired
Direction
Temporary
Modificatin to
Elevator
Configuration
MONITOR
LOCATION AND
DIRECTION OF
ALL PRIORITY
WAITING
PASSENGERS
A22
Digitized
Priority
Passenger
Requests
Digitized
Nonpriority
Passenger
Requests
List of all
Floors with
Waiting
Priority
Passengers
& Desired
Direction
Elevator Control
Component
Configuration
Controls
Diagnostic
Queries
6
x
Elevator Case Study
Dennis Buede
George Mason
Univ.
05/24/99
CONTROL ELEVATOR CARS
A2
Figure 7.11

50

Scenario Tracing, #6

USED AT:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
Passenger
Characteristics
Passenger
Environment
Electric Power
& Emergency
Communication
Response
Assignments
for Elevator
Cars
Elevator
Entry/Exit
Opportunity
Elevator
Position &
Direction
Sensed
Malfunctions
RECEIVE &
DISCHARGE
PASSENGERS
A31
TRAVEL
TO NEXT
STOP
A32
PROVIDE
COMFORTABLE
ATMOSPHERE
A33
Electric
Power
Travel OK
Message
Travel
Stopped
Message
Passenger
Weight
Passenger
Heat
Sensed
Discharge
Malfunctions
Sensed
Travel
Malfunctions
Sensed
Comfort
Malfunctions
Elevator Cars
Component
Elevator
Car Door
Elevator Cab
& Door
Elevator Car
Sensors & Controls
Configuration
Controls
Diagnostic
Queries
7
x
Elevator Case Study
Dennis Buede
George Mason
Univ.
05/24/99
MOVE PASSENGERS BETWEEN FLOORS
A3
Figure 7.12

51

Feedback & Control in
Functional Design

Control
Variable
Process Input
into Output
Input
Output
Process Input
into Output
Input
Output
Control
Process
Desired
Output
Control
Variable
Basic Process
Open-Loop Control of Process
Process Input
into Output
Input
Output
Control
Process
Desired
Output
Closed-Loop Control of Process
Compare
Desired to
Actual
Delta
Sense Output




Figure 7.5

52

Feedback Control in Operational
Architecture Development

USED AT:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
Originating & System
Requirements,
Objectives Hierarchy,
Boundary & Qualification
System Requirements
System-level
Operational
Concept
Candidate
Physical
Architectures
Subsystem
Design
Requirements,
Boundaries,
Missions,
Objectives
& Constraints
Architecture
Changes
Allocate
Functions &
System-wide
Requirements
to Physical
Subsystems
A1141
Define &
Analyze
Functional
Activation &
Control
Structure
A1142
Document
Architectures
& Obtain
Approval
A1144
Document
Subsystem
Specifications
A1145
System-level
Architectures
Function to
Subsystem
Allocation
Conduct
Performance
& Risk
Analyses
A1143
Alternative
System-level
Operational
Architectures
Analysis
Results
Suggested
Revisions
Risk Analysis,
System Design
Document,
Operational
Architecture,
System Interface
Control Document
System-level
Functional
Architecture
Discrepancies in the
Specifications,
Interface Control,
and Acceptance
Test Plan
Operational
Architecture
Interface
Architecture
System's
Qualification
System
Documentation
9
x
Engineering Design of a System
Dennis Buede
GMU Systems
Engineering
Program
05/24/99
Develop System Operational Architecture
A114
Figure 7.6

53

Common Mistakes

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)


Input Requirements


Output Requirements

Functional
Requirement

External
Interface
Requirement







Functions

The elevator
system shall
receive calls for up
and down service
from all floors of
the building.

The ele
vator
system shall
receive passenger
activated fire
alarms in each
elevator car.

The elevator
system shall
provide
adequate
illumination.

The elevator
system shall open
and close
automatically upon
arrival at each
selected floor.

The elevator
system shall
control
elevator cars
efficiently.

The elevator
system shall use
a phone line
from the
building for
emergency calls.

0 Provide Elevator Services

X

X

X

X

X

X

1 Accept Passenger Requests
+
Provide Feedback

X

X




X

1.1 Support Waiting Passengers

X






1.2 Support Riding Passengers







1.3 Support Passengers in Emergency


X




X

2 Control Elevator Cars







3 Move Passengers between Floors



X

X



3.1 Receive + Discharge Passengers




X



3.2 Travel to Next Stop







3.3 Provide C
omfortable Atmosphere



X




4 Enable Effective Maintenance and Servicing








Figure 7.13

62

Tracing Requirements

Remote Door
Unlock
Accident Assist
Instrumented Test
Equipment
Demonstration
Analysis and
Simulation
x
x
1.2
The OnStar system shall accept verbal communication from the user.
x
x
1.3
The OnStar system shall accept notification of the user being locked out.
x
x
2.2
The OnStar system shall request assistance from local emergency services.
x
x
2.3
The OnStar system shall provide the location of the user's vehicle
x
x
1.10
The OnStar system shall accept a request for assistance from the user.
x
x
x
2.1
The OnStar system shall provide verbal communication with the user.
x
x
2.13
The OnStar system shall communicate with the user's friend or family member.
x
x
x
3.2
The OnStar system shall communicate with the phone system
x
x
x
3.3
The OnStar system shall provide verbal information to the user.
x
User Case
Qualification
From last time

Also, all I/O
requirements must
be qualified

I/O Requirements

Additional Decomposition
Examples

63


ATM Machine


64

USED AT:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
Provide
ATM Services
A-0
Perform
Customer
Activities
A-11
Provide Bank
Information to
ATM
A-12
Maintain ATM
A-13
Customers
ATM System
Bank
Computer
Bank
Employees
Customer Needs
Banking
Policies
General ID,
Unique ID
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
Transaction,
Request for Fmax,
Request for Status Inf..,
Input Not Working,
Request for Funds,
Request for Receipts,
Break-in Attempted
Access Opportunity,
ATM Opened,
Cust Deposits,
Cust Payments,
Test Results,
Fixes Applied
ATM Closed
Request to Open,
ATM Cash,
Blank Receipts,
Initialization,
Diagnostic Test,
ATM Fixes,
Request to Close
Rob
ATM
A-14
Robber
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
Audible
Alarm,
Operation
Terminated
Main Menu
Cust Status Inf..,
Fmax
Employee
ID Code
Break-in
Attempt
Operational Phase External Systems
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
Safety
Regulations
Clim
None
1
x
Automatic Teller Machine
SYST 520 Student
George Mason
University
09/28/99
A-1
65

USED AT:
CONTEXT:
NODE:
TITLE:
NUMBER:
AUTHOR:
PROJECT:
NOTES: 1 2 3 4 5 6 7 8 9 10
DATE:
REV:
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
P.
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
Cust Status Inf..,
Fmax
General ID,
Unique ID
Employee
ID Code
Audible
Alarm,
Operation
Terminated
Break-in
Attempt
Safety
Regulations
Americans with
Disabilities Act
Choice, ATM Reset,
No Input Device,
Request for ID #2,
Request for ID #3,
Customer Alert, Apology,
Request for Paymt Source
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
Transaction,
Request for Fmax,
Request for Status Inf..,
Input Not Working,
Request for Funds,
Request for Receipts,
Break-in Attempted
Request to Open,
ATM Cash,
Blank Receipts,
Initialization,
Diagnostic Test,
ATM Fixes,
Request to Close
Access Opportunity,
ATM Opened,
Cust Deposits,
Cust Payments,
Test Results,
Fixes Applied
ATM Closed
Main Menu
Provide
Access to
ATM
A1
Accept
Customer
Requests and
Provide
Feedback
A2
Determine
ATM
Responses
A3
Communicate
with Bank
Computer
A4
Enable
Re-Supply and
Maintenance
A5
Respond to
Hostile
Situations
A6
Request for
Unique ID
Banking
Policies
No Input Device,
Request for ID #2,
Request for ID #3,
Customer Alert
Choice, ATM Reset,
Apology, Request
for Paymt Source
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
Customer
Valid
Employee
Valid
ID Validation
ID Received
Activity Selected,
A/C Type Entered,
Deposit Type Entered
Deposit Received,
Amount Entered,
Source A/C Entered,
Dest A/C Entered,
Ftrns>Fmax
Need for Fmax,
Trans Complete,
Receipts<25
Need to Open,
Paymts Inserted,
Deposits Inserted,
Diagnostics,
Fixes to ATM
Need to Close
Creq>Cleft
Balance Inf.,
Paymt Source Entered,
Payment Received,
Ptrns>Fmax,
Cancel Received,
Choice Received
Account
FMax
Account Balance
Cust Activity,
Cust A/C Type,
Deposit Entered,
Cust Amount,
Trans Source,
Trans Dest,
Paymt Source,
Payment Entered,
Cancel Entered,
Choice Entered
Attempted Break-in
Clim
Calculations
for
Withdrawal
Input not
Available
3
x
Automatic Teller Machine
SYST 520 Student
George Mason
University
08/07/00
Provide ATM Services
A0