1 / 42

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. Ch 34 – Operational Utility.

tthompson
Download Presentation

The Engineering Design of Systems: Models and Methods

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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?

  3. 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).

  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 Cancelled HW4a: Operational utility, suitability, and effectiveness of a product for you, given the way you use it.

  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 Cancelled HW4a: The presumed system design objectives of the system, given what you know about it, in Wasson’s terms.

  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. Improper operation 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 Cancelled HW4a: Try to describe the architecture of the product, as far as you can tell as a user, in Wasson’s terms.

  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 capability-based 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 Cancelled HW4a: Describe the “Entity specification requirements” in general terms.

  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 (ConOps). 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 ConOps

  34. Domain solution development challenges ConOps acceptance Use case identification and priorities Most likely or worst-case scenarios and conditions “Gaps” in operational capabilities “Fitness-for-use” or acceptance criteria 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: Requirements traceability Challenge 2: Stakeholder collaboration Challenge 3: Stakeholder reviews Challenge 4: Critical issue risk mitigation Challenge 5: Baseline management Challenge 6: Realism Challenge 7: Behavioral solution system description Challenge 8: CWBS traceability

More Related