ECE362 – 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
Inside versus outside
Requirement statement
Design statement
Detailed design statement
Detailed requirement statement
More detailed
requirement Requirements
statement
Environment
Design
More detailed
Interfaces design statement
I
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
sub-states:
– 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
refinement
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
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:
Input 1
Actor A
Actor B
Output X
Output Y
Subject System
Input 3
Actor C
Input 2
Domain Interaction
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.
Subject System
Proportional
K1
Operator
Differentiator
+
-
K2 * S
+
Controlled
Plant
Integrator
K3 / S
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!
Subject System
Input 1
Actor A
Output X
Logical
Role L
Logical
Role M
Output Y
Input 3
Actor C
Logical Role K
Actor B
Input 2
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
Domain Interaction
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