The Engineering Design of Systems Models and Methods

The Engineering Design of Systems: Models and Methods Wasson - Chapter 34 -39 Functional Architecture Development Edited Mar. 2013, Jul 2015 1

Ch 34 – Operational Utility 1. If we invest in the development of this system, product or service, will it have UTILITY to the User in accomplishing their organizational missions? 2. If the system has UTILITY, will it be SUITABLE for the User’s mission application(s) and integrate easily into their business model? 3. If the system has UTILITY and is SUITABLE for the application, will it be operationally AVAILABLE to perform the mission when tasked? 4. If the system has UTILITY to the organization, is SUITABLE for the application, and is AVAILABLE to perform its mission when tasked, will it be EFFECTIVE in performing mission and accomplishing mission objectives with a required level of success? 2

Technical Performance Measures (TPMs) • Most engineers are not trained to understand WHAT a TPM is, HOW it originates, and WHY TPMs are important—an organizational management and training system failure. • The Lead Systems Engineer (LSE) and the System Engineering and Integration Team (SEIT) that oversee the technical program have not performed their job of linking lower level TPMs to critical MOEs (measures of effectiveness) and MOSs (measures of suitability). 3

4

How good are our TPMs? 5

Wasson’s TPM Challenges • Bureaucratic Metrics Tracking • Select TPMs Wisely – vs randomly from requirements • Withholding TPM Data • TPM “Shelf Life” • TPM Reporting – Internal vs external, and political agendas 6

Typical project for MOE’s and TPM’s • Oak Creek power plant, just fired up… 7

So, are these an improvement over Agile? • Where we let the designated Product Owner pick, at will, what they want us to do next, without any particular system? • Which would work best, for a large, complex system? – Structured priority selection, like with MOE’s and TPM’s, or – Unstructured, like we do 8

Ch 34 – Operational Utility • HW 4 a: Operational utility, suitability, and effectiveness of a product for you, given the way you use it. d n a C e l l ce 9

Ch 35 – Design To/For Objectives • When SEs engineer systems, the general mindset is to propose and develop solutions that solve User solution spaces within problem spaces. • The problem with this mindset is that it lacks a central focal point that captures WHAT the User needs or seeks. 10

All the “design for” objectives… 1. Design to value (DTV) 2. Design to cost (DTC) 3. Design for usability 4. Design for single-use/multi-use applications 5. Design for comfort 6. Design for interoperability 7. Design for transportability 8. Design for mobility 9. Design for maneuverability 10. Design for portability 11. Design for growth and expansion 12. Design for reliability 13. Design for availability 14. Design for producibility 15. Design for mission support 16. Design for deployment 17. Design for training 18. Design for vulnerability 19. Design for lethality 20. Design for survivability 21. Design for efficiency 22. Design for effectiveness 23. Design for reconfigurability 24. Design for integration, test, and evaluation 25. Design for verification 26. Design for maintainability 27. Design for disposal 28. Design for security and protection 29. Design for safety 11

Ch 35 – Design To/For Objectives • HW 4 a: The presumed system design objectives of the system, given what you know about it, in Wasson’s d terms. n a C e l l ce 12

Ch 36 – Sys Architecture 1. What is a system architecture? 2. What are the key attributes of an architecture? 3. What are the primary architectural views of a system? 4. Define the semantics of architectures. 5. What is centralized control processing architecture? 6. What is decentralized control processing architecture? 7. What is distributed processing architecture? 8. What is a fault tolerant architectural design? 9. What are some architectural power system considerations? 10. What are some architectural environmental, safety, and health (ES&H) considerations? 11. What are some fire detection and suppression architectural configuration considerations? 12. What are some security and protection architectural considerations? 13

Ch 36 – Sys Architecture 14

Presentation Methods 15

Stakeholder Views 16

Arch Elements 17

Viewpoints and Views 18

Element Relationships 19

Centralized vs Decentralized 20

Fault tolerance – flaw causes 1. Inadequate system architecture selection. 2. Lack of system stability during various OPERATING ENVIRONMENT conditions. 3. Internal component failures due to OPERATING ENVIRONMENT conditions, surges, or long-term effects. 4. Latent defects due to improper or inadequate testing. 5. Faulty control logic. 6. Unknown modes and states. 7. Preoccupation with trivial, molecular level computation processing. 8. Poor work practices. 9. Improperation results from abuse, misuse, or misapplication of the system or product. 10. Physical breaks in resource or data communications interfaces or supplies. 11. Lack of preventive and corrective maintenance. 21

Types of Redundancies • Goal – avoid Single Points of Failure (SPFs) • Architectural configuration: – Operational redundancy – Cold or standby redundancy – K-out-of-n systems redundancy – includes “voted k out of n redundancy” • Redundancy implementation approaches: – Like redundancy configuration – Unlike redundancy configuration 22

Architecture Lessons Guidepost 36. 4 The development of a system architecture requires more than simply innovation and creation, it also requires other architectural considerations: 1. Compliance with local, state, federal, and international statutes and regulations. 2. Sustainment of resources. 3. Recognition of the cause and effect the architecture has on the public and the environment. 23

Ch 36 – Sys Architecture • HW 4 a: Try to describe the architecture of the product, as far as you can tell as a user, in Wasson’s terms. d n a C e l l ce 24

Ch 37 – Entity Requirements Domain Specs 1. WHAT capabilities and performance characteristics are required from the system, product, or service. 2. WHAT levels of performance are expected—and HOW WELL. 3. System element accountability for accomplishing capabilitybased requirements. 4. WHEN the capability is required. 5. Under WHAT OPERATING ENVIRONMENT conditions and interactions. 6. WHAT outcomes or results are expected to satisfy the User’s operational needs and successfully achieve the system and mission objectives. 25

Requirements demand proof! The objectives of the Requirements Domain Solution development activity are to: 1. Accurately, precisely, consistently, and completely bound the solution space and identify the required capabilities—the functions and performance, and characteristics required to satisfy the User’s (contextual role) validated operational need(s). 2. Provide objective evidence as a work product to support entity verification and formal acceptance. 26

And balance… • Each requirement has a cost to implement within contract or task cost and schedule performance measurement baseline constraints. • If any requirement is not traceable back to a source or originating requirement, either eliminate the requirement or renegotiate cost and schedule constraints and replan the effort. 27

Methodology Step 1: Understand the problem and solution space(s). Step 2: Capture and bound entity requirements. Step 3: Analyze and reconcile entity specification requirements. Step 4: Derive and assimilate entity capabilities. Step 5: Resolve requirements issues and clarifications. Step 6: Verify and validate the Requirements Solution. Step 7: Establish and maintain a Requirements Solution baseline. 28

Mapping to capabilities 29

Ch 37 – Entity Requirements Domain Specs • HW 4 a: Describe the “Entity specification requirements” in general terms. d e l l e c n a C 30

Ch 38 – Entity Operational Domain Solution Step back to look at the domain your system of interest (SOI) will operate in: 1. What is the objective of the Operations Domain Solution? 2. What are the key elements of the Operations Domain Solution? 3. What is the relationship of the Operations Domain Solution to the SE Process Model? 4. What is the relationship of the Operations Domain Solution with the Requirements, Behavioral, and Physical Domain Solutions? … 31

Sample operating environment 32

Methodology Step 1: Conduct a mission analysis. Step 2: Identify system elements and actors. Step 3: Develop actor-based operational architecture. Step 4: Develop system operations workflow sequences. Step 5: Allocate mission operations to phases of operation. Step 6: Establish the Mission Event Timeline (MET). Step 7: Translate mission operations into system use cases and scenarios. Step 8: Identify the system modes and states of operation. Step 9: Derive system capabilities from use cases and scenarios. Step 10: Develop the system Concept of Operations (Con. Ops). Step 11: Resolve critical operational and technical issues (COIs/CTIs) and risks. Step 12: Verify and validate operational solution. Step 13: Establish and maintain the Baseline Concept Description (BCD). 33

Step 10: Developing Con. Ops 34

Domain solution development challenges 1. Con. Ops acceptance 2. Use case identification and priorities 3. Most likely or worst-case scenarios and conditions 4. “Gaps” in operational capabilities 5. “Fitness-for-use” or acceptance criteria 6. Performance timeline(s) 35

Ch 39 – Entity Behavioral Domain Solution 1. HOW the system is expected to react and respond to operator and external stimuli. 2. HOW WELL the responses are to be performed. 36

How the system reacts or responds 1. Communicates via one or more interactions. 2. Is bounded by at least one or more performance budgets and safety margins. 37

Logical/Functional Architecture Development Methodology Step 1: Identify logical objects or entities. Step 2: Identify each entity’s capabilities. Step 3: Create a logical interactions matrix. Step 4: Create the logical/functional architecture. 38

A logical/functional arch 39

The N x N Matrix 40

OO Representation 41

Behavioral domain solution development challenges Challenge 1: Challenge 2: Challenge 3: Challenge 4: Challenge 5: Challenge 6: Challenge 7: description Challenge 8: Requirements traceability Stakeholder collaboration Stakeholder reviews Critical issue risk mitigation Baseline management Realism Behavioral solution system CWBS traceability 42