all about systems engineering; introductory course

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.


tender design andengineering installation

operation andmaintenance disposal

offer

order

acceptancefinal payment

Project Life Cycle



offer

order

acceptancefinal payment

Project Systems Engineering Introduction; Phasing, Process, Organization4 Gerrit Muller


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


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


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



PCPbusinessPhases

Evolutionary PCP model

requirementsspecification

designbuild

test andevaluate

2% of budget (EVO)2 weeks (XP)

up to 2 monthsper cyclus



PCPspiral

Reuse and Products

reus

epr

oduc

ts

reus

esp

ecs

reus

epr

oduc

ts

reus

esp

ecs









PSEIPreuseAndProducts

Simplified Process View

strategyprocess

customer

supplying business

value

product creationprocess

customer oriented (sales,service, production) process

people, process and technologymanagement process



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!



RSPprocessDecompositionAnnotated

Simplified process diagram for project business

systems architecting

tender projectexecution

product creation

deploymentcontract systems

products orcomponents

policy andplanning

people, process, and technology management



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



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



PCPoperationalOrganization

Prime Responsibilities of the Operational Leader

Resources Time

Specification

Quality



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



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



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



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



The Role and Task of the System Architectby Gerrit Muller Buskerud University Collge


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


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


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



RSAdeliverablesSpecific

Responsibilities of the System Architect

systemsubsystem

Balance Consistency

module

Overview

RequirementSpec

DesignRealization

DecompositionIntegration

modules

Func

tionQuality

KISS

EleganceSimple Integrity Fitting

satisfiedstakeholders

system

context



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



RSAsecondaryResponsibilities

What does the System Architect do?

V4aa

IO

design,brainstorm,

explain

Idea

think,analyze


BlahBlah

write,consolidate,

browse


discuss

read,review

Design

Spec

Report

test,integrate


schedule, risks


conference



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



RSAdetailHierarchy

Reality or Virtuality?

Abstractions only exist for concrete facts.



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



RSApyramid

The Awakening of a System Architectby Gerrit Muller Buskerud University College


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



roottechnical

knowledge

generalisttechnical

knowledge

business,application insight

process insightpsychosocial

skills

Typical Growth of a System Architect

roottechnical

knowledge

generalisttechnical

knowledge



skills

The Awakening of a System Architect30 Gerrit Muller


MATsystemArchitectGrowth

Generalist versus Specialist

spec

ialis

tgeneralist

rootknowledge

breadth ofknowledge

dept

h of

kn

owle

dge



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



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



MATfromSpecialistToSystemArchitect

Architecting Interaction Stylesby Gerrit Muller Buskerud University College


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


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


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


BlahBlah

write,consolidate,

browse


discuss

read,review

Design

Spec

Report

test,integrate


schedule, risks


conference


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



Personal characteristics of a System Architect

Typical growth of a Architect

roottechnical

knowledge

generalisttechnical

knowledge



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



Module Requirementsby Gerrit Muller Buskerud University College


AbstractThis module addresses requirements: What are requirements? How to find,select, and consolidate requirements?

Distribution



Fundamentals of Requirements Engineeringby Gerrit Muller Buskerud University College


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



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



REQwhatWhatHow

System as a Black Box

system seen as black box

inputs outputsfunctionsquantified characteristics

restrictions, prerequisitesboundaries, exceptionsstandards, regulations

interfaces



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)



REQstakeholders

The Formal Requirements for Requirements

Specific

Unambiguous

Verifiable

Quantifiable

Measurable

Complete

Traceable



REQrequirementsForRequirementsList

The Requirements to Enable Human Use

Accessible

Understandable

Low threshold



REQrequirementsFromHumans

Short introduction to basic CAFCR modelby Gerrit Muller Buskerud University College


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



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


drives, justifies, needsenables, supports

Customerobjectives


Short introduction to basic CAFCR model48 Gerrit Muller


CAFCRannotated

Integrating CAFCR

Customerobjectives


intention

constraintawareness

objectivedriven

contextunderstanding

oppor-tunities

knowledgebased

CustomerWhat

CustomerHow

ProductWhat

ProductHow




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



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



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



BCAFCRwhoIsTheCustomer

CAFCR+ model; Life Cycle View

Customerobjectives


Life cycleoperationsmaintenanceupgrades

developmentmanufacturing

installation

sales, service, logistics, production, R&D



BCAFCRplusLifeCycle

Key Drivers How Toby Gerrit Muller Buskerud University College


AbstractThe notion of business key drivers is introduced and a method is described tolink these key drivers to the product specification.

Distribution



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


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



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



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



REQfromDriverToRequirement

Requirements Elicitation and Selectionby Gerrit Muller Buskerud University College


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


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


version: 0March 6, 2013REQselection

Simple Qualification Methodim

porta

nt

urgentef

fort

value

do

don't discuss

discuss

do

don't discuss

discuss



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)



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


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



CustomerWhat

CustomerHow

ProductWhat

ProductHow


story caseanalyzedesign

designanalyzedesign

a priori solution knowledgemarketvision

Customerobjectives


From story to design

CustomerWhat

CustomerHow

ProductWhat

ProductHow


story caseanalyzedesign

designanalyzedesign

a priori solution knowledgemarketvision

Customerobjectives


Story How To66 Gerrit Muller


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



SHTexampleStoryLayout

Points of attention

purpose scope viewpoint, stakeholders visualization size (max 1 A4) recursive decomposition, refinement



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



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



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



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


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


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



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



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)



CSSBconclusions

Qualities as Integrating Needlesby Gerrit Muller Buskerud University College


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


March 6, 2013status: finishedversion: 1.3

ApplicationCustomerobjectives

Functional Conceptual Realization

safety

evolvability

usability

Quality needles as generic integrating concepts



safety

evolvability

usability

Qualities as Integrating Needles78 Gerrit Muller


QNneedles

Security as example through all views



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



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



QNchecklist

System Partitioning Fundamentalsby Gerrit Muller Buskerud University College


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



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


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



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


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



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



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



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



SPFinterfaceDecoupling

The Ideal Modularity

System is composed

by using standard interfaces

limited catalogue of variants (e.g. cost performance points)



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



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



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



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



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



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



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

print

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)



LEANoverviewA3

all about systems engineering; introductory course

Documents

project phasing

frequent feedback

project leader

gaud project philosophy

spiral model

life cycle context

anopen creation process

mature version toget