Systems and Software Architecting for “the Many” -- Some Research Challenges of SoS

Systems and SoftwareArchitecting for “the

Many” -- Some Research Challenges of

SoS

Stephen C-Y. Lu, Ph.D.David Packard Chair in Manufacturing Engineering

Director, Product Development Engineering ProgramFounding Director, the IMPACT Research Laboratory

University of Southern CaliforniaLos Angeles, California USA 90089

Tuesday, October 24, 2006 – Los Angeles, California

USC/CSSE Convocation, 2006 (Systems, Software and People)

2Systems and Software Architecting for “the Many” – Research Challenges of SoS

USC/CSSE Convocation, Los Angeles, CA, 10-24-06

Stephen C-Y. Lu © 2006

Prologue…My research interest is in design theory & methodology for engineering systems. For example,• How should a design team collaborate to reach sound and

rationale system decisions?• How can we encourage and improve the level of innovation in

engineering systems design?

Specifically, I have been working on basic researches in• Collaborative engineering (close collaboration)• Technological innovation (open innovation)

I have the benefit of pre-viewing some of your slides to• Learn new perspectives from experts in systems and software• Share my viewpoints from design, collaboration, & innovation• Ask a few critical questions that may stimulate new thinking • Explore basic research challenges for our common interests




Basic Premises…

As our world becomes “flat”…• Internet revolution; Web 2.0 era; globalization; etc.• From “Power of the Few” to “Power of the Many”

System of Systems is definitely in – beyond scaling*• The social and technical spiral interaction• The evolutionary and emergent property• The dynamic and evolving complexity

It is “not your father’s” old systems and software engineering (SSE) anymore!• The SSE filed has reached a Strategic Inflection Point

• Nothing less than fundamental changes will do..• What is your “soapbox” in this new flatten world?

• A new framework** and architecting*** approach for SoS

* Nielsen

** Categories for organizing views – Axelband*** Creating and building complex systems – Rechtin




What is System of Systems (SoS)?

SoS = a set of interacting technical systems (i.e., relations & variables) that are being collaboratively worked on by a network of stakeholders in organizations (i.e., a dynamic social system) to jointly perform some desired functions.

Socio-technical System(System of Systems)

Systemof

Systems

relation

variableTechnical System

Technical Systems

Determinism / Physics

stakeholderSocial System

organizationConstructionism / Preferences

Social System

SoS is a system which is comprised of systems that are independently developed and managed, having their own purposes and can dynamically come and go – Boehm

Aust

inN

iels

en

Boeh

m




The Traditional Technical Paradigm

WHAT HOW

Engineering

(WHY)(WHO)

(WHY)(WHO)

Marketing

Service

??

?

Design Engineer / System Engineer

WHAT HOW?Engineering Decision

Making

What do you want to achieve?

How do you propose to achieve it?




A Socio-Technical SoS Framework

Teamwork Taskwork

Interaction

WHO(Stakeholder)

Preference

WHY(Rationale)

The Social Dimension The Technical Dimension

Understanding

WHAT(Goal)

Agreement

HOW(Decision)

A Socio-TechnicalFramework for SoS

systematicallymodel social

interactions among stakeholderswithin a team

consistentlyaggregate group

preferences basedon a common

understanding

collaborativelynegotiate conflicts; make participative joint decision with a group preference

dynamicallymanage the socio-technical cycles based on the agreement




Process/Stage of SoS Framework

Who (stakeholder)• A common goal (based

on the shared value)• Sufficient expertise

What (goal)• Common understanding

of the given goal• Communal understanding

of roles w.r.t. the problem

Why (rationale)• Aggregate multiple

preferences to form a group preference, or

• (when a group preference fails) identify conflicts

How (decision)• Make a participative joint

decision (PJD): agreement

• or, manage conflicts and negotiate consensuses

Administer Social Interactions

Aggregate Multiple Preferences

Negotiate Joint Decisions

Common Understanding

Group Preference or Conflicts

PJD or Team AgreementTechnical

Social

Manage t

he s

oci

o-t

ech

nic

al cy

cle

CE Team

Stage 1

Stage 2

Stage 3




IDEF0 Definition of SoS Framework

(1) a given goal(2) sufficient expertise(3) limited resources(4) time bound(5) autonomy

WHO(stakeholder)

WHAT(goal)

a commonunderstandingof goal & task

AdministerSocial

Interactions

AggregateMultiple

PreferencesNegotiate

JointDecisions

WHY(rationale)

HOW(decision)

SocialConstructionMechanisms

SocialChoiceModels

CollaborativeNegotiation

Methods

(1) a common understanding of the taskwork goal

(2) a common understanding of task dependencies

(3) a common understanding of stakeholder roles

(4) available continuous social choice models

(1) a group preference, or identified conflicts

(2) each stakeholder’s BATNAs (or EATNAs)

(3) negotiation protocols

Input Output

Control

Mechanism

Function

a grouppreference or

identified conflicts

an agreementcommitted by

team members

a collaborativeengineering

team

1

2

3

FEEDBACK

FEEDBACK

FEEDBACK

IDEF0FunctionalDefinition




SoS Architecting as an Design Task

SoS architecting can be treated as an engineering design task:• Design the right thing (choose innovative functional requirements)• Design the thing right (generate creative design concepts)• Detail technical design (produce accurate technical specifications)

Preference of the Customer Physics of the NatureFunction

Assignment

(Social) (Technical)(Socio-Technical)

What? How ?

What? How ?

CustomerCustomerNeedsNeeds

FunctionalFunctionalRequirementsRequirements

DesignDesignParametersParameters

ProcessProcessVariablesVariables

Who?

Why?

SystemArchitecti

ng

Conceptual Design Detail DesignFunction Assignment




You Should Never Mix FR with DP

Functional Requirements (FRs) and Design Parameters (DPs) are two very DIFFERENT things - they should not be mixed• They should be architected in different DOMAINS (see next)

FRs are WHAT you want/wish/choose to achieve• Designer’s (not customer’s) choices, i.e. “wish-list” from CNs• Conceptual and abstract (not in the physical world)• Not subjected to the limitations of physics and resources

• Ideally, they should be based on implementation-free thinking

• They should be written down (and read) as “verbs”DPs are HOW you propose to achieve the chosen WHAT• Designer’s creative choices derived from FRs – the real thing• Less conceptual and abstract (in the physical world)• Subjected to the limitations of physics and resources

• Practically, they should lead to actionable parameters

• They should be written down (and read) as “nouns”




Approach to Systems Architecting

The old-fashion way: • Ad-hoc process jumping around

•Unable to deal with complex systems•Chaos, unstable, costly, time consuming practice

The current systems engineering approach: • 1-D architecture hierarchical decomposition

•Can control the abstraction, but not the dependency

•Resulting systems are often fragile and not robust

The advanced engineering design approach: • 2-D architecture mapping and decomposition

•Can deal with both abstraction and dependency•Can yield highly modularized and robust systems




Axiomatic Design (AD) Architecture

“Zig-zag” maneuver from CN-i to PV-n in a 2-D spaceAD suggests 2 axioms to guide zig-zaging operations

Socio-Technical

CustomerDomain

FunctionalDomain

PhysicalDomain

ProcessDomain

CNs FRs DPs PVs

Layer I

Layer II

Layer III

Layer IV

Layer N

Mapping

Decomposition

Y

Xwhat how

abstract

detailSOCIAL

TECHNICAL

FunctionalHierarchy

PhysicalHierarchy

(realized-by)

(part-of)




CN1 = Food preservation FR1 = Cool the food DP1 = a refrigerator PV1 = Refrigerator manufacturing process

FR1-1 = Keep foodWithin specific Ts

FR1-2 = Maintain uniformTemperature within the box

DP1-1 = ?

DP1-2 = ?DP1-1

MappingFrom FR1-1

Decompose from DP1

ConstraintFrom PV1

CN1

Mapping

Decomposition Constraint

“Zigzagging” Architecting Process




Two Fundamental Design Axioms

The 1st Axiom (Independence Axiom)• Always maintain the independence of FRs

•Choose independent and minimal FRs to satisfy CNs

•Ensure each FR is independently satisfied by a DP Uncoupled; Decoupled; Coupled design

The 2nd Axiom (Information Axiom)• For those designs satisfy the 1st axiom, the best

one has the minimal information content • Information content is defined in terms of its

probability of satisfying a specific FRs

FR11

FR12

FR13

X O O

O X O

O O X

•

DP11

DP12

DP13

FR11

FR12

FR13

X O O

X X O

X X X

•

DP11

DP12

DP13

FR11

FR12

FR13

X O X

O X X

X X X

•

DP11

DP12

DP13




Water Faucet Example

(A)

(B)

(C)

Fu

nctio

nal

Cou

plin

g

Ph

ysic

al

Cou

plin

g

Resu

lting

Desig

n

Desig

n(A

)D

esig

n(B

)D

esig

n(C

)

YES

YES

NO

NO

NO

NO

Bad

Desig

nG

ood

Desig

nB

ette

rD

esig

n

CN = having a comfortable shower

FR1 = to regulate water flowFR2 = to control water temperature

DP1= Hot valvePD2= Cold valve

DP1= Up-down movePD2= Side-side move




Real Case: NASA’s CEV System*

13 Phases of a Typical Lunar Mission

Level 0 Functional Requirements (FRs):• FR1 = carry crews to the moon from Earth• FR2 = carry crews from the moon to Earth• FR3 = carry cargo to the moon from Earth• FR4 = carry cargo from the moon to EarthSome examples Constraints (Cs):• C1 = Max. no. of crew members is N both ways• C2 = Max. cargo weight is W1 from Earth to moon• C3 = Max. cargo weight is W2 from moon to Earth• C4 = test flight by 2008Level 0 Design Parameters (DPs):• DP1 = LV and CEV human (CEV-H) system• DP2 = CEV human (CEV-H) system• DP3 = LV and CEV cargo (CEV-C) system• DP4 = CEV cargo (CEV-C) system

FR

FR1 FR2 FR3 FR4 DP1 DP2 DP3 DP4

DPdecomposition

mapping

DP21DP22DP23FR21 FR22FR23

* From “Complexity in Engineering,” by N. P. Suh, CIRP Keynote, 2006




2 Different System Architectures* (A) (B)

DecoupledDesign

(achieve independent controlof all 4 FRs – less complex)

CoupledDesign

(more complex)





FRs/DPs Architecting for Option B*

Level 1 Functional Requirements (FRs):• FR11 = lift (CEV-H with emergency power & fuel) from Earth to in-space site• FR12 = lift (LM-H with emergency power & fuel) from Earth to in-space site• FR13 = lift RTS from Earth to in-space site• FR14 = transport (CEV-H & fuel + LM-H) from in-space site to lunar orbit• FR15 = land the crew on the moon from lunar orbit• FR16 = assemble (LM-H with emergency power & fuel) to LM-H and RTS• FR17 = fuel RTS• FR18 = lift fuel

Level 1 Design Parameters (DPs):• DP11 = ELV-1• DP12 = ELV-2• DP13 = ELV-3• DP14 = RTS• DP15 = LM-H• DP16 = assembly station• DP17 = fuel station• DP18 = ELV-4

(Maintain a decoupled design)





Conclusion: Implications to SoS

SoS is more than just bigger and bigger systems!• How to architect the socio-technical system framework?

• How to manage the evolutionary emergent behavior?

• How to control the dynamic system complexity?

SSE architecting plays a critical role in SoS• Must simultaneously deal with dependency & abstraction

• Must explicitly model the stakeholder interactions as part of the system architecture – constructionism

Engineering design research can offer some helps• Design theory and methodology

• Collaborative engineering




For More Information…

International Journal of Collaborative Engineering• http://www.inderscience.com/ijce

Engineering Collaboration via Negotiation @ CIRP• http://wisdom.usc.edu/ecn and http://www.cirp.net

Collaboration Science and Technology @ USC• http://wisdom.usc.edu/cst

MS in Product Development Engineering (MSPDE)• http://wisdom.usc.edu/mspde and

http://den.usc.edu/programs/mspde

Socio-Technical Framework for Collaborative Design• http://wisdom.usc.edu/stf

Stephen Lu (personal website)• http://wisdom.usc.edu/stephenlu

Systems and Software Architecting for “the Many” -- Some Research Challenges of SoS

Documents

Transcript of Systems and Software Architecting for “the Many” -- Some Research Challenges of SoS