1

The Engineering

Design of Systems:

Models and Methods

Wasson - Chapter 34-39

Functional Architecture Development

Edited Mar. 2013, Jul 2015

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

• HW4a: Operational utility, suitability, and effectiveness of a product for you, given the way you use it.

9

Cancelled

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 usability4. Design for single-use/multi-use applications5. Design for comfort6. Design for interoperability7. Design for transportability8. Design for mobility9. Design for maneuverability10. Design for portability11. Design for growth and expansion12. Design for reliability13. Design for availability14. Design for producibility15. Design for mission support

16. Design for deployment17. Design for training18. Design for vulnerability19. Design for lethality20. Design for survivability21. Design for efficiency22. Design for effectiveness23. Design for reconfigurability24. Design for integration, test, and evaluation25. Design for verification26. Design for maintainability27. Design for disposal28. Design for security and protection29. Design for safety

11

Ch 35 – Design To/For Objectives

• HW4a: The presumed system design objectives of the system, given what you know about it, in Wasson’s terms.

12

Cancelled

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 causes1. Inadequate system architecture selection.2. Lack of system stability during various OPERATING ENVIRONMENT conditions.3. Internal component failures due to OPERATING ENVIRONMENT conditions, surges, orlong-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

• HW4a: Try to describe the architecture of the product, as far as you can tell as a user, in Wasson’s terms.

24

Cancelled

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

• HW4a: Describe the “Entity specification requirements” in general terms.

30

Cancelled

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

MethodologyStep 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

1. ConOps acceptance2. Use case identification and priorities3. Most likely or worst-case scenarios and

conditions4. “Gaps” in operational capabilities5. “Fitness-for-use” or acceptance criteria6. 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

MethodologyStep 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 traceabilityChallenge 2: Stakeholder collaborationChallenge 3: Stakeholder reviewsChallenge 4: Critical issue risk mitigationChallenge 5: Baseline managementChallenge 6: RealismChallenge 7: Behavioral solution system descriptionChallenge 8: CWBS traceability

42