Download presentation
Presentation is loading. Please wait.
Published byHorace Leonard Modified over 6 years ago
1
ECE362 – Principles of Design The System Engineering Process
High Level Design For the rest of the day we’ll be talking about a specific procedure of HLR. Tuesday we’re going to cover section2 which is DR--deals with defining individual functions and section3 which covers ways to assemble all this information. System Environment
2
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
3
Requirements Inside versus outside Statements at the external boundary
What we want the system to be or do, seen externally Requirements do not describe how the system is supposed to meet requirements through its internal structure. It is merely a description of what the system must do in relation to its environment. Req are outside the system boundary A req statement for a LM could be that it “must cut grass” System Environment
4
Design Inside versus outside
Statements about internal physical components and their interaction relationships How we are going to meet requirements Design is inside the system boundary. Design statement for a LM may be that “there is a blade system that spins to cut grass” System Environment
5
Inside versus outside Inside versus outside Design Interfaces
Requirement statement Design statement Detailed requirement statement Detailed design statement More detailed requirement statement More detailed design statement Requirements Design Interfaces So req occur at the outside, design occurs inside. People like to say design has more detail than req and that’s what makes it design. But req. and design can have just as much detail. The diff between req and design is whether you are working inside or outside the system boundary. Req: cut grass, cut grass to inch, cut grass to inch meeting LMA standard 5.7 and noise standard 6.8 with only 1.3% change of cutting off a toe. Des: spinning blade cuts grass, spinningblade at x RPM cuts grass, spinning blad made of space age plastic spinning at xrpm cuts grass. Detail does not equal design. System Environment I Detail does not equal design
6
Inside vs. outside, continued
Inside versus outside Inside vs. outside, continued Reference boundaries One person’s design is another person’s requirement System Environment
7
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”)
8
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.
9
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.
10
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.
11
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 sub-states: dividing when things happen; pulls apart time
12
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)
13
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.
14
Decomposition: Synthesis vs. Analysis
We check potential solutions by analysis, to see if they meet requirements. Requirements Specification (“Analysis”) Design (“Design”) refinement design impacts requirement structure Customer/Market Needs Available Technologies
15
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
16
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 System Environment
17
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!
18
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:
19
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.
20
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!
21
High Level Design Is Architecture
Architecture is a listing of a system’s major components and relationships Simple patterns to reduce complexity
22
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.
23
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”
24
Conceptual Design Generate Ideas on how to implement the PDS
Evaluate the Ideas as to which is the best way to implement the PDS
25
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
26
Systematica, Gestalt Rules, Return on Variation are trademarks of System Sciences, LLC.
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.