1 Week 6 - Systems Engineering and Analysis Buede ch 9 and Wasson ch 41 – Operational Architecture...
-
Upload
rodger-lane -
Category
Documents
-
view
216 -
download
0
Transcript of 1 Week 6 - Systems Engineering and Analysis Buede ch 9 and Wasson ch 41 – Operational Architecture...
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