The Engineering Design of Systems Models and Methods

The Engineering Design of Systems: Models and Methods Buede - Chapter 7 Functional Architecture Development Edited Mar. 2013, Jun 2015 Above – Notoriously, “Deconstructivist Architecture” both reveals how it functions, and also has weird, attention-getting features to make you question that it does what it should. 1

Process, rule based approach AT WH HOW Design, creativity, derived material 2

Why do we need the functional architecture ? ? 1. ESD is good, but we need to provide more detail to our model of the system. 2. i. e. - What goes on inside the main function? 3. Major functions provide a clearer view of architecture and interfaces. 4. Related to product architecture, modularity, and integral/modular designs. Every system has an ‘architecture’ – sometimes it is really good, sometimes really bad. M. Collins. 3

This is carving-up the system “cloud, ” top-down • A simple example – it “controls lighting”: 4

Functional Architecture-1 • The logical/functional architecture defines what the system must do - it is a decomposition or partitioning of the system’s top-level function. 5

Functional Architecture-2 • A logical model of a functional decomposition plus the flow of inputs and outputs, to which input/output requirements have been traced to specific functions and items (inputs, outputs, and controls) • A logical model that captures the transformation of inputs into outputs using control information. This definition adds the flow of inputs and outputs throughout the functional decomposition; these items that comprise the inputs and outputs are commonly modeled via a data model (see Chapter 12). • An IDEF 0 model without any mechanisms is used as the modeling technique in this chapter to represent the functional architecture at this level of detail. 6

Like Kung Fu… • This is a skill and an art. • This is where the systems engineer really provides benefit and value. Image from http: //www. pathsatlanta. org/2009/04/10/is-kung-fu-a-martial-art/ 7

Functional Architecture Process Figure 7. 1 8

Ok, how do we create this ? ? Defining Functional Partitions 1. Use operating modes 2. Use outputs 3. Use inputs & controls 4. Use Hatley-Pirbhai template – Slide 15 5. Ulrich and Eppinger – ‘Energy/Material/Signal Flows’ – Slide 17 6. Use Miller “Living Systems” template – Slides 18 - 20 9

Buede Guidelines • Decomposition/Top Down – System is an update or variation of an existing system. • Composition – System is unprecedented or radical departure of existing systems. 13

Basic Approaches or Templates • Operating Modes – a function for each operating mode ? (a software system? ) • Output – Input/Control – a function for each ? – Hatley-Pirbhai extends Input / Processing / Output – Adds user interface processing, maintenance and self-testing processing 14

Hatley-Pirbhai Template Figure 7. 2 15

Hatley-Pirbhai Decomposition Figure 7. 4 16

Energy/Material/Signal Flows Decomposition Ulrich and Eppinger 17

Living Systems Template, #1 Subsystems that Process Both Matter-Energy and Information 1. Reproducer, the subsystem that is capable of giving rise to other systems similar to the one it is in. 2. Boundary, the subsystem at the perimeter of a system that holds together the components that make up the system, protects them from environmental stresses, and excludes or permits entry to various sorts of matter-energy and information. Biomimicry or biomimetics is the examination of nature, its models, systems, processes, and elements to emulate or take inspiration from in order to solve human problems. Table 7. 1 18

Living Systems Template, #2 Subsystems that Process Matter-Energy 3. Ingestor, the subsystem which brings matter-energy across the system boundary from the environment. 4. Distributor, the subsystem that carries inputs from outside the system or outputs from its subsystems around the system to each component. 5. Converter, the subsystem that changes certain inputs to the system into forms more useful for the special processes of that particular system. 6. Producer, the subsystem that forms stable associations that endure for significant periods among matter-energy inputs to the system or outputs from its converter, the materials synthesized being for growth, damage repair, or replacement of components of the system, or for providing energy for moving or constituting the system’s outputs of products or information markers to its suprasystem. 7. Matter-energy storage, the subsystem that retains in the system, for different periods of time, deposits of various sorts of matter-energy. 8. Extruder, the subsystem that transmits matter-energy out of the system in the forms of products or wastes. 9. Motor, the subsystem that moves the system or parts of it in relation to part or all of its environment or moves components of its environment in relation to each other. 10. Supporter, the subsystem that maintains the proper spatial relationships among components of the system, so that they can interact without weighting each other down or crowding each other. Table 7. 1 19

Living Systems Template, #3 Subsystems that Process Information 11. Input transducer, the sensory subsystem that brings markers bearing information into the system, changing them to other matter-energy forms suitable for transmission within it. 12. Internal transducer, the sensory subsystem that receives, from subsystems or components within the system, markers bearing information about significant alterations in those subsystems or components, changing them to other matter-energy forms of a sort which transmitted within it. 13. Channel and net, the subsystem composed of a single route in physical space, or multiple interconnected routes, by which markers bearing information are transmitted to all parts of the system. 14. Decoder, the subsystem that alters the code of information input to it through the input transducer or internal transducer into a “private” code that can be used internally by the system. 15. Associator, the subsystem that carries out the first stage of the learning process, forming enduring associations among items of information in the system. 16. Memory, the subsystem that carries out the second stage of the learning process, storing various sorts of information in the system for different periods of time. 17. Decider, the executive subsystem that receives information inputs from all other subsystems and transmits to them information outputs that control the entire system. 18. Encoder, the subsystem that alters the code of information input to it from other information processing subsystems, from a “private” code used internally by the system into a “public” code which can be interpreted by other systems in its environment. 19. Output transducer, the subsystem that puts out markers bearing information from the system, changing markers within the system into other matter-energy forms which can be transmitted over channels in the system’s environment. Table 7. 1 20

Some Examples !! • Elevator • Google • Exercises: – – Machine monitor That pesky lawn mower A few more examples Your choice 21

Elevator Example - ESD 22

23

Elevator Functional Decomposition ( ) around arrow head = tunneling (page 72) 24

How did we get here ? • Create an IDEF 0 block diagram with all the H-P blocks • Which ones do we need? • Which ones to combine ? • Do this mentally. 25

IDEF 0 Page Structure Page Number(s) A-1 A-0 A 1, A 2, . . . A 11, A 12, . . . , A 21, . . . Figure 3. 5; Table 3. 2 Page Content Ancestor or external system diagram Context or system function diagram (contains A 0) Level 0 diagram with first tier functions specified Level 1 diagrams with second tier functions specified Level 2 diagrams with third tier functions specified … 26

27

Google • Build it yourself. • Do for everything: – – – Parallelize Distribute to atomic level Compress Secure Cache Make redundant 28

The Exterior Picture 29

Physical Architecture 30

Data Center 31

Rack 32

O/S 33

The Interior Network 34

Major Glue 35

Google • “Latency is evil” • Slides from talk by Ed Austin, 2009: http: //www. slideshare. net/hasanveldstra/t he-anatomy-of-the-google-architecturefina-lv 11. • See also http: //highscalability. com/googlearchitecture for links 36

Exercise - Lawnmower • Create two simple scenarios – Start-up – Cutting grass • Create two system properties – Convert from ‘customer wants’ to ‘engineering specifications’ via the House of Quality • Create an ESD from the scenarios • Create a first level decomposition using either – Hatley-Pirbhai –or– Energy-Materials-Flows 38

39 How about – design it by considering constraints?

Exercise : Pick a System • Create simple External Systems Diagram • Show top level function • Create first level decomposition • What’s a good software example to use? Try Energy/Material/Signal Flows? 40

Exercise : Cooking Wok • Use ‘Energy, Materials, Signal Flows’ to model the wok. 41

Exercise : ATM Manufacturing • We work for the Acme ATM Manufacturing Company. Develop a Systems Engineering model for the manufacturing system for an ATM. • Identify a scenario, external systems, and create the External Systems Diagram. • Decompose one level. 42

Exercise : Vehicle Security System • Develop a Systems Engineering functional model for a vehicle security system. • Identify external systems and create the External Systems Diagram and decompose one level. 43

44

Checklist approach? Evaluation of Functional Hierarchy • Shortfalls – absence of functionality – Absence of functionalities for input set – Inability to produce desired output – Insufficient feedback/control to produce desired output • Overlaps – redundancy in functionality • Evaluation technique – scenario tracing. • Feedback needed ? • Rules Followed ? • BIST and Fault Tolerance functionality ? 45

Scenario Tracing, #1 Figure 7. 7 46

Scenario Tracing, #2 Figure 7. 8 ‘Internal’ I/O become derived requirements 47

Scenario Tracing, #3 Figure 7. 9 48

Scenario Tracing, #4 Figure 7. 10 49

Scenario Tracing, #5 Figure 7. 11 50

Scenario Tracing, #6 Figure 7. 12 51

Feedback & Control in Functional Design Figure 7. 5 52

Feedback Control in Operational Architecture Development Figure 7. 6 53

Common Mistakes-1 1. Including the external systems and their functions. The functional architecture only addresses the top-level function of the system in question. The external system diagram establishes the inputs, controls, and outputs for this function. A boundary has been drawn around the system to exclude the external systems and their functions. 2. Choosing the wrong name for a function. The function name should start with an action verb and include an object of that action. The verb should not contain an objective or performance goal such as maximize, but should describe an action or activity that is to be performed. 54

Common Mistakes-2 3. Including a verb phrase as part of the inputs, controls, or outputs of a function. Verb phrases are reserved for functions. 4. Violating the law of conservation of inputs, controls, and outputs. That is, every input, control, and output of a particular function must appear on the decomposition of that function, and there can be no new ones. 5. Creating outputs from thin air. The most common mistake is to define a function that monitors the system’s status but that does not receive inputs about the functioning or lack of functioning of other parts of the system. 55

Common Mistakes-3 6. Creating a decomposition of a function that is not a partition of that function. For example, a student once decomposed “A 0: Provide Elevator Services” into “A 1: Transport Users, ” “A 2: Evaluate System Status, ” and “A 3: Perform Security & Maintenance Operations. ” “A 1: Transport Users” was then decomposed as follows: “A 11: Provide Access to Elevator, ” “A 12: Transport Users, ” and “A 13: Provide Emergency Operations. ” A 12 cannot be a child of itself. The subfunctions of a function should all be at the same level of abstraction [Chapman et al. , 1992]. 7. Trivializing the richness of interaction between the functions that decompose their parent. Consider many possible simple functionalities that comprise the children of a parent function and then develop the inputs, controls, and outputs that enable these simple functionalities to exist, including the necessary feedback and control. 56

Finishing the Functional Architecture • Inserting functionality to detect – – Errors – Failure Modes • Inserting functionality for – – – Built in self test Testability Maintainability Serviceability 57

Definitions from Fault Tolerance System: an identifiable mechanism that maintains a pattern of behavior at an interface between the system and it environment [Anderson and Lee, 1981]. Failure: deviation in behavior between the system and its requirements. Since the system does not maintain a copy of its requirements, a failure is not observable by the system. Error: a subset of the system state, which may lead to a failure. The system can monitor its own state, so errors are observable in principle. Failures are inferred when errors are observed. Since a system is usually not able to monitor its entire state continuously, not all errors are observable. As a result, not all failures are going to be detected (inferred). Fault: a defect in the system that can cause an error. Faults can be permanent (e. g. , a failure of system component that requires replacement) or temporary due to either an internal malfunction or external transient. Temporary faults may not cause a sufficiently noticeable error or may cause a permanent fault in addition to a temporary error. 58

Fault Tolerance Functions • Error detection • • – Data – range, type, structure – Timing – real-time systems – Physical errors Damage confinement Error recovery Fault isolation and reporting Built in self test - BIST Examples ? ? 59

Examples from Montronix • Data – User input, range checking. • Sensor Inputs – range checking. • Memory – validity, checksums, check errors on power up. • Timing – A/D converter speed variations, number of channels, algorithm complexity. • BIST software, hardware functionality on power up, loopback tests, test stations. 60

Traceability • All I/O on scenarios must trace to corresponding functional representations and input/output requirements • All ‘customer wants’ generally trace to technology and system-wide requirements. 61

Tracing Requirements Figure 7. 13 62

Tracing Requirements I/O Requirements Also, all I/O requirements must be qualified From last time 63

Additional Decomposition Examples • ATM Machine 64

65

66