system architecting

CPDA – D6 Foundation of Systems Engineering

1/25© University of the West of England, Bristol 2007

System Architecting



Conventional Engineering Design Paradigm

• Traditional engineering tends to jump to design solutions very early in the process of problem definition (and solving) and fixes the unintended emergence as and when it occurs

• There is a strong pre-disposition to re-use and adapt existing design solutions

• This commitment to a specific solution architecture occurs early in the requirements definition stage and is very difficult to depart from

• Innovation is as often driven by technical enthusiasm as much as by user need

• The operating paradigm is generally evolutionary – stepwise advance generation by generation.

In conventional system design The System of Interest and its configuration are the Centre of Interest



The Focus Is On The System To Be Deployed

Source : Martin, J., 2004, The Seven Samurai of Systems Engineering,INCOSE International Conference – on UWEOnlineSource : Martin, J., 2004, The Seven Samurai of Systems Engineering,INCOSE International Conference – on UWEOnline



Source : Martin, J., 2004, The Seven Samurai of Systems Engineering,INCOSE International Conference – on UWEOnline

Source : Martin, J., 2004, The Seven Samurai of Systems Engineering,INCOSE International Conference – on UWEOnline

The System of

Interest

The Focus Is On The System To Be Deployed



Containing system

System of Interest

System

System

System

What are the interactions required with the System of InterestThese are the STAKEHOLDER or USER REQUIREMENTS

Look at the Interaction

s

The Focus is Generally on the System of Interest

BA



System of Interest

A B

White box analysis

Containing system

First Treat the System of Interest

as a Black BoxSystem

System

System

Look at the Interaction

sBut Is the Boundary

Right?

Do the Stakeholders

Know?

However We Need to Understand The Interactions and Opportunities



Explore The Robustness of the Requirements

• Perceptions of need are often framed against a conscious or unconscious pre-disposition to a particular solution– Challenge that by proposing alternate solutions to explore

the stated needs– If the requirements appear stable perhaps challenge that

stability with bizarre alternatives

• Try and mine the stated requirements as initially stated to bring out the underlying needs (or aspiration) that the candidate has revealed

• A test for a very robust requirement is that it survives intact with a wide variety of candidate solutions

• If not – why not?



The Use of Candidates Solutions Can Facilitate Understanding

Containing system

System of Interest

A B



System

System

Look at the Interactions

Containing system

System of Interest

A B



System

System

Look at the Interactions Containing system

System of Interest

A B



System

System


Containing system

System of Interest

A B



System

System


If some candidates do not meet the emerging stakeholder requirements – they have still served a purpose!!



But Be Careful……..

• The candidate solutions considered are often only increments of the existing solutions– Extension of an existing design– A development of what the customer already uses

• The frame of reference often constrains the solution space to an low margin incremental opportunity– Consider taking the analysis up a level to consider

the “System of Systems” issues– Question the stakeholders to understand their

“stakeholders” needs – the childlike “Why?” has its merits!

So Where Is This Particularly Important?



Strategic (Enterprise) Architecting - Airbus



Integrated Power Systems – Rolls Royce

AIR THRUST

ELECTRICAL GENERATOR

HYDRAULIC PUMP

STARTER SYSTEM

EHM DATA BLEED AIRSHAFT POWER

CABIN AIR

FUEL TANK PRESSURE

ELECTRICAL POWER

HYDRAULIC POWER

engine functionality

FUEL CONTROL

ANTI-ICING

Aircraft functionality

ENGINE BAY VENTILATION

AIR THRUST

ELECTRICAL GENERATOR

HYDRAULIC PUMP

STARTER SYSTEM

EHM DATA BLEED AIRSHAFT POWER

CABIN AIR

FUEL TANK PRESSURE

ELECTRICAL POWER

HYDRAULIC POWER


FUEL CONTROL

ANTI-ICING


ENGINE BAY VENTILATION

AIRAIR THRUSTTHRUST

ELECTRICAL GENERATORELECTRICAL GENERATOR

HYDRAULIC PUMP

HYDRAULIC PUMP

STARTER SYSTEM

STARTER SYSTEM

EHM DATAEHM DATAEHM DATA BLEED AIRBLEED AIRBLEED AIRSHAFT POWERSHAFT POWERSHAFT POWER

CABIN AIRCABIN AIR

FUEL TANK PRESSUREFUEL TANK PRESSURE

ELECTRICAL POWER

HYDRAULIC POWER



FUELFUEL CONTROLCONTROL

ANTI-ICINGANTI-ICING



ENGINE BAY VENTILATIONENGINE BAY VENTILATION

Rolls -Royce Design Authority

Not Rolls -Royce Design Authority

Customer Outputs

Rolls -Royce Design Authority

Not Rolls -Royce Design Authority

Customer Outputs

Air

Command

Fuel

Mechanical Power

Bleed

Thrust

Hydraulic Power

Electrical Power

Engine Health Data

Flight Data

Integrated Power

Systems Solutions

Conventional Power System Engine provides thrust plus mechanical &

pneumatic power. Aircraft systems transform mechanical

power into electrical/hydraulic power. System components individually optimised,

system functionally integrated.

Integrated Power System IPS provides thrust plus mechanical,

electrical, pneumatic & hydraulic power. Aircraft systems define demand for power

which is interpreted by the IPS Resource Manager.

System components are designed to deliver optimal system performance.

Air

Command

Fuel

Mechanical Power

Bleed

Thrust

Hydraulic Power

Electrical Power

Engine Health Data

Flight Data

Integrated Power

Systems Solutions

Air

Command

Fuel

Air

Command

Fuel

Mechanical Power

Bleed

Thrust

Hydraulic Power

Electrical Power

Engine Health Data

Flight Data

Mechanical Power

Bleed

Thrust

Hydraulic Power

Electrical Power

Engine Health Data

Flight Data

Integrated Power

Systems Solutions

Integrated Power

Systems Solutions

Integrated Power

Systems Solutions

Source : INCOSE BLG Presentation – Sept 2004 – Gordon Warnes, Rolls Royce



Candidate Architecture

• Getting this right is critical to success• Modelling can support decision-making• “Expert” viewpoints are a critical success

factor• The further the departure from the norm the

higher the risks but offset by potentially much higher returns

• Early Risk Reduction becomes dominant paradigm for innovative lines of development



System of Interest

A B

White box analysis

Containing system

System

System

System

Now We Need to

Open the Box

To Take the Analysis Further We Need to Open the Box and Start Testing the Architecture



• Once the initial stakeholder requirements (including in house ones) are exposed the candidate systems of interest can then be explored from a wide range of viewpoints

– Manufacture – Does it use the existing infrastructure?

– Use – Will the customer need to collaborate?

– Support – Who is providing it?

– Maintenance – Are we paying?

– Misuse – Is it vulnerable?

– Retirement – Can we recycle/reuse it?

– Disposal – Are there new hazards?

– etc.?????

• The ambition is to achieve an understanding of both desirable and undesirable interactions.

With the Candidate Architectures

These will be dependent on the system architectureultimately chosen and in reality are often determinants of it



Remember Rich Pictures Help to Illuminate Interactions

I hope we don’t get computers

We need to automate

100 test centres

accountant

manualfiling system

education assistant

education secretary

members

students

exams

GENERAL COMMITTEE

secretary

employers

How can weget a better

service?

Too muchwork due toincreased

role

D E Avison & G Fitzgerald, Information Systems Development, 2nd ed (McGraw-Hill, 1995),Fig 4.2



Life-Cycle Views

• What is required of the system of interest over time– What is the proposed system replacing?

• What is its predecessor doing• What new is needed

– When will it be needed?

– How will it be introduced?

– How will it be supported?

– When will it be replaced?

Again some of these issues will reveal constraints whichwill ultimately lead to certain candidates being unviable



The Systems Engineering Life- Cycle Standard – ISO15288

Need to be Considered at the Stakeholder Requirements and Architecting Stages



So Now We Know What’s Wanted – What Next? – System Requirements

Containing system

System

System

System of Interest

A B

Attributes of B

Attributes of A

Attributes of A-B

interactions

System

Who designs these?Who designs these?

Attributes of interactions with other systems



Containing system

System of Interest

We now have more Black Boxes at a

Lower Level in the Hierarchy!!

So Now We Know What’s Wanted – What Next – System Requirements

System

System

SystemBlack Box 1 Black Box 2

WHITE BOX



Developing the Systems Resqirement Document (SRD) Often Forms Part of a Concept Study

• SRD Development is a fluid process• Often driven by Simulation, Modelling, Scenario

Investigation, Review of Technology Options• The objective is to determine the risk, cost, return

balance to develop a realistic SRD which can be costed

• This phase is often undertaken in a separate contract often led be a party who is barred from bidding for the main contract

• In a non-contractual environment it may be led by a team of experts drawn from the lead company and its suppliers and run as a discrete activity



A Typical Process for System Requirements Maturation

Note The Feedback

Loop



Heuristics (Guides) Can Be Used to Assist Architectural Development - A Challenge!!

• The team that created and built the present successful product is often the best for its evolution but seldom for creating its replacement

• If you don’t understand the present system you can’t be sure you’re re-architecting a better one

• When implementing a change keep some elements constant to provide an anchor point

Source : Maier, M. and Rechtin, E (2003); The Art of Systems Architecting, CRC Press



• A good design has benefits in more than one area

• System quality is defined in terms of customer satisfaction not requirements satisfaction

• If you think your design is perfect it is only because you haven’t shown it to someone else

• “Proven” and “State of the Art” are mutually exclusive qualities

Heuristics (Guides) Can Be Used to Assist Architectural Development - A Challenge!!

Source : Maier, M. and Rechtin, E (2003); The Art of Systems Architecting, CRC Press



You will find hundreds of these in Maier and Rechtin’s book!!

However the production of a viable system still depends on engineering the detail right……………..



Once The Architecture Is Set (or Postulated) Then The Conventional SE Tools Come into Play To Design, Develop and Verify

Capture stated customerrequirements and determineKey Requirements

“Customer”Requirement

URD Operational ...

Functional…..

Non - Functional….

userinteraction maintenance cutting

process

IntelligentLawn mower

supplymachine

navigation supplypower cutting

cut grasscollect grasscuttings

drive andmanoeuvre

determineposition

senseobstacles

senselawn state

internalmanagement

learning selfmonitor

Textual Analysis

Viewpoint Analysis

Viewpoint: Function S Severity of Occurrence Criticality Index Date................................

No: ....

System: Washing MachineO Probability of Occurrence CI = SOD

Author: .......................... Issue

Subsystem: ......................................D Probability of Detection

Checked: ....................... ...........

FUNCTIONCHARACTERISTICS OF FAILURE INDEX

MODE EFFECTS CAUSE O S D CI COMMENTS

LOAD DIRTY CLOTHES

DETERMINE LOAD MAKEUP

OVERLOAD

UNDERLOAD

EXTREME MIX OFLOAD

INCORRECT LOADMAKE UPINDENTIFIED

POOR WASH

POOR WASH

POSSIBLE COLOURRUN

FABRIC SHRINK

POOR WASH

POSSIBLE COLOURRUN

FABRIC SHRINK

USER ERROR

USER ERROR

EXTREMES NOTIDENTIFIED

EXTREMES NOTIDENTIFIED

ITEM OF CLOTHINGNOT INDENTIFIED

6

4

8

4

4

6

4

8

8

8

3

3

3

3

3

108

48

96

96

96

FlowReceivingFunction

Sensitivityto flow

X 1.1

y 1.2

w 2.2.1

u 2.3.1

etc

Multi-language

Coin/card/credit

Durable

Reliable

Cleans easily

Maintainable

CustomerRequirements

Design Requirements

Importance to Customer

Opt

iona

l Lan

Key

pad

Car

d re

ader

Coi

n ha

ndlin

g

Con

tain

men

t

Wip

e cl

ean

3

5

5

4

2

5

Importance Weighting 5839 82 139 126 50 18

x

xx

Easy to use

Fea

ture

sO

pera

tion

4

Dis

play

x

Eur

opea

nA

rabi

c

16 m

ax1M

ops

lum

inos

ity

95%

val

idat

ion

All

stan

dard

500k

inse

rts

1kN

sho

ck

3 m

inm

in in

gres

s

Target values

Technical competitiveassessment

QFD 1

Determine product/system functionality Y = f and Structure requirements

Functional ModellingDevelop a functional model ofthe product/system Y= f(x)to identify logical interfaces

Correlate and cross checkrequirements for completenessand consistency

PURCHASE

1

CULTIVATE

2

PICKVEGETABLE

3

EXTRACTSEED

4

CU

RR

EN

T_PR

ICE

S

BU

DG

ET

HE

ALT

H_I

TE

MS

PURCHASED_SEEDS

PURCHASED_FERTILIZER

PURCHASED_HEALTH_ITEMS

CO

MP

OS

T

VEGETABLES

HO

ME

_GR

OW

N_S

EE

D

DIAGRAM 0

WE

AT

HE

R

SO

IL_Q

UA

LITY

PLANTS

SEEDS

WATER

AcceptanceTest Spec

Sensitivity AnalysisAssess the functional sensitivity and potential functional failure modes to give an early riskassessment

Generateacceptance criteria

DOORS

GenerateDOORS database

12.1

2.2 2.3

2.4 2.5

2.63

N2 Analysis

Whole concept Selection

QFD 2

CriteriaMaterialcost

M’fcturecost

Time toproduce

Reliability Safety Loadcarrying

OverallSatisfaction

Weighting 0.10 0.20 0.05 0.25 0.3 0.1 1.0

Schemes

Built-upplateswelded

90%

9

80%

16

80%

4

90%

22.5

80%

24

90%

9 84.5

Built-upplatesriveted

90%

9

90%

18

90%

4.5

90%

22.5

80%

24

90%

9 86.5

Cast hook80%

10

50%

10

75%

3.7

80%

20

80%

24

80%

8 75.7

Decision Matrix

Function Means Analysis

Identify means ofachieving functionality

Assess degree of natural functionalbinding and coupling to identify natural Architecture and system redundancy

Determination of whole concept solutions

Evaluate whole conceptsagainst CTQs for furtherdown-selection

Requirements-concept solution compliance and determine sub system targets

PURCHASE

1

CULTIVATE

2

PICKVEGETABLE

3

EXTRACTSEED

4

CU

RR

EN

T_PR

ICE

S

BU

DG

ET

HE

ALT

H_I

TE

MS

PURCHASED_SEEDS

PURCHASED_FERTILIZER

PURCHASED_HEALTH_ITEMS

CO

MP

OS

T

VEGETABLES

HO

ME

_GR

OW

N_S

EE

D

DIAGRAM 0

WE

AT

HE

R

SO

IL_Q

UA

LITY

PLANTS

SEEDS

WATER

UpdateFunctional Model

Reliability Model

Fault Tree Analysis

Determine failuremodes & mechanisms

Determine design reliability

FMEA

Source : INCOSE BLG Presentation – Sept 2004 – Gordon Warnes, Rolls Royce

system architecting

Documents