IBM Research - Haifa
Pluggable Libraries
for System Analysis
and Optimization
Michael Masin
IBM Research - Haifa
Henry Broodney, Lev Greenberg, Nir Mashkif,
Lior Limonad, Aviad Sela, Evgeny Shindin
© 2012 IBM Corporation
Systems Engineering research in IBM
Virtual Verification of Systems
Complex System Optimization
Mass
«inventory,expand»
LeftGen:Generator
Sense_Out
«inventory,expand»
1
APU:Generator
On_Of f
Sense_Out
1
«expand»
1
T1
aRelay:Relay
«inventory,expand»
RightGen:Generator
Sense_Out
T2
AC_Out
AC_Out
AC_Out
Latency
Solution A
«block»
EPS_Technical
1
Energy
Consumption
Cost
Solution B
«expand»
1
aJunction:Junction
I3
I4
1
«inventory,expand»
RightACBus:AC_Bus
I1
output
output
PowerIn[1..*]
power:int
«block»
1
«inventory,expand»
Solution C
I2
LeftACBus:AC_Bus
power:int
«block,V aryingPart»
1
DMS_Expanded.DoorClosedSensor @ Door 2_147:DoorClosedSensor
DMS_Expanded.DoorLockedSensor @ Door 2_150:DoorLockedSensor
Link_72068
1
Link_72066
«block,V aryingPart»
1
DMS_Expanded.RDC @ Door 2_155:RDC
control
Link_72049
Link_72070
weight:float=0.138
analog:int
device
network
power:int
«block,V aryingPart»
1
DMS_Expanded.DoorLatchActuator @ Door 2_153:DoorLatchActuator
Oper a tio ns
PowerOut[1..*]
Link_72071
control
«block,V aryingPart»
1
power:int
DMS_Expanded.DoorLockActuator @ Door 2_154:DoorLockActuator
power:int
output
PowerIn[1..*]
power:int
«block»
1
DMS_Expanded.DoorLockedSensor @ Door 4_174:DoorLockedSensor
AC_Out
On_Of f
output
power:int
«block,V aryingPart»
1
Link_90086
DMS_Expanded.DoorClosedSensor @ Door 4_171:DoorClosedSensor
1
«inventory,expand»
itsInverter:Inverter
control
Link_90088
«block,V aryingPart»
1
OK
power:int
«block,V aryingPart»
1
DMS_Expanded.DoorLatchActuator @ Door 4_177:DoorLatchActuator
Link_90084
DMS_Expanded.RDC @ Door 4_179:RDC
Link_90049
device
power:int
latency:float=50.0
power:float=15.0
PowerOut[1..*]
Link_90089
O per a tio ns
network
control
power:int
«block,V aryingPart»
1
control
DMS_Expanded.DoorLockActuator @ Door 6_226:DoorLockActuator
output
power:int
«block»
1
Link_110104
power:int
«block,V aryingPart»
1
DMS_Expanded.DoorLockActuator @ Door 4_178:DoorLockActuator
Link_110107
DMS_Expanded.DoorLockedSensor @ Door 6_222:DoorLockedSensor
device
power:int
«block,V aryingPart»
1
DMS_Expanded.RDC @ Door 6_229:RDC
network
Link_110103
Link_110106
control
power:int
«block,V aryingPart»
1
DMS_Expanded.DoorLatchActuator @ Door 6_225:DoorLatchActuator
output
power:int
«block,V aryingPart»
1
DMS_Expanded.DoorClosedSensor @ Door 6_220:DoorClosedSensor
Link_41049
Link_110049
power:int
«block,V aryingPart»
1
Link_44049
DMS_Expanded.Switch @ Switch Bay 1_113:Switch
network[NumOfPorts]
control
1
«block,V aryingPart»
power:int
DMS_Expanded.DoorLatchActuator @ Door 1_141:DoorLatchActuator
network
1
power:int
«block,V aryingPart»
DMS_Expanded.Controller @ Avionics Bay_105:Controller
network
power:int
«block,V aryingPart»
1
Link_40044
control
power:int
«block»
1
Link_65062
«block,V aryingPart»
1
«block,V aryingPart»
1
power:int
device
DMS_Expanded.Switch @ Switch Bay 1_108:Switch
DMS_Expanded.DoorLockedSensor @ Door 5_210:DoorLockedSensor
Link_65061
power:int
DMS_Expanded.DoorLockActuator @ Door 1_142:DoorLockActuator
DMS_Expanded.Controller @ Avionics Bay_102:Controller
output
«block,V aryingPart»
1
power:int
DMS_Expanded.RDC @ Door 1_145:RDC
network[NumOfPorts]
network
Link_65044
output
Link_100044
power:int Link_100093
«block,V aryingPart»
1
Link_65059
device
«block,V aryingPart»
1
output
Link_65058
Link_100095
DMS_Expanded.DoorClosedSensor @ Door 5_207:DoorClosedSensor
control
power:int
Link_81044
DMS_Expanded.RDC @ Door 5_216:RDC
«block,V aryingPart»
1
output
power:int
DMS_Expanded.DoorLockActuator @ Door 3_166:DoorLockActuator
1
«block,V aryingPart»
1
«block»
power:int
DMS_Expanded.DoorLockedSensor @ Door 1_138:DoorLockedSensor
power:int
DMS_Expanded.DoorClosedSensor @ Door 1_136:DoorClosedSensor
Implementation
network
Link_100098
Link_100097
control
1
«block,V aryingPart»
DMS_Expanded.DoorLatchActuator @ Door 5_213:DoorLatchActuator
control
1
«block,V aryingPart»
power:int
Link_81080
DMS_Expanded.DoorLockActuator @ Door 5_214:DoorLockActuator
power:int
output
1
power:int
«block»
Link_81077
device
DMS_Expanded.DoorLockedSensor @ Door 3_162:DoorLockedSensor
«block,V aryingPart»
1
power:int
DMS_Expanded.RDC @ Door 3_167:RDC
network
Link_81075
Link_81079
control
1
«block,V aryingPart»
power:int
DMS_Expanded.DoorLatchActuator @ Door 3_165:DoorLatchActuator
output
1
«block,V aryingPart»
power:int
DMS_Expanded.DoorClosedSensor @ Door 3_159:DoorClosedSensor
Complex Hybrid System Simulations
Design Collaboration Frameworks
stm [block] TSM_Pattern04_Complex_SqSq [StatechartOfTSM_Pattern04_Complex_SqSq]
Idle
chC
WaitEe
E1[!Eb]
E1[Eb && Ee && (!chC)]
Check1
WaitEb
[else]
Failure
Eb[Ee]
[C]
E1[Eb && (!Ee)]
Monitor
Eb[!Ee]
[C]
AllRight
chC[C]
Ee[!C]
2
Do not distribute
© 2012 IBM Corporation
Agenda
 Approaches to Architectural Design
 Background: Architectural Optimization Workbench (AOW)
 Reusable system analysis: objective and use cases
 TotalCost journey
 Paradigm shift: Classification by Property
 Summary
3
Do not distribute
© 2012 IBM Corporation
Architectural Design
 Key concern:
– System Complexity is increasing – manual decisions no longer possible
4
Do not distribute
© 2012 IBM Corporation
Architectural Design
 Key concern:
– System Complexity is increasing – manual decisions no longer possible
 Solution approaches:
– Levels of Abstraction
Layer 1
Layer i
Layer i + 1
Implementation
5
Do not distribute
© 2012 IBM Corporation
Architectural Design
 Key concern:
– System Complexity is increasing – manual decisions no longer possible
 Solution approaches:
– Levels of Abstraction
• Mapping from Layer i (Requirements) to Layer i+1 (Architecture)
Layer 1
Layer i
Layer i + 1
Implementation
6
Do not distribute
© 2012 IBM Corporation
Architectural Design
 Key concern:
– System Complexity is increasing – manual decisions no longer possible
 Solution approaches:
– Levels of Abstraction
– Separation of concerns
7
Do not distribute
© 2012 IBM Corporation
Architectural Design
 Key concern:
– System Complexity is increasing – manual decisions no longer possible
 Solution approaches:
– Levels of Abstraction
– Separation of concerns
• Multiple viewpoints: functional, technical, geometrical, safety, timing, …
• Modeling Viewpoints vs. Analysis Viewpoints
• Independent asynchronous development
8
Do not distribute
© 2012 IBM Corporation
Architectural Design
 Key concern:
– System Complexity is increasing – manual decisions no longer possible
 Solution approaches:
– Levels of Abstraction
– Separation of concerns
– Tools
9
Do not distribute
© 2012 IBM Corporation
Architectural Design
 Key concern:
– System Complexity is increasing – manual decisions no longer possible
 Solution approaches:
– Levels of Abstraction
– Separation of concerns
– Tools
• Modeling
– Component Based Design
10
Do not distribute
© 2012 IBM Corporation
Architectural Design
 Key concern:
– System Complexity is increasing – manual decisions no longer possible
 Solution approaches:
– Levels of Abstraction
– Separation of concerns
– Tools
• Modeling
– Component Based Design
• Analysis
11
Do not distribute
© 2012 IBM Corporation
Architectural Design
 Key concern:
– System Complexity is increasing – manual decisions no longer possible
 Solution approaches:
– Levels of Abstraction
– Separation of concerns
– Tools
• Modeling
– Component Based Design
• Analysis
– Domain specific tools (e.g., SafetyHelper or OpenFTA for safety, SymTA/S for timing)
– Extension of modeling tools (e.g., PCE in Rhapsody, Simulink Design Optimization toolbox,
Optimica extension of Modelica, PaceLab optimization toolkit)
– Black box integration (e.g., ModelCenter, modeFrontier)
– Custom optimization modeling (in AMPL, OPL, GAMS, AIMMS)
12
Do not distribute
© 2012 IBM Corporation
Objective
1. Talking Systems Engineers language, applying the best optimization tools
13
Do not distribute
© 2012 IBM Corporation
Agenda
 Approaches to Architectural Design
 Background: Architectural Optimization Workbench (AOW)
 Reusable system analysis: objective and use cases
 TotalCost journey
 Paradigm shift: Classification by Property
 Summary
14
Do not distribute
© 2012 IBM Corporation
AOW Vision: Accelerate Smarter Architectural Decisions
NOW
Definition of design
alternatives
Analysis
 Manual process
–
–
–
–
Mostly based on individual undocumented experience
Lots of reuse of previous designs
No assurance for solution optimality
Each additional design – linear effort
Review
 No formal capture of designs
With AOW
– Modeling for specific analysis types
15
time
 Formal composition rules and
constraints
 Automatic generation of
optimization code
 Transparency, traceability,
visualization of results
 Knowledge capture and reuse
 Optimization Capabilities in the
hands of Architects
 Management of tools
orchestration and collaboration
Architectural template
definition
Review
Automated Design
Space Exploration
Do not distribute
© 2012 IBM Corporation
IBM’s Architecture Optimization Workbench Concept
16
Do not distribute
© 2012 IBM Corporation
AOW uses Concise Modeling
«block»
output
DMS_Technical
output
power:int
«block»
1
DMS_Expanded.DoorClosedSensor @ Door 2_147:DoorClosedSensor
Link_72068
Link_72066
«block,V aryingPart»
1
DMS_Expanded.RDC @ Door 2_155:RDC
doorClosedSensors
control
Link_72070
weight:float=0.138
analog:int
device
1..*
power:int
«block,V aryingPart»
1
DMS_Expanded.DoorLockedSensor @ Door 2_150:DoorLockedSensor
Link_72049
power
network
power:int
«block,V aryingPart»
1
DMS_Expanded.DoorLatchActuator @ Door 2_153:DoorLatchActuator
Oper a tio ns
output
Link_72071
control
«block,V aryingPart»
1
power:int
DMS_Expanded.DoorLockActuator @ Door 2_154:DoorLockActuator
power:int
output
power:int
«block»
1
DMS_Expanded.DoorLockedSensor @ Door 4_174:DoorLockedSensor
output
power 1..*
doorLockedSensors
output
power:int
«block,V aryingPart»
1
Link_90086
DMS_Expanded.DoorClosedSensor @ Door 4_171:DoorClosedSensor
control
power:int
«block,V aryingPart»
1
DMS_Expanded.DoorLatchActuator @ Door 4_177:DoorLatchActuator
Link_90084
Link_90088
«block,V aryingPart»
1
switchToSwitchConnector
DMS_Expanded.RDC @ Door 4_179:RDC
Link_90049
device
power:int
latency:float=50.0
power:float=15.0
Link_90089
O per a tio ns
network
1..*
doorLatchedSensors
control
output
power:int
«block,V aryingPart»
1
control
DMS_Expanded.DoorLockActuator @ Door 6_226:DoorLockActuator
power
output
1..*
RDCs
1..*
network
controllers
power:int
«block»
1
Link_110104
power:int
«block,V aryingPart»
1
DMS_Expanded.DoorLockActuator @ Door 4_178:DoorLockActuator
Link_110107
DMS_Expanded.DoorLockedSensor @ Door 6_222:DoorLockedSensor
network
device
power:int
«block,V aryingPart»
1
DMS_Expanded.RDC @ Door 6_229:RDC
network
power
1..*
switches
Link_110103
control
1
power:int
«block,V aryingPart»
DMS_Expanded.DoorLatchActuator @ Door 6_225:DoorLatchActuator
power
output
1..*
lockActuators
power
Link_110106
power:int
«block,V aryingPart»
1
DMS_Expanded.DoorClosedSensor @ Door 6_220:DoorClosedSensor
control
power
Link_41049
Link_110049
power:int
«block,V aryingPart»
1
Link_44049
DMS_Expanded.Switch @ Switch Bay 1_113:Switch
network[NumOfPorts]
power
1..*
latchActuators
control
control
1
«block,V aryingPart»
power:int
DMS_Expanded.DoorLatchActuator @ Door 1_141:DoorLatchActuator
network
1
power:int
«block,V aryingPart»
DMS_Expanded.Controller @ Avionics Bay_105:Controller
network
power:int
«block,V aryingPart»
1
Link_40044
control
power:int
«block»
1
Link_65062
«block,V aryingPart»
1
«block,V aryingPart»
1
power:int
device
DMS_Expanded.Switch @ Switch Bay 1_108:Switch
DMS_Expanded.DoorLockedSensor @ Door 5_210:DoorLockedSensor
Link_65061
power:int
DMS_Expanded.DoorLockActuator @ Door 1_142:DoorLockActuator
DMS_Expanded.Controller @ Avionics Bay_102:Controller
output
«block,V aryingPart»
1
power:int
DMS_Expanded.RDC @ Door 1_145:RDC
network[NumOfPorts]
network
Link_65044
output
Link_100044
power:int Link_100093
«block,V aryingPart»
1
Link_65059
device
powerBays
«block,V aryingPart»
1
output
Link_65058
Link_100095
DMS_Expanded.DoorClosedSensor @ Door 5_207:DoorClosedSensor
power
2
control
power:int
Link_81044
DMS_Expanded.RDC @ Door 5_216:RDC
«block,V aryingPart»
1
output
power:int
DMS_Expanded.DoorLockActuator @ Door 3_166:DoorLockActuator
1
«block,V aryingPart»
1
«block»
DMS_Expanded.DoorLockedSensor @ Door 1_138:DoorLockedSensor
power:int
DMS_Expanded.DoorClosedSensor @ Door 1_136:DoorClosedSensor
network
Link_100098
Link_100097
control
1
«block,V aryingPart»
DMS_Expanded.DoorLatchActuator @ Door 5_213:DoorLatchActuator
control
1
«block,V aryingPart»
power:int
Link_81080
DMS_Expanded.DoorLockActuator @ Door 5_214:DoorLockActuator
power:int
output
1
power:int
«block»
Link_81077
device
DMS_Expanded.DoorLockedSensor @ Door 3_162:DoorLockedSensor
«block,V aryingPart»
1
power:int
DMS_Expanded.RDC @ Door 3_167:RDC
network
Link_81075
Link_81079
control
1
«block,V aryingPart»
power:int
DMS_Expanded.DoorLatchActuator @ Door 3_165:DoorLatchActuator
output
1
«block,V aryingPart»
power:int
DMS_Expanded.DoorClosedSensor @ Door 3_159:DoorClosedSensor
 Large systems architectures are difficult to model
– Lots of elements and details
– Time consuming
– Error prone
 Concise Modeling – SysML models combined with tabular data
– SysML depicts the system composition rules
– Tables contain instantiations
 For an existing model the tabular data is taken from a component library
 In AOW some tables are filled by the optimization engine
17
Do not distribute
© 2012 IBM Corporation
power:int
Optimization Auto-Generation
Requirements & Constraints
Component library
Objectives
par [block] EPS_Technical [Cost_Algebra]
«block,catalog»
PDB
P1: whenever [E] occurs [SC] holds during following [I]
«catalog»
1
EPS_Technical.CF:CostFormulae
P2: whenever [E1] occurs [E2] implies [E3] during following [I]
TotalCost:RhpReal
«ConstraintProperty»
PDB_Costs[1..*]:RhpReal
Constraints
System_Cost:RhpReal
System_Cost = PDB_Costs->sum() + Cables_Costs->su...
Cables_Costs[1..*]:RhpReal
P3: whenever [E1] occurs [E2] does not occur during following [I]
«block,catalog»
PowerCable
«block»
DMS_Technical
P4: whenever [E] occurs [E/SC] occurs within [I]
power
1..*
P5: [SC] during [I] raises [E]
power 1..*
doorClosedSensors
doorLockedSensors
«Attribute»
«optimized»
SystemCost:RhpReal
TotalCost:RhpReal
output
output
«Function»
4
DMS_Functional.doors_R:DoorFunctionality
switchToSwitchConnector
P6: [E1] occurs [N] times during [I] raises [E2]
1..*
doorLatchedSensors
Latching
1
«Function»
1
P7: [E] occurs at most [N] times during [I]
RDCs
1
LockSensing
1..*
network
1..*
switches
power
«allocate»
«allocate»
«allocate»
«allocate»
«allocate»
power
«allocate»
lockActuators
«allocate»
«block»
1
latchActuators
«Function»
1
network
power
control
1..*
«Function»
Locking
«Function»
Functional::DMS_Functional.ctrl_R:Control
Functional::DMS_Functional.ctrl_L:Control
controllers
P8: [SC] during [I] implies [SC1] during [I1] then [SC2] during [I2]
power
«Function»
1
output
1..*
1..*
«Function»
CloseSensing
LatchSensing
power
power
1
«Function»
1
control
Technical::DMS_Technical
«expand,cat alog»
doorLockedSensors:DoorLockedSensor
1
«expand,cat alog»
controllers:Controller
«expand,cat alog»
1
latchActuators:DoorLatchActuator
1
«expand,cat alog»
lockActuators:DoorLockActuator
power
2
powerBays
1
«expand,cat alog»
1
«expand,cat alog»
doorClosedSensors:DoorClosedSensor
doorLatchedSensors:DoorLatchedSensor
Automatic
Generation
Optimization Problem
Formulation (CPLEX)
18
Do not distribute
© 2012 IBM Corporation
EADS, Doors Management System
Development and Analysis of a Simplified Doors Control System
• Monitor and Control Passenger Doors, Emergency Exits, and Cargo Doors
• Design a system out of existing components for best weight, cost, power etc.
20
Do not distribute
© 2012 IBM Corporation
DMS: From user story to model
Functional
Mapping
«Function»
4
DMS_Functional.doors_R:DoorFunctionality
1
«Function»
1
«Function»
CloseSensing
LatchSensing
«Function»
1
Latching
«Function»
1
«Function»
1
«Function»
«Function»
1
1
Functional::DMS_Functional.ctrl_R:Control
Functional::DMS_Functional.ctrl_L:Control
LockSensing
Locking
«allocate»
«allocate»
«allocate»
«allocate»
«allocate»
«allocate»
«allocate»
«block»
Technical::DMS_Technical
«expand,cat alog»
1
doorLockedSensors:DoorLockedSensor
1
Technical
«expand,cat alog»
«expand,cat alog»
1
latchActuators:DoorLatchActuator
controllers:Controller
«expand,cat alog»
1
lockActuators:DoorLockActuator
«expand,cat alog»
1
«expand,cat alog»
1
doorClosedSensors:DoorClosedSensor
doorLatchedSensors:DoorLatchedSensor
Allocation
DMS_Technical
1..*
1..*
doorClosedSensors
doorLatchedSensors
«allocate»
Attributes
1..*
doorLockedSensors
Attributes
1..*
lockActuators
Attributes
«allocate»
1..*
RDCs
«allocate»
1..*
1..*
controllers
latchActuators
«allocate»
«allocate»
1..*
sw itches
«allocate»
«allocate»
Geometrical
21
«allocate»
DMS_Physical
1
Do not distribute
ClosedSensorPlaceholders 1 LockActuatorPlaceholders
1 LatchActuactorPlaceholders1 Sw itchPlaceholders
1
CtlPlaceholders
1
RDCPlaceholders
1
1 LatchedSensorPlaceholders
LockedSensorPlaceholders
© 2012 IBM Corporation
DMS: Results [1/2]
3.Visualize the alternatives
1. SysML modeling
2. Run Optimization and show alternatives
22
Do not distribute
© 2012 IBM Corporation
DMS: Results [2/2]
3.Visualize the alternatives
1. SysML modeling
2. Run Optimization and show alternatives
23
Do not distribute
© 2012 IBM Corporation
Agenda
 Approaches to Architectural Design
 Background: Architectural Optimization Workbench (AOW)
 Reusable system analysis: objective and use cases
 TotalCost journey
 Paradigm shift: Classification by Property
 Summary
24
Do not distribute
© 2012 IBM Corporation
Objective
1. Talking Systems Engineers language, applying the best optimization tools
2. Library of reusable pluggable Analysis Viewpoints
25
Do not distribute
© 2012 IBM Corporation
Objective
1. Talking Systems Engineers language, applying the best optimization tools
2. Library of reusable pluggable Analysis Viewpoints
Questions
 Do we really have repeating types of analysis?
 Does current optimization modeling support building the libraries?
 What should be the methodology and supportive framework?
26
Do not distribute
© 2012 IBM Corporation
Use Case 1 – EADS
Development and Analysis of a Doors and Slides Control System
DC 1 BusBar
Sensor
Data
Concentrator
Ethernet
Cable
Switch
Controller
Et
h
Ca ern
ble et
Switch
•Passenger Doors, Emergency Exits,
and Cargo Doors
Structure
Virtual Link
Cable (Data and Power)
Actuator
Data
Concentrator
Switch
Ethernet
Cable
Cable (Data)
Power Cable
DC 2 BusBar
Functional
Geometrical
Door
Emergenc
y
Door
Sense
Power Cables
Landing Gear Bay
Avionics Bay
Controllers
RDC
Control
Sensors
Door
Door
Actuators
Emergenc
y
Switches
Actuate
Design metrics
Weight, Cable length, Power distribution, Mapping, Allocation, Reliability …
27
Do not distribute
27
© 2012 IBM Corporation
Use Case 2 – UTC
Power Distribution System
 Typical Power Distribution System
– Draw power from sources and distribute to
the loads
– The core is a collection of Power Distribution
Boxes (PDB) housing electric protection and
power management circuitry
– Several loads per PDB
 Task - optimal selection, allocation,
connections, and placement of PDBs
 Inputs:
– Loads’ power requirements
– Available components properties
– Geometry of the platform
«block»
EP S_Technical
1
PowerOut[1..*]
28
Mapping
Weight
Cost
Cable length
Reliability requirements
Power efficiency
«TypedConnector,optimized»
«TypedConnector,optimized»
«inventory»
Loads:Load
1
DCIn
DCOut[*]
1
«optimized»
ModeIn
ACOut[*]
«inventory»
itsController:Controller
PDBs:PDB
«T ypedConnec tor,optimized»
ACIn
PowerIn[1..*]
SensorsIn[1..*]
ACIn
1
RightAC_Bus:AC_Bus
PowerOut[1..*]
PowerIn[1..*]
 Design metrics:
–
–
–
–
–
–
1
LeftAC_Bus:AC_Bus
Outputs[1..*]
«T ypedConnec tor,optimized»
Network
«T ypedConnec tor,optimized»
DCIn
PowerIn
1
1
LeftDC_Bus:DC_Bus
PowerIn[1..*]
Do not distribute
RightDC_Bus:DC_Bus
PowerOut[1..*]
PowerOut[1..*]
«TypedConnector,optimized»
«TypedConnector,optimized»
PowerIn[1..*]
© 2012 IBM Corporation
Use Case 3 – Automotive
Design metrics:
• Mapping
 Optimal mapping of SW components to ECUs
• Reliability
• Cost
• Power
SwC1
SwC2
• Timing/schedulability
• Data communication
SwC3
• Operational
scenarios
 Complex system topology
mapping
ECU1
29
ECU2
Do not distribute
© 2012 IBM Corporation
Use Case 4 - INCOSE 2012 Tool Vendor Challenge
Forest Fire Fighting
 A country with several districts has a history of forest fires. Each district
has a fire detection and fire fighting forces and there is no cooperation
between them. The government wants to build a Command and Control
center that will coordinate between the forces. The government wants to
know how much savings this can bring, to justify the cost of the C&C.
 Task - optimal placement
of detection and firefighting
assets in the districts so that
all the required scenarios
are successfully dealt with.
Design metrics:
• Resource allocation
• Cost
• Timing
• Data communication
• Scenarios
30
Do not distribute
© 2012 IBM Corporation
INCOSE 2012 Tool Vendor Challenge - Forest Fire
Fighting, Results
3.Visualize the alternatives
1. SysML modeling
2. Run Optimization and show alternatives
31
Do not distribute
© 2012 IBM Corporation
Use cases
we have explored so far
UTC, Power Distribution System
Draw power from sources and distribute
to the loads and PBC, optimal selection,
allocation, connections, and placement
Airbus, Cabin Configuration
Find Optimal Cabin Architecture
fulfilling different airlines requirements
by Minimize cost, weight, power and
voltage drop, and redundancy
INCOSE 2012, Forest Fire Fighting
Optimal placement of detection and
firefighting assets in the districts so that
all the required scenarios are successfully
dealt with
EADS, Doors Management System
Cables
Controller
Remote Data
Concentrators (RDC)
Bus (e.g.
ARINC/AFDX)
Find Optimal architecture, and geo
allocation considering cost, cable length,
weight and reliability aspects.
Controller
DANSE, Sensor positioning in
System of Systems context
Assign the possible antenna bridge
positions , Estimate the coverage
area for each antenna
32
Do not distribute
Automotive, E/E usecase
T1/T2 suppliers provide software modules
with their hardware, OEMs are required to
allocate each module to an ECU
IT Architecture design
Build IT architecture based on
applications requirements,
interconnection, application, software and
hardware catalogues
© 2012 IBM Corporation
Objective
1. Talking Systems Engineers language, applying the best optimization tools
2. Library of reusable pluggable Analysis Viewpoints
Questions
 Do we really have repeating types of analysis?
 Does current optimization modeling support building the libraries?
 What should be the methodology and supportive framework?
33
Do not distribute
© 2012 IBM Corporation
Agenda
 Approaches to Architectural Design
 Background: Architectural Optimization Workbench (AOW)
 Reusable system analysis: objective and use cases
 TotalCost journey
 Paradigm shift: Classification by Property
 Summary
34
Do not distribute
© 2012 IBM Corporation
Example
Requirement Layer Layer
1
Sensing
1
Controlling
1
Actuating
Architecture Layer
Layer
35
Do not distribute
© 2012 IBM Corporation
totalCost Journey
Minimize totalCost
Subject to
𝑡𝑜𝑡𝑎𝑙𝐶𝑜𝑠𝑡 =
𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒 𝑗 . 𝐶𝑜𝑠𝑡 ∙ 𝑠𝑒𝑛𝑠𝑜𝑟 𝑖 𝑗 + ⋯
𝑗∈𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒𝑠 𝑖∈𝑆𝑒𝑛𝑠𝑜𝑟𝑠
+
𝑆𝑤𝑖𝑡𝑐ℎ𝑇𝑦𝑝𝑒 𝑗 . 𝐶𝑜𝑠𝑡 ∙ 𝑠𝑤𝑖𝑡𝑐ℎ 𝑖 𝑗
𝑗∈𝑆𝑤𝑖𝑡𝑐ℎ𝑇𝑦𝑝𝑒𝑠 𝑖∈𝑆𝑤𝑖𝑡𝑐ℎ𝑒𝑠
…
// Mapping
𝑠𝑒𝑛𝑠𝑖𝑛𝑔2𝑠𝑒𝑛𝑠𝑜𝑟[𝑙] 𝑖 𝑗 = 1 ∀ 𝑙 ∈ 𝑆𝑒𝑛𝑠𝑖𝑛𝑔𝐹𝑢𝑛𝑐𝑡𝑖𝑜𝑛𝑠
𝑗∈𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒𝑠 𝑖∈𝑆𝑒𝑛𝑠𝑜𝑟𝑠
36
Do not distribute
© 2012 IBM Corporation
totalCost Journey
 Requirement for using several types of sensors
– thermal and volume sensors
– each having its own attributes and a catalog of available types
𝑡𝑜𝑡𝑎𝑙𝐶𝑜𝑠𝑡 =
𝑇ℎ𝑒𝑟𝑚𝑎𝑙𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒 𝑗 . 𝐶𝑜𝑠𝑡 ∙ 𝑡ℎ𝑒𝑟𝑚𝑎𝑙𝑆𝑒𝑛𝑠𝑜𝑟 𝑖 𝑗
𝑗∈𝑇𝑒𝑟𝑚𝑎𝑙𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒𝑠 𝑖∈𝑇𝑒𝑟𝑚𝑎𝑙𝑆𝑒𝑛𝑠𝑜𝑟𝑠
+
𝑉𝑜𝑙𝑢𝑚𝑒𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒 𝑗 . 𝐶𝑜𝑠𝑡 ∙ 𝑣𝑜𝑙𝑢𝑚𝑒𝑆𝑒𝑛𝑠𝑜𝑟 𝑖 𝑗 + ⋯
𝑗∈𝑉𝑜𝑙𝑢𝑚𝑒𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒𝑠 𝑖∈𝑇𝑒𝑟𝑚𝑎𝑙𝑆𝑒𝑛𝑠𝑜𝑟𝑠
+
𝑆𝑤𝑖𝑡𝑐ℎ𝑇𝑦𝑝𝑒 𝑗 . 𝐶𝑜𝑠𝑡 ∙ 𝑠𝑤𝑖𝑡𝑐ℎ 𝑖 𝑗 .
𝑗∈𝑆𝑤𝑖𝑡𝑐ℎ𝑇𝑦𝑝𝑒𝑠 𝑖∈𝑆𝑤𝑖𝑡𝑐ℎ𝑒𝑠
37
Do not distribute
© 2012 IBM Corporation
totalCost Journey
 Cable component connects other architectural components
– new type – Cable
– cables’ costs are also dependent on the geometrical layout
𝑡𝑜𝑡𝑎𝑙𝐶𝑜𝑠𝑡 =
𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒 𝑗 . 𝐶𝑜𝑠𝑡 ∙ 𝑠𝑒𝑛𝑠𝑜𝑟 𝑖 𝑗 [𝒌] + ⋯
𝑗∈𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒𝑠 𝑖∈𝑆𝑒𝑛𝑠𝑜𝑟𝑠 𝒌∈𝑪𝒐𝒎𝒑𝒂𝒓𝒕𝒎𝒆𝒏𝒕𝒔
+
𝐶𝑎𝑏𝑙𝑒𝑇𝑦𝑝𝑒 𝑗 . 𝐶𝑜𝑠𝑡 ∙ 𝑐𝑎𝑏𝑙𝑒 𝑖 𝑗 𝒌 .
𝑗∈𝐶𝑎𝑏𝑙𝑒𝑇𝑦𝑝𝑒𝑠 𝑖∈𝐶𝑎𝑏𝑙𝑒𝑠 𝒌∈𝑺𝑷𝒂𝒕𝒉𝒔
38
Do not distribute
© 2012 IBM Corporation
totalCost Journey
 Safety requirements
– functions and functional links could be implemented by several redundant
channels
𝑠𝑒𝑛𝑠𝑖𝑛𝑔2𝑠𝑒𝑛𝑠𝑜𝑟 𝑙 [𝒓] 𝑖 𝑗 = 𝑟𝑒𝑑𝑢𝑛𝑑𝑎𝑛𝑐𝑦𝐶ℎ𝑎𝑛𝑛𝑒𝑙 𝑙 [𝑟]
𝑗∈𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒𝑠 𝑖∈𝑆𝑒𝑛𝑠𝑜𝑟𝑠
∀ 𝑙 ∈ 𝑆𝑒𝑛𝑠𝑖𝑛𝑔𝐹𝑢𝑛𝑐𝑡𝑖𝑜𝑛𝑠, 𝒓 ∈ 𝑹𝒆𝒅𝒖𝒏𝒅𝒂𝒏𝒄𝒚𝑪𝒉𝒂𝒏𝒏𝒆𝒍𝒔
39
Do not distribute
© 2012 IBM Corporation
Objective
1. Talking Systems Engineers language, applying the best optimization tools
2. Library of reusable pluggable Analysis Viewpoints
Questions
 Do we really have repeating types of analysis?
 Does current optimization modeling support building the libraries?
 What should be the methodology and supportive framework?
40
Do not distribute
© 2012 IBM Corporation
Agenda
 Approaches to Architectural Design
 Background: Architectural Optimization Workbench (AOW)
 Reusable system analysis: objective and use cases
 TotalCost journey
 Paradigm shift: Classification-by-Property
 Summary
41
Do not distribute
© 2012 IBM Corporation
Problem Analysis
 Algebraic style depends on element sets from system’s viewpoints
– designers constantly revise the optimization model ensuring its consistency
with system’s engineering model
42
Do not distribute
© 2012 IBM Corporation
Problem Analysis
 Algebraic style depends on element sets from system’s viewpoints
– designers constantly revise the optimization model ensuring its consistency
with system’s engineering model
 Classification-by-Containment
– engineers first identify sets of classifications
– associate each class with a collection of properties, some being inherent and
some reflecting interactions with other classes
– each class is a containment of individuals having the same characteristics in
common
– each class may then be further specialized into a hierarchy of containments
– analysis tools use these classifications as first class citizens in any algebraic
or analysis model.
43
Do not distribute
© 2012 IBM Corporation
New Approach
 Why do we need classes?
– technical purpose: to help in defining or initializing instances
• Classification by Containment does the job
– conceptual purpose: to be used for defining effectively common rules or
constraints on collection of similar instances
• Classification by Containment fails
44
Do not distribute
© 2012 IBM Corporation
New Approach
 Why do we need classes?
– technical purpose: to help in defining or initializing instances
• Classification by Containment does the job
– conceptual purpose: to be used for defining effectively common rules or
constraints on collection of similar instances
• Classification by Containment fails
 Paradigm shift – Classification-by-Property
– suggested by Parsons and Wand (2000) for information management
– define things that possess properties
• intrinsic properties and mutual properties
– no a-priory classification
– classes are defined by set of properties
• things could belong to many classes
– instance, class and property bases
45
Do not distribute
© 2012 IBM Corporation
Classification-by-Property API
 Scope(A), where A is a set of attributes
– returns instances that have all attributes in set A
– e.g., Scope {Cost} returns all instances that have attribute “Cost”
DSE Ontology
– Attributes
o variables
o parameters
– isSelected
– isContainedIn(instance)
– isMapped
– couldBeMapped(instance)
46
Do not distribute
© 2012 IBM Corporation
totalCost journey – Magic of the New Approach
totalCost 𝑖
=
isSelected 𝑗 ∙ Cost 𝑗
𝑗∈Scope({Cost,
isContainedIn
∀ 𝑖 ∈ Scope totalCost
𝑖 })
// Mapping
isMapped(𝑖)(𝑗) = 𝑖𝑠𝑆𝑒𝑙𝑒𝑐𝑡𝑒𝑑(𝑖)
𝑗∈Scope
couldBeMapped 𝑖
∀ 𝑖 ∈ Scope(isRequirementsElement)
47
Do not distribute
© 2012 IBM Corporation
totalCost journey – Magic of the New Approach
 Resource viewpoint
– capacity of architectural component j for resource i, dseCapacity(i)(j), is not
exceeded by granting all the requests, dseRequest 𝑖 𝑘 , from requirements
mapped to it
dseCapacity 𝑖 𝑗 ≥
isMapped 𝑘 𝑗 ∙ dseRequest 𝑖 𝑘
𝑘∈Scope
dseRequest
𝑖
∀ 𝑖 ∈ dseResources, 𝑗 ∈ Scope dseCapacity 𝑖
48
Do not distribute
© 2012 IBM Corporation
Current Metrics / Analysis Patterns
 Minimizing overall Architecture Cost
 Minimizing overall weight, and wiring length and weight
 Mapping functional requirements to physical architecture
 Optimize Power distribution, Minimize voltage drop
 Data flow
 Optimize geographical coverage and positioning
 Optimal placement of assets, sensors and ground fields
 Scenarios fulfillment
 Reliability: Approximate algebra to take Reliability into account for optimization
 Timing: Approximate algebra to take Timing into account for optimization
 Interface compatibility
 Resource allocation
49
Do not distribute
© 2012 IBM Corporation
Agenda
 Approaches to Architectural Design
 Background: Architectural Optimization Workbench (AOW)
 Reusable system analysis: objective and use cases
 TotalCost journey
 Paradigm shift: Classification-by-Property
 Summary
50
Do not distribute
© 2012 IBM Corporation
Main Findings
 Using tools for DSE and analysis requires reusable analysis libraries
– similar to component libraries in modeling tools
 In system design, several analysis metrics/patterns are repeatedly used
– mapping functionality to architecture, reliability, resource allocation, energy and data flow
 Current analysis modeling does not support building reusable analysis libraries)
51
Do not distribute
© 2012 IBM Corporation
Main Recommendations
 The main problem with the existing methodology is the definition of sets –
Classification- by-Containment
– good to define concepts and initialize values
– fails to define sets needed for analysis
 New paradigm of Classification-by-Properties defines robust sets for analysis
 Ontology based concepts and property-defined sets enable building reusable
libraries for system optimization and analysis
 Current reusable libraries
– mapping, reliability, resource allocation, interface compatibility, power distribution, voltage
drop, data flow, … ongoing extension
52
Do not distribute
© 2012 IBM Corporation
Future directions
 Extending the proposed approach to dynamic systems
– reusable state charts / activity diagrams
 Optimization patterns in building Analysis Viewpoints constraints
– symmetry breaking
53
Do not distribute
© 2012 IBM Corporation
IBM Research - Haifa
© 2012 IBM Corporation
Where can we use this approach?
 Safety Critical Systems
– Systems with redundant functions (flight control, hydraulic systems, Automotive safety
systems etc.)
 Network systems (data, power, energy, fluid)
– Integrated Modular Avionics, AutoSAR
– Electrical Architecture (e.g. GM global-B )
– Cabin Intercommunication system
– Entertainment systems
– Fuel and cooling systems
– Electric power systems
 Complex multi-physics systems
– For example any mix of the above with an electronic/software control
 Cabin Architecture
 System of Systems
– Scenarios handling
55
Do not distribute
© 2012 IBM Corporation