Week 6 - Systems Engineering and Analysis

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 • 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 • Model and simulate functional activation and control structure – (define some of the ‘when’) • Conduct performance and risk analysis • Document architectures and obtain approval • Document subsystem specifications

3. The Big Picture Functional Architecture Operational Architecture Physical Architecture State Transition Diagram Derived Requirements and Flowdown Interfaces Risk Analysis and Documentation

4. Buede Ch 9 starts here. Wasson Ch 41 starts on Slide 24. 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.

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 Components Integral Modular Figure 9.3

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

14. 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

15. Circuit Board Testing Qualification an Afterthought

16. Circuit Board Testing Qualification planned and designed

17. 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 Wait-for-Resource Graph Depicting Deadlock Figure 9.8

18. 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

19. The Big Picture Functional Architecture Operational Architecture Physical Architecture State Transition Diagram Derived Requirements and Flowdown Interfaces Risk Analysis and Documentation

20. Exercise : Class Discussion • Review the Operational Architecture for the Elevator problem. • Review the Operational Architecture for the ATM problem.

21. 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

22. Exercise : Class Discussion Originating Requirements Document 1.0 System Overview 2.0 Applicable Documents 3.0 Requirements 3.1 Development Phase (Programmatic) Requirements 3.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 Requirements 3.5.1 Input/Output Requirements for Operations 3.5.1.1 Input Requirements for Operations 3.5.1.2 Output Requirements for Operations 3.5.1.3 External Interface Requirements for Operations 3.5.1.4 Functional Requirements for Operations 3.5.2 System-wide/Technology Requirements for Operations 3.5.3 Trade-off Requirement for Operations 3.5.4 Qualification Requirement for Operations 3.6 System Improvement/Upgrade Phase Requirements ... 3.7 Retirement Phase Requirements ... 3.8 Overall Trade-Off Requirement Appendix A. Operational Concepts by Phase Appendix B. External System Diagrams by Phase • Review the Originating Requirements Document Outline.

23. Wasson ch 41 – component selection and development Wasson’s key questions for making these real, final design choices:

24. Making the make/buy decision:

25. Extra Slides Don’t forget to look at the slide with “Fitts’ List”!

26. Fitts’ List: Men Are Better At, Machines Are Better At Table 9.1

27. Taxonomy of the Distribution of Responsibility between Human and Computer (after Sheridan and Verplanck [1978]) Table 9.2

28. Price’s Functional Allocation Principles-2 7. 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