Embed Size (px)
Citation preview
System Integration Frameworks
Joseph J. SimpsonMary J. Simpson
July, 2005
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 2
Overview
• Definitions of System, Meta-System
• Integration and Complexity Reduction
• Classical System Engineering Approach
• System Engineering Patterns, CCFRAT
• System Engineering Cognitive Support
• System Engineering Language Proposal
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 3
Definitions
System Meta-system*
“A constraint on variety.” (Heylighen 1994)
[‘Functional’ Definition – Constraint identifies and defines the system]
“A non-empty set of objects and a non-empty set of relationships mapped over these objects and their attributes.”(Simpson & Simpson 2003)
[‘Construction Rule’ Definition]
“A constrained variation of constrained varieties.”(Heylighen 1994)
“A set of value sentences which describe the wanted physical system, and which imply or actually comprise the parts and relationships of the meta-system.” (A.D. Hall, 1989)
“Indicates the field within which the system arises and within which it interacts with other systems.”(K.D. Palmer, 2000)
* Related definitions in that:1. All value determined in context2. Concept of system used in
different modes
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 4
‘Real’ Objects
Increasing Complexity
Design Objects
Design Objects
Discover Relationships
Discover Relationships
‘Conceptual’ Objects
Design Mode(Know
Relationships)
Discovery Mode(Know
Objects)
System Objects Relationships“Over which
we map”
Discovery Mode
Know the Objects
Discover the Relationships
Design Mode
Design the Objects
Know the Relationships
A Mapping Context for Complexity
Discovery (Kepler)
Design (Kennedy)
Know the Planets
Design the Objects, Config
Discover the Mathematical Relationships
Know “Man on the Moon”
System Modes
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 5
Types of System Complexity
Type 1 System Complexity - Allocates the complexity characteristic to the system of interest
Number of objects – WeinbergNumber of relationshipsNumber of different types of objectsNumber of different types of relationships (Casti)
Type 2 System Complexity - Allocates the complexity characteristic to the relationship between two systems (Warfield and Casti)
Rate of change of objectsRate of change of relationships (Casti)Rate of change of the environmentRange of variability
Number of relationshipsNumber of observersDifference in abstraction level (ant hill to ant – not complex
ant hill to human – very complex)
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 6
Problem Space TopologyIn
crea
sing
Com
plex
ity
Table adapted from Chapter 9 Problem Solving Skills, Introduction to the Engineering of Complex Systems, Brian W. Mar, 1996.
Features of a system are largely driven by its problem space
A systems approach is characterized hierarchically by
• Abstraction frames
• Degree of complexity
• Levels of detail
Complexity# of Individuals,# of Variables
Problem SpaceWell-defined vs
Ill-Defined
Solution SpaceUnique vs Multiple
Solution(s)
Simple
Simple
Simple
Simple
Complex
Complex
Complex
Complex
Well-Defined
Ill-Defined
Well-Defined
Ill-Defined
Well-Defined
Ill-Defined
Well-Defined
Ill-Defined
Closed
Closed
Open
Open
Closed
Closed
Open
Open
6
Indu
ctiv
eD
educ
tive
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 7
Increas
ing
Complexity
Deducti
ve
Inductive
Complexity Problem Space Solution Space
Well-DefinedIll-Defined Closed Open
Simple
Simple
Simple
Simple
Complex
Complex
Complex
Complex
(# of Variables# of Individuals)
Model
Model
Model
Model
Model
Model
Model
Model
System Conceptual Topology
Types of Systems with respect to Methods of Thinking
ComplexityComplexity
I. Organizedsimplicity(machines)
Ran
dom
ness
Ran
dom
ness
II. UnorganizedComplexity
(aggregates)
III. OrganizedComplexity(systems)
Adapted from “introduction to General Systems Thinking” G.M. Weinberg
Weinberg’s Conceptual RegionsSystem Integration Frameworks
“too complex for analysis;too organized for statistics”
Use of Statistics
Use of Analysis
Copyright 2005Joseph Simpson, Mary Simpson
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 9
Exterior Interior
ProblemStatement
SuggestedSolution
System Boundary
Goode & Machol System Design (1)
Exterior Interior
ProblemStatement
MathematicalModel
Design ofExperiments
Single-threadDesign
High-trafficDesign
CompetitiveDesign
- SuggestedSolution
System Boundary
Organization Phase
Initiation Phase – Initiates the Project• Exterior portion concerns itself with things outside
of the system: requirements on the system and its environment
• Interior portion concerns itself with design choices relative to equipment, procedures and people: the system itself
Problem is outside the SystemSolution is inside the System
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 10
* Goode, Harry H. and Machol, Robert E., System Engineering, McGraw-Hill Book Company, Inc, 1957 10
Preliminary Design Phase
Goode & Machol System Design (2)
Answers questions which have only equivocal answers, iterates & documents the reasoning for choices made
Describes overall system operation in considerable detail
Achieves‘First’ System
Creates the Initial System
Boundary
Delineates each subsystem by (a) inputs and outputs, (b) its functioning (operation on its input to produce its output), (c) limiting specifications concerning allowable sizes, weights, etc., and (d) at least one method of physically realizing proposed function within these limitations
Exterior Interior
ProblemStatement
Inputs
MathematicalModel
LogicalControl
ExperimentalDesign
HandlingEquipment
FieldExperiments
Communication
ReflexiveControl
Outputs
Single-threadDesign
High-trafficDesign
CompetitiveDesign
Analysis
CriticalEquipment
Experiments
- Suggested SolutionExterior Interior
ProblemStatement
Inputs
MathematicalModel
LogicalControl
ExperimentalDesign
HandlingEquipment
FieldExperiments
Communication
ReflexiveControl
Outputs
Single-threadDesign
High-trafficDesign
CompetitiveDesign
Analysis
CriticalEquipment
Experiments
- Suggested Solution
System Boundary
Relationship between Systems
Warfield, Poly-Loop Model in Problem Solving
© 2004 Joseph J Simpson, Mary J SimpsonFigure adapted from Chapter 4 Managing Complexity through Systems Design: The Use of the Science, A Science of Generic Design, John W Warfield, 1994.
1-Loop
0-LoopFoundationsE
4-Loop
Act on theFoundations D
B
3-Loop
Act on theProcess Set
Set of ProcessesC
Theory
Act on theTheory
2-Loop
A
One Process Plan
Act on theProblem
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson
∆af n-1 ∆af n ∆af n+1
Overall Environment
Abstraction Frame (n-1) Abstraction Frame (n+1)Abstraction Frame (n)
© 2004, Joseph J Simpson
Abstraction Frame SequencingSystem Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson ∆af n-1
© 2004, Joseph J Simpson∆af n-1 ∆af n ∆af n+1
Discovery
Knowledge
Design
SystemsSystems
Discovery
Knowledge
Design
SystemsSystems
Discovery
Knowledge
Design
SystemsSystems
Discovery
Design
Discovery
Design
Discovery
Design
Discovery
Knowledge
Design
Systems
Discovery
Knowledge
Design
SystemsSystems
Discovery
Knowledge
Design
Systems
Discovery
Knowledge
Design
SystemsSystems
Discovery
Knowledge
Design
Systems
Discovery
Knowledge
Design
SystemsSystems
Discovery
Design
Discovery
Design
Discovery
Design
Discovery
Design
Discovery
Design
Discovery
Design
Abstraction Frame (n-1) Abstraction Frame (n+1)Abstraction Frame (n)
Coupling SE Process Modes through Knowledge
Frame Context RelationshipsSystem Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson
∆af n-1
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 14
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
© 2004 Joseph J Simpson
CCFRAT
System
Context
Boundary
Concept
Example
Wisdom
Knowledge
Information
Data
Incontext is
Concepts include
Incontext is
Concepts include
Incontext is
Concepts include
Constraints
DefineMission Needs
Define FunctionsThat Meet Needs
DefineRequirements
DevelopAlternatives
Regulators
CustomerReviews& Audits
Customer
Developer
Developer Goals &Objectives
Customer &Stakeholders
Customer &Developer
System Descriptions generated at this level form the Mission
for the next level
SelectSolution
V & V
Developer
Developer
DevelopDecisionCriteria
From “FRAT – A Basic Framework for Systems Engineering,” Mar & Morais
DefineSystemSolution
DefineProblem
Statement
© 2004 Joseph J Simpson,
The FRAT Design EngineSystem Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
CO
NTE
XT V
IEW
CONTEXT VIEW
CO
NTEXT VIEW
CONTEXT VIEW
Architecture
A1 A2 A3
Arch. View
Requirement
R1 R2 R3
Reqt. View
Test
T1 T2 T3
Test View
Function
F1 F2 F3
Funct. View
CONCEPT VIEW
CONCEPT VIEW
Value Set 1
Value Set 2
Value Set 1
Value Set 2
© 2004 Joseph J Simpson
Value Network in the Context ViewSystem Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson
* Simpson, Joseph J., “Innovation and Technology Management,” INCOSE 12th
Annual International Symposium, Las Vegas, NV, 2002 17
Science Stream
Organization Stream
Technology Stream
Application Stream
Product Stream
t
Product(System)
Incremental(sustaining)
Incremental(sustaining)
Fundamen
tally
new (ra
dical)
NewTechnology
Fundamen
tally
new (ra
dical)
ApplicationNewScience
Organization(System)
Incremental(sustaining)
Incremental(sustaining)
Fundamen
tally
new (ra
dical)
Fundamen
tally
new (ra
dical)
Value “Streams of Change”System Integration Frameworks
How the Problem Changes in the System Environment
Copyright 2005Joseph Simpson, Mary Simpson
Content• Technical• Management• Programmatic
Content• Technical• Management• Programmatic
Phases• Over time• Over products• Over events
Phases• Over time• Over products• Over events
Hierarchies• Abstraction• Meta-levels• Levels of detail
Hierarchies• Abstraction• Meta-levels• Levels of detail
Meta Process
Applies to:
Meta Process
Applies to:
Pick One Aspect from Each Axis© 1999 Mary J Simpson
CCFRAT ApproachSystem Integration Frameworks
Phases, Hierarchies, Content
Copyright 2005Joseph Simpson, Mary Simpson
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 19
*“… house consists of several thousand pounds of carbon,
some complex polymers, about 5000 bricks, two bathrooms,
and 13 ceilings…”
A House Consists of: Use of Abstraction ‘Stacks’
* From Chapter 12, What do Classes Represent?, The C++ Programming Language, 2nd Edition, Bjarne Stroustrup, 1991.
Atoms
Molecules
Lumber, Bricks
Floors, Walls,Ceilings
Rooms
‘Abstraction Stacks’
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 20
Warfield, S&T Language Design Capability
Natural Language(The Metalanguage)
Formal Logic(Intermediate Language)
Formal Language of Choice
Object Language Drawing on Formal Language of Choice
In Terms of an Abstraction Stack
Natural Language(The Metalanguage)
Formal Logic(Intermediate Language)
Formal Language of Choice
Object Language Drawing on Formal Language of Choice
Initial Inter-Relationships Defined: “Pattern of Infrastructure”
“ProvidesLinguisticSupportFor”
Where
=
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 21
State / Event
Time
S-5
T-n
S-M S-4 S-3S-6 S-2
T-10 T-9 T-8 T-7 T-6 T-5 T-4 T0
S-1
Interdependencies
T-3 T-2 T-1
..
….
State / Event
Time
S-5
T-n
S-M S-4 S-3S-6 S-2
T-10 T-9 T-8 T-7 T-6 T-5 T-4 T0
S-1
Interdependencies
T-3 T-2 T-1
..
….
State / Event
Time
S3
T-1
S1 S4 S5S2 S6
T0 T1 T2 T3 T4 T5 T6 Tn
SM
T7 T8 T9 T10
..
….Interdependencies
State / Event
Time
S3
T-1
S1 S4 S5S2 S6
T0 T1 T2 T3 T4 T5 T6 Tn
SM
T7 T8 T9 T10
..
….Interdependencies
Pre-Trigger
Post-Trigger
Process Mechanisms(Precedence/Timing Logic)
Atoms
Lumber, Bricks
Molecules
Floor, Walls
Rooms
Atoms
Lumber, Bricks
Molecules
Floor, Walls
Rooms
Relationships(Mapping/Order/Constraint Logic)
Abstraction ‘Stacks’(Contextual Logic)
Expanded CCFRAT Approach
Being’sMeta-levels
Bateson’sSeries
Modalities ofBeing-in-the-
World
Being meta-level 5
ULTRA
Being meta-level 4
WILD
Being meta-level 3
HYPER
Being meta-level 2
PROCESS
Being meta-level 1
PURE
Being meta-level 0
ENTITY
Learning 1as an ideal gloss
ConcreteInstances 0
of learning in world
Empty Handedness
Emptiness or Void
Out-of-Hand
In-Hand
Ready-to-Hand
Present-at-Hand
Orientationtoward Things
Associated Cognitive Abilities
CognitiveInability
Encompassing
Bearing
Grasping
Pointing
Thing
Associated Cognitive Abilities
CognitiveInability
Encompassing
Bearing
Grasping
Pointing
Thing
5
4
3
2
1
0
Learning 2to learn
Learning 3to learn to learn
Learning 4to learn to learn to
learn
This step into non-Being is ultimately
unthinkable
Systems Meta-Levels
• Table from Palmer, Kent D., “Meta-systems Engineering,”• 10th Annual Symposium of INCOSE, 2000
Systems Meta-levels
Single Physical Instance
Conceptual System Schema
Architectural System Schema
ArchitecturalFrameworks
Rules For Developing Frameworks
Rules ForDeveloping Rules
© 2004 Joseph J Simpson
Meta-LevelsSystem Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 23
A formal systems engineering language will greatly reduce complexity in the practice of systems engineering, as well as facilitate the solution of even more complex problems. The initial basis for formal SE language development includes:
Robust set of system meta-levels
Clear set of conceptual transforms to reduce system complexity
Applicable combination of CCFRAT methods
Well-defined system meta-level heuristics
A formalized set of system meta-levels and meta-level transforms must be created in a structured fashion to support the development of a systems engineering language.
Basis for SE Language
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 24
Increasing system and environmental complexity can be measured and managed.
Systems engineering processes and principles provide a logical framework for evaluation of system complexity.
As product systems grow in size and complexity, system engineering must find and utilize the proper abstraction frame which reduces the system complexity and retains the proper level of system analysis.
The CCFRAT concepts and methods combined with well-defined meta-levels provide a foundation for a specialized systems engineering language.
Summary and Conclusions
System Integration Frameworks
Copyright 2005Joseph Simpson, Mary Simpson 25
Questions?
