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
3Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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
4Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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
5Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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?
6Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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
7Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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
8Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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
9Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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
10Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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”
11Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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
12Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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)
13Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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
14Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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
15Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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
16Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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
17Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
2 Different System Architectures* (A) (B)
DecoupledDesign
(achieve independent controlof all 4 FRs – less complex)
CoupledDesign
(more complex)
* From “Complexity in Engineering,” by N. P. Suh, CIRP Keynote, 2006
18Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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)
* From “Complexity in Engineering,” by N. P. Suh, CIRP Keynote, 2006
19Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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
20Systems and Software Architecting for “the Many” – Research Challenges of SoS
USC/CSSE Convocation, Los Angeles, CA, 10-24-06
Stephen C-Y. Lu © 2006
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