Upload
jinwon-park
View
15
Download
0
Tags:
Embed Size (px)
DESCRIPTION
All About Systems Engineering; Introductory Course
Citation preview
All About Systems Engineering; Introductory Coursematerial by Gerrit Muller
presented by
AbstractThis introductory course sketches all fundamentals of Systems Engineering. Startingat the business contexts, touching Project, Processes, and Organization. Therole 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 Gaudproject. The Gaud project philosophy is to improveby obtaining frequent feedback. Frequent feedback ispursued by an open creation process. This documentis published as intermediate or nearly mature version toget feedback. Further distribution is allowed as long asthe document remains complete and unchanged.
March 6, 2013status: preliminarydraftversion: 0.2
more theory and exercisestheory and casesintroduction to SE,process, organizationcase, phasing, V-Model, spiral model,relation with other business disciplines
organization and processin practiceexercise and discussionproduct families, products vs projects
design and conceptselection in practiceexercise and discussionexample case to wrap-up
creating the big pictureexercise and discussionroadmapping, key performanceparameters
capturing customerunderstandingexercise and discussioncustomer key drivers, story telling,scenarios and use cases
systems engineer role andtaskdeliverables, responsibilties, activities,styles, characteristics
system contextcustomer context, life cycle context,stakeholders, needs, concerns,requirements, story telling, conops, usecases
system designconcept selection, physicaldecomposition, functionaldecomposition, qualities, interfacemanagement, budgeting, modeling
day 3
day 4
day 1
day 2
Introduction Course Program
introduction to SE,process, organizationcase, phasing, V-Model, spiral model,relation with other business disciplines
systems engineer role andtaskdeliverables, responsibilties, activities,styles, characteristics
system contextcustomer context, life cycle context,stakeholders, needs, concerns,requirements, story telling, conops, usecases
system designconcept selection, physicaldecomposition, functionaldecomposition, qualities, interfacemanagement, budgeting, modeling
day 1
day 2
morning afternoon
morning afternoon
All About Systems Engineering; Introductory Course2 Gerrit Muller
version: 0.2March 6, 2013
SEINTROprogram2day
Project Systems Engineering Introduction; Phasing,Process, Organization
by Gerrit Muller Buskerud University Collegee-mail: [email protected]
www.gaudisite.nl
AbstractThe fundamental concepts and approach to project oriented Systems Engineeringare explained. We look at project phasing, phase transition, processes, andorganization.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 6, 2013status: preliminarydraftversion: 0.1
tender design andengineering installation
operation andmaintenance disposal
offer
order
acceptancefinal payment
Project Life Cycle
tender design andengineering installation
operation andmaintenance disposal
offer
order
acceptancefinal payment
Project Systems Engineering Introduction; Phasing, Process, Organization4 Gerrit Muller
version: 0.1March 6, 2013
PSEIPprojectLifeCycle
Phased Project Approach
needs
design
verification
engineering
core informationin draft 50%
most informationavailable in
concept
information is stableenough to use
heavier change controlLegend:
specification
preparing or updating workfull under development
0.feasibility
1.definition
2.systemdesign
3.engineering
4.integration
& test
5.field
monitoring
tender design and engineering installation operation andmaintenance
Project Systems Engineering Introduction; Phasing, Process, Organization5 Gerrit Muller
version: 0.1March 6, 2013PSEIPphases
V-Model
needs
specification
system design
subsystem design
component design
component realization
component test
subsystem test
system test
verification
validation
Project Systems Engineering Introduction; Phasing, Process, Organization6 Gerrit Muller
version: 0.1March 6, 2013TPSEPvModel
All Business Functions Participate
0.feasibility
1.definition
2.systemdesign
3.engineering
4.integration
& test
5.field
monitoring
saleslogisticsproductionservicedevelopment & engineering: marketing, project management, design
Project Systems Engineering Introduction; Phasing, Process, Organization7 Gerrit Muller
version: 0.1March 6, 2013
PCPbusinessPhases
Evolutionary PCP model
requirementsspecification
designbuild
test andevaluate
2% of budget (EVO)2 weeks (XP)
up to 2 monthsper cyclus
Project Systems Engineering Introduction; Phasing, Process, Organization8 Gerrit Muller
version: 0.1March 6, 2013
PCPspiral
Reuse and Products
reus
epr
oduc
ts
reus
esp
ecs
reus
epr
oduc
ts
reus
esp
ecs
tender design andengineering installation
operation andmaintenance disposal
tender design andengineering installation
operation andmaintenance disposal
tender design andengineering installation
operation andmaintenance disposal
Project Systems Engineering Introduction; Phasing, Process, Organization9 Gerrit Muller
version: 0.1March 6, 2013
PSEIPreuseAndProducts
Simplified Process View
strategyprocess
customer
supplying business
value
product creationprocess
customer oriented (sales,service, production) process
people, process and technologymanagement process
Project Systems Engineering Introduction; Phasing, Process, Organization10 Gerrit Muller
version: 0.1March 6, 2013
RSPprocessDecomposition
Simplified Process; Money and Feedback
strategyprocess
supplying business
value
people, process and technology
long termknow how(soft) assets
feed
back
product creation
customer oriented
customer
short term;cashflow!
mid term;cashflow
next year!
Project Systems Engineering Introduction; Phasing, Process, Organization11 Gerrit Muller
version: 0.1March 6, 2013
RSPprocessDecompositionAnnotated
Simplified process diagram for project business
systems architecting
tender projectexecution
product creation
deploymentcontract systems
products orcomponents
policy andplanning
people, process, and technology management
Project Systems Engineering Introduction; Phasing, Process, Organization12 Gerrit Muller
version: 0.1March 6, 2013
PPSprojectProcess
Decomposition of the Product Creation Process
Product Creation Process
OperationalManagement
DesignControl
Marketing
specificationbudgettime
technical profitabilitysaleability
needs
specification
design
engineering
what is needed
what will be realized
how to realize
how to produceand to maintain
customer input
customer expectations
market introduction
introduction at customer
feedback
product pricing
commercial structureplanning
progress controlresource managementrisk management
project log
verificationmeeting specsfollowing design
Project Systems Engineering Introduction; Phasing, Process, Organization13 Gerrit Muller
version: 0.1March 6, 2013
PCPDecomposition
Operational Organization of the PCP
subsystem
singleproduct
productfamily
entireportfolio
developersmodule
portfoliooperationalmanager
familyoperationalmanager
(single product)projectleader
subsystemprojectleader
operational
portfolioarchitect
familyarchitect
productarchitect
subsystemarchitect
technicalportfolio
marketingmanager
familymarketingmanager
productmanager
commercial
Project Systems Engineering Introduction; Phasing, Process, Organization14 Gerrit Muller
version: 0.1March 6, 2013
PCPoperationalOrganization
Prime Responsibilities of the Operational Leader
Resources Time
Specification
Quality
Project Systems Engineering Introduction; Phasing, Process, Organization15 Gerrit Muller
version: 0.1March 6, 2013
PCPoperationalTriangle
The Rules of the Operational Game
assess risksdetermine feasibility
define projectupdate project
specification, resources, time
business management project leader
accept or reject
execute projectwithin normalquality rules
accept
Project Systems Engineering Introduction; Phasing, Process, Organization16 Gerrit Muller
version: 0.1March 6, 2013
PCPoperationalGame
Operational Teams
Operational Leader(project leader)
Operational Support(project manager)
Marketing orProduct Manager
Architect
ApplicationManager
Test Engineer
Service Manufacturing
LogisticsSalesManager QualityAssurance
RequirementsAnalyst
SubsystemOperational
Leaders
SubsystemArchitectsTechnology-
SpecificArchitects
Developmentsupport
Project Systems Engineering Introduction; Phasing, Process, Organization17 Gerrit Muller
version: 0.1March 6, 2013
PCPconcentricTeams
What Service Level to Deliver?
initial production
expert support
use results
technicalcapability
functionalcapability
customer support
facility management conventionalmaintenance
contract
productacceptance
and warranty
capability management
performance-based or service-level
agreement
factory
Project Systems Engineering Introduction; Phasing, Process, Organization18 Gerrit Muller
version: 0.1March 6, 2013
PPSservicesOperationalModel
Role and Task of the System Architectby Gerrit Muller Buskerud University College
e-mail: [email protected]
AbstractThe 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 projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 6, 2013status: preliminarydraftversion: 1.0
The Role and Task of the System Architectby Gerrit Muller Buskerud University Collge
e-mail: [email protected]
AbstractThe role of the system architect is described from three viewpoints: deliverables,responsibilities and activities. This description shows the inherent tension in thisrole: a small set of hard deliverables, covering a fuzzy set of responsibilities,hiding an enormous amount of barely visible day-to-day work.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 6, 2013status: conceptversion: 2.0
V4aa
IO
design,brainstorm,
explain
Idea
think,analyze
listen, talk,walk around
BlahBlah
write,consolidate,
browse
present,meet, teach,
discuss
read,review
Design
Spec
Report
test,integrate
assist project leaderwith work breakdown,
schedule, risks
travel tocustomer,supplier,
conference
providevision andleadership
Deliverables of the System Architect
Spec DesignReport
Report Report DesignDesign
SpecSpec
The Role and Task of the System Architect21 Gerrit Muller
version: 2.0March 6, 2013
RSAdeliverables
List of Deliverables
Customer and Life-Cycle Needs (what is needed)
System Specification (what will be realized)
Design Specification (how the system will be realized)
Verification Specification (how the system will be verified)
Verification Report (the result of the verification)
Feasibility Report (the results of a feasibility study)
Roadmap
The Role and Task of the System Architect22 Gerrit Muller
version: 2.0March 6, 2013
RSAdeliverablesSpecific
Responsibilities of the System Architect
systemsubsystem
Balance Consistency
module
Overview
RequirementSpec
DesignRealization
DecompositionIntegration
modules
Func
tionQuality
KISS
EleganceSimple Integrity Fitting
satisfiedstakeholders
system
context
The Role and Task of the System Architect23 Gerrit Muller
version: 2.0March 6, 2013
RSAresponsibilities
Examples of Secondary Responsibilities
responsibility
business plan, profit
schedule, resources
market, salability
technology
process, people
detailed designs
primary owner
business manager
project leadermarketing manager
technology manager
line manager
engineers
The Role and Task of the System Architect24 Gerrit Muller
version: 2.0March 6, 2013
RSAsecondaryResponsibilities
What does the System Architect do?
V4aa
IO
design,brainstorm,
explain
Idea
think,analyze
listen, talk,walk around
BlahBlah
write,consolidate,
browse
present,meet, teach,
discuss
read,review
Design
Spec
Report
test,integrate
assist project leaderwith work breakdown,
schedule, risks
travel tocustomer,supplier,
conference
providevision andleadership
The Role and Task of the System Architect25 Gerrit Muller
version: 2.0March 6, 2013RSAactivities
From Detail to Overview
driving views
shared issues
touched details
seen details
real-world facts
10
102
104
107
infinite
Quantityper year
(order-of-magnitude)
architecttime per
item
100 h
1 h
10 minmeetings
consolidationin
deliverables
informalcontacts
product detailssamplingscanning
0.1105
0.5
1 sec106
1010
The Role and Task of the System Architect26 Gerrit Muller
version: 2.0March 6, 2013
RSAdetailHierarchy
Reality or Virtuality?
Abstractions only exist for concrete facts.
The Role and Task of the System Architect27 Gerrit Muller
version: 2.0March 6, 2013
Visible Output versus Invisible Work
V4aa
IOIdea
Bla Bla
Design
Spec
Report
system
subsystemmodule
RequirementSpec
DesignRealization
modules
Func
tio
n
Quality KISS
Activities
Responsibilities
DeliverablesDecr
easin
gVi
sibilit
y
Spec DesignReport
Report
ReportDesign
Design
SpecSpec
From Manager perspective
The Role and Task of the System Architect28 Gerrit Muller
version: 2.0March 6, 2013
RSApyramid
The Awakening of a System Architectby Gerrit Muller Buskerud University College
e-mail: [email protected]
AbstractThe typical phases of a system architect development are described, beginningat the fundamental technology knowledge, with a later broadening in technologyand in business aspects. Finally the subtlety of individual human beings is takeninto account.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 6, 2013status: conceptversion: 1.1
roottechnical
knowledge
generalisttechnical
knowledge
business,application insight
process insightpsychosocial
skills
Typical Growth of a System Architect
roottechnical
knowledge
generalisttechnical
knowledge
business,application insight
process insightpsychosocial
skills
The Awakening of a System Architect30 Gerrit Muller
version: 1.1March 6, 2013
MATsystemArchitectGrowth
Generalist versus Specialist
spec
ialis
tgeneralist
rootknowledge
breadth ofknowledge
dept
h of
kn
owle
dge
The Awakening of a System Architect31 Gerrit Muller
version: 1.1March 6, 2013
MATgeneralistVsSpecialist
Generalists and Specialists are Complementary
spec
ialis
t
spec
ialis
t
spec
ialis
t
spec
ialis
t
spec
ialis
t
spec
ialis
t
spec
ialis
t
spec
ialis
t
generalistgeneralist
breadth ofknowledge
dept
h of
kn
owle
dge
The Awakening of a System Architect32 Gerrit Muller
version: 1.1March 6, 2013
MATcomplementaryExpertises
Spectrum from Specialist to System Architect
all-
roun
d sp
ecia
list systems architect
spec
ialist
rootknowledge
aspectarchitect
breadth ofknowledge
dept
h of
kn
owle
dge
The Awakening of a System Architect33 Gerrit Muller
version: 1.1March 6, 2013
MATfromSpecialistToSystemArchitect
Architecting Interaction Stylesby Gerrit Muller Buskerud University College
e-mail: [email protected]
AbstractA system architects needs skills to apply different interactions styles, dependingon the circumstances. This document discusses the following interaction styles:provocation, facilitation, leading, empathic, interviewing, white board simulation,and judo tactics.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 6, 2013status: draftversion: 0.2
provocation
facilitation
leading
empathic
interviewing
whiteboard simulation
judo tactics
when in an impasse: provokeeffective when used sparsely
especially recommended when new in a field:contribute to the team, while absorbing new knowledge
provide vision and direction, make choicesrisk: followers stop to give the needed feedback
take the viewpoint of the stakeholderacknowledge the stakeholder's feelings, needs, concerns
investigate by asking questions
invite a few engineers and walk throughthe system operation step by step
first listen to the stakeholder and thenexplain cost and alternative opportunities
Architecting Styles
provocation
facilitation
leading
empathic
interviewing
whiteboard simulation
judo tactics
when in an impasse: provokeeffective when used sparsely
especially recommended when new in a field:contribute to the team, while absorbing new knowledge
provide vision and direction, make choicesrisk: followers stop to give the needed feedback
take the viewpoint of the stakeholderacknowledge the stakeholder's feelings, needs, concerns
investigate by asking questions
invite a few engineers and walk throughthe system operation step by step
first listen to the stakeholder and thenexplain cost and alternative opportunities
Architecting Interaction Styles35 Gerrit Muller
version: 0.2March 6, 2013
ASstyles
Exercise Role and Task of the System Architect
Role play with 3 roles and optional observer:
1 operational leader (project leader)
1 system architect
1 marketing manager
1 observer (optional)
Discuss the definition (business relevance, specification, and planning) of a travele-mail mate.
Present (max. 2 flips) the result and the process (the relation and interaction ofthe three roles).
Exercise Role and Task System Architect36 Gerrit Muller
version: 0.2March 6, 2013MRSAexercise
Role and Task of a System Architect
Deliverables
Spec DesignReport
Report Report DesignDesign
SpecSpec
Responsibilities
systemsubsystem
Balance Consistency
module
Overview
RequirementSpec
DesignRealization
DecompositionIntegration
modules
Func
tionQuality
KISS
EleganceSimple Integrity Fitting
satisfiedstakeholders
system
context
Daily Activities
V4aa
IO
design,brainstorm,
explain
Idea
think,analyze
listen, talk,walk around
BlahBlah
write,consolidate,
browse
present,meet, teach,
discuss
read,review
Design
Spec
Report
test,integrate
assist project leaderwith work breakdown,
schedule, risks
travel tocustomer,supplier,
conference
providevision andleadership
From detail to overview
driving views
shared issues
touched details
seen details
real-world facts
10
102
104
107
infinite
Quantityper year
(order-of-magnitude)
architecttime per
item
100 h
1 h
10 minmeetings
consolidationin
deliverables
informalcontacts
product detailssamplingscanning
0.1105
0.5
1 sec106
1010
Exercise Role and Task System Architect37 Gerrit Muller
version: 0.2March 6, 2013
Personal characteristics of a System Architect
Typical growth of a Architect
roottechnical
knowledge
generalisttechnical
knowledge
business,application insight
process insightpsychosocial
skills
Generalist vs Specialist
spec
ialis
t
generalist
rootknowledge
breadth ofknowledge
dept
h of
kn
owle
dge
Complementary Roles
spec
ialis
t
spec
ialis
t
spec
ialis
t
spec
ialis
t
spec
ialis
t
spec
ialis
t
spec
ialis
t
spec
ialis
t
generalistgeneralist
breadth ofknowledge
dept
h of
kn
owle
dge
Role Spectrum
all-
roun
d sp
ecia
list systems architect
spec
ialist
root
knowledge
aspectarchitect
breadth ofknowledge
dept
h of
kn
owle
dge
Exercise Role and Task System Architect38 Gerrit Muller
version: 0.2March 6, 2013
Module Requirementsby Gerrit Muller Buskerud University College
e-mail: [email protected]
AbstractThis 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 projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 6, 2013status: conceptversion: 1.3
Fundamentals of Requirements Engineeringby Gerrit Muller Buskerud University College
e-mail: [email protected]
AbstractRequirements engineering is one of the systems engineering pillars. In this documentwe discuss the fundamentals of systems engineering, such as the transformationof needs into specification, the need to prescribe what rather than how, and therequirements when writing requirements.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 6, 2013status: conceptversion: 0.1
system seen as black box
inputs outputsfunctionsquantified characteristics
restrictions, prerequisitesboundaries, exceptionsstandards, regulations
interfaces
Definition of Requirement
Requirements describing the needs of the customer:Customer Needs
Requirements describing the needs of the companyitself over the life cycle: Life Cycle Needs
Requirements describing the characteristics of thefinal resulting product: Product Specification
The requirements management process recursivelyapplies definition 2 for every level of decomposition.
Fundamentals of Requirements Engineering41 Gerrit Muller
version: 0.1March 6, 2013REQdefinition
Flow of Requirements
What
What
How
customer needs:What is needed by the customer?
product specification:What are we going to realize?
system design:How are we going to realize the product?
What
How
What
How
What
How
What are the subsystems we will realize?
How will the subsystems be realized?What
How
What
How
What
How
What
How
What
How
What
How
up to "atomic" components
choicestrade-offsnegotiations
Fundamentals of Requirements Engineering42 Gerrit Muller
version: 0.1March 6, 2013
REQwhatWhatHow
System as a Black Box
system seen as black box
inputs outputsfunctionsquantified characteristics
restrictions, prerequisitesboundaries, exceptionsstandards, regulations
interfaces
Fundamentals of Requirements Engineering43 Gerrit Muller
version: 0.1March 6, 2013
REQsystemAsBlackBox
Stakeholders w.r.t. Requirements
Policy and Planning(business, marketing,operational managers)
customer(purchaser, decision maker, user, operator, maintainer)
company
Product Creation Process(project leader, product
manager, engineers, suppliers)
Customer-Oriented Process(sales, service, production,
logistics)
People, Process, and Technology management process(capability managers, technology suppliers)
Fundamentals of Requirements Engineering44 Gerrit Muller
version: 0.1March 6, 2013
REQstakeholders
The Formal Requirements for Requirements
Specific
Unambiguous
Verifiable
Quantifiable
Measurable
Complete
Traceable
Fundamentals of Requirements Engineering45 Gerrit Muller
version: 0.1March 6, 2013
REQrequirementsForRequirementsList
The Requirements to Enable Human Use
Accessible
Understandable
Low threshold
Fundamentals of Requirements Engineering46 Gerrit Muller
version: 0.1March 6, 2013
REQrequirementsFromHumans
Short introduction to basic CAFCR modelby Gerrit Muller Buskerud University College
e-mail: [email protected]
AbstractThe basic CAFCR reference model is described, which is used to describea system in relation to its context. The main stakeholder in the context is thecustomer. The question Who is the customer? is addressed.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 6, 2013status: draftversion: 0.4
CustomerWhat
CustomerHow
ProductWhat
ProductHow
What does Customer need in Product and Why?
drives, justifies, needsenables, supports
Customerobjectives
Application Functional Conceptual Realization
The CAFCR model
CustomerWhat
CustomerHow
ProductWhat
ProductHow
What does Customer need in Product and Why?
drives, justifies, needsenables, supports
Customerobjectives
Application Functional Conceptual Realization
Short introduction to basic CAFCR model48 Gerrit Muller
version: 0.4March 6, 2013
CAFCRannotated
Integrating CAFCR
Customerobjectives
Application Functional Conceptual Realization
intention
constraintawareness
objectivedriven
contextunderstanding
oppor-tunities
knowledgebased
CustomerWhat
CustomerHow
ProductWhat
ProductHow
What does Customer need in Product and Why?
Short introduction to basic CAFCR model49 Gerrit Muller
version: 0.4March 6, 2013
MSintegratingCAFCR
CAFCR can be applied recursively
System(producer)
CustomerBusiness Drives
Enables
Customer'sCustomerBusiness
Drives
Enables
Consumer Drives
Enables
Value Chain
larger scope has smaller
influence on architecture
Short introduction to basic CAFCR model50 Gerrit Muller
version: 0.4March 6, 2013
CAFCRrecursion
Market segmentation
geographical
business model profit, non profit
examples
economics
USA, UK, Germany, Japan, China
high end versus cost constrained
consumers youth, elderly
segmentationaxis
outlet retailer, provider, OEM, consumer direct
Short introduction to basic CAFCR model51 Gerrit Muller
version: 0.4March 6, 2013
BCAFCRcustomerSegmentation
Example of a small buying organization
decision maker(s) purchaser
maintaineroperator
user
CEOCFO
CTOCIO
department head
Who is the customer?
CMO
CEO: Chief Executive OfficerCFO: Chief Financial OfficerCIO: Chief Information OfficerCMO: Chief Marketing OfficerCTO: Chief Technology Officer
Short introduction to basic CAFCR model52 Gerrit Muller
version: 0.4March 6, 2013
BCAFCRwhoIsTheCustomer
CAFCR+ model; Life Cycle View
Customerobjectives
Application Functional Conceptual Realization
Life cycleoperationsmaintenanceupgrades
developmentmanufacturing
installation
sales, service, logistics, production, R&D
Short introduction to basic CAFCR model53 Gerrit Muller
version: 0.4March 6, 2013
BCAFCRplusLifeCycle
Key Drivers How Toby Gerrit Muller Buskerud University College
e-mail: [email protected]
AbstractThe notion of business key drivers is introduced and a method is described tolink these key drivers to the product specification.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 6, 2013status: draftversion: 0.2
Safety
EffectiveFlow
SmoothOperation
Environment
Reduce accident ratesEnforce lawImprove emergency
responseReduce delay due to accident
Improve average speed
Improve total network throughput
Optimize road surface
Speed up target groups
Anticipate on future traffic condition
Ensure traceability
Ensure proper alarm handling
Ensure system health and fault indication
Reduce emissions
Early hazard detectionwith warning and signalingMaintain safe roadconditionClassify and track dangerousgoods vehicles
Detect and warnnoncompliant vehicles
Enforce speed compliance
Enforce red light compliance
Enforce weight compliance
Key-drivers Derived application drivers RequirementsAutomatic upstreamaccident detection
Weather conditiondependent control
DeicingTraffic conditiondependent speed control
Traffic speed anddensity measurement
Note: the graph is only partially elaboratedfor application drivers and requirements
Cameras
Example Motorway Management Analysis
Safety
EffectiveFlow
SmoothOperation
Environment
Reduce accident ratesEnforce lawImprove emergency
responseReduce delay due to accident
Improve average speed
Improve total network throughput
Optimize road surface
Speed up target groups
Anticipate on future traffic condition
Ensure traceability
Ensure proper alarm handling
Ensure system health and fault indication
Reduce emissions
Early hazard detectionwith warning and signalingMaintain safe roadconditionClassify and track dangerousgoods vehicles
Detect and warnnoncompliant vehicles
Enforce speed compliance
Enforce red light compliance
Enforce weight compliance
Key-drivers Derived application drivers RequirementsAutomatic upstreamaccident detection
Weather conditiondependent control
DeicingTraffic conditiondependent speed control
Traffic speed anddensity measurement
Note: the graph is only partially elaboratedfor application drivers and requirements
Cameras
Key Drivers How To55 Gerrit Muller
version: 0.2March 6, 2013
COVmotorwayManagementKeyDrivers
Method to create Key Driver Graph
Build a graph of relations between drivers and requirementsby means of brainstorming and discussions
Define the scope specific. in terms of stakeholder or market segments
Acquire and analyze facts extract facts from the product specificationand ask why questions about the specification of existing products .
Iterate many times increased understanding often triggers the move of issuesfrom driver to requirement or vice versa and rephrasing
where requirementsmay have multiple drivers
Obtain feedback discuss with customers , observe their reactions
Key Drivers How To56 Gerrit Muller
version: 0.2March 6, 2013
TCAFkeyDriverSubmethod
Recommendation for the Definition of Key Drivers
Use short names, recognized by the customer.
Limit the number of key-drivers minimal 3, maximal 6
for instance the well-known main function of the product Dont leave out the obvious key-drivers
for instance replace ease of use byminimal number of actions for experienced users ,
or efficiency by integral cost per patient
Use market-/customer- specific names, no generic names
Do not worry about the exact boundary betweenCustomer Objective and Application
create clear goal means relations
Key Drivers How To57 Gerrit Muller
version: 0.2March 6, 2013
TCAFkeyDriverRecommendations
Transformation of Key Drivers into Requirements
Key(Customer)
Drivers
DerivedApplication
DriversRequirements
CustomerWhat
CustomerHow
ProductWhat
Customerobjectives
Application Functional
goal meansmay be skipped or
articulated by severalintermediate steps
functionsinterfacesperformance figures
Key Drivers How To58 Gerrit Muller
version: 0.2March 6, 2013
REQfromDriverToRequirement
Requirements Elicitation and Selectionby Gerrit Muller Buskerud University College
e-mail: [email protected]
AbstractAn elicitation method for needs is described using many different viewpoints. Aselection process with a coarse and a fine selection is described to reduce thespecification to an acceptable and feasible subset.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 6, 2013status: draftversion: 0 bottom-up
top-downkey-drivers
(customer, business)
roadmap(positioning and trends in time)
competition(positioning in the market)
"ideal" reference designprototyping, simulation(learning vehicle)bottom-up(technological opportunities)existing systems
operational drivers(logistics, production, etc.)
NeedsContinued
Product CreationProcess
Feedback
regulations
Complementary Viewpoints to Capture Requirements
bottom-up
top-downkey-drivers
(customer, business)
roadmap(positioning and trends in time)
competition(positioning in the market)
"ideal" reference designprototyping, simulation(learning vehicle)bottom-up(technological opportunities)existing systems
operational drivers(logistics, production, etc.)
NeedsContinued
Product CreationProcess
Feedback
regulations
Requirements Elicitation and Selection60 Gerrit Muller
version: 0March 6, 2013
REQviewpoints
Requirement Selection Process
customer needs
operational needs
roadmap
strategy
competition
selection process
product specification
needcharacterizationrequirementphasing
Technology, People, Processcosts and constraints
Requirements Elicitation and Selection61 Gerrit Muller
version: 0March 6, 2013REQselection
Simple Qualification Methodim
porta
nt
urgentef
fort
value
do
don't discuss
discuss
do
don't discuss
discuss
Requirements Elicitation and Selection62 Gerrit Muller
version: 0March 6, 2013
REQqualitativeSelectionMatrix
Examples of Quantifiable Aspects
Value for the customer
(dis)satisfaction level for the customer Selling value (How much is the customer willing to pay?) Level of differentiation w.r.t. the competition
Impact on the market share
Impact on the profit marginUse relative scale, e.g. 1..5 1=low value, 5 -high valueAsk several knowledgeable people to scoreDiscussion provides insight (don't fall in spreadsheet trap)
Requirements Elicitation and Selection63 Gerrit Muller
version: 0March 6, 2013
MPBAvalueCriteria
Exercise Requirements Capturing
Determine the key drivers for one particular product family.
Translate these drivers into application drivers and derive from them the require-ments.
Exercise Requirements Capturing64 Gerrit Muller
version: 0March 6, 2013MREQexercise
Story How Toby Gerrit Muller Buskerud University College
e-mail: [email protected]
AbstractA story is an easily accessible story or narrative to make an application live. Agood story is highly specific and articulated entirely in the problem domain: thenative 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 projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 6, 2013status: conceptversion: 1.1
CustomerWhat
CustomerHow
ProductWhat
ProductHow
What does Customer need in Product and Why?
story caseanalyzedesign
designanalyzedesign
a priori solution knowledgemarketvision
Customerobjectives
Application Functional Conceptual Realization
From story to design
CustomerWhat
CustomerHow
ProductWhat
ProductHow
What does Customer need in Product and Why?
story caseanalyzedesign
designanalyzedesign
a priori solution knowledgemarketvision
Customerobjectives
Application Functional Conceptual Realization
Story How To66 Gerrit Muller
version: 1.1March 6, 2013
SHTfromStoryToDesign
Example story layout
A day in the life of Bobbla blah bla, rabarber musicbla bla composer bla blaqwwwety30 zeps.
nja nja njet njippie est quovadis? Pjotr jaleski bla blabla brree fgfg gsg hgrg
mjmm bas engel heeft eeninterressant excuus, lex steltvoor om vanavond door tewerken.
In the middle of the night heis awake and decides tochange the world forever.
The next hour the greatevent takes place:
This brilliant invention will change the world foreverbecause it is so unique andvaluable 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 willobsolete 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 trivialpassword, followed by a thorough authentication. The PDA asks for the fingerprint ofthis little left toe and to pronounce the word shit. After passing this test Bob cancontinue.
draft or sketch ofsome essential
applianceca. half a page ofplain English textYes
or
No
that is the question
Story How To67 Gerrit Muller
version: 1.1March 6, 2013
SHTexampleStoryLayout
Points of attention
purpose scope viewpoint, stakeholders visualization size (max 1 A4) recursive decomposition, refinement
Story How To68 Gerrit Muller
version: 1.1March 6, 2013
SHTattentionPoints
Criteria for a good story
accessible, understandable
valuable, appealing
critical, challenging
frequent, no exceptional niche
specific
"Do you see it in front of you?"
attractive, important"Are customers queuing up for this?"
"What is difficult in the realization?""What do you learn w.r.t. the design?"
names, ages, amounts, durations, titles, ...
"Does it add significantly to the bottom line?"
Customerobjectives
Application
Functional
Conceptual
Realization
Customerobjectives
Application
Application
Application
Story How To69 Gerrit Muller
version: 1.1March 6, 2013
SHTcriterionsList
Example of a story
Betty is a 70-year-old woman who lives in Eindhoven. Three years ago her husband passedaway 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 technicalappearance. She knows how to operate her television, but a VCR or even a DVD player isway to complex.When Betty turned 60, she stopped working in a sewing studio. Her work in this noisyenvironment made her hard-of-hearing with a hearing-loss of 70dB around 2kHz. The rest ofthe frequency spectrum shows a loss of about 45dB. This is why she had problemsunderstanding her grandchildren and why her children urged her to apply for hearing aids twoyears ago. Her technophobia (and her first hints or arthritis) inhibit her to change her hearingaids batteries. Fortunately her children can do this every weekend.This Wednesday Betty visits the weekly Bingo afternoon in the meetingplace of the old-folkshome. Its summer now and the tables are outside. With all those people there its a lot ofchatter and babble. Two years ago Betty would never go to the bingo: I cannot hear a thingwhen everyone babbles and clatters with the coffee cups. How can I hear the winningnumbers?!. Now that she has her new digital hearing instruments, even in the bingocacophony, she can understand everyone she looks at. Her social life has improved a lot andshe 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 thesparkling high piccolos. Her other friend Carol never joins their visits to the theaters. Carolalso has hearing aids, however hers only work well in normal conversations. When I hearmusic its as if a butchers knife cuts through my head. Its way too sharp!. So Carol prefers totake her hearing aids out, missing most of the fun. Betty is so happy that her hearinginstruments simply know where they are and adapt to their environment.
source: Roland MathijssenEmbedded Systems Institute
Eindhoven
Story How To70 Gerrit Muller
version: 1.1March 6, 2013
SHTexample
Value and Challenges in this story
Challenges in this story:Intelligent hearing instrumentBattery life at least 1 weekNo buttons or other fancy user interface on the hearing instrument,other than a robust On/Off methodThe user does not want a technical device but a solution for a problemInstrument can be adapted to the hearing loss of the userDirectional sensitivity (to prevent the so-called cocktail party effect)Recognition of sound environments and automatic adaptation (adaptivefiltering)
source: Roland Mathijssen, Embedded Systems Institute, Eindhoven
Conceptual
Realization
Customerobjectives
Application
Value proposition in this story:quality of life:
active participation in different social settingsusability for nontechnical elderly people:
"intelligent" system is simple to useloading of batteries
Story How To71 Gerrit Muller
version: 1.1March 6, 2013
SHTexampleCriteria
Concept Selection, Set Based Design and LateDecision Making
by Gerrit Muller Buskerud University Collegee-mail: [email protected]
www.gaudisite.nl
AbstractWe discuss a systems design approach where several design options are maintainedconcurrently. In LEAN Product Development this is called set-based design. Concen-tioanl systems engineering also promotes the concurrent evaluation of multipleconcepts, the so-called concept selection. Finally, LEAN product developmentadvocates to keep options open as long as feasible; the so-called late decisionmaking.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 6, 2013status: plannedversion: 0
1
2
3
4
1'
2'
3'
4'
1"
2"
3"
4"
2"'
5
1"'
3"' 3""
5"5'
B
A
B' B" B'"
A'
time
Problem Solving Approach
1. Problem understanding byexploration and simple models
2. Analysis by+ exploring multiple propositions (specification + design proposals)+ exploring decision criteria (by evaluation of proposition feedback)
+ assessment of propositions against criteria
3. Decision by+ review and agree on analysis+ communicate and document
4. Monitor, verify, validate by+ measurements and testing
+ assessment of other decisions
insufficient datano satisfying solution
invalidated solution
conflicting other decision
vague problem statement
Concept Selection, Set Based Design and Late Decision Making73 Gerrit Muller
version: 0March 6, 2013
TORdecisionFlow
Examples of Pugh Matrix Application
Swivel concept selectionconnectors in
hubwith roll-off
connectors inhub
wirelessconnection
two sidedconnectors
clamp swivel dynamicswivel
CBV swivel
1290
from master paper Halvard Bjrnsen, 2009
MaturityDevelopment levelCostHardware costDevelopment costDesign robustnessDesign life
swivel cyclespressure cycles
Pressure rangeinternalexternal
Temperature rangeInstallationInitial installatio/retrievalConnection/disconnection
OperationSwivel resistanceSpool Length ShortSpool Length LongHub loads
10
20
25
25
20
evaluation criteria weight
5
45
55
424
2311
22
50752525
4040
10050
100125125
100
50
80
2
22
43
454
4544
43
100125100100
8060
100125100100
75
40
20
40
2
52
53
424
5555
54
125125125125
10080
10050
100125
75
40
50
100
985 1165points
CBV clamp dynamic
from master paper Dag Jostein Klever, 2009
Time to connectNeed for ROVDesign
RobustnessConnector designNumber of partsHandle roll-offInfluence other
RedundancyDesignInterchangeability
CostHW costManufacturing costEngineering costService cost
Maturity
- + + +- + + +
- S S +- - + ++ - S ++ S - S
+ - - S+ - - -
- - - -
S S - S+ - S -- + + +- - S +
7 7 5 31 3 4 35 3 4 7
Evaluation Criteria 1 2 3 4Concepts
Score
-
S+
3 4 2 1Pos.
EDP-LRP connection
Concept Selection, Set Based Design and Late Decision Making74 Gerrit Muller
version: 0March 6, 2013
CSSBpughExamples
Evolution of Design Options
1
2
3
4
1'
2'
3'
4'
1"
2"
3"
4"
2"'
5
1"'
3"' 3""
5"5'
B
A
B' B" B'"
A'
time
Concept Selection, Set Based Design and Late Decision Making75 Gerrit Muller
version: 0March 6, 2013
CSSBsetEvolution
Conclusions
Evolving multiple concepts increases insight and understanding(LEAN product development: set-based design, SE: Pugh matrix)
Articulation of criteria sharpens evaluation
The discussion about the Pugh matrix is more valuable than finalbottomline summation
Delaying decisions may help to keep options (Lean ProductDevelopment: late decision making, finance: real options)
Concept Selection, Set Based Design and Late Decision Making76 Gerrit Muller
version: 0March 6, 2013
CSSBconclusions
Qualities as Integrating Needlesby Gerrit Muller Buskerud University College
e-mail: [email protected]
AbstractMany stakeholder concerns can be specified in terms of qualities. These qualitiescan be viewed from all 5 CAFCR viewpoints. In this way qualities can be usedto relate the views to each other.
The meaning of qualities for the different views is described. A checklist of qualitiesis provided as a means for architecting. All qualities in the checklist are describedbriefly.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 6, 2013status: finishedversion: 1.3
ApplicationCustomerobjectives
Functional Conceptual Realization
safety
evolvability
usability
Quality needles as generic integrating concepts
ApplicationCustomerobjectives
Functional Conceptual Realization
safety
evolvability
usability
Qualities as Integrating Needles78 Gerrit Muller
version: 1.3March 6, 2013
QNneedles
Security as example through all views
ApplicationCustomerobjectives
Functional Conceptual Realization
sensitiveinformation
trusted
not trusted
selectionclassification
peopleinformation
authenticationbadgespasswords
locks / wallsguardsadministrators
social contactsopen passwordsblackmailburglaryfraudunworkable procedures
cryptographyfirewallsecurity zonesauthenticationregistrylogging
holes betweenconcepts
functions foradministrationauthenticationintrusion detectionlogging
quantification
bugsbuffer overflownon encrypted
storagepoor exception
handling
missingfunctionality
wrongquantification
specificalgorithmsinterfaceslibrariesserversstorageprotocols
desired characteristics, specifications & mechanisms
threats
Qualities as Integrating Needles79 Gerrit Muller
version: 1.3March 6, 2013
QNsecurityExample
Quality Checklist
usabilityattractivenessresponsivenessimage qualitywearabilitystorabilitytransportability
usable
safetysecurityreliabilityrobustnessintegrityavailability
dependable
throughput orproductivity
effective
serviceabilityconfigurabilityinstallability
serviceable
liabilitytestabilitytraceabilitystandards compliance
liable
ecological footprintcontaminationnoisedisposability
ecological
reproducibilitypredictability
consistent
efficientresource utilizationcost of ownership
cost pricepower consumptionconsumption rate
(water, air,chemicals,et cetera)
size, weightaccuracy
down to earthattributes
manufacturabilitylogistics flexibilitylead time
logistics friendly
evolvabilityportabilityupgradeabilityextendibilitymaintainability
future proof
interoperableconnectivity3rd party extendible
Qualities as Integrating Needles80 Gerrit Muller
version: 1.3March 6, 2013
QNchecklist
System Partitioning Fundamentalsby Gerrit Muller Buskerud University College
e-mail: [email protected]
AbstractThe fundamental concepts and approach system partitioning are explained. Welook at physical decomposition and functional decomposition in relation to supplychain, lifecycle support, project manageemnt, and system specification and design.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 6, 2013status: preliminarydraftversion: 0.1
system
subsystem 1
subsystem 2
subsubsystem A
subsubsystem B
subsubsystem A
subsubsystem B
subsubsystem N
subsubsystem N
atomicpart
atomicpart
atomicpart
subsystem n
subsubsystem A
subsubsystem B
subsubsystem N
Engineering
engineeringsystem specification
system design
parts data base
production procedures
qualification procedures
system documentation
procurement
production
installation
lifecyclesupport
qualityassurance
ERP PDMSCMCAD
mechanicalelectricaldesign
database
sourcecode
management
resourceplanning,e.g. SAP
productdata
management
docDB
projectdocuments
know-ledge
DB
source data
engineering knowledge
pastexperience
System Partitioning Fundamentals82 Gerrit Muller
version: 0.1March 6, 2013
SPFengineering
Example Physical Decomposition
Fluidicsubsystem
chamber
bottom chuck
electronicsinfrastructure
processpowersupply
1
3
2
4
5electronics
infrastructure1 5granite
ZUBA
stage
frame
base frame +x, y, stage
stagecontrol
ZUBAcontrol
opticsstage
scoop
cameravision
optic
s st
age
cont
rol
visioncontrol
6
7
8
9
10
cabling
covers andhatches
ventilationair flow
contaminationevacuation
sensorsmeasurement
frame
machinecontrol
"remote"electronics rack
10
11
12
13
14
15
?
back side view front side view integrating
System Partitioning Fundamentals83 Gerrit Muller
version: 0.1March 6, 2013
REPLIsubsystemsAll
Partitioning is Applied Recursively
system
subsystem 1
subsystem 2
subsubsystem A
subsubsystem B
subsubsystem A
subsubsystem B
subsubsystem N
subsubsystem N
atomicpart
atomicpart
atomicpart
subsystem n
subsubsystem A
subsubsystem B
subsubsystem N
System Partitioning Fundamentals84 Gerrit Muller
version: 0.1March 6, 2013SPFrecursion
Software plus Hardware Decomposition
tuner frame-buffer MPEG DSP CPU RAM
drivers scheduler OS
etc
audio video TXT file-systemnetworkingetc.
view PIP
browseviewport menu
adjust viewTXT
hardware
driver
applications
servicestoolboxes
domain specific generic
signal processing subsystem control subsystem
System Partitioning Fundamentals85 Gerrit Muller
version: 0.1March 6, 2013
CVconstructionDecomposition
Guidelines for Partitioning
the part is cohesive
the coupling with other parts is minimal
the part is selfsustained for production and qualification
clear ownership of part
functionality and technology belongs together
minimize interfaces
can be in conflict with cost or space requirements
e.g. one department or supplier
System Partitioning Fundamentals86 Gerrit Muller
version: 0.1March 6, 2013
SPFpartitioningGuidelines
How much self-sustained?
mainfunction
powerconversion
powerdistribution
powerstabilization
cooling EMCshielding
productionsupport
adjustmentsupport
qualificationsupport
controlinterface
controlelectronics
mechanicalpackage
control SW applicationSW HMI SW
cost/speed/spaceoptimization
How self sustained should a part be?trade-off:
logistics/lifecycle/productionflexibility
clarity
System Partitioning Fundamentals87 Gerrit Muller
version: 0.1March 6, 2013
SPFselfSustained
Decoupling via Interfaces
parte.g. pressure
and flowregulator
parte.g. pipe
parte.g. pipe
hydrocarboninterface
powerinterface
controlinterfacee.g. CAN
mechanicalmounting interface
other part withsame interfaces
can replaceoriginal
System Partitioning Fundamentals88 Gerrit Muller
version: 0.1March 6, 2013
SPFinterfaceDecoupling
The Ideal Modularity
System is composed
by using standard interfaces
limited catalogue of variants (e.g. cost performance points)
System Partitioning Fundamentals89 Gerrit Muller
version: 0.1March 6, 2013
SPFmodularityGame
System Creation
engineering
design
architecting
procurement
production
installation
lifecyclesupport
qualityassurance
specification
designpartitioning
interfacesfunctionsallocation
architectureguidelines
top-level designrationale
stakeholderneeds
businessobjectives
documentationsystem and parts data
procedures
System Partitioning Fundamentals90 Gerrit Muller
version: 0.1March 6, 2013
SPFsystemCreation
Simplistic Functional SubSea Example
preventblow-outs
regulateflow andpressure
hydrocarbonsfrom well
increasewell
pressure
separategas, oil,
water, sand watersand
transport totop-side
measurepressure,temp, flow
controlpressure,temp, flow
sensorsignals
sensordata
settings
hydrocarbons
combinemultiplestreams
System Partitioning Fundamentals91 Gerrit Muller
version: 0.1March 6, 2013
SPFfunctionalExample
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
System Partitioning Fundamentals92 Gerrit Muller
version: 0.1March 6, 2013
SPFfunctionalDecomposition
Quantification
Size
Weight
Cost
Reliability
Throughput
Response time
Accuracy
2.4m * 0.7m * 1.3m
1450 Kg
30000 NoK
MTBF 4000 hr
3000 l/hr
0.1 s
+/- 0.1%
many characteristicsof a system, function or part
can be quantified
Note that quantitieshave unit
System Partitioning Fundamentals93 Gerrit Muller
version: 0.1March 6, 2013
SPFquantification
Question Generator
accuracy
scannerPIM finisher
throughputmemory footprint
response time
processing load
solvingpaper jam
copying
preparing
printing What is the accuracy ofthe fuse
when printingpaper path fuse
func
tions
component
chara
cteris
tics
when performing
?of the
How about the
example from a high volume printer
System Partitioning Fundamentals94 Gerrit Muller
version: 0.1March 6, 2013
BS05questionGenerator
Example Technical Budget
processoverlay80 nm
reticule15 nm
matchedmachine
60 nmprocess
dependencysensor
5 nm
matchingaccuracy
5 nm
singlemachine
30 nm
lensmatching
25 nm
globalalignmentaccuracy
6 nm
stageoverlay12 nm
stage gridaccuracy
5 nm
systemadjustmentaccuracy
2 nm
stage Al.pos. meas.accuracy
4 nm
off axis pos.meas.
accuracy4nm
metrologystability5 nm
alignmentrepro5 nm
positionaccuracy
7 nm
framestability2.5 nm
trackingerror phi75 nrad
trackingerror X, Y2.5 nm
interferometerstability
1 nm
blue alignsensorrepro3 nm
off axisSensorrepro3 nm
trackingerror WS
2 nm
trackingerror RS
1 nm
System Partitioning Fundamentals95 Gerrit Muller
version: 0.1March 6, 2013
ASMLoverlayBudget
Example of A3 overview
A3 architecture overview of the Metal Printer (all numbers have been removed for competitive sensitivity)
process steps
metal printing cell
Fluidicsubsystem
chamber
bottom chuck
electronicsinfrastructure
processpowersupply
1
3
2
4
5electronics
infrastructure1 5granite
ZUBA
stage
frame
base frame +x, y, stage
stagecontrol
ZUBAcontrol
opticsstage
scoop
cameravision
optic
s st
age
cont
rol
visioncontrol
6
7
8
9
10
cabling
covers andhatches
ventilationair flow
contaminationevacuation
sensorsmeasurement
frame
machinecontrol
"remote"electronics rack
10
11
12
13
14
15
?
metal printer back side metal printer front side integratingsubsystems
metal printer subsystems
tprepare = tclose doors + tmove to proximity
tprint = tp,prepare+ tp,align + tchamber(thickness) + tp,finalize
tfinalize = tmove to unload + topen doors
tprint = tp,overhead+ Ctransfer*thickness
2. Align
3. Move to proximity
4. Process
6. Open doors
1. Close doors
5. Move substrate unloading position
talign
tchamber
note: original diagram was annotated with actual performance figuresfor confidentiality reasons these numbers have been removed
metal printerfunctional flow formula print cycle time
key performance parameters
metal printer subsystems, functions, and cycle time model
metal printing cell: systems and performance model
back-end factory: systems and process model
pattern quality
cost per layer
environmentalimpact
design enablinge.g. CD, separation
patternresolution
X-section control
accuracy overlay
high MTBFearly delivery
vsvolume production
uptime
throughput
operationalcosts
system cost
electric powerclean waterelyteN2, airdisposal water, air, ...
reliability
integral costs
consumableswaste
contaminationand climate
partial graphmany nodes
and connectionsare not shown
customer key drivers
Customer key-drivers and Key Performance Parameters
Document meta-information
authorversiondate last update
scopestatus
Gerrit Muller0.1August 3, 2010
system and supersystempreliminary draft
metal printing time-line
min. line widthoverlaythroughputMTBF
a mb mc WPHd hr
wafer sizepowerclean room classfloor vibration class
200, 300 mmx kW
throughput
1. inspection
2. seed sputter
3. metal print
4. seed etch
wafer
waferseed
waferCu
wafer
5. coat/develop dielectricswafer
6. exposure or CMP for polymer viaswafer
7. E-test
spin coatedpolymer
per waferthroughput in minutes
1
t
1
3..4
1..2
dual layer only
robot
prefill
masterFOUP
waferFOUP
waferFOUP flip
prealigncleanwafer
cleanmaster
metalprinter
robot
prealigncleanmaster
prefill
clean wafer
0 100b 200b
waferwithICs
back-end factory
exposewafer
stepper
exposewafer
stepper
metalprinter
advancedprocesscontrol
logistics &automation
powerchemicals
climateinfrastructure
computing &networking
infrastructure
metrologymask
power, chemicalsconsumables, waste
ICs
REX
wafer fab(front end)
System Partitioning Fundamentals96 Gerrit Muller
version: 0.1March 6, 2013
LEANoverviewA3