1

Week 6 - Systems Engineering and Analysis

Buede ch 9 and Wasson ch 41 – Operational Architecture

“Operations systems” are a whole category of software, in the world of running complex systems. They are the part that makes decisions about all the rest, and/or enables humans to do that. How much do the humans do, of that control? Hmmm… good question!

Here we see NASA’s “Operations systems” in action, with humans!From http://www.nasa.gov/centers/ames/research/technology-onepagers/mission_ops_risk_mngt_prt.htm.

2

Major Activities

1. Allocate functions and system-wide requirements to physical subsystems• Allocate functions to components• Derive ‘internal’ requirements• ‘Flowdown’ system-wide requirements to system

and derive requirements

2. Model and simulate functional activation and control structure – (define some of the ‘when’)

3. Conduct performance and risk analysis4. Document architectures and obtain approval5. Document subsystem specifications

3

The Big Picture

OperationalConcept

Stakeholders

Life-CyclePhase

ObjectivesHierarchy

Stakeholders

OriginatingRequirements

Life-CyclePhase

ExternalSystemsDiagramInputs &

Outputs

Inputs &Outputs

CompleteInputs &Outputs

Objectives

Validation &AcceptanceTest Scenarios

FunctionalArchitecture

PhysicalArchitecture

OperationalArchitecture

StateTransitionDiagram

DerivedRequirementsand Flowdown

Risk Analysis and

Documentation

Interfaces

4

Operational Architecture

• Completes the functional to physical transition.

• Benefit of making major design decisions early : manageable blocks, chance of success, rapid development.

• Leave time for redesign, rework.

Buede Ch 9 starts here. Wasson Ch 41 starts on Slide 24.

5

Operational Architecture

Provides a complete description of the system design including :– Functional Architecture allocated to the

Physical Architecture– Derived I/O, Tech and Sys Wide, Trade Off,

and Qualification requirements for each component

– Interface Architecture– Complete Documentation

6

Allocate Functions

to Component

s

Functions

f2

f3

f4

f1

f5

Components

c2

c3

c4

c1

c5

Function for the allocation of functions to components

Functions

f2

f3

f4

f1

f5

Components

c2

c3

c4

c1

c5

One-to-one and ontofunction for the allocation

of functions to components

Functions

f2

f4

f5

f1

f8

Components

c2

c3

c4

c1

c5

Onto, but not one-to-onefunction for the allocation

of functions to components

f3

f7f6

Functions

f2

f3

f4

f1

f5

Components

c2

c3

c4

c1

c5

Relation for the allocation of functions to components

Figure 9.3 Modular Integral

7

Allocation Is Multi-objective Optimization Problem

• Maximize the fundamental objectives

• Minimize the number and complexity of interfaces – modularization

• Maximize early critical testing opportunities - risk minimization – Equalizing risks – Localizing risks

8

Allocating Functions to Components Using IDEF0

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.

PassengerCharacteristics

Electric Power& EmergencyCommunication Response

Service, Tests& Repairs

Diagnostic &Status Messages

Acknowledgmentthat Request WasRecieved & StatusInformation

PassengerEnvironment

Request forElevator Service &Entry support

Request forFloor & Exit Support

Request forEmergencySupport &EmerencyMessage

StructuralSupport,Alarm Signals& BuildingEnvironment

ModifiedElevatorConfiguration& ExpectedUsage Patterns

ACCEPT PASSENGER REQUESTS &

PROVIDE FEEDBACK

A1

CONTROL ELEVATOR

CARSA2

MOVE PASSENGERS

BETWEEN FLOORS

A3

ENABLE EFFECTIVE

MAINTENANCE & SERVICING

A4

DigitizedPassengerRequests

Assignmentsfor ElevatorCars

ElevatorEntry/ExitOpportunity

EmergencySupport

ElevatorPosition &Direction

SensedMalfunctions

TemporaryModificatin toElevator Configuration

EmergencyCommunication

ElectricPower

ElectricPower

Elevator System

PassengerInterfaceComponent

Elevator ControlComponent

Elevator CarsComponent

Maintenance & ServiceComponent

ConfigurationControls

DiagnosticQueries

3

xElevator Case StudyDennis Buede

George Mason Univ.

05/24/99

PROVIDE ELEVATOR SERVICESA0

In IDEF0 the mechanisms show the allocation of functions to components.

Figure 9.5

9

Derive Internal Input/Output Requirements

• For each internal item in functional architecture, derive 2 internal I/O requirements– The elevator system shall produce digitized

passenger requests. – The elevator system shall consume digitized

passenger requests.

• Associate each derived I/O requirement to the appropriate function

10

Trace System-wide Requirements

and Derive Subsystem-wide Requirements

• Trace system-wide/technology requirements to system

• For each system-wide/technology requirement, derive subsystem-wide requirements for each subsystem

• Trace each derived subsystem requirement to the appropriate subsystem

11

Technology and System-Wide Requirements and ‘Flowdown’

• We may have the following technology and system-wide requirements:

– The system shall be blue,– The system shall weigh 100 Newtons,– The system shall achieve a top speed of 80

kph.

• How are these applied to subsystems ??

12

Methods of Flowdown

– Equivalence is a simple flowdown technique that causes the subsystem requirement to be the same as the system requirement

– Apportionment spreads a system-level requirement among the system’s subsystems of the system, maintaining the same units, e.g., cost, reliability

– Synthesis addresses those situations in which the system-level requirement is comprised of complex contributions from the subsystems, causing the subsystem requirements that are flowed down from the system to be based upon some analytic model

13

Trace Trade-off Requirements and Derive Subsystem Trade-off Requirements

• Trace trade-off requirements to the system

• Derive subsystem trade-off requirements based on tracing of appropriate I/O and subsystem-wide/technology requirements

15

Trace Qualification Requirements and Derive Subsystem Qualification

Requirements

• Trace qualification requirements to system

• Derive qualification requirements for each subsystem

• Define at what point qualification will take place

• More on qualification later

16

Circuit Board

Testing

Qualification an Afterthought

17

Circuit Board

TestingQualification planned and designed

18

Define and Analyze Functional Activation

and Control Structure • Build Executable Simulation of Operational

Architecture– Use Behavior Modeling Techniques in Chapter 12– Investigate Performance & Timing Issues Related

to Requirements

• Possible Timing Concerns– Deadlock - activity halts because various activities are holding or

utilizing resources needed by other activities (see Wait for Resource Graph)

– Livelock - resources are being routed in cycles (oscillating) while waiting for the proper allocation of resources to enable the completion of necessary activities

– Starvation - function needs a particular resource for execution, but the resource is always allocated to other functions

– Surge or race - components are competing with each other to perform a task

C1

C3

C2

C4

Wait-for-Resource

Graph Depicting Deadlock

Figure 9.8

19

Conduct Performance and Risk

Analyses • Risk analysis examines the ability of the divergent

concepts to perform up to the needed level of performance across a wide range of operational scenarios

• Performance analyses are for the purpose of discovering the range of performance that can be expected from a specific design or a set of designs that are quite similar

• Trade study focuses on finding ways to improve the system’s performance on some highly important objective while maintaining the system’s capability in other objectives

20

The Big Picture

OperationalConcept

Stakeholders

Life-CyclePhase

ObjectivesHierarchy

Stakeholders

OriginatingRequirements

Life-CyclePhase

ExternalSystemsDiagramInputs &

Outputs

Inputs &Outputs

CompleteInputs &Outputs

Objectives

Validation &AcceptanceTest Scenarios

FunctionalArchitecture

PhysicalArchitecture

OperationalArchitecture

StateTransitionDiagram

DerivedRequirementsand Flowdown

Risk Analysis and

Documentation

Interfaces

21

Exercise : Class Discussion

• Review the Operational Architecture for the Elevator problem.

• Review the Operational Architecture for the ATM problem.

22

Price’s Functional Allocation Principles

1. Allocation is part of design - allocation is one part of a larger process.

2. Allocation is invention - there is no formula for allocation, imagination is crucial to the success of the process.

3. Allocation can be systematized - the inclusion of imagination and invention does not preclude formalizing allocation as a rational decision process, combining invention and systematization yields a superior result.

4. Make use of analogous technologies - building upon allocation decisions and their resulting successes and failures expands our allocation expertise.

5. Consider future technology - allocation decisions cannot be based on what exists now but must address expected advances of technology.

6. Consider human optimization (realistic system implementation) - allocation cannot be based upon idealistic expectations of how the system will be realized but should be based upon the likely capabilities of the system in its environment.

Table 9.3

23

Exercise : Class Discussion

• Review the Originating Requirements Document Outline.

Originating Requirements Document1.0 System Overview2.0 Applicable Documents3.0 Requirements

3.1 Development Phase (Programmatic) Requirements3.1.1 Input/Output Requirements for Development...3.1.4 Qualification Requirement for Development

3.2 Manufacturing Phase Requirements...

3.3 Deployment Phase Requirements...

3.4 Training Phase (if present) Requirements...

3.5 Operational Phase Requirements3.5.1 Input/Output Requirements for Operations

3.5.1.1 Input Requirements for Operations3.5.1.2 Output Requirements for Operations3.5.1.3 External Interface Requirements for Operations3.5.1.4 Functional Requirements for Operations

3.5.2 System-wide/Technology Requirements for Operations3.5.3 Trade-off Requirement for Operations3.5.4 Qualification Requirement for Operations

3.6 System Improvement/Upgrade Phase Requirements...

3.7 Retirement Phase Requirements...

3.8 Overall Trade-Off RequirementAppendix A. Operational Concepts by PhaseAppendix B. External System Diagrams by Phase

Wasson ch 41 – component selection and development

• Wasson’s key questions for making these real, final design choices:

24

25

Making the make/buy decision:

Extra Slides

• Don’t forget to look at the slide with “Fitts’ List”!

26

29

Fitts’ List: Men Are Better At, Machines Are Better At

Humans appear to surpass present- day machines with respect to the following:

Present- day machines appear to surpass humans with respect to the following:

1. Ability to detect small amounts of visual or acoustic energy.

1. Ability to respond quickly to control signals and to apply great force smoothly and precisely.

2. Ability to perceive patterns of light or sound.

2. Ability to perform repetitive, routine tasks.

3. Ability to improvise and use flexible procedures.

3. Ability to store information briefly and then to erase it completely.

4. Ability to store very large amounts of information for long periods and to recall relevant facts at the appropriate time.

4. Ability to reason deductively, including computational ability.

5. Ability to reason inductively. 5. Ability to handle highly complex operations, i.e., to do many diff erent things at once.

6. Ability to exercise judgment.

Table 9.1

30

Taxonomy of the Distribution of Responsibility between Human and Computer (after Sheridan

and Verplanck [1978])

Table 9.2

1. Human does all planning, scheduling, optimizing, etc. and turns task over to computer merely for deterministic execution.

2. Computer provides options but the human chooses between them, plans the operations, and then turns task over to computer for execution.

3. Computer helps to determine options, and suggests one for use, which human may or may not accept before turning task over to computer for execution.

4. Computer selects option and plans action, which human may or may not approve, computer can reuse options suggested by human.

5. Computer selects action and carries it out if human approves.

6. Computer selects options, plans, and actions and displays them in time for human to intervene and then carries them out in default if there is no human input.

7. Computer does entire task and informs human of what it has done.

8. Computer does entire task and informs human only if requested.

9. Computer does entire task and informs human if it believes the latter needs to know.

10. Computer performs entire task autonomously, ignoring the human supervisor who must completely trust the computer in all aspects of decisionmaking.

31

Price’s Functional Allocation Principles-27. Use cycles of hypothesis and test - like any other part of system design, we are not smart enough to do it right the first time, so build in stages of and time for iteration.

8. Provide interaction - there are three design decisions that cannot be completely separated. The engineering decision of what the physical resources of the system are, the functional allocation of which functions will be performed by each system resource, and the detailed design decision that implements the allocation. There must be interaction among these decisions during the design process.

9. Provide iteration and decomposition - do not make the allocation final too quickly.

10. Develop tools of cognitive analysis. (human-machine allocation only).

11. Assure interdisciplinary communication - involve experts from all relevant fields in the allocation process.

Table 9.3