all about systems engineering; introductory course - gaud system

All About Systems Engineering; Introductory Courseby Gerrit Muller

University of South-Eastern Norway-NISE

Abstract

This introductory course sketches all fundamentals of Systems Engineering.Starting at the business contexts, touching Project, Processes, and Organization.The role of the Systems Engineer is discussed, and the relation with other roles,e.g. project leader and product manager. The architecting and design tools areshown; from Stakeholder Needs to Requirements to Modeling and Analysis.

Distribution

This article or presentation is written as part of the Gaudíproject. The Gaudí project philosophy is to 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 7, 2019status: preliminarydraftversion: 0.2

more theory and exercisestheory and cases

introduction to SE,

process, organizationcase, phasing, V-Model, spiral model,

relation with other business disciplines

organization and process

in practiceexercise and discussion

product families, products vs projects

design and concept

selection in practiceexercise and discussion

example case to wrap-up

creating the big pictureexercise and discussion

roadmapping, key performance

parameters

capturing customer

understandingexercise and discussion

customer key drivers, story telling,

scenarios and use cases

systems engineer role and

taskdeliverables, responsibilties, activities,

styles, characteristics

system contextcustomer context, life cycle context,

stakeholders, needs, concerns,

requirements, story telling, conops, use

cases

system designconcept selection, physical

decomposition, functional

decomposition, qualities, interface

management, 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 and

taskdeliverables, responsibilties, activities,

styles, characteristics

system contextcustomer context, life cycle context,

stakeholders, needs, concerns,

requirements, story telling, conops, use

cases

system designconcept selection, physical

decomposition, functional

decomposition, qualities, interface

management, budgeting, modeling

day 1

day 2

morning afternoon

morning afternoon

All About Systems Engineering; Introductory Course2 Gerrit Muller

version: 0.2March 7, 2019

SEINTROprogram2day

Project Systems Engineering Introduction; Phasing,Process, Organization

by Gerrit Muller University of South-Eastern Norway-NISEe-mail: [email protected]

www.gaudisite.nl

Abstract

The 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.


tenderdesign and

engineeringinstallation

operation and

maintenancedisposal

offer

order

acceptance

final payment

Project Life Cycle

tenderdesign and


operation and

maintenancedisposal

offer

order

acceptance

final payment

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


PSEIPprojectLifeCycle

Phased Project Approach

needs

design

verification

engineering

core information

in draft50%

most information

available in

concept

information is stable

enough to use

heavier change control

Legend:

specification

preparing or updating workfull under development

0.

feasibility

1.

definition

2.

system

design

3.

engineering

4.

integration

& test

5.

field

monitoring

tender design and engineering installationoperation and

maintenance

DR DR DR


version: 0.2March 7, 2019PSEIPphases

V-Model

needs

specification

system design

subsystem design

component design

component realization

component test

subsystem test

system test

verification

validation


version: 0.2March 7, 2019TPSEPvModel

All Business Functions Participate

0.

feasibility

1.

definition

2.

system

design

3.

engineering

4.

integration

& test

5.

field

monitoring

sales

logistics

production

service

development & engineering: marketing, project management, design



PCPbusinessPhases

Evolutionary PCP model

requirements

specification

designbuild

test and

evaluate

2% of budget (EVO)

2 weeks (XP)

up to 2 months

per cyclus



PCPspiral

Reuse and Products

reuse

pro

ducts

reuse

specs

reuse

pro

ducts

reuse

specs

tenderdesign and


operation and

maintenancedisposal

tenderdesign and


operation and

maintenancedisposal

tenderdesign and


operation and

maintenancedisposal



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

tenderproject

execution

product creation

deploymentcontract systems

products or

components

policy and

planning

people, process, and technology management



PPSprojectProcess

Decomposition of the Product Creation Process

Product Creation Process

Operational

Management

Design

ControlMarketing

specification

budget

time

technical profitability

saleability

needs

specification

design

engineering

what is needed

what will be realized

how to realize

how to produce

and to maintain

customer input

customer expectations

market introduction

introduction at customer

feedback

product pricing

commercial structureplanning

progress control

resource

management

risk management

project log

verification

meeting specs

following design



PCPdecomposition

Operational Organization of the PCP

subsystem

singleproduct

productfamily

entireportfolio

developersmodule

portfolio

operational

manager

family

operational

manager

(single product)

project

leader

subsystem

project

leader

operational

portfolio

architect

family

architect

product

architect

subsystem

architect

technical

portfolio

marketing

manager

family

marketing

manager

product

manager

commercial



PCPoperationalOrganization

Prime Responsibilities of the Operational Leader

Resources Time

Specification

Quality



PCPoperationalTriangle

The Rules of the Operational Game

assess risks

determine feasibility

define project

update projectspecification, resources, time

business management project leader

accept or reject

execute project

within normal

quality rules

accept



PCPoperationalGame

Operational Teams

Operational Leader

(project leader)

Operational Support

(project manager)

Marketing or

Product Manager

Architect

Application

Manager

Test Engineer

Service Manufacturing

LogisticsSales

Manager Quality

Assurance

Requirements

AnalystSubsystem

Operational

Leaders

Subsystem

ArchitectsTechnology-

Specific

Architects

Development

support



PCPconcentricTeams

What Service Level to Deliver?

initial production

expert support

use results

technical

capability

functional

capability

customer support

facility management conventional

maintenance

contract

product

acceptance

and warranty

capability management

performance-based

or service-level

agreement

factory



PPSservicesOperationalModel

Systems Engineering Management Plan (SEMP)

How the project will perform the systems engineering process:

· main events and activities

· roles and responsibilities

· work products

· procedures and standards

Bridge between project management and engineering (NASA

2016)



PSEIPsemp

Role and Task of the System Architectby Gerrit Muller University of South-Eastern Norway-NISE

e-mail: [email protected]

Abstract

The 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


Abstract

The 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 7, 2019status: conceptversion: 2.0

V4aa

IO

design,

brainstorm,

explain

Idea

think,

analyze

listen, talk,

walk around

Blah Blah

write,

consolidate,

browse

present,

meet, teach,

discuss

read,

review

Design

Sp

ec

Report

test,

integrate

assist project leader

with work breakdown,

schedule, risks

travel to

customer,

supplier,

conference

provide

vision and

leadership

Deliverables of the System Architect

Spec DesignReport

Re

po

rt

ReportDesign

Design

SpecSpec

The Role and Task of the System Architect22 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

system

subsystem

Balance Consistency

module

Overview

RequirementSpec

DesignRealization

Decomposition

Integration

modules

FunctionQ

uality

KISS

Elegance

Simple Integrity Fitting

satisfied

stakeholderssystem

context



RSAresponsibilities

Examples of Secondary Responsibilities

responsibility

business plan, profit

schedule, resources

market, saleability

technology

process, people

detailed designs

primary owner

business manager

project leader

marketing manager

technology manager

line manager

engineers



RSAsecondaryResponsibilities

What does the System Architect do?

V4aa

IO

design,

brainstorm,

explain

Idea

think,

analyze

listen, talk,

walk around

Blah Blah

write,

consolidate,

browse

present,

meet, teach,

discuss

read,

review

Design

Sp

ec

Report

test,

integrate



schedule, risks

travel to

customer,

supplier,

conference

provide

vision and

leadership


version: 2.0March 7, 2019RSAactivities

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)

architect

time per

item

100 h

1 h

10 min

meetings

consolidation

in

deliverables

informal

contacts

product details

sampling

scanning

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

Sp

ec

Report

system

subsystem

module

Requirement

Spec

Design

Realization

modules

Fun

ctio

nQuality

KISS

Activities

Responsibilities

DeliverablesDec

reas

ing

Vis

ibili

ty

Spec DesignReport

Re

po

rt

Report

Design

Design

Spec

Spec

From Manager perspective



RSApyramid

The Awakening of a System Architectby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

The 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



root

technical

knowledge

generalist

technical

knowledge

business,

application insight

process insight

psychosocial

skills

Typical Growth of a System Architect

root

technical

knowledge

generalist

technical

knowledge

business,

application insight

process insight

psychosocial

skills

The Awakening of a System Architect31 Gerrit Muller


MATsystemArchitectGrowth

Generalist versus Specialist

sp

ecia

list

generalist

root

knowledge

breadth ofknowledge

dep

th o

fkn

ow

led

ge



MATgeneralistVsSpecialist

Generalists and Specialists are Complementary

sp

ecia

list

sp

ecia

list

sp

ecia

list

sp

ecia

list

sp

ecia

list

sp

ecia

list

sp

ecia

list

sp

ecia

list

generalistgeneralist

breadth ofknowledge

dep

th o

fkn

ow

led

ge



MATcomplementaryExpertises

Spectrum from Specialist to System Architect

all-

rou

nd

sp

ecia

list systems architect

sp

ecia

list

root

knowledge

aspect

architect

breadth ofknowledge

dep

th o

fkn

ow

led

ge



MATfromSpecialistToSystemArchitect

Architecting Interaction Stylesby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

A 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 7, 2019status: draftversion: 0.2

provocation

facilitation

leading

empathic

interviewing

whiteboard simulation

judo tactics

when in an impasse: provoke effective when used sparsely

especially recommended when new in a field: contribute to the team, while absorbing new knowledge

provide vision and direction, make choices risk: followers stop to give the needed feedback

take the viewpoint of the stakeholder acknowledge the stakeholder's feelings, needs, concerns

investigate by asking questions

invite a few engineers and walk through the system operation step by step

first listen to the stakeholder and then explain cost and alternative opportunities

Architecting Styles

provocation

facilitation

leading

empathic

interviewing

whiteboard simulation

judo tactics

when in an impasse: provoke effective when used sparsely

especially recommended when new in a field: contribute to the team, while absorbing new knowledge

provide vision and direction, make choices risk: followers stop to give the needed feedback

take the viewpoint of the stakeholder acknowledge the stakeholder's feelings, needs, concerns

investigate by asking questions

invite a few engineers and walk through the system operation step by step

first listen to the stakeholder and then explain cost and alternative opportunities

Architecting Interaction Styles36 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 Architect37 Gerrit Muller

version: 0.2March 7, 2019MRSAexercise

Role and Task of a System Architect

Deliverables

Spec DesignReport

Re

po

rt

ReportDesign

Design

SpecSpec

Responsibilities

system

subsystem

Balance Consistency

module

Overview

RequirementSpec

DesignRealization

Decomposition

Integration

modules

FunctionQ

uality

KISS

Elegance

Simple Integrity Fitting

satisfied

stakeholderssystem

context

Daily ActivitiesV4aa

IO

design,

brainstorm,

explain

Idea

think,

analyze

listen, talk,

walk around

Blah Blah

write,

consolidate,

browse

present,

meet, teach,

discuss

read,

review

Design

Sp

ec

Report

test,

integrate



schedule, risks

travel to

customer,

supplier,

conference

provide

vision and

leadership

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)

architect

time per

item

100 h

1 h

10 min

meetings

consolidation

in

deliverables

informal

contacts

product details

sampling

scanning

0.1105

0.5

1 sec106

1010



Personal characteristics of a System Architect

Typical growth of a Architectroot

technical

knowledge

generalist

technical

knowledge

business,

application insight

process insight

psychosocial

skills

Generalist vs Specialist

sp

ecia

list

generalist

root

knowledge

breadth ofknowledge

dep

th o

fkn

ow

led

ge

Complementary Roles

sp

ecia

list

sp

ecia

list

sp

ecia

list

sp

ecia

list

sp

ecia

list

sp

ecia

list

sp

ecia

list

sp

ecia

list

generalistgeneralist

breadth ofknowledge

dep

th o

fkn

ow

led

ge

Role Spectrum

all-

rou

nd

sp

ecia

list systems architect

sp

ecia

list

root

knowledge

aspect

architect

breadth ofknowledge

dep

th o

fkn

ow

led

ge



Module Requirementsby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

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

Distribution



Fundamentals of Requirements Engineeringby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

Requirements engineering is one of the systems engineering pillars. In thisdocument we discuss the fundamentals of systems engineering, such as thetransformation of needs into specification, the need to prescribe what rather thanhow, and the requirements when writing requirements.

Distribution



system seen as black box

inputs outputsfunctions

quantified characteristics

restrictions, prerequisites

boundaries, exceptions

standards, regulations

interfaces

Definition of “Requirement”

Requirements describing the needs of the customer:

Customer Needs

Requirements describing the needs of the company itself

over the life cycle: Life Cycle Needs

Requirements describing the characteristics of the final

resulting system (product): System (Product)

Specification

The requirements management process recursively

applies this definition for every level of decomposition.

Fundamentals of Requirements Engineering42 Gerrit Muller

version: 0.1March 7, 2019REQdefinition

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

choices

trade-offs

negotiations



REQwhatWhatHow

System as a Black Box

system seen as black box

inputs outputsfunctions

quantified characteristics

restrictions, prerequisites

boundaries, exceptions

standards, 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 University of South-Eastern Norway-NISE


Abstract

The 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



Customer

What

Customer

How

Product

What

Product

How

What does Customer need

in Product and Why?

drives, justifies, needs

enables, supports

Customer

objectives

Application Functional Conceptual Realization

The “CAFCR” model

Customer

What

Customer

How

Product

What

Product

How


in Product and Why?

drives, justifies, needs

enables, supports

Customer

objectives


Short introduction to basic “CAFCR” model49 Gerrit Muller


CAFCRannotated

Integrating CAFCR

Customer

objectives


intention

constraintawareness

objectivedriven

contextunderstanding

oppor-tunities

knowledgebased

Customer

What

Customer

How

Product

What

Product

How


in Product and Why?



MSintegratingCAFCR

CAFCR can be applied recursively

System

(producer)

Customer

BusinessDrives

Enables

Customer's

Customer

BusinessDrives

Enables

ConsumerDrives

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

segmentation

axis

outlet retailer, provider, OEM, consumer direct



BCAFCRcustomerSegmentation

Example of a small buying organization

decision maker(s) purchaser

maintainer

operator

user

CEO

CFO

CTO

CIO

department head

Who is the customer?

CMO

CEO: Chief Executive Officer

CFO: Chief Financial Officer

CIO: Chief Information Officer

CMO: Chief Marketing Officer

CTO: Chief Technology Officer



BCAFCRwhoIsTheCustomer

CAFCR+ model; Life Cycle View

Customer

objectives


Life cycleoperations

maintenance

upgrades

development

manufacturing

installation

sales, service, logistics, production, R&D



BCAFCRplusLifeCycle

Key Drivers How Toby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

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

Distribution



Safety

Effective

Flow

Smooth

Operation

Environment

Reduce accident rates

Enforce law

Improve emergency

response

Reduce delay due to accident

Improve average speed

Improve total network throughput

Optimize road surface

Speed up target groups

Anticipate on future traffic condition

Ensure traceability

Ensure proper alarm handling

Ensure system health and fault indication

Reduce emissions

Early hazard detection

with warning and signaling

Maintain safe road

condition

Classify and track dangerous

goods vehicles

Detect and warn

noncompliant vehicles

Enforce speed compliance

Enforce red light compliance

Enforce weight compliance

Key-drivers Derived application drivers Requirements

Automatic upstream

accident detection

Weather condition

dependent control

Deicing

Traffic condition

dependent speed control

Traffic speed and

density measurement

Note: the graph is only partially elaborated

for application drivers and requirements

Cameras

Example Motorway Management Analysis

Safety

Effective

Flow

Smooth

Operation

Environment


Enforce law

Improve emergency

response







Ensure traceability



Reduce emissions



Maintain safe road

condition


goods vehicles

Detect and warn






Automatic upstream

accident detection

Weather condition

dependent control

Deicing

Traffic condition


Traffic speed and

density measurement



Cameras

Key Drivers How To56 Gerrit Muller


COVmotorwayManagementKeyDrivers

Method to create Key Driver Graph

• Build a graph of relations between drivers and requirements

by 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 specification

and ask why questions about the specification of existing products.

• Iterate many times increased understanding often triggers the move of issues

from driver to requirement or vice versa and rephrasing

where requirements

may 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• Don’t leave out the obvious key-drivers

for instance replace “ease of use” by

“minimal 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 between

Customer Objective and Applicationcreate clear goal means relations



TCAFkeyDriverRecommendations

Transformation of Key Drivers into Requirements

Key

(Customer)

Drivers

Derived

Application

Drivers

Requirements

Customer

What

Customer

How

Product

What

Customer

objectives

Application Functional

goal means

may be skipped or

articulated by several

intermediate steps

functions

interfaces

performance figures



REQfromDriverToRequirement

Requirements Elicitation and Selectionby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

An 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 7, 2019status: draftversion: 0 bottom-up

top-down

key-drivers(customer, business)

roadmap(positioning and trends in time)

competition(positioning in the market)

"ideal" reference design

prototyping, simulation(learning vehicle)

bottom-up(technological opportunities)

existing systems

operational drivers(logistics, production, etc.)

NeedsContinued

Product Creation

Process

Feedback

regulations

Complementary Viewpoints to Capture Requirements

bottom-up

top-down







existing systems


NeedsContinued

Product Creation

Process

Feedback

regulations

Requirements Elicitation and Selection61 Gerrit Muller

version: 0March 7, 2019

REQviewpoints

Requirement Selection Process

customer needs

operational needs

roadmap

strategy

competition

selection process

product specification

need

characterization

requirement

phasing

Technology, People, Process

costs and constraints


version: 0March 7, 2019REQselection

Simple Qualification Method

important

urgent

effort

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 margin

Use relative scale, e.g. 1..5 1=low value, 5 -high value

Ask several knowledgeable people to score

Discussion 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

requirements.

Exercise Requirements Capturing65 Gerrit Muller

version: 0March 7, 2019MREQexercise

Needs and Requirements

Needs, Specification, RequirementsRequirements describing the needs of the customer:

Customer Needs

Requirements describing the needs of the company itself

over the life cycle: Life Cycle Needs

Requirements describing the characteristics of the final

resulting system (product): System (Product)

Specification

The requirements management process recursively

applies this definition for every level of decomposition.

Flow of RequirementsWhat

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

choices

trade-offs

negotiations

Requirements for Requirements

Specific

Unambiguous

Verifiable

Quantifiable

Measurable

Complete

Traceable

Enable Human Use

Accessible

Understandable

Low threshold



CAFCR, Customer Key Driver Graph

CAFCR+ ModelCustomer

objectives


Life cycleoperations

maintenance

upgrades

development

manufacturing

installation

sales, service, logistics, production, R&D

Iterate over Views

Customer

objectives


intention

constraintawareness

objectivedriven

contextunderstanding

oppor-tunities

knowledgebased

Customer

What

Customer

How

Product

What

Product

How


in Product and Why?

Example Key Driver Graph

Safety

Effective

Flow

Smooth

Operation

Environment


Enforce law

Improve emergency

response







Ensure traceability



Reduce emissions



Maintain safe road

condition


goods vehicles

Detect and warn






Automatic upstream

accident detection

Weather condition

dependent control

Deicing

Traffic condition


Traffic speed and

density measurement



Cameras

Complementary Viewpoints

bottom-up

top-down







existing systems


NeedsContinued

Product Creation

Process

Feedback

regulations



Story How Toby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

A 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



Customer

What

Customer

How

Product

What

Product

How


in Product and Why?

story caseanalyze

design

designanalyze

design

a priori solution knowledgemarket

vision

Customer

objectives


From story to design

Customer

What

Customer

How

Product

What

Product

How


in Product and Why?

story caseanalyze

design

designanalyze

design

a priori solution knowledgemarket

vision

Customer

objectives


Story How To69 Gerrit Muller


SHTfromStoryToDesign

Example story layout

A day in the life of Bob

bla blah bla, rabarber music

bla bla composer bla bla

qwwwety30 zeps.

nja nja njet njippie est quo

vadis? Pjotr jaleski bla bla

bla brree fgfg gsg hgrg

mjmm bas engel heeft een

interressant excuus, lex stelt

voor om vanavond door te

werken.

In the middle of the night he

is awake and decides to

change the world forever.

The next hour the great

event takes place:

This brilliant invention will change the world foreverbecause it is so unique and

valuable that nobody beliefs the feasibility. It is great and WOW at the same time,

highly exciting.

Vtables are seen as the soltution for an indirection problem. The invention of Bob will

obsolete all of this in one incredibke move, which will make him famous forever.

He opens his PDA, logs in and enters his provate secure unqiue non trivial password,

followed by a thorough authentication. The PDA asks for the fingerprint of this little left

toe and to pronounce the word shit. After passing this test Bob can continue.

draft or sketch of

some essential

applianceca. half a page of

plain English text

Yes

or

No

that is the question



SHTexampleStoryLayout

Points of attention

• purpose

• scope

• viewpoint, stakeholders

• visualization

• size (max 1 A4)

• recursive decomposition, refinement

What do you need to know for

specification and design?

“umbrella” or specific event?

Define your stakeholder and viewpoint

f.i. user, maintainer, installer

Sketches or cartoon

Helps to share and communicate ideas

Can be read or told in few minutes



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?"

Customer

objectives

Application

Functional

Conceptual

Realization

Customer

objectives

Application

Application

Application



SHTcriterionsList

Example of a story

Betty is a 70-year-old woman who lives in Eindhoven. Three years ago her husband passed

away and since then she lives in a home for the elderly. Her 2 children, Angela and Robert,

come and visit her every weekend, often with Betty’s grandchildren Ashley and Christopher.

As so many women of her age, Betty is reluctant to touch anything that has a technical

appearance. She knows how to operate her television, but a VCR or even a DVD player is

way to complex.

When Betty turned 60, she stopped working in a sewing studio. Her work in this noisy

environment made her hard-of-hearing with a hearing-loss of 70dB around 2kHz. The rest of

the frequency spectrum shows a loss of about 45dB. This is why she had problems

understanding her grandchildren and why her children urged her to apply for hearing aids two

years ago. Her technophobia (and her first hints or arthritis) inhibit her to change her hearing

aids’ batteries. Fortunately her children can do this every weekend.

This Wednesday Betty visits the weekly Bingo afternoon in the meetingplace of the old-folk’s

home. It’s summer now and the tables are outside. With all those people there it’s a lot of

chatter and babble. Two years ago Betty would never go to the bingo: “I cannot hear a thing

when everyone babbles and clatters with the coffee cups. How can I hear the winning

numbers?!”. Now that she has her new digital hearing instruments, even in the bingo

cacophony, she can understand everyone she looks at. Her social life has improved a lot and

she even won the bingo a few times.

That same night, together with her friend Janet, she attends Mozart’s opera The Magic Flute.

Two years earlier this would have been one big low rumbly mess, but now she even hears the

sparkling high piccolos. Her other friend Carol never joins their visits to the theaters. Carol also

has hearing aids, however hers only “work well” in normal conversations. “When I hear music

it’s as if a butcher’s knife cuts through my head. It’s way too sharp!”. So Carol prefers to take

her hearing aids out, missing most of the fun. Betty is so happy that her hearing instruments

simply know where they are and adapt to their environment.

source: Roland Mathijssen

Embedded Systems Institute

Eindhoven



SHTexample

Value and Challenges in this story

Challenges in this story:

Intelligent hearing instrument

Battery life at least 1 week

No buttons or other fancy user interface on the hearing instrument,

other than a robust On/Off method

The user does not want a technical device but a solution for a problem

Instrument can be adapted to the hearing loss of the user

Directional sensitivity (to prevent the so-called cocktail party effect)

Recognition of sound environments and automatic adaptation (adaptive

filtering)

source: Roland Mathijssen, Embedded Systems Institute, Eindhoven

Conceptual

Realization

Customer

objectives

Application

Value proposition in this story:

quality of life:

active participation in different social settings

usability for nontechnical elderly people:

"intelligent" system is simple to use

loading of batteries



SHTexampleCriteria

Concept Selection, Set Based Design and Late DecisionMaking

by Gerrit Muller University of South-Eastern Norway-NISEe-mail: [email protected]

www.gaudisite.nl

Abstract

We discuss a systems design approach where several design options aremaintained concurrently. In LEAN Product Development this is called set-baseddesign. Concentioanl systems engineering also promotes the concurrent evalu-ation of multiple concepts, the so-called concept selection. Finally, LEAN productdevelopment advocates to keep options open as long as feasible; the so-calledlate decision making.

Distribution


March 7, 2019status: 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 by

exploration 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

insu

fficie

nt d

ata

no

sa

tisfy

ing

so

lutio

n

inva

lida

ted

so

lutio

n

co

nflic

ting

oth

er d

ecis

ion

vague problem statement

Concept Selection, Set Based Design and Late Decision Making76 Gerrit Muller


TORdecisionFlow

Examples of Pugh Matrix Application

Swivel concept selectionconnectors in

hub

with roll-off

connectors in

hub

wireless

connection

two sided

connectorsclamp swivel dynamic

swivel

CBV swivel

1290

from master paper Halvard Bjørnsen, 2009

MaturityDevelopment level

CostHardware cost

Development cost

Design robustnessDesign life

swivel cycles

pressure cycles

Pressure rangeinternal

external

Temperature range

InstallationInitial installatio/retrieval

Connection/disconnection

OperationSwivel resistance

Spool Length Short

Spool Length Long

Hub loads

10

20

25

25

20

evaluation criteria weight

5

4

5

55

4

2

4

2

3

1

1

2

2

50

75

25

25

40

40

100

50

100

125125

100

50

80

2

2

2

43

4

5

4

4

5

4

4

4

3

100

125

100

100

80

60

100

125

100

10075

40

20

40

2

5

2

53

4

2

4

5

5

5

5

5

4

125

125

125

125

100

80

100

50

100

12575

40

50

100

985 1165points

CBV clamp dynamic

from master paper Dag Jostein Klever, 2009

Time to connect

Need for ROV

Design

Robustness

Connector design

Number of parts

Handle roll-off

Influence other

Redundancy

Design

Interchangeability

Cost

HW cost

Manufacturing cost

Engineering cost

Service cost

Maturity

- + + +

- + + +

- S S +

- - + +

+ - S +

+ S - S

+ - - S

+ - - -

- - - -

S S - S

+ - S -

- + + +

- - S +

7 7 5 3

1 3 4 3

5 3 4 7

Evaluation Criteria 1 2 3 4

Concepts

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 final

bottomline summation

Delaying decisions may help to keep options (Lean Product

Development: late decision making, finance: real options)



CSSBconclusions

Qualities as Integrating Needlesby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

Many 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 ofqualities is provided as a means for architecting. All qualities in the checklistare described briefly.

Distribution


March 7, 2019status: finishedversion: 1.3

ApplicationCustomer

objectives

Functional Conceptual Realization

safety

evolvability

usability

Quality needles as generic integrating concepts

ApplicationCustomer

objectives


safety

evolvability

usability

Qualities as Integrating Needles81 Gerrit Muller


QNneedles

Security as example through all views

ApplicationCustomer

objectives


sensitive

information

trusted

not trusted

selection

classificationpeople

information

authenticationbadges

passwords

locks / walls

guards

administrators

social contacts

open passwords

blackmail

burglary

fraud

unworkable procedures

cryptography

firewall

security zones

authentication

registry

logging

holes between

concepts

functions foradministration

authentication

intrusion detection

logging

quantification

bugsbuffer overflow

non encrypted

storage

poor exception

handling

missing

functionality

wrong

quantification

specific

algorithms

interfaces

libraries

servers

storage

protocols

desired characteristics, specifications & mechanisms

threats



QNsecurityExample

Quality Checklist

usability

attractiveness

responsiveness

image quality

wearability

storability

transportability

usable

safety

security

reliability

robustness

integrity

availability

dependable

throughput or

productivity

effective

serviceability

configurability

installability

serviceable

liability

testability

traceability

standards compliance

liable

ecological footprint

contamination

noise

disposability

ecological

reproducibility

predictability

consistent

efficientresource utilization

cost of ownership

cost price

power consumption

consumption rate

(water, air,

chemicals,

et cetera)

size, weight

accuracy

down to earth

attributes

manufacturability

logistics flexibility

lead time

logistics friendly

evolvability

portability

upgradeability

extendibility

maintainability

future proof

interoperable

connectivity

3rd

party extendible



QNchecklist

System Partitioning Fundamentalsby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

The fundamental concepts and approach system partitioning are explained. Welook at physical decomposition and functional decomposition in relation to supplychain, lifecycle support, project management, and system specification anddesign.

Distribution



system

subsystem 1

subsystem 2

subsub

system A

subsub

system B

subsub

system A

subsub

system B

subsub

system N

subsub

system N

atomic

part

atomic

part

atomic

part

subsystem n

subsub

system A

subsub

system B

subsub

system N

Parts, Dynamics, Characteristics

parts

characteristics

dynamics

interact

results in

prime interest

of organization

prime interest

of customer

prime system

responsibility

functionality

System Partitioning Fundamentals85 Gerrit Muller


SPFpartsDynamicsCharacteristics

Engineering

engineeringsystem specification

system design

parts data base

production procedures

qualification procedures

system documentation

procurement

production

installation

lifecycle

support

quality

assurance

ERP PDMSCMCAD

mechanical

electrical

design

database

source

code

management

resource

planning,

e.g. SAP

product

data

management

doc

DB

project

documents

know-

ledge

DB

source data

engineering knowledge

past

experience



SPFengineering

Example Physical Decomposition

Fluidic

subsystem

chamber

bottom chuck

electronics

infrastructure

process

power

supply

1

3

2

4

5electronics

infrastructure1 5granite

ZUBA

stage

frame

base frame +

x, y, stage

stage

control

ZUBA

control

optics

stagescoop

cameravision

op

tics s

tag

e

co

ntr

ol

vision

control

6

7

8

9

10

cabling

covers and

hatches

ventilation

air flow

contamination

evacuation

sensors

measurement

frame

machine

control

"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

subsub

system A

subsub

system B

subsub

system A

subsub

system B

subsub

system N

subsub

system N

atomic

part

atomic

part

atomic

part

subsystem n

subsub

system A

subsub

system B

subsub

system N


version: 0.2March 7, 2019SPFrecursion

Software plus Hardware Decomposition

tunerframe-

bufferMPEG DSP CPU RAM

drivers scheduler OS

etc

audio video TXTfile-

systemnetworkingetc.

view PIP

browseviewport menu

adjustview

TXT

hardware

driver

applications

services

toolboxes

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?

main

function

power

conversion

power

distribution

power

stabilization

coolingEMC

shielding

production

support

adjustment

support

qualification

support

control

interface

control

electronics

mechanical

package

control SWapplication

SWHMI SW

cost/speed/space

optimization

How self sustained should a part be?

trade-off:

logistics/lifecycle/production

flexibility

clarity



SPFselfSustained

Decoupling via Interfaces

part

e.g. pressure

and flow

regulator

part

e.g. pipe

part

e.g. pipe

hydrocarbon

interface

power

interface

control

interface

e.g. CAN

mechanical

mounting interfaceother part with

same interfaces

can replace

original



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

lifecycle

support

quality

assurance

specification

designpartitioning

interfaces

functions

allocation

architectureguidelines

top-level design

rationale

stakeholder

needs

business

objectives

documentationsystem and parts data

procedures



SPFsystemCreation

Simplistic Functional SubSea Example

prevent

blow-outs

regulate

flow and

pressure

hydrocarbons

from well

increase

well

pressure

separate

gas, oil,

water, sand water

sand

transport to

top-side

measure

pressure,

temp, flow

control

pressure,

temp, flow

sensor

signals

sensor data

settings

hydro

carbons

combine

multiple

streams



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 characteristics

of a system, function or part

can be quantified

Note that quantities

have unit



SPFquantification

Question Generator

accuracy

scanner PIM finisher

throughput

memory footprint

response time

processing load

solving paper jam

copying

preparing

printing What is the a ccuracy of the f use

when printing paper path fuse

func

tions

component

char

acte

ristic

s when performing <function> ?

of the <component> How about the <characteristic>

example from a high volume printer



BS05questionGenerator

Example Technical Budget

process

overlay

80 nm

reticule

15 nm

matched

machine

60 nm

process

dependency

sensor

5 nm

matching

accuracy

5 nm

single

machine

30 nm

lens

matching

25 nm

global

alignment

accuracy

6 nm

stage

overlay

12 nm

stage grid

accuracy

5 nm

system

adjustment

accuracy

2 nm

stage Al.

pos. meas.

accuracy

4 nm

off axis pos.

meas.

accuracy

4nm

metrology

stability

5 nm

alignment

repro

5 nm

position

accuracy

7 nm

frame

stability

2.5 nm

tracking

error phi

75 nrad

tracking

error X, Y

2.5 nm

interferometer

stability

1 nm

blue align

sensor

repro

3 nm

off axis

Sensor

repro

3 nm

tracking

error WS

2 nm

tracking

error 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

Fluidic

subsystem

chamber

bottom chuck

electronics

infrastructure

process

power

supply

1

3

2

4

5electronics

infrastructure1 5granite

ZUBA

stage

frame

base frame +

x, y, stage

stage

control

ZUBA

control

optics

stagescoop

cameravision

op

tics s

tag

e

co

ntr

ol

vision

control

6

7

8

9

1

0

cabling

covers and

hatches

ventilation

air flow

contamination

evacuation

sensors

measurement

frame

machine

control

"remote"

electronics rack

10

11

12

13

14

15

?

metal printer back side metal printer front sideintegrating

subsystems

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 figures

for confidentiality reasons these numbers have been removed

metal printer

functional 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

environmental

impact

design enablinge.g. CD, separation

pattern

resolution

X-section control

accuracy overlay

high MTBF

early delivery

vs

volume production

uptime

throughput

operational

costs

system cost

electric power

clean water

elyte

N2, air

disposal water, air, ...

reliability

integral costs

consumables

waste

contamination

and climate

partial graph

many nodes

and connections

are not shown

customer key drivers

Customer key-drivers and Key Performance Parameters

Document meta-information

author

version

date last update

scope

statusGerrit Muller

0.1

August 3, 2010

system and supersystem

preliminary draft

metal printing time-line

min. line width

overlay

throughput

MTBF

a m

b m

c WPH

d hr

wafer size

power

clean room class

floor vibration class

200, 300 mm

x kW

throughput

1. inspection

2. seed sputter

3. metal print

4. seed etch

wafer

waferseed

wafer

Cu

wafer

5. coat/develop dielectricswafer

6. exposure or CMP for polymer viaswafer

7. E-test

spin coated

polymer

per waferthroughput in minutes

1

t

1

3..4

1..2

dual layer only

robot

prefill

master

FOUP

wafer

FOUP

wafer

FOUPflip

prealignclean

wafer

clean

master

metal

printer

print

robot

prealign

clean

master

prefill

clean wafer

0 100b 200b

wafer

with

ICs

back-end factory

expose

wafer

stepper

expose

wafer

stepper

metal

printer

advanced

process

control

logistics &

automation

power

chemicals

climate

infrastructure

computing &

networking

infrastructure

metrologymask

power, chemicals

consumables, waste

ICs

REX

wafer fab

(front end)



LEANoverviewA3

all about systems engineering; introductory course - gaud system

Documents