Академический Документы
Профессиональный Документы
Культура Документы
Abstract
This introductory course sketches all fundamentals of Systems Engineering. Starting
at the business contexts, touching Project, Processes, and Organization. The
role of the Systems Engineer is discussed, and the relation with other roles, e.g.
project leader and product manager. The architecting and design tools are shown;
from Stakeholder Needs to Requirements to Modeling and Analysis.
Distribution
This article or presentation is written as part of the Gaud
project. The Gaud project philosophy is to improve
by obtaining frequent feedback. Frequent feedback is
pursued by an open creation process. This document
is published as intermediate or nearly mature version to
get feedback. Further distribution is allowed as long as
the document remains complete and unchanged.
introduction to SE,
process, organization
day 1
March 6, 2013
status:
preliminary
draft
version: 0.2
day 2
day 3
capturing customer
understanding
system context
system design
day 4
morning
introduction to SE,
process, organization
morning
system context
day 1
afternoon
day 2
afternoon
system design
version: 0.2
March 6, 2013
SEINTROprogram2day
Abstract
The fundamental concepts and approach to project oriented Systems Engineering
are explained. We look at project phasing, phase transition, processes, and
organization.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
March 6, 2013
status:
preliminary
draft
version: 0.1
order
design and
engineering
tender
offer
installation
operation and
maintenance
acceptance
final payment
disposal
order
design and
engineering
tender
offer
installation
operation and
maintenance
acceptance
final payment
version: 0.1
Project Systems Engineering Introduction; Phasing, Process, Organization
March 6, 2013
PSEIPprojectLifeCycle
4
Gerrit Muller
disposal
2.
system
design
3.
engineering
installation
4.
integration
& test
operation and
maintenance
5.
field
monitoring
needs
specification
design
verification
engineering
Legend:
core information
in draft
full under development
50%
most information
available in
concept
version: 0.1
March 6, 2013
PSEIPphases
information is stable
enough to use
heavier change control
V-Model
needs
validation
specification
verification
system design
system test
subsystem design
component design
subsystem test
component test
component realization
version: 0.1
March 6, 2013
TPSEPvModel
0.
feasibility
1.
definition
2.
system
design
3.
engineering
4.
integration
& test
sales
logistics
production
service
development & engineering:
version: 0.1
Project Systems Engineering Introduction; Phasing, Process, Organization
March 6, 2013
PCPbusinessPhases
7
Gerrit Muller
5.
field
monitoring
test and
evaluate
requirements
specification
2% of budget (EVO)
2 weeks (XP)
up to 2 months
per cyclus
build
design
version: 0.1
March 6, 2013
PCPspiral
design and
engineering
reuse
spec
s
design and
engineering
tender
operation and
maintenance
installation
operation and
maintenance
reuse
produ
cts
reuse
spec
s
tender
installation
reuse
produ
cts
tender
design and
engineering
installation
operation and
maintenance
disposal
version: 0.1
Project Systems Engineering Introduction; Phasing, Process, Organization
March 6, 2013
PSEIPreuseAndProducts
9
Gerrit Muller
disposal
disposal
customer oriented
(sales,
service, production) process
val
ue
process
product creation
process
version: 0.1
Project Systems Engineering Introduction; Phasing, Process, Organization
March 6, 2013
RSPprocessDecomposition
10
Gerrit Muller
fee
bac d
k
supplying business
strategy
customer oriented
val
u
process
short term;
cashflow!
product creation
mid term;
cashflow
next year!
long term
know how
(soft) assets
version: 0.1
Project Systems Engineering Introduction; Phasing, Process, Organization
March 6, 2013
RSPprocessDecompositionAnnotated
11
Gerrit Muller
policy and
planning
tender
contract
project
execution
systems architecting
systems
deployment
products or
components
product creation
version: 0.1
March 6, 2013
PPSprojectProcess
Design
Control
Marketing
profitability
saleability
technical
customer input
needs
what is needed
customer expectations
specification
what will be realized
commercial structure
design
how to realize
verification
meeting specs
following design
engineering
how to produce
and to maintain
product pricing
market introduction
introduction at customer
feedback
version: 0.1
March 6, 2013
PCPDecomposition
entire
portfolio
product
family
single
product
subsystem
module
technical
portfolio
operational
manager
portfolio
architect
family
operational
manager
project
leader
project
leader
marketing
manager
family
marketing
manager
product
product
manager
architect
subsystem
portfolio
family
architect
(single product)
commercial
subsystem
architect
developers
version: 0.1
Project Systems Engineering Introduction; Phasing, Process, Organization
March 6, 2013
PCPoperationalOrganization
14
Gerrit Muller
Specification
Q uality
Resources
Time
version: 0.1
Project Systems Engineering Introduction; Phasing, Process, Organization
March 6, 2013
PCPoperationalTriangle
15
Gerrit Muller
business management
define project
update project
project leader
assess risks
determine feasibility
accept
execute project
within normal
quality rules
version: 0.1
Project Systems Engineering Introduction; Phasing, Process, Organization
March 6, 2013
PCPoperationalGame
16
Gerrit Muller
Operational Teams
Sales
Manager
Application
Manager
Requirements
Analyst
Operational Support
(project manager)
Marketing or
Product Manager
Operational Leader
(project leader)
Architect
Test Engineer
Service
Logistics
Quality
Assurance
TechnologySpecific
Architects
Subsystem
Operational
Leaders
Subsystem
Architects
Development
support
version: 0.1
Project Systems Engineering Introduction; Phasing, Process, Organization
March 6, 2013
PCPconcentricTeams
17
Gerrit Muller
Manufacturing
use results
functional
capability
capability management
technical
capability
facility management
expert support
initial production
customer support
factory
performance-based
or service-level
agreement
conventional
maintenance
contract
product
acceptance
and warranty
version: 0.1
Project Systems Engineering Introduction; Phasing, Process, Organization
March 6, 2013
PPSservicesOperationalModel
18
Gerrit Muller
Abstract
The role and the task of the system architect are described in this module.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
March 6, 2013
status:
preliminary
draft
version: 1.0
Abstract
The role of the system architect is described from three viewpoints: deliverables,
responsibilities and activities. This description shows the inherent tension in this
role: a small set of hard deliverables, covering a fuzzy set of responsibilities,
hiding an enormous amount of barely visible day-to-day work.
Blah
Blah
V4aa
Idea
Distribution
March 6, 2013
status: concept
version: 2.0
listen, talk,
walk around
design,
assist project leader
brainstorm, with work breakdown,
explain
schedule, risks
Spec
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
think,
analyze
IO
Report
Design
test,
integrate
write,
consolidate,
browse
present,
meet, teach,
discuss
read,
review
travel to
customer,
supplier,
conference
provide
vision and
leadership
Report
Report
Report
Design
Design
Design
Spec
Spec
Spec
version: 2.0
March 6, 2013
RSAdeliverables
List of Deliverables
(what is needed)
version: 2.0
March 6, 2013
RSAdeliverablesSpecific
ua
Function
lity
module
modules
subsystem
system
Balance
Consistency
KISS
Elegance
Simple
Decomposition
Integration
system
Overview
satisfied
stakeholders
context
Integrity
Fitting
version: 2.0
March 6, 2013
RSAresponsibilities
responsibility
primary owner
business manager
schedule, resources
project leader
market, salability
marketing manager
technology
technology manager
process, people
line manager
detailed designs
engineers
version: 2.0
March 6, 2013
RSAsecondaryResponsibilities
V4aa
Idea
think,
analyze
IO
listen, talk,
walk around
design,
assist project leader
brainstorm, with work breakdown,
explain
schedule, risks
Spec
Report
Design
test,
integrate
write,
consolidate,
browse
present,
meet, teach,
discuss
read,
review
travel to
customer,
supplier,
conference
version: 2.0
March 6, 2013
RSAactivities
provide
vision and
leadership
Quantity
consolidation
in
deliverables
driving views
per year
(order-ofmagnitude)
10
shared issues
10 2
touched details
10 4
architect
time per
item
100 h
1h
meetings
informal
contacts
sampling
scanning
seen details
10 5
10 6
product details
10 7
10 10
real-world facts
The Role and Task of the System Architect
26
Gerrit Muller
0.5
10 min
0.1
1 sec
infinite
version: 2.0
March 6, 2013
RSAdetailHierarchy
Reality or Virtuality?
version: 2.0
March 6, 2013
Spec
Spec
Spec
Report
Requirement
Spec
Design
Realization
ua
lity
Design
Design
Design
Functio
n
Report
Report
Deliverables
Responsibilities
KISS
module
subsystem
Decreasing
Visibility
modules
system
Bla Bla
Idea
V4aa
Spec
IO
Report
Design
version: 2.0
March 6, 2013
RSApyramid
Activities
Abstract
The typical phases of a system architect development are described, beginning
at the fundamental technology knowledge, with a later broadening in technology
and in business aspects. Finally the subtlety of individual human beings is taken
into account.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
March 6, 2013
status: concept
version: 1.1
root
technical
knowledge
generalist
technical
knowledge
business,
application insight
process insight
psychosocial
skills
root
technical
knowledge
generalist
technical
knowledge
business,
application insight
process insight
version: 1.1
March 6, 2013
MATsystemArchitectGrowth
psychosocial
skills
specialist
depth of
knowledge
generalist
root
knowledge
version: 1.1
March 6, 2013
MATgeneralistVsSpecialist
version: 1.1
March 6, 2013
MATcomplementaryExpertises
specialist
specialist
specialist
specialist
specialist
specialist
specialist
depth of
knowledge
specialist
generalist
generalist
all-round specialist
specialist
depth of
knowledge
breadth of
knowledge
systems architect
aspect
architect
root
knowledge
version: 1.1
March 6, 2013
MATfromSpecialistToSystemArchitect
Abstract
A system architects needs skills to apply different interactions styles, depending
on the circumstances. This document discusses the following interaction styles:
provocation, facilitation, leading, empathic, interviewing, white board simulation,
and judo tactics.
provocation
facilitation
Distribution
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
leading
March 6, 2013
status: draft
version: 0.2
empathic
interviewing
whiteboard simulation
judo tactics
Architecting Styles
when in an impasse: provoke
effective when used sparsely
provocation
facilitation
leading
empathic
interviewing
whiteboard simulation
judo tactics
version: 0.2
March 6, 2013
ASstyles
version: 0.2
March 6, 2013
MRSAexercise
Responsibilities
Requirement
Spec
Design
Realization
Function
ua
lity
module
modules
subsystem
system
Balance
Report
Report
Design
Design
Design
Spec
Spec
Spec
Report
Daily Activities
KISS
Elegance
Simple
system
design,
assist project leader
brainstorm, with work breakdown,
explain
schedule, risks
present,
meet, teach,
discuss
consolidation
in
deliverables
Fitting
Spec
Report
read,
review
travel to
customer,
supplier,
conference
sampling
scanning
provide
vision and
leadership
architect
time per
driving views
per year
(order-ofmagnitude)
10
shared issues
10 2
1h
touched details
10 4
item
100 h
meetings
informal
contacts
Design
write,
consolidate,
browse
satisfied
stakeholders
Quantity
IO
listen, talk,
walk around
Overview
context
Integrity
V4aa
Idea
test,
integrate
Decomposition
Integration
Blah
Blah
think,
analyze
Consistency
seen details
10 5
10 6
product details
10 7
10 10
real-world facts
version: 0.2
March 6, 2013
infinite
0.5
10 min
0.1
1 sec
psychosocial
skills
Complementary Roles
specialist
business,
application insight
generalist
technical
knowledge
depth of
knowledge
root
technical
knowledge
generalist
root
knowledge
Role Spectrum
breadth of
knowledge
specialist
depth of
knowledge
specialist
specialist
specialist
specialist
specialist
specialist
specialist
depth of
knowledge
specialist
generalist
generalist
all-round specialist
breadth of
knowledge
systems architect
aspect
architect
root
knowledge
version: 0.2
March 6, 2013
Module Requirements
by Gerrit Muller
Buskerud University College
e-mail: gaudisite@gmail.com
www.gaudisite.nl
Abstract
This module addresses requirements: What are requirements? How to find,
select, and consolidate requirements?
Distribution
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
March 6, 2013
status: concept
version: 1.3
Abstract
Requirements engineering is one of the systems engineering pillars. In this document
we discuss the fundamentals of systems engineering, such as the transformation
of needs into specification, the need to prescribe what rather than how, and the
requirements when writing requirements.
interfaces
Distribution
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
inputs
March 6, 2013
status: concept
version: 0.1
functions
quantified characteristics
restrictions, prerequisites
boundaries, exceptions
standards, regulations
outputs
Definition of Requirement
Requirements describing the needs of the customer:
Customer Needs
Requirements describing the characteristics of the
final resulting product: Product Specification
The requirements management process recursively
applies definition 2 for every level of decomposition.
Requirements describing the needs of the company
itself over the life cycle: Life Cycle Needs
version: 0.1
March 6, 2013
REQdefinition
Flow of Requirements
What
choices
trade-offs
negotiations
customer needs:
What is needed by the customer?
What
product specification:
What are we going to realize?
How
system design:
How are we going to realize the product?
up to "atomic" components
version: 0.1
March 6, 2013
REQwhatWhatHow
functions
quantified characteristics
outputs
restrictions, prerequisites
boundaries, exceptions
standards, regulations
Fundamentals of Requirements Engineering
43
Gerrit Muller
version: 0.1
March 6, 2013
REQsystemAsBlackBox
(business, marketing,
operational managers)
Customer-Oriented Process
version: 0.1
March 6, 2013
REQstakeholders
Specific
Unambiguous
Verifiable
Quantifiable
Measurable
Complete
Traceable
version: 0.1
March 6, 2013
REQrequirementsForRequirementsList
Accessible
Understandable
Low threshold
version: 0.1
March 6, 2013
REQrequirementsFromHumans
Abstract
The basic CAFCR reference model is described, which is used to describe
a system in relation to its context. The main stakeholder in the context is the
customer. The question Who is the customer? is addressed.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
March 6, 2013
status: draft
version: 0.4
Customer
How
Customer
Application
objectives
Product
What
Functional
Product
How
Conceptual
Realization
Customer
How
Customer
Application
objectives
Product
How
Product
What
Functional
Conceptual
version: 0.4
March 6, 2013
CAFCRannotated
Realization
Integrating CAFCR
What does Customer need
in Product and Why?
Customer Customer
What
How
Customer
Application
Product
How
Product
What
Functional
Conceptual
context
intention
objective
opportunities
constraint knowledge
objectives
understanding
awareness
driven
based
version: 0.4
March 6, 2013
MSintegratingCAFCR
Realization
Consumer
Enables
Drives
Customer's
Customer
Business
larg
Va
infl er sco lue C Enables
uen
hai
p
e
n
ce
h
on as s
arc ma
hite ller
ctu
re
Drives
Customer
Business
Enables
version: 0.4
March 6, 2013
CAFCRrecursion
Drives
System
(producer)
Market segmentation
segmentation
axis
examples
geographical
business model
economics
consumers
youth, elderly
outlet
version: 0.4
March 6, 2013
BCAFCRcustomerSegmentation
CFO
CIO
CMO
CEO CTO
decision maker(s)
purchaser
maintainer
operator
version: 0.4
March 6, 2013
BCAFCRwhoIsTheCustomer
Customer
Application
Functional
Conceptual
operations
maintenance
upgrades
Life cycle
development
manufacturing
installation
objectives
version: 0.4
March 6, 2013
BCAFCRplusLifeCycle
Realization
Abstract
The notion of business key drivers is introduced and a method is described to
link these key drivers to the product specification.
Key-drivers
Safety
Distribution
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
Effective
Flow
March 6, 2013
status: draft
version: 0.2
Improve emergency
response
Reduce delay due to accident
Improve average speed
Improve total network throughput
Optimize road surface
Speed up target groups
Anticipate on future traffic condition
Smooth
Operation
Ensure traceability
Environment
Reduce emissions
Requirements
Automatic upstream
accident detection
Weather condition
dependent control
Effective
Flow
Improve emergency
response
Reduce delay due to accident
Improve average speed
Improve total network throughput
Optimize road surface
Speed up target groups
Smooth
Operation
Automatic upstream
accident detection
Weather condition
dependent control
Deicing
Traffic condition
dependent speed control
Ensure traceability
Ensure proper alarm handling
Ensure system health and fault indication
Environment
Requirements
Reduce emissions
version: 0.2
March 6, 2013
COVmotorwayManagementKeyDrivers
in terms of
market segments
or
extract
and ask
Obtain feedback
stakeholder
requirements
multiple drivers
where
may have
discuss with
customers , observe
their
reactions
version: 0.2
March 6, 2013
TCAFkeyDriverSubmethod
minimal
for instance the well-known
main function
3 , maximal 6
of the product
create clear
version: 0.2
March 6, 2013
TCAFkeyDriverRecommendations
goal means
relations
Customer
How
Product
What
Customer
Application
Functional
Key
(Customer)
Drivers
Derived
Application
Drivers
Requirements
objectives
goal
means
may be skipped or
articulated by several
intermediate steps
functions
interfaces
performance figures
version: 0.2
March 6, 2013
REQfromDriverToRequirement
Abstract
An elicitation method for needs is described using many different viewpoints. A
selection process with a coarse and a fine selection is described to reduce the
specification to an acceptable and feasible subset.
top-down
key-drivers
(customer, business)
operational drivers
roadmap
competition
Distribution
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
March 6, 2013
status: draft
version: 0
regulations
"ideal" reference design
prototyping, simulation
(learning vehicle)
bottom-up
(technological opportunities)
existing systems
bottom-up
Needs
Continued
Product Creation
Process
Feedback
key-drivers
(customer, business)
operational drivers
roadmap
competition
regulations
"ideal" reference design
prototyping, simulation
(learning vehicle)
bottom-up
Continued
Product Creation
Process
Needs
Feedback
(technological opportunities)
existing systems
bottom-up
version: 0
March 6, 2013
REQviewpoints
strategy
roadmap
competition
product specification
customer needs
selection process
operational needs
need
characterization
requirement
phasing
version: 0
March 6, 2013
REQselection
discuss
do
don't
discuss
effort
important
don't
discuss
discuss
do
urgent
value
version: 0
March 6, 2013
REQqualitativeSelectionMatrix
March 6, 2013
MPBAvalueCriteria
version: 0
March 6, 2013
MREQexercise
Story How To
by Gerrit Muller
Buskerud University College
e-mail: gaudisite@gmail.com
www.gaudisite.nl
Abstract
A story is an easily accessible story or narrative to make an application live. A
good story is highly specific and articulated entirely in the problem domain: the
native world of the users. An important function of a story is to enable specific
(quantified, relevant, explicit) discussions.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
March 6, 2013
status: concept
version: 1.1
Customer
What
Customer
How
Product
What
Customer
Application
Functional
objectives
market
vision
Conceptual
Realization
analyze
design
case
analyze
design
design
Customer
How
Product
What
Customer
Application
Functional
objectives
market
vision
Conceptual
Realization
Story How To
66
Gerrit Muller
analyze
design
case
analyze
design
version: 1.1
March 6, 2013
SHTfromStoryToDesign
design
Yes
or
draft or sketch of
some essential
appliance
No
that is the question
This brilliant invention will change the world foreverbecause it is so unique and
valuable that nobody beliefs the feasibility. It is great and WOW at the same time,
highly exciting.
Vtables are seen as the soltution for an indirection problem. The invention of Bob will
obsolete all of this in one incredibke move, which will make him famous forever.
He opens his PDA, logs in and enters his provate secure unqiue non trivial
password, followed by a thorough authentication. The PDA asks for the fingerprint of
this little left toe and to pronounce the word shit. After passing this test Bob can
continue.
Story How To
67
Gerrit Muller
version: 1.1
March 6, 2013
SHTexampleStoryLayout
Points of attention
purpose
scope
viewpoint, stakeholders
visualization
size (max 1 A4)
recursive decomposition, refinement
Story How To
68
Gerrit Muller
version: 1.1
March 6, 2013
SHTattentionPoints
ustomer
objectives
accessible, understandable
"Do you see it in front of you?"
Application
C
ustomer
objectives
valuable, appealing
Application
Conceptual
critical, challenging
Realization
Application
attractive, important
"Are customers queuing up for this?"
"What is difficult in the realization?"
"What do you learn w.r.t. the design?"
Application
specific
Functional
Story How To
69
Gerrit Muller
version: 1.1
March 6, 2013
SHTcriterionsList
Example of a story
Betty is a 70-year-old woman who lives in Eindhoven. Three years ago her husband passed
away and since then she lives in a home for the elderly. Her 2 children, Angela and Robert,
come and visit her every weekend, often with Bettys grandchildren Ashley and Christopher.
As so many women of her age, Betty is reluctant to touch anything that has a technical
appearance. She knows how to operate her television, but a VCR or even a DVD player is
way to complex.
When Betty turned 60, she stopped working in a sewing studio. Her work in this noisy
environment made her hard-of-hearing with a hearing-loss of 70dB around 2kHz. The rest of
the frequency spectrum shows a loss of about 45dB. This is why she had problems
understanding her grandchildren and why her children urged her to apply for hearing aids two
years ago. Her technophobia (and her first hints or arthritis) inhibit her to change her hearing
aids batteries. Fortunately her children can do this every weekend.
This Wednesday Betty visits the weekly Bingo afternoon in the meetingplace of the old-folks
home. Its summer now and the tables are outside. With all those people there its a lot of
chatter and babble. Two years ago Betty would never go to the bingo: I cannot hear a thing
when everyone babbles and clatters with the coffee cups. How can I hear the winning
numbers?!. Now that she has her new digital hearing instruments, even in the bingo
cacophony, she can understand everyone she looks at. Her social life has improved a lot and
she even won the bingo a few times.
That same night, together with her friend Janet, she attends Mozarts opera The Magic Flute.
Two years earlier this would have been one big low rumbly mess, but now she even hears the
sparkling high piccolos. Her other friend Carol never joins their visits to the theaters. Carol
also has hearing aids, however hers only work well in normal conversations. When I hear
music its as if a butchers knife cuts through my head. Its way too sharp!. So Carol prefers to
take her hearing aids out, missing most of the fun. Betty is so happy that her hearing
instruments simply know where they are and adapt to their environment.
Story How To
70
Gerrit Muller
version: 1.1
March 6, 2013
SHTexample
Application
at least 1 week
Conceptual
Realization
The user does not want a technical device but a solution for a problem
Instrument can be adapted to the hearing loss of the user
Directional sensitivity (to prevent the so-called cocktail party effect)
Recognition of sound environments and automatic adaptation (adaptive
filtering)
source: Roland Mathijssen, Embedded Systems Institute, Eindhoven
Story How To
71
Gerrit Muller
version: 1.1
March 6, 2013
SHTexampleCriteria
Abstract
We discuss a systems design approach where several design options are maintained
concurrently. In LEAN Product Development this is called set-based design. Concentioanl systems engineering also promotes the concurrent evaluation of multiple
concepts, the so-called concept selection. Finally, LEAN product development
advocates to keep options open as long as feasible; the so-called late decision
making.
Distribution
1'
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
March 6, 2013
status: planned
version: 0
1"
2'
1"'
2"
3'
4
2"'
3"
4'
3"'
3""
B
4"
5
5'
A'
5"
B'
B"
time
B'"
by
3. Decision
by
+ review and agree on analysis
+ communicate and document
by
version: 0
March 6, 2013
TORdecisionFlow
invalidated solution
by
+ exploring multiple propositions (specification + design proposals)
+ exploring decision criteria (by evaluation of proposition feedback)
+ assessment of propositions against criteria
insufficient data
no satisfying solution
2. Analysis
evaluation criteria
clamp swivel
weight
Maturity
10
Cost
20
Design robustness
25
Development level
Hardware cost
Development cost
Design life
swivel cycles
pressure cycles
Pressure range
internal
external
Temperature range
Installation
20
Operation
25
Initial installatio/retrieval
Connection/disconnection
Swivel resistance
Spool Length Short
Spool Length Long
Hub loads
points
CBV
EDP-LRP connection
dynamic
swivel
clamp
dynamic
50
20
50
4
5
80
100
2
2
40
40
5
2
100
40
5
5
125
125
3
4
75
100
3
5
75
125
4
2
4
100
50
100
4
5
4
100
125
100
4
2
4
100
50
100
2
2
40
40
3
4
60
80
4
5
80
100
1
1
3
2
25
25
75
50
4
4
5
4
100
100
125
100
5
5
5
5
125
125
125
125
985
1165
two sided
connectors
connectors in
hub
connectors in
hub
with roll-off
wireless
connection
Concepts
Evaluation Criteria
Score
+
+
+
+
+
+
+
+
S
S
S
+
S
-
+
+
+
S
+
+
S
-
S
+
-
S
+
-
S
+
S
S
+
+
S
+
7
1
5
7
3
3
5
4
4
3
3
7
Pos.
Time to connect
Need for ROV
Design
Robustness
Connector design
Number of parts
Handle roll-off
Influence other
Redundancy
Design
Interchangeability
Cost
HW cost
Manufacturing cost
Engineering cost
Service cost
Maturity
1290
version: 0
March 6, 2013
CSSBpughExamples
1'
2
3
1"
2'
1"'
2"
3'
4
2"'
3"
4'
3"'
3""
B
4"
5
5'
A'
B'
5"
B"
time
version: 0
March 6, 2013
CSSBsetEvolution
B'"
Conclusions
version: 0
March 6, 2013
CSSBconclusions
Abstract
Many stakeholder concerns can be specified in terms of qualities. These qualities
can be viewed from all 5 CAFCR viewpoints. In this way qualities can be used
to relate the views to each other.
The meaning of qualities for the different views is described. A checklist of qualities
is provided as a means for architecting. All qualities in the checklist are described
briefly.
Customer
objectives
Distribution
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
March 6, 2013
status: finished
version: 1.3
usability
safety
evolvability
Application
Functional
Conceptual
Realization
Application
Functional
Conceptual
Realization
usability
safety
evolvability
version: 1.3
March 6, 2013
QNneedles
Customer
objectives
sensitive
information
trusted
Application
selection
classification
people
information
authentication
badges
passwords
Functional
functions for
administration
authentication
intrusion detection
logging
quantification
Conceptual
cryptography
firewall
security zones
authentication
registry
logging
locks / walls
guards
administrators
Realization
specific
algorithms
interfaces
libraries
servers
storage
protocols
not trusted
social contacts
missing
open passwords
functionality
blackmail
wrong
burglary
quantification
fraud
unworkable procedures
holes between
concepts
threats
version: 1.3
March 6, 2013
QNsecurityExample
bugs
buffer overflow
non encrypted
storage
poor exception
handling
Quality Checklist
usable
usability
attractiveness
responsiveness
image quality
wearability
storability
transportability
dependable
safety
security
reliability
robustness
integrity
availability
effective
throughput or
productivity
interoperable
connectivity
3rd party extendible
liable
liability
testability
traceability
standards compliance
efficient
resource utilization
cost of ownership
consistent
reproducibility
predictability
serviceable
ecological
ecological footprint
contamination
noise
disposability
serviceability
configurability
installability
future proof
evolvability
portability
upgradeability
extendibility
maintainability
down to earth
attributes
logistics friendly
manufacturability
logistics flexibility
lead time
version: 1.3
March 6, 2013
QNchecklist
cost price
power consumption
consumption rate
(water, air,
chemicals,
et cetera)
size, weight
accuracy
Abstract
The fundamental concepts and approach system partitioning are explained. We
look at physical decomposition and functional decomposition in relation to supply
chain, lifecycle support, project manageemnt, and system specification and design.
system
subsystem 1
Distribution
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
March 6, 2013
status:
preliminary
draft
version: 0.1
subsub
system A
subsub
system B
subsub
system N
atomic
part
atomic
part
atomic
part
subsystem 2
subsub
system A
subsub
system B
subsub
system N
subsystem n
subsub
system A
subsub
system B
subsub
system N
Engineering
engineering knowledge
system specification
system design
source data
procurement
production procedures
qualification procedures
system documentation
production
installation
quality
assurance
lifecycle
support
knowdoc
CAD
SCM
ledge
DB
DB
past
project
source
mechanical
experience documents electrical
code
design management
database
ERP
PDM
resource
product
planning,
data
e.g. SAP management
version: 0.1
March 6, 2013
SPFengineering
chamber
bottom chuck
optics stage
control
Fluidic
subsystem
8
5 electronics
infrastructure
ZUBA
control
vision
control
9 vision
optics
stage
16base frame +
x, y, stage
1
10
0
covers and
hatches
11
cabling
12
ventilation
air flow
13
contamination
evacuation
sensors
measurement
frame
14
machine
control
15
"remote"
electronics rack
7 ZUBA
camera
scoop
stage
control
stage
granite
electronics
infrastructure
frame
process
power
supply
integrating
version: 0.1
March 6, 2013
REPLIsubsystemsAll
subsub
system B
subsub
system N
atomic
part
atomic
part
atomic
part
subsystem 2
subsub
system A
subsub
system B
subsub
system N
subsystem n
subsub
system A
subsub
system B
subsub
system N
version: 0.1
March 6, 2013
SPFrecursion
applications
services
toolboxes
view
viewport
audio
tuner
adjust
view
TXT
menu
video
drivers
driver
hardware
PIP
framebuffer
browse
TXT
etc.
networking
scheduler
MPEG
DSP
OS
CPU
RAM
etc
control subsystem
domain specific
filesystem
generic
version: 0.1
March 6, 2013
CVconstructionDecomposition
version: 0.1
March 6, 2013
SPFpartitioningGuidelines
control SW
application
SW
HMI SW
control
electronics
control
interface
cooling
EMC
shielding
main
function
qualification
support
adjustment
support
power
stabilization
power
conversion
power
distribution
production
support
mechanical
package
logistics/lifecycle/production
flexibility
clarity
version: 0.1
March 6, 2013
SPFselfSustained
power
interface
control
interface
e.g. CAN
part
e.g. pressure
and flow
regulator
part
e.g. pipe
hydrocarbon
interface
mechanical
mounting interface
part
e.g. pipe
version: 0.1
March 6, 2013
SPFinterfaceDecoupling
System is composed
by using standard interfaces
limited catalogue of variants (e.g. cost performance points)
version: 0.1
March 6, 2013
SPFmodularityGame
System Creation
stakeholder
needs
business
objectives
specification
architecting
design
architecture
guidelines
top-level design
rationale
procurement
design
partitioning
interfaces
functions
allocation
production
engineering
documentation
version: 0.1
March 6, 2013
SPFsystemCreation
installation
quality
assurance
lifecycle
support
sensor
signals
measure
pressure,
temp, flow
sensor
data
control
pressure,
temp, flow
settings
transport to
top-side
increase
well
pressure
hydrocarbons
from well
hydro
carbons
prevent
blow-outs
regulate
flow and
pressure
combine
multiple
streams
separate
gas, oil,
water, sand
version: 0.1
March 6, 2013
SPFfunctionalExample
water
sand
Functional Decomposition
How does the system work and operate?
Functions describe what rather than how.
Functions are verbs .
Input-Process-Output paradigm.
Multiple kinds of flows:
physical (e.g. hydrocarbons)
information (e.g. measurements)
control
At lower level one part ~= one function
pump pumps, compressor compresses, controller controls
At higher level functions are complex interplay of physical parts
e.g. regulating constant flow, pressure and temperature
version: 0.1
March 6, 2013
SPFfunctionalDecomposition
Quantification
Size
Weight
Cost
1450 Kg
30000 NoK
Reliability
MTBF 4000 hr
Throughput
3000 l/hr
0.1 s
Response time
Accuracy
+/- 0.1%
many characteristics
of a system, function or part
can be quantified
Note that quantities
have unit
version: 0.1
March 6, 2013
SPFquantification
Question Generator
functions
printing
preparing
copying
solving
paper jam
paper path
fuse
PIM
finisher
scanner
accuracy
component
processing load
response time
ch
ara
cte
ris
tics
throughput
memory footprint
version: 0.1
March 6, 2013
BS05questionGenerator
global
alignment
accuracy
process
overlay
80 nm
nm
off axis
Sensor
repro
3 nm
stage Al.
pos. meas.
accuracy
4 nm
blue align
sensor
repro
3 nm
system
adjustment
accuracy
2 nm
reticule
15 nm
lens
matching
25 nm
matched
machine
60 nm
single
machine
30 nm
stage
overlay
12 nm
position
accuracy
7 nm
frame
stability
2.5 nm
process
dependency
matching
accuracy
5 nm
stage grid
accuracy
5 nm
alignment
repro
tracking
error X, Y
2.5 nm
sensor
5 nm
interferometer
stability
1 nm
nm
metrology
stability
5 nm
tracking
error phi
75 nrad
version: 0.1
March 6, 2013
ASMLoverlayBudget
tracking
error WS
2 nm
tracking
error RS
1 nm
Example of A3 overview
A3 architecture overview of the Metal Printer
throughput in minutes
back-end factory
logistics &
automation
advanced
process
control
wafer
computing &
networking
infrastructure
seed
2. seed sputter
wafer
wafer
metrology
wafer
wafer fab
(front end) wafer
with
ICs
metal
expose
expose
wafer
wafer
printer
stepper
power
chemicals
climate
infrastructure
power, chemicals
consumables, waste
author
version
date last update
3. metal print
4. seed etch
wafer
wafer
REX
3..4
1..2
design enabling
e.g. CD, separation
throughput
process steps
metal
printer
clean wafer
clean
wafer
prefill
prealign
contamination
and climate
X-section control
uptime
reliability
high MTBF
throughput
system cost
integral costs
operational
costs
environmental
impact
robot
consumables
waste
partial graph
many nodes
and connections
are not shown
electric power
clean water
elyte
N2, air
disposal water, air, ...
prealign
clean
master
master
FOUP
wafer
FOUP
prefill
robot
wafer
FOUP
flip
100b
optics stage
control
chamber
bottom chuck
Fluidic
subsystem
9 vision
3
5 electronics
infrastructure
1
10
0
camera
scoop
stage
control
stage
16base frame +
x, y, stage
granite
electronics
infrastructure
covers and
hatches
1. Close doors
11
cabling
12
ventilation
air flow
13
contamination
evacuation
4. Process
sensors
measurement
frame
14
machine
control
15
"remote"
electronics rack
frame
process
power
supply
integrating
subsystems
talign
2. Align
3. Move to proximity
tchamber
6. Open doors
metal printer
functional flow
200, 300 mm
x kW
7 ZUBA
optics
8
stage
wafer size
power
clean room class
floor vibration class
vision
control
a m
b m
c WPH
d hr
200b
accuracy overlay
early delivery
vs
volume production
7. E-test
pattern
resolution
pattern quality
5. coat/develop dielectrics
scope
status
Gerrit Muller
0.1
August 3, 2010
Document meta-information
spin coated
polymer
ICs
stepper
per wafer
1. inspection
Cu
mask
version: 0.1
March 6, 2013
LEANoverviewA3