university of south-eastern norway-nise · 2020. 6. 21. · single page course overview company...

Systems Engineering Fundamentals Courseby Gerrit Muller

University of South-Eastern Norway-NISE

Abstract

This course touches all fundamentals of Systems Engineering. Topics areprograms, projects, strategy and operation, stakeholders and concerns, needselicitation and requirements management, concept selection, architecting anddesign, supply chain, risk management, systems integration, verification andvalidation, deployment, and life cycle.

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.

November 18, 2020status: plannedversion: 0.1

logoTBD

Systems Engineering Fundamentals Course Overviewby Gerrit Muller TNO-ESI, University College of South-Eastern Norway

e-mail: [email protected]

Abstract

Course overview of the course Systems Engineering Fundamentals.

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.

November 18, 2020status: plannedversion: 0

logoTBD

Single page Course Overview

company context

programs, projects

case discussion

systems engineering

intro

requirements

management

identify needs

and capabilities

reflection and

discussion

reflection and

discussion

concept selection

risk management

reflection and

discussion

transform sequence

into a PERT plan

reflection and

discussion

lunch lunch

day 1 day 2

project management

day 4

reflection and

discussion

Sketch and discuss

program and

project

organization

identify

stakeholders and

concerns

sketch a typical

mission and a

scenario

determine 10

SMART KPPs and

use case

lunch

perform concept

selection

assess risks

9:00

10:00

11:00

12:00

13:00

14:00

15:00

16:00

reflection and

discussion

determine an

incremental

integration

sequence

sketch installation

and commissioning

verification and

validation

deployment

lunch

wrap-up

course intro

needs and

requirements

day 5

system development

process

sketch system

life cycle

system life cycle

supporting systems

day 3

partitioning and

interfaces

make system and

work breakdown

lunch

dynamic behavior,

functionality

show dynamic

behavior

reflection and

discussion

reflection and

discussion systems integration

supply chain and

logistics

sketch goods flow

architecture and

design

Systems Engineering Fundamentals Course Overview3 Gerrit Muller

version: 0November 18, 2020

SEFOVschedule

Systems Engineering Fundamentals; Course Materialby Gerrit Muller TNO-ESI, University College of South-Eastern Norway


Abstract

Listing the course material for the course Systems Engineering Fundamentals.

Distribution



logoTBD

Introduction

core

Systems Engineering Fundamentals Introduction

http://gaudisite.nl/info/SEFintroduction.info.html

optional

Systems Engineering Fundamentals; Course Material5 Gerrit Muller

version: 0.1November 18, 2020SEFMAintroduction

Course Overview

core

Systems Engineering Fundamentals Course Overview

http://gaudisite.nl/info/SEFoverview.info.html

optional


version: 0.1November 18, 2020

SEFMAoverview

Assignments

core

Systems Engineering Fundamentals Assignments

http://gaudisite.nl/info/SEFassignments.info.html

optional



SEFMAassignments

Programs, Projects, Process, Organization

core

Project Systems Engineering Introduction; Phasing, Process, Organization

http://gaudisite.nl/info/ProjectSEintroPPO.info.html

Module System Architecture Context

https://gaudisite.nl/ModuleSystemArchitectureContextPaper.pdf

Products, Projects, and Services; similarities and differences in architecting

https://gaudisite.nl/ProductsProjectsServicesPaper.pdf

optional

System Engineering Management Plan (SEMP) DOES ONE SIZE FIT ALL?

Zonnenshain, A., Malotaux, N., Honour, E., Kasser, J., Urio, U., Shabtay, M.,

INCOSE 2009

Systems Engineering Management Plan (SEMP) Technical Content

https://www.nasa.gov/consortium/SystemsEngineeringManagementPlanTechnicalContent



SEFMAppo

Life Cycle

core

Systems Engineering Fundamentals Life Cycle

http://gaudisite.nl/info/SEFlifeCycle.info.html

Modeling and Analysis: Life Cycle Models

https://gaudisite.nl/MAlifeCyclePaper.pdf

optional

SEBoK Life Cycle models

https://www.sebokwiki.org/wiki/Life_Cycle_Models



SEFMAlifeCycle

Needs and Requirements

core

Systems Engineering Fundamentals Needs Elicitation

http://gaudisite.nl/info/SEFneeds.info.html

optional

SEBoK Stakeholder Needs and Requirements

https://www.sebokwiki.org/wiki/Stakeholder_Needs_and_Requirements



SEFMAneeds

Requirements Management

core

Systems Engineering Fundamentals Requirements Management

http://gaudisite.nl/info/SEFrequirements.info.html

Fundamentals of Requirements Engineering

https://gaudisite.nl/FundamentalsOfRequirementsPaper.pdf

optional



SEFMArequirements

Concept Selection

core

Concept Selection, Set Based Design and Late Decision Making

https://gaudisite.nl/SEFconceptSelectionSlides.pdf

optional

Concept Selection - Applying Pugh Matrices in the Subsea Processing Domain by

Linda Lønmo and Gerrit Muller; INCOSE 2014 in Las Vegas

https://gaudisite.nl/INCOSE2014_Lonmo_Muller_ConceptSelection.pdf

Researching the application of Pugh Matrix in the sub-sea equipment industry by

Gerrit Muller, Dag Jostein Klever, Halvard H. Bjørnsen, and Michael Pennotti; CSER

2011 in Los Angeles

https://gaudisite.nl/CSER2011_MullerEtAl_ResearchingPughMatrix.pdf



SEFMAconceptSelection

Visualizing Dynamic Behavior

core

Visualizing Dynamic Behavior

http://gaudisite.nl/info/VisualizingDynamicBehavior.info.html

optional

Creating an A3 Architecture Overview; a Case Study in SubSea Systems by Gerrit

Muller, Damien Wee, and Martin Moberg; INCOSE 2015 in Seattle, WA, USA

http://gaudisite.nl/INCOSE2015_MullerEtAl_SubseaOverviewA3.pdf



MSIMAvisualizingDynamicBehavior

Supply Chain and Logistics

core

Systems Engineering Fundamentals Supply Chain and Logistics

https://gaudisite.nl/SEFsupplyChainSlides.pdf

optional

Build to order https://en.wikipedia.org/wiki/Build_to_order

P-D Ratios https://oldleandude.com/2015/05/27/p-d-ratios/


version: 0.1November 18, 2020SEFMAsupplyChain

Risk Management

core

Systems Engineering Fundamentals Risk Management

https://gaudisite.nl/SEFriskManagementSlides.pdf

optional

Failure Mode and Effects Analysis

https://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis



SEFMArisks

Readiness Levels

core

Course Systems Integration; Readiness Levels

http://www.gaudisite.nl/info/MSIreadinessLevels.info.html

optional

From TRL to SRL: The Concept of Systems Readiness Levels

CSER 2006, Brian Sauser et al.

Technology Readiness Levels

https://en.wikipedia.org/wiki/Technology_readiness_level



MSIMAreadinessLevels

Systems Integration Process and Positioning

core

Mastering Systems Integration; Process and Positioning

http://gaudisite.nl/info/MSIprocessAndPositioning.info.html

optional

SESA /SARCH Module 01, System Architecture Context

http://gaudisite.nl/info/ModuleSystemArchitectureContext.info.html



MSIMAprocessAndPositioning

Project Management and Systems Integration

core

Course Systems Integration; Project Management

http://gaudisite.nl/info/MSIprojectManagement.info.html

optional

Combating Uncertainty in the Workflow of Systems Engineering Projects

INCOSE 2013, Barry Papke and Rick Dove



MSIMAprojectManagement

Verification and Validation Terminology

core

Course Systems Integration; Terminology

http://www.gaudisite.nl/info/MSIterminology.info.html

optional

Understanding Objective Evidence: (What It Is and What It Definitely Is Not),

by Denise Dion

http://www.eduquest.net/Advisories/EduQuest%20Advisory_ObjectiveEvidence.pdf

List of Cognitive Biases, Wikipedia:

https://en.wikipedia.org/wiki/List_of_cognitive_biases


version: 0.1November 18, 2020MSIMAterminology

Systems Engineering Fundamentals Assignmentsby Gerrit Muller TNO-ESI, USN-NISE


Abstract

All assignments of the course Systems Engineering Fundamentals.

Distribution



logoTBD

Case

Propose a Non-Lethal Urban Crowd Controller

Systems Engineering Fundamentals Assignments21 Gerrit Muller


SEFAScaseCrowdController

Discuss the Case

Sketch the system-of-interest

Sketch some of the environment the system will be

operating in

Sketch some of the system internals

Draw the system boundary



SEFAScaseDiscussion

Map the Operational Organization

Make a map with names of

individuals in the operational

organization of one project

and its context

Identify the relationships of

the project core team:

· geographical

· organizational

· psychological

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


version: 0November 18, 2020SEFASorganization

Sketch Mission and Scenario

Sketch

a typical mission

and a specific scenario.

The scenario needs to be highly specific:

· numbers (how much, how far, how accurate)

· names (where, who)

· circumstances (when, where)

· actions (what, how)



SEFASmissionAndScenario

Identify Stakeholders and Concerns

Brainstorm stakeholders

Brainstorm for each stakeholder the concerns

Elaborate concerns in 5 to 10 words, make them more specific

Use the mission and scenario for inspiration



SEFASstakeholdersAndConcerns

Sketch the System Life Cycle

Sketch the system life cycle

from idea until decommissioning and recycling.

Identify stakeholders per phase or activity



SEFASlifeCycle

Identify Needs and Capabilities

Identify stakeholder needs

in terms of capabilities.

Capabilities typically are functions

with quantifiable characteristics

Use the mission, scenario, and stakeholder analysis for inspiration



SEFASneedsAndCapabilities

Determine Key Performance Parameters and Use Case

Determine 5 to 10 Key Performance Parameters (KPP)

of the System

Quantify these KPPs

Define the KPPs roughly, using a Use Case



MSIASdetermineKPPS

Perform a Concept Selection

Make a decision matrix for one of the concept selections.

· define at least 3 concepts

· define 7 to 10 criteria for selection

· score the concepts against the criteria, for example using a scale

from 1 to 5: 1 = very poor, 5 = very good

· recommend a concept with a rationale

concept 1 concept 2 concept 3

criterion 1

criterion n

1 3 5

4 4 2

best,

because ...



SEMAexerciseConceptSelection

Show Dynamic Behavior

Model the Dynamic Behavior of the System.

Focus on the Dynamic Behavior that relates to the KPP.

Visualize the Dynamic Behavior with various sketches,

diagrams, or graphs (see Visualizing Dynamic Behavior

for inspiration).



MSIASmodelDynamicBehavior

Make a System and Work Breakdown

Make a system breakdown

in subsystems and subsubsystems

and a work breakdown structure

to assist in organizing the project



SEFASbreakdown

Sketch the Goods Flow

sketch the goods flow

from (sub) suppliers

via assembly and test

to customer site,

deployment,

and maintenance



SEFASgoodsFlow

Assess Risks

Assess risks

· feasibility of achieving KPPs

· fitness for purpose in customer context

· integration configurations and testware

· supplier and logistics status

· technology readiness

· development and resource status

Determine probability and severity per risk



SEFASrisks

Determine an Incremental Integration Sequence

Determine an incremental integration sequence to build

confidence in the KPP ASAP.

Strive for about 6 main increments.

Reason starting at the end result and then backward in

time.

For each increment determine its prerequisites in terms of

parts, interfaces, functions, and performance levels.



MSIASdetermineSequence

Transform Sequence into a PERT Plan

Transform the integration sequence and the planning from

the other perspectives into a PERT-plan.

A PERT-plan focuses on activities and their mutual

relations; the logic of the plan. Time and resources are

secondary information.



MSIASpertPlan

Sketch an Installation and Commissioning

Sketch an installation

and commissioning



SEFASinstallationAndCommissioning

Systems Engineering Fundamentals Introductionby Gerrit Muller TNO-ESI, University College of South-Eastern Norway


Abstract

This presentation introduces the ideas behind the course Systems EngineeringFundamentals.

Distribution



logoTBD

Architecture Top View

customer value

proposition

business

proposition

system

requirements

system design &

technology

drives drives

drive

s

en

ab

les

enables enab

les

Systems Engineering Fundamentals Introduction38 Gerrit Muller


ARCVtopView

Architecting Playing Field

organizational

context

operational and lifecycle context

technology

customer value

proposition

business

proposition

system

requirements

system designdrives dr

ives

drive

s

en

ab

les

enables enab

les

customer

organization

business

organization

developing

organization

supplying

organizations



ARCVtopViewExpanded

Simplified Systems Engineering Model

engineering

architecting

and design

life cycle

support

specification

designpartitioning

interfaces

functions

allocation

architectureguidelines

top-level design

rationale

inputsstakeholder needs

business objectives

documentationsystem and parts data

procedures

integration

verification &

validation

feedback

qualificationevidence

artifactsmodels

prototypes

parts



MSIINdefinition

Level of Abstraction Single System

100

101

106

105

104

103

102

107

static system definition

monodisciplinary

nu

mb

er o

fd

etai

ls

system

requirements

multidisciplinary

design



RAPpyramid

From system to Product Family or Portfolio

nu

mb

er

of

de

tails

system

multidisciplinary

monodisciplinary

100

101

106

105

104

103

102

107

100

101

106

105

104

103

102

107

108

109

systems

multidisciplinary

monodisciplinary

system portfolio

increase



DRALpyramidGrowth

Product Family in Context

100

106

103

109

systems

multidisciplinary design

parts, connections, lines of code

103

109

106

stakeholders

enterprise

enterprise contextn

um

be

r o

f

de

tails



RAPdiabolo

Engineering

100

101

106

105

104

103

102

107


mono-disciplinary

nu

mb

er o

fd

etai

ls

system

requirements

multi-disciplinary

design

En

gin

ee

rin

g

Capturing all information that is required for:

logistics, manufacturing, legislation,

maintenance, life cycle support,



LAWFengineering

Design

100

101

106

105

104

103

102

107


mono-disciplinary

nu

mb

er o

fd

etai

ls

system

requirements

multi-disciplinary

design

De

sig

n

from needs and requirements to design:

decomposition, interface definition, allocation,

concept selection, technology choices

anticipating engineering

needs and constraints



LAWFdesign

Architecting

100

106

103

109

systems

multidisciplinary design

parts, connections, lines of code

103

109

106

stakeholders

enterprise

enterprise context

nu

mb

er

of

de

tails

Architecting:

realization and

design choices

in context

some context

details are

essential

some technical

details are

essential



LAWFdiabolo

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


November 18, 2020status: preliminarydraftversion: 0.2

tenderdesign and

engineering

manufacturing

and

installation

operation and

maintenancedisposal

offer

order

acceptance

final payment

FEED1

study

1Front-end engineering design

concept

study

request

for proposal

Project Life Cycle

tenderdesign and

engineering

manufacturing

and

installation

operation and

maintenancedisposal

offer

order

acceptance

final payment

FEED1

study

1Front-end engineering design

concept

study

request

for proposal

Project Systems Engineering Introduction; Phasing, Process, Organization48 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

FEED

study

DR = Design Review



PSEIPphases

V-Model

needs

specification

system design

subsystem design

component design

component realization

component test

subsystem test

system test

verification

validation



TPSEPvModel

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

engineeringinstallation

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


version: 0.2November 18, 2020PPSprojectProcess

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


version: 0.2November 18, 2020PCPdecomposition

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

Mastering Systems Integration; Early Validationby Gerrit Muller TNO-ESI, University of South-Eastern Norway]


Abstract

The core principle of systems integration is early validation; are the assumptionsof the needs, specifications and design decisions valid? it is better to fail early,then to hit faulty assumptions, unknowns, or uncertainties late in development.

Distribution



identify needs

specify

design

realize

integrate

qualify

learn fast by iterating over needs and

technology

· more chaotic

· requires agile mindset

Most Problems are Found Late

needs

specification

system design

subsystem design

component design


component test

subsystem test

system test

verification

validation

inte

grat

ion

and

test

specification and design

ε

ε

failures found during integration and testcan be traced back to unknowns,

unforeseens, and wrong assumptions

ε

Mastering Systems Integration; Early Validation65 Gerrit Muller


MSIEVlateValidation

Waterfall model

identify

needs

specify

design

realize

integrate

verify &

validate

works well:

· in mature product-market combinations

· with long development cycles

works poorly:

· in new product-market combinations

· short development cycles



BSEARwaterfall

Concurrent Engineering

identify

needs

specify

design

realize

integrate

qualify

· total development time is shorter

· technology constraints & opportunities

take time to get in the picture

· validation is still late (=feedback on

uncertain requirements)



BSEARconcurrentEngineering

Iterative Approach

identify needs

specify

design

realize

integrate

qualify

learn fast by iterating over needs and

technology

· more chaotic

· requires agile mindset



BSEARiterativeApproach

Continuous Integration

frequency of

integration

steps

perceived

development

disturbance

number of

hidden issues

continuous integration forces

· continuous confrontation

· no build-up of issues

· ensures working system

· less complex diagnosis

However,

ongoing changes may be

perceived as disturbing



MSICBcontinuousIntegration

Development Processes From Waterfall to Agile

triple-VM1

functional

model

M2

prototype

M3

product

many Vs

spiral

waterfall

agile/incremental/

continuous

and all kinds of

hybrids



MSIINprocesses

Systems Engineering Fundamentals Life Cycleby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

Products and enterprises evolve over time. This presentation explores the impactof these changes on the system and on the business by making (small and simple)models of life cycle aspects.

Distribution


November 18, 2020status: preliminarydraftversion: 0

life cycle context

systemusage context

other

systemsdesign

realization

other

systems

requirements

automated data inputs

interoperability

human inputs

error prone!~3% error rate

change request

problem report

legend

Product Related Life Cycles

system

creation

system

productionsystem

sales

service

individual systems

disposalupgrades and options

productionupgrades and options

sales

upgrades and options

creation

Systems Engineering Fundamentals Life Cycle72 Gerrit Muller


MALCproductLifeCycle

System Life Cycle

system

order

using

local

changes, e.g.accounts

procedures

ma

inte

na

nce

up

gra

de

using

orde

ring

com

pone

nts

man

ufac

turin

g

shipping

installatio

n

shipping

installatio

n

refu

rbishing

shipping

secondary

use dis

po

se

ma

inte

na

ncead

d o

ptio

n

sales



MALCsystemLifeCycle

Approach to Life Cycle Modeling

Identify potential life cycle changes and sources

Determine required effort

Characterize time aspect of changes

amount

type

Determine impact of change on

system and context

performance

reliability

Analyse risks business

how often

how fast

see

reasoning



MALCapproach

Systems Engineering Fundamentals Needs Elicitationby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

This presentation uses the TRIZ 9 Windows diagram as framework to think aboutneeds elicitation.

Distribution



system of

interest

developing

organization

architect

super

system

customer

organization

subsystems

past system

of interest

past super

system

past

subsystems

past current future

future system

of interest

future super

system

future

subsystems

based on TRIZ

supplier

organizationconstraints

needs

Our Primary Interest

system of

interest

developing

organization

architect

Systems Engineering Fundamentals Needs Elicitation76 Gerrit Muller

version: 0November 18, 2020SEMABcoreEntities

Context, Zoom-out and Zoom-in

system of

interest

developing

organization

architect

super

system

customer

organization

subsystemssupplier

organization



SEMABsuperSubEntities

Adding the Time Dimension

system of

interest

developing

organization

architect

super

system

customer

organization

subsystems

past system

of interest

past super

system

past

subsystems

past current future

future system

of interest

future super

system

future

subsystems

based on TRIZ

knowledge innovation

supplier

organization



SEMABentitiesInTime

Sources of Needs and Constraints

system of

interest

developing

organization

architect

super

system

customer

organization

subsystems

past system

of interest

past super

system

past

subsystems

past current future

future system

of interest

future super

system

future

subsystems

based on TRIZ

supplier

organizationconstraints

needs



SEFNEtriz

Systems Engineering Fundamentals RequirementsManagement


www.gaudisite.nl

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. Needs and requirements prescribewhat rather than how.

Distribution


November 18, 2020status: draftversion: 0

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

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.

Systems Engineering Fundamentals Requirements Management81 Gerrit Muller


REQdefinition

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


version: 0November 18, 2020REQwhatWhatHow

System as a Black Box

system seen as black box

inputs outputsfunctions

quantified characteristics

restrictions, prerequisites

boundaries, exceptions

standards, regulations

interfaces



REQsystemAsBlackBox

Good Requirements are “SMART”

• Specific

• Measurable

• Achievable (Attainable, Action oriented, Acceptable,

Agreed-upon, Accountable)

• Realistic (Relevant, Result-Oriented)

• Time-bounded (Timely , Tangible, Traceable)

quantified

verifiable



SAFMdefinitionSMART

Specific Requirements have Specific Circumstances

Typical Use Case

· What is the user typically doing with the system in the

system context

· Quantify the operation and context in this typical case

Other Use Cases

· Operational variants

· Boundary behavior

· Exceptional casesthese use cases >> S

ysML use cases



SEFRQuseCase

Concept Selection, Set Based Design and Late DecisionMaking


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



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 Making87 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

Systems Engineering Fundamentals Architecture andDesign


www.gaudisite.nl

Abstract

This presentation explains the fundamentals behind Architecture and Design,such as conceptual and functional design, partitioning, interfaces, and allocation.

Distribution



logoTBD

Architecture and Design

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

Systems Engineering Fundamentals Architecture and Design92 Gerrit Muller

version: 0November 18, 2020SPFsystemCreation

Visualizing Dynamic Behaviorby Gerrit Muller TNO-ESI, University of South-Eastern Norway]


Abstract

Dynamic behavior manifests itself in many ways. Architects need multiple comple-mentary visualizations to capture dynamic behavior effectively. Examples arecapturing information, material, or energy flow, state, time, interaction, or commu-nication.

Distribution



print

robot

prealign

clean

master

prefill

clean wafer

0 100b 200b

run

ED

P/L

RP

ho

ok u

p c

oile

d tu

bin

g/w

ire

line

fun

ctio

n a

nd

se

al te

st

run

co

iled

tu

bin

g/w

ire

line

asse

mb

ly a

nd

te

st

run

ris

ers

retr

ieve

co

iled

tu

bin

g/w

ire

line

ho

ok u

p S

FT

an

d T

F

retr

ieve S

FT

an

d T

F

retr

ieve

ris

ers

retr

ieve

ED

P/L

RP

actual workover operation

48 hrs

24 48 72 96

hours

dis

asse

mb

ly

preparation 36 hrs finishing 27 hrs

stop productionresume

productiondeferred operation 62 hrs

mo

ve

ab

ove

we

ll

mo

ve

aw

ay fro

m w

ell

RO

V a

ssis

ted

co

nn

ect

assembly,

functional test

run

EDP/LRP

run risers

hook up SFT

and TF

hook up coil

tubing and

wireline BOP

system function

and connection

seal test

run coil tubing

and wireline

retrieve coil

tubing and

wireline BOP

retrieve SFT and

TF

retrieve risers

retrieve

EDP/LRP

perform

workover

operations

move above wellmove away from

well

disassembly

3

2

1

4

5

7

6

unhook coil

tubing and

wireline BOP

12

11

10

9

7

8

ROV assisted

connect

ROV assisted

disconnect

Gz

Gx

Gy

RF

TETR

typical TE:

5..50ms

transmit receive

functional flow

9 101 2 3 4 5 6 7 8

call family doctor

visit family doctor

call neurology department

visit neurologist

call radiology department

examination itself

diagnosis by radiologist

report from radiologist to

neurologist

visit neurologist

19 2011 12 13 14 15 16 17 18 21 22 23 24 25

days

alarm mode

pre-alarm mode

operating

event reset

acknowledge

alarm handled

idle

start

Information Transformation Flow

Concrete “Cartoon” Workflow

Timeline of Workflow

Timeline and Functional

Flow

Swimming Lanes

Concurrency and Interaction

Signal Waveforms

State Diagram

Abstract

Workflow

get

sensor

data

transform

into image

get

sensor

data

transform

into image

fuse

sensor

images

detect

objects

classify

objects

update

world

model

get

external

data

analyze

situation

get goal

trajectory

get GPS

data

get v, a

calculate

GPS

location

estimate

location

update

location

world model

determine

next step

location

objects

vessel or

platform

rig

vessel or

platform

EDP

LRP

riser

XT

well

TF

SFT

well

head

WOCS

rig

vessel or

platform

EDP

LRP

riser

XT

well

TF

SFT

well

head

WOCS

rig

vessel or

platform

EDP

LRP

riser

XT

well

TF

SFT

well

head

WOCS

rig

vessel or

platform

EDP

LRP

TF

SFT

WOCS

XT

well

well

head

rig

vessel or

platform

EDP

LRP

riser

XT

well

TF

SFT

well

head

WOCS

ROV

ROV

rig

vessel or

platform

EDP

LRP

TF

SFT

WOCS

XT

well

well

head

rigTF

SFT

WOCS

XT

well

well

head

EDP

LRP

rig

vessel or

platform

TF

SFT

WOCS

XT

well

well

head

EDP

LRP

vessel or

platform

rigTF

SFT

WOCS

XT

well

well

head

EDP

LRP

vessel or

platform

rig

TF

SFT WOCS

XT

well

well

head

EDP

LRP

ROV

1 2 3 4 5 6

7 8 11 12

vessel or

platform

rig

TF

SFT WOCS

XT

well

well

head

LRP

9

EDP

vessel or

platform

rigTF

SFT

WOCS

XT

well

well

head

LRP

10

EDP

Information Centric Processing

Diagram

Flow of Light

illuminatorlaser

sensor

pulse-freq, bw,

wavelength, ..uniformity

lens

wafer

reticle

aerial image

NA

abberations

transmission

raw

image

resized

imageenhanced

image

grey-

value

image

view-

port

gfx

text

retrieve enhance inter-polate

lookup merge display

Overview of Visualizations of Dynamic Behavior

print

robot

prealign

clean

master

prefill

clean wafer

0 100b 200b

run

ED

P/L

RP

ho

ok u

p c

oile

d tu

bin

g/w

ire

line

fun

ctio

n a

nd

se

al te

st

run

co

iled

tu

bin

g/w

ire

line

asse

mb

ly a

nd

te

st

run

ris

ers

retr

ieve

co

iled

tu

bin

g/w

ire

line

ho

ok u

p S

FT

an

d T

F

retr

ieve

SF

T a

nd

TF

retr

ieve

ris

ers

retr

ieve

ED

P/L

RP


48 hrs

24 48 72 96

hours

dis

asse

mb

ly




mo

ve

ab

ove

we

ll

mo

ve

aw

ay fro

m w

ell

RO

V a

ssis

ted

co

nn

ect

assembly,

functional test

run

EDP/LRP

run risers

hook up SFT

and TF

hook up coil

tubing and

wireline BOP

system function

and connection

seal test

run coil tubing

and wireline

retrieve coil

tubing and

wireline BOP

retrieve SFT and

TF

retrieve risers

retrieve

EDP/LRP

perform

workover

operations


well

disassembly

3

2

1

4

5

7

6

unhook coil

tubing and

wireline BOP

12

11

10

9

7

8

ROV assisted

connect

ROV assisted

disconnect

Gz

Gx

Gy

RF

TETR

typical TE:

5..50ms

transmit receive

functional flow

9 101 2 3 4 5 6 7 8

call family doctor

visit family doctor


visit neurologist


examination itself



neurologist

visit neurologist

19 2011 12 13 14 15 16 17 18 21 22 23 24 25

days

alarm mode

pre-alarm mode

operating

event reset

acknowledge

alarm handled

idle

start

Information Transformation Flow

Concrete “Cartoon” Workflow

Timeline of Workflow

Timeline and Functional

Flow

Swimming Lanes

Concurrency and Interaction

Signal Waveforms

State Diagram

Abstract

Workflow

get

sensor

data

transform

into image

get

sensor

data

transform

into image

fuse

sensor

images

detect

objects

classify

objects

update

world

model

get

external

data

analyze

situation

get goal

trajectory

get GPS

data

get v, a

calculate

GPS

location

estimate

location

update

location

world model

determine

next step

location

objects

vessel or

platform

rig

vessel or

platform

EDP

LRP

riser

XT

well

TF

SFT

well

head

WOCS

rig

vessel or

platform

EDP

LRP

riser

XT

well

TF

SFT

well

head

WOCS

rig

vessel or

platform

EDP

LRP

riser

XT

well

TF

SFT

well

head

WOCS

rig

vessel or

platform

EDP

LRP

TF

SFT

WOCS

XT

well

well

head

rig

vessel or

platform

EDP

LRP

riser

XT

well

TF

SFT

well

head

WOCS

ROV

ROV

rig

vessel or

platform

EDP

LRP

TF

SFT

WOCS

XT

well

well

head

rigTF

SFT

WOCS

XT

well

well

head

EDP

LRP

rig

vessel or

platform

TF

SFT

WOCS

XT

well

well

head

EDP

LRP

vessel or

platform

rigTF

SFT

WOCS

XT

well

well

head

EDP

LRP

vessel or

platform

rig

TF

SFT WOCS

XT

well

well

head

EDP

LRP

ROV

1 2 3 4 5 6

7 8 11 12

vessel or

platform

rig

TF

SFT WOCS

XT

well

well

head

LRP

9

EDP

vessel or

platform

rigTF

SFT

WOCS

XT

well

well

head

LRP

10

EDP

Information Centric Processing

Diagram

Flow of Light

illuminatorlaser

sensor

pulse-freq, bw,


lens

wafer

reticle

aerial image

NA

abberations

transmission

raw

image

resized

imageenhanced

image

grey-

value

image

view-

port

gfx

text



Visualizing Dynamic Behavior94 Gerrit Muller


VDBoverview

Example Functional Model of Information Flow

get

sensor

data

transform

into image

get

sensor

data

transform

into image

fuse

sensor

images

detect

objects

classify

objects

update

world

model

get

external

data

analyze

situation

get goal

trajectory

get GPS

data

get v, a

calculate

GPS

location

estimate

location

update

location

world model

determine

next step

location

objects



BSEARfunctionalModel

”Cartoon” Workflow

vessel or

platform

rig

vessel or

platform

EDP

LRP

riser

XT

well

TF

SFT

well

head

WOCS

rig

vessel or

platform

EDP

LRP

riser

XT

well

TF

SFT

well

head

WOCS

rig

vessel or

platform

EDP

LRP

riser

XT

well

TF

SFT

well

head

WOCS

rig

vessel or

platform

EDP

LRP

TF

SFT

WOCS

XT

well

well

head

rig

vessel or

platform

EDP

LRP

riser

XT

well

TF

SFT

well

head

WOCS

ROV

ROV

rig

vessel or

platform

EDP

LRP

TF

SFT

WOCS

XT

well

well

head

rigTF

SFT

WOCS

XT

well

well

head

EDP

LRP

rig

vessel or

platform

TF

SFT

WOCS

XT

well

well

head

EDP

LRP

vessel or

platform

rigTF

SFT

WOCS

XT

well

well

head

EDP

LRP

vessel or

platform

rig

TF

SFT WOCS

XT

well

well

head

EDP

LRP

ROV

1 2 3 4 5 6

7 8 11 12

vessel or

platform

rig

TF

SFT WOCS

XT

well

well

head

LRP

9

EDP

vessel or

platform

rigTF

SFT

WOCS

XT

well

well

head

LRP

10

EDP



SSMEtypicalWorkoverOperationCartoon

Workflow as Functional Model

rig

vessel or

platform

assembly,

functional test

run

EDP/LRP

run risers

hook up SFT

and TF

hook up coil

tubing and

wireline BOPEDP

LRP

riser

XT

well

TF

SFT

wireline

coil tubing BOP

well

head

WOCS

system function

and connection

seal test

run coil tubing

and wireline

retrieve coil

tubing and

wireline BOP

retrieve SFT and

TF

retrieve risers

retrieve

EDP/LRP

perform

workover

operations


well

disassembly

3

2

1

4

5

7

6

unhook coil

tubing and

wireline BOP

12

11

10

9

7

8

ROV assisted

connect

ROV assisted

disconnect



SSMEtypicalWorkoverOperation

Workflow as Timeline

run

ED

P/L

RP

ho

ok u

p c

oile

d tu

bin

g/w

ire

line

fun

ctio

n a

nd

se

al te

st

run

co

iled

tu

bin

g/w

ire

line

asse

mb

ly a

nd

te

st

run

ris

ers

retr

ieve

co

iled

tu

bin

g/w

ire

line

ho

ok u

p S

FT

an

d T

F

retr

ieve S

FT

an

d T

F

retr

ieve

ris

ers

retr

ieve

ED

P/L

RP


48 hrs

24 48 72 96

hours

dis

asse

mb

ly

assumptions:

running and retrieving risers: 50m/hr

running and retrieving coiled tubing/wireline: 100m/hr

depth: 300m




mo

ve

ab

ove

we

ll

mo

ve

aw

ay fro

m w

ell

RO

V a

ssis

ted

co

nn

ect



SSMEtypicalWorkoverOperationTimeline

Swimming Lane Example

print

robot

prealign

clean

master

prefill

clean wafer

0 100b 200b



REPLIcellTimeLineSimplified

Example Signal Waveforms

Gz

Gx

Gy

RF

TETR

Gy=0 Gy=127

imaging =

repeating similar pattern

many times

typical TE:

5..50ms

transmit receive



MRimaging

Example Time Line with Functional Model

functional flow

9 101 2 3 4 5 6 7 8

call family doctor

visit family doctor


visit neurologist


examination itself



neurologist

visit neurologist

19 2011 12 13 14 15 16 17 18 21 22 23 24 25

days



MRendToEndTimeLine

Information Centric Processing Diagram

raw

image

resized

imageenhanced

image

grey-

value

image

view-

port

gfx

text





MICVprocessingCachedPixmaps

Example State Diagram

alarm mode

pre-alarm mode

operating

event reset

acknowledge

alarm handled

idle

start



VDBstateDiagram

Flow of Light (Physics)

illuminatorlaser

sensor

pulse-freq, bw,


lens

wafer

reticle

aerial image

NA

abberations

transmission


version: 0November 18, 2020TSAITphysicsView

Dynamic Behavior is Multi-Dimensional

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, goods, energy)

information (e.g. measurements, signals)

control

Time, events, cause and effect

Concurrency, synchronization, communication

multi-dimensional

information and

dynamic behavior



VDBkeyPhrases

Systems Engineering Fundamentals Partitioning andInterfaces


www.gaudisite.nl

Abstract

The presentation explains fundamental concepts of and approach to system parti-tioning .

Distribution



logoTBD

Partitioning is Applied Recursively

system

subsystem

1

subsub

system A

subsub

system B

subsub

system N

atomic

part

subsystem

n

subsub

system P

subsub

system Q

atomic subsub

system Z

atomic

part

atomic

part

atomic

part

atomic

part

atomic

part

atomic

part

atomic

part

atomic

part

atomic

part

atomic sub

system k

Systems Engineering Fundamentals Partitioning and Interfaces107 Gerrit Muller


SPFrecursion

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

Example Physical Decomposition and Visualization

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

Example Work Breakdown Structure

work packagesproject organization

TIP:NBE

R1

xDASreconstruction

hardware

viewing

database

scanning

xFEC

run time

acq

prepa-

ration

conver-

sion

algo-

rithms

UIgfxalgo-

rithmsVDU console

import

exportarchive

bulk

dataclinical

database

engine

computing

system

host OSfoundation

classes

start up

shutdown

exception

handling

integra-

tionSPS

SD

STPS

alfa

test

beta

test

conf

man

make SW

make HW

buy SW

buy HW

system

segment

project

legend


version: 0November 18, 2020CVworkBreakdown

Example SW plus HW 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

Systems Engineering Fundamentals Supply Chain andLogistics


www.gaudisite.nl

Abstract

The supply chain dominates the economic viability of systems. Developing asystem and its business requires the design of the supply chain.

Distribution



logoTBD

System Order Lead Time

order

order

order

build ship

build ship

build ship

build ship

system order lead time

store

for all systems, subsystems, modules,

components, ...

Systems Engineering Fundamentals Supply Chain and Logistics117 Gerrit Muller


SEFSCleadTime

Considerations for Designing the Supply Chain

· Flow of goods; stock = cost

· Produce Delivery Ratio < 1

· Facilitate demand-driven goods flow.

· Forecasting causes stocks and risks of

obsolescence or underrun)

· Risk management

· supplier dependency (2nd

supplier policy)

· Production and service life time

· Traceability of configurations and versions

Systems Engineering Fundamentals Supply Chain and Logistics118 Gerrit Muller


SEFSCdesign

Systems Engineering Fundamentals Risk Managementby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

Systems Engineering offers many methods and techniques to detect and mitigaterisks. This presentaion touches upon methods like Failure Mode Effect Analysis,Hazard Analysis, etc. addressing related concerns such as reliability, safety, andsecurity.

Distribution



logoTBD

Life-cycle Commitment, Knowledge, and Incurred Cost

Syste

ms E

ng

ine

erin

g a

nd

An

aly

sis

, F

ifth

Ed

itio

n

Be

nja

min

S.

Bla

nch

ard

• W

olte

r J. F

ab

rycky

Co

pyrig

ht ©

20

11

, ©

20

06, ©

19

98

by P

ea

rso

n E

du

ca

tio

n, In

c.

Up

pe

r S

ad

dle

Riv

er,

Ne

w J

ers

ey 0

74

58

Systems Engineering Fundamentals Risk Management120 Gerrit Muller


MSIEVblanchardFabryckyFigure212

FMEA-like Analysis Techniques

potential hazardssafetyhazard analysis

reliabilityFMEA

failure modes

exceptional cases

security vulnerability risks

damage

effects

consequences

measures

measures

measures

maintainability change cases impact, effort, time

performance worst cases system behavior decisions

(systematic)

brainstorm

improvespec, design,

process,

procedure, ...

analysis and

assessmentprobability

severity

propagation

decisions



MAANfmeaLikeAnalysis

Severity-Probability Classification Matrix

unacceptable

highmoderate

unacceptable

unacceptable

unacceptable

lowlow low low

unacceptable

unacceptable

unacceptable

high

high

high

high

moderate

moderate

moderate

moderate

moderate

moderate

moderate

lowlow low

low low

low

severity

pro

ba

bili

ty

I II III IV V VI

A

B

C

D

E

based on https://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis



SEFRMmatrix

Mastering Systems Integration; Readiness Levelsby Gerrit Muller TNO-ESI, University of South-Eastern Norway]


Abstract

Readiness level models offer a yardstick to assess the status of specific projectaspects. Examples are technology readiness and integration readiness.

Distribution



logoTBD

Technology Readiness Levels

TRL 1

TRL 2

TRL 3

TRL 4

TRL 5

TRL 6

TRL 7

TRL 8

TRL 9 actual system proven in operational environment

system complete and qualified

system prototype demonstration in operational environment

technology demonstrated in relevant environment

technology validated in relevant environment

technology validated in lab

experimental proof of concept

technology concept formulated

basic principles observed

after: https://serkanbolat.com/2014/11/03/technology-readiness-level-trl-math-for-innovative-smes/

Mastering Systems Integration; Readiness Levels124 Gerrit Muller


MSIRLtechnology

Integration Readiness Levels

TRL 1

TRL 2

TRL 3

TRL 4

TRL 5

TRL 6

TRL 7The integration of technologies has been verified and validated with

sufficient detail to be actionable.

The integrating technologies can accept, translate, and structure

information for its intended application.

There is sufficient control between technologies necessary to establish,

manage, and terminate the integration.

There is sufficient detail in the quality and assurance of the integration

between technologies.

There is compatibility (i.e. common language) between technologies to

orderly and efficiently integrate and interact.

There is some level of specificity to characterize the interaction (i.e.

ability to influence) between technologies through their interface.

An interface (i.e. physical connection) between technologies has been

identified with sufficient detail to allow characterization of the relationship.

from: From TRL to SRL: The Concept of Systems Readiness Levels, CSER2006, by Sauser et al.

Mastering Systems Integration; Readiness Levels125 Gerrit Muller


MSIRLintegration

Mastering Systems Integration; Process and Positioningby Gerrit Muller TNO-ESI, University of South-Eastern Norway]


Abstract

This lesson positions systems integration as process in the developmentprocesses.

Distribution



design

0.

feasibility

1.

definition

2.

system

design

3.

engineering

4.

integration

& test

5.

field

monitoring

6.

product operational

life cycle

-1

strategy

integrate test

requirements and

specification

policy

testintegratedesignrequirementspolicy

Typical Concurrent Product Creation Process

design

0.

feasibility

1.

definition

2.

system

design

3.

engineering

4.

integration

& test

5.

field

monitoring

6.

product operational

life cycle

-1

strategy

integrate test

requirements and

specification

policy

testintegratedesignrequirementspolicy

Mastering Systems Integration; Process and Positioning127 Gerrit Muller


SINTproductCreationProcess

Zooming in on Integration and Tests

0.

feasibility

1.

definition

2.

system

design

3.

engineering4.

integration & test

5.

field

monitoring

6.

product operational

life cycle

integratebeta

test

system

test

alpha

test

gamma

test

focus on reducing uncertainties

and hitting unknowns

“Fail Early”

focus on qualification:

documenting objective

evidence



MSIPPfocus

Integration Takes Place in a Bottom-up Fashion

component

system function

product

subsystem

integratealpha

test

context



SINTlevels

Mastering Systems Integration; Integration Strategyby Gerrit Muller TNO-ESI, University of South-Eastern Norway]


Abstract

This presentations discusses the strategy for integration. The strategy is trans-formed into an approach to determine an integration sequence based on KeyPerformance Parameters and potential risks to achieve them.

Distribution



Key Performance Parameters (KPPs) and Key Functionality milestones

control and performance stream

imaging stream

Full IQ

Full speed

First image

manual

preparation

10% IQ

manual

preparation

20% IQ

automated

preparation

10% speed

50% IQ

automated

preparation

100% speed

functioning

exposure

and

acquisition

time

definition of integration increments working backwards in time (demand driven)

IQ 3

increment

IQ 2

increment

IQ 1

increment

speed

increment

automation

increment

imaging

increment

IQ 4

increment

manual prep

increment

acquisition

increment

exposure

increment

Integration Strategy

· Get Key Performance Parameters functioning ASAP

· Work on highest risks ASAP

· Use a pacing process (regular visible results)

· with regular milestones

· and increments in functionality and performance

· Merge constraints from test configurations, suppliers,

resources, etc.

Mastering Systems Integration; Integration Strategy131 Gerrit Muller


MSIISstrategy

Pacing Milestones

Full IQ

Full speed

First image

manual

preparation

10% IQ

manual

preparation

20% IQ

automated

preparation

10% speed

50% IQ

automated

preparation

100%

speed

functioning

exposure

and

acquisition

pacing:

maximum 6 month between milestones

depending on technology and domain

time



MSIPMpacingMilestones

Defining an Integration Sequence in Increments

Key Performance Parameters (KPPs) and Key Functionality milestones

control and performance stream

imaging stream

Full IQ

Full speed

First image

manual

preparation

10% IQ

manual

preparation

20% IQ

automated

preparation

10% speed

50% IQ

automated

preparation

100% speed

functioning

exposure

and

acquisition

time

definition of integration increments working backwards in time (demand driven)

IQ 3

increment

IQ 2

increment

IQ 1

increment

speed

increment

automation

increment

imaging

increment

IQ 4

increment

manual prep

increment

acquisition

increment

exposure

increment



MISIPMdefiningIntegrationSequence

Stepwise Integration Approach

Determine most critical system performance parameters.

Identify subsystems and functions involved in these parameters.

Work towards integration configurations along these chains of

subsystems and functions.

Show system performance parameter as early as possible;

start with showing "typical" system performance.

Show "worst-case" and "boundary" system performance.

Rework manual integration tests in steps into automated regression

tests.

Monitor regression results with human-driven analysis.

1

7

5

3

2

6

4

Integrate the chains: show system performance of different parameters

simultaneously on the same system. 8



SINTapproach

Mastering Systems Integration; Project Managementby Gerrit Muller TNO-ESI, University of South-Eastern Norway]


Abstract

Systems Integration requires specific project management. The challenge forproject managers is to plan ahead, knowing that the integration plan will needcontinuous adaptations.

Distribution



master planning

time

now

~6 weeks

~2 weeksCombating Uncertainty in the Workflow of Systems Engineering Projects

by Barry Papke and Rick Dove, INCOSE 2013

commitment

planning

look ahead

planning

Integration Planning

defining

integration

sequence

project planning

resource

management

(test)facility

managementsuppliers

needsoptions

constraints

needs

options

constraintsmaster plan

actual situation

now

lead customers

Mastering Systems Integration; Project Management136 Gerrit Muller


MSIPMplanning

Demand Driven, Fitting Constraints

defining

integration

sequence

suppliers

defined by

output demand

mapped on

limited set of

test systems

trade-offs with

constraints

from suppliers

use of various environments (from virtual to final)

reordering of integration sequence

resource

management

trade-offs with

internal resource

constraints

(test)facility

management

lead

customers

limited

validation

options



MSIPMplanningIntegration

Last Planner; Look Ahead!

master planning

time

now

~6 weeks

~2 weeksCombating Uncertainty in the Workflow of Systems Engineering Projects

by Barry Papke and Rick Dove, INCOSE 2013

commitment

planning

look ahead

planning


version: 0.6November 18, 2020MSIPMlastPlanner

Mastering Systems Integration; Terminologyby Gerrit Muller TNO-ESI, University of South-Eastern Norway]


Abstract

This presentation defines terms, which are used in relation to systems integration,such as validation, verification, qualification, evidence, approval process, certifi-cation, and acceptance.

Distribution



logoTBD

Validation and Verification in the V-model

needs

specification

system

design

subsystem

design

component

design


component

test

subsystem

test

system test

verification

validationvalidation does the system fit the

needs and match expectations?

verification did we build

what we specified and

according the design?

Mastering Systems Integration; Terminology140 Gerrit Muller


VVTvModel

Functional Model of Verification

test

review

assess

report

system-of-interest

requirements

report

results

conclusion

test

specification

referencesqualification

documentation

with objective

evidence

problem reports

deviations

test

environment

test inputs



VVTverification

Certification

Certification: an independent agency (e.g. DNV-GL) certifies the quality of

the system-of-interest, technology, or process

Self-certification: the company has been accredited by the agency to do the

certification themselves.

check

qualification data

check process

and organization

optional audit

certify



VVTcertification

Development and (repeated) Production

development; only after design changes

production and delivery

once per system

system

specification

system

design

test

specification

qualification

documentation

acceptance

test procedure

verification

FAT factory

FAT report

SAT site

SAT report



VVTproduction

Objective Evidence

From a business perspective: Objective evidence is “information based on

facts that can be proved through analysis, measurement, observation, and

other such means of research.”

From a legal perspective: Objective evidence is “real evidence, also known

as demonstrative or objective evidence; this is naturally the most direct

evidence.”

From a scientific perspective: “To be termed scientific, a method of inquiry

must be based on gathering observable, empirical, and measurable

evidence subject to specific principles of reasoning. A scientific method

consists of the collection of data through observation and experimentation,

and the formulation and testing of hypotheses.”

From a list of Plain English definitions related to the ISO 9000, 9001

and 9004: Objective evidence is “data that show or prove that something

exists or is true. Objective evidence can be collected by performing

observations, measurements, tests, or by using any other suitable method.”

from: Understanding Objective Evidence: (What ItIs and What It Definitely Is Not),

by Denise Dion http://www.eduquest.net/Advisories/EduQuest%20Advisory_ObjectiveEvidence.pdf



MSITMobjectiveEvidence

FDA Requirements for Objective Evidence

FDA is a science-based law enforcement agency and, therefore, requires

answers that are scientifically and legally supported. FDA expects your

objective data to answer the following questions:

· Scientific – Can the data be evaluated by independent observers to

reach the same conclusions?

· Scientific – Are the data documented in a manner that allows re-

creation of the data or the events described?

· Scientific – Does the documented evidence provide sufficient data to

prove what happened, when, by whom, how, and why?

· Legal – Was the documentation completed concurrently with the tasks?

· Legal – Is the documentation attributable (directly traceable to a person)?

· Legal – Have the data and associated documentation been maintained in a manner that provides

traceable evidence of changes, deletions, additions, substitutions, or alterations?

· Legal – Are the data and associated documentation maintained in a manner that protects and

secures them from changes, deletions, additions, substitutions, or alterations?

from: Understanding Objective Evidence: (What It Is and What It Definitely Is Not),

by Denise Dion http://www.eduquest.net/Advisories/EduQuest%20Advisory_ObjectiveEvidence.pdf



MSITMobjectiveEvidenceFDAscientific

Regulatory Approval Process

regulatory agency

(e.g. FDA, DNV-GL)

manufacturer

create system

perform tests and

trials

review and approve

manufacture and

deliver

provide regulations

audit and inspect



MSITMapprovalProcess

Systems Engineering Deployment and Commissioningby Gerrit Muller University of South-Eastern Norway-NISE


Abstract

Deployment covers all steps from receiving shipped components to getting thesystem live and operating the system in its operational context.

Distribution



logoTBD

Deployment Workflow

installing

configuring

commissioning

configuration data

e.g. I/O lists

shipped

parts installed

system

customization data

e.g. doctrines, procedures

configured

system

operational

system

operating &

maintaining

operational data, e.g. mission, maps, weather

consumables, spare parts

physical

logical

application

performance

data

recycling

material

pollution

noise

installation

doc.

configuration doc.

commissioning doc.

operations and maintenance doc.

Systems Engineering Deployment and Commissioning148 Gerrit Muller


SEFDCworkflow

university of south-eastern norway-nise · 2020. 6. 21. · single page course overview company...

Documents