ECE 362 Principles of Design The System Engineering

ECE 362 – Principles of Design The System Engineering Process High Level Design Environment System Copyright © 2003, International Centers for Telecommunication Technology, Inc. 1

Unit Overview • • • Inside versus outside Design decomposition, synthesis High level design is physical architecture Tracing requirements to design Detail design Host Company standard design architectural patterns Copyright © 2003, International Centers for Telecommunication Technology, Inc. 2

Inside versus outside Requirements • Statements at the external boundary – What we want the system to be or do, seen externally Environment System Copyright © 2003, International Centers for Telecommunication Technology, Inc. 3

Inside versus outside Design • Statements about internal physical components and their interaction relationships – How we are going to meet requirements Environment System Copyright © 2003, International Centers for Telecommunication Technology, Inc. 4

Inside versus outside Requirement statement Design statement Detailed requirement statement More detailed requirement. Requirements statement Environment I Design Detailed design statement More detailed Interfaces design statement I System Detail does not equal design Copyright © 2003, International Centers for Telecommunication Technology, Inc. 5

Inside versus outside Inside vs. outside, continued • Reference boundaries • One person’s design is another person’s requirement Environment System Copyright © 2003, International Centers for Telecommunication Technology, Inc. 6

Inside versus Outside In the following sections, we will refine our understanding of the meaning of “inside” and “outside”, by considering: – System boundaries and interiors (“who”) – Function boundaries and interiors (“what”) – State boundaries and interiors (“when”) Copyright © 2003, International Centers for Telecommunication Technology, Inc. 7

Uniform bookkeeping language • There is a tendency to record designs in a different language from that used to express requirements. – In particular, to record designs in technology-specific languages • This causes problems of communication and understanding across groups and job functions. – Technology-specific language can cloud the structure of a design, and obscure its connection to requirements. • Remember, what is a design for one person is a requirement for another, so language ought not shift. Copyright © 2003, International Centers for Telecommunication Technology, Inc. 8

Uniform bookkeeping language • A big surprise: High level designs can be recorded in exactly the same language as requirements: – Who: who are the internal components? – What: what are the functional interactions between these components? – When: when do these interactions occur? • This is the same language that expressed interactions of the subject system with its external environment/actors. • This improves communication and understanding. • In particular, it makes tracing external requirements to internal architecture much easier--improving everyone’s understanding. Copyright © 2003, International Centers for Telecommunication Technology, Inc. 9

Uniform bookkeeping language • This does not prevent us from recording detail designs in technology-specific languages--and we should do so; e. g. , – – electronic schematics program design mechanical drawings hydraulic schematics • But, it means that each such design should have its high level design (physical architecture) recorded in the uniform language of system engineering. – This expresses high level organization as a framework for later detail design, and across different technologies that must be integrated. – It connects design to the requirements it supports. Copyright © 2003, International Centers for Telecommunication Technology, Inc. 10

Design Decomposition • System decomposition divides a system into sub-systems: – dividing who does things; pulls apart systems • Functional decomposition divides a function into sub -functions: – dividing what gets done; pulls apart functions • State decomposition divides a state into -states: sub – dividing when things happen; pulls apart time Copyright © 2003, International Centers for Telecommunication Technology, Inc. 11

Function Allocation • Function Allocation allocates the “whats” to the “whos” and “whens”: – which sub-systems perform which function roles (who) – in which sub-states functions are to occur (when) Copyright © 2003, International Centers for Telecommunication Technology, Inc. 12

Decomposition: Synthesis and Analysis • There are infinitely many ways to divide and allocate these. • This division process is synthesis--often a creative act. – May be viewed as a kind of unfolding of the structure of the system, in three (or more) dimensions. Copyright © 2003, International Centers for Telecommunication Technology, Inc. 13

Decomposition: Synthesis vs. Analysis We check potential solutions by analysis, to see if they meet requirements. Available Technologies Customer/Market Needs Requirements Specification (“Analysis”) Design Specification (“Design”) design impacts requirement structure refinement Copyright © 2003, International Centers for Telecommunication Technology, Inc. refinement 14

Synthesis • Synthesis is challenging when there is no familiar design pattern (decomposition) that satisfies the given requirements. • Known patterns of architecture, or even known useful components, can help this process. – This can include analogy • A family pattern of architecture for the subject system can help even more: – Changes the problem from synthesis to re-use, configuration, and analysis Copyright © 2003, International Centers for Telecommunication Technology, Inc. 15

Synthesis methods • While differing in specifics, all these methods have same goals: – Establish a set of internal physical subsystems and their organizing framework of interactions – Allocation of external interactions (functional requirements) to them – Optimization of trade-offs to meet various objectives and constraints • So, even though different methods may produce different design solutions, the form of the information they produce is the same: – The high level design of the system – And allocation of requirements onto that architecture Environment System Copyright © 2003, International Centers for Telecommunication Technology, Inc. 16

Functional analysis vs. synthesis • The term “analysis” is used in two different ways: – Requirements analysis (or functional analysis): • Analyzes the functional requirements of a system, decomposing them into logical architecture that is still short of a design, but begins to hint at a design. • This is the logical architecture discussed in the Requirements unit. – Analysis of design: • After a design has been synthesized, this kind of analysis studies the characteristics of that design – e. g. , by simulation, mathematics, reasoning, constructing prototypes, etc. • These are certainly not the same thing! Copyright © 2003, International Centers for Telecommunication Technology, Inc. 17

Functional requirements • Functional requirements are the relationship between system inputs and system outputs : – In linear systems, this reduces to the system’s transfer function. – Most systems aren’t linear, but the general statement still holds for all of them. – This relationship is therefore encoded in words, tables, graphs, mathematics, fuzzy statements, and other forms. – But, it is still the formal relationship of inputs to outputs: Copyright © 2003, International Centers for Telecommunication Technology, Inc. 18

Example: PID Controller (proportional, integral, derivative) – The diagram expresses the external mathematical relationships of inputs and outputs—equivalent to a differential equation. – But, this does not say whether the result is to be obtained by allocation onto analog electronics, a DSP chip, a mechanical Bush Differential Analyzer, a block oriented simulator, nor the order of differentiation and integration around the loop. – It expresses external requirements, not internal design. Copyright © 2003, International Centers for Telecommunication Technology, Inc. 19

Implications for creative design solutions • “Thinking outside the box” has come to mean thinking of solutions to requirements that are outside of expected paradigms. • Suppose instead that you let “the box” stand for the boundary of the Subject System. • If you draw a logical architecture inside the box, you are really expressing a way of thinking about the external functional relationships. • Different decompositions suggest different design solutions when these are allocated onto physical components. • So, you can “think outside the box” (think about external relationships) by drawing inside the box! Copyright © 2003, International Centers for Telecommunication Technology, Inc. 20

High Level Design Is Architecture • Architecture is a listing of a system’s major components and relationships • Simple patterns to reduce complexity Copyright © 2003, International Centers for Telecommunication Technology, Inc. 21

Types of architecture • A single system has multiple architectures. • Each architecture is a different view of what is considered to be the major components and relationships of a system. • Each view is from a different perspective: – Example: Architecture of a building, viewed by occupant, electrical/mechanical contractor, and janitorial services contractor. Copyright © 2003, International Centers for Telecommunication Technology, Inc. 22

Types of architecture • Examples of types of architecture: – – – – Physical architecture Logical architecture Manufacturing architecture Shipping and storage architecture Service, maintenance, support architecture Embedded intelligence architecture Project architecture • “Views of Systems” Copyright © 2003, International Centers for Telecommunication Technology, Inc. 23

Conceptual Design • Generate Ideas on how to implement the PDS • Evaluate the Ideas as to which is the best way to implement the PDS Copyright © 2003, International Centers for Telecommunication Technology, Inc. 24

Detail Design • • This is type of design in the core ECE courses Decomposition is repeated in successive stages Detail Design follows High Level Design Technology-specific aspects appear: – – Electronic parts Software modules Mechanical components etc. • Where system engineering meets technology specific engineering disciplines Copyright © 2003, International Centers for Telecommunication Technology, Inc. 25

Systematica, Gestalt Rules, Return on Variation are trademarks of System Sciences, LLC. Copyright © 2003, International Centers for Telecommunication Technology, Inc. 26