IBM Research - Haifa Pluggable Libraries for System ... · DMS_Expanded.Controller @ Avionics...
Transcript of IBM Research - Haifa Pluggable Libraries for System ... · DMS_Expanded.Controller @ Avionics...
IBM Research - Haifa
© 2012 IBM Corporation
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 2 Do not distribute
Implementation
Complex Hybrid System Simulations
Virtual Verification of Systems
Complex System Optimization
EPS_Technical
«block»
LeftGen:Generator
1 «inventory,expand»Sense_Out
AC_Out
RightGen:Generator
1 «inventory,expand»Sense_Out
AC_Out
APU:Generator
1 «inventory,expand»Sense_Out
AC_Out
aRelay:Relay
1 «expand»
On_Of f
T2T1
aJunction:Junction
1 «expand» I4
I3
I2
I1
LeftACBus:AC_Bus
1 «inventory,expand»
PowerOut[1..*]
PowerIn[1..*]
RightACBus:AC_Bus
1 «inventory,expand»
PowerOut[1..*]
PowerIn[1..*]
itsInverter:Inverter
1 «inventory,expand»
OK
On_Of fAC_Out
Design Collaboration Frameworks stm [block] TSM_Pattern04_Complex_SqSq [StatechartOfTSM_Pattern04_Complex_SqSq]
Idle
E1[Eb && Ee && (!chC)]
Check1
E1[Eb && Ee && (!chC)]
Monitor
E1[Eb && (!Ee)]E1[Eb && (!Ee)]
WaitEb
E1[!Eb]
Eb[!Ee]
Eb[Ee]
E1[!Eb]
Eb[!Ee]
Eb[Ee]
Ee[!C]
Failure
Ee[!C]
[else][else]
AllRight[C]
chC[C]
[C]
chC
[C]
chC[C]
[C]
chC
WaitEe
Systems Engineering research in IBM
Mass CostEnergy
ConsumptionLatency
Solution A
Solution B
Solution C
DMS_Expanded.DoorLatchActuator @ Door 6_225:DoorLatchActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.RDC @ Door 6_229:RDC
1 «block,VaryingPart» power:intdevice
network
Link_110106Link_110106
DMS_Expanded.DoorLockActuator @ Door 3_166:DoorLockActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.Controller @ Avionics Bay_105:Controller
1 «block,VaryingPart» power:intnetwork
Link_81080
DMS_Expanded.RDC @ Door 3_167:RDC
1 «block,VaryingPart» power:intdevice
network
Link_81080
DMS_Expanded.Switch @ Switch Bay 1_113:Switch
1 «block,VaryingPart» power:int
network[NumOfPorts]
Link_41049
Link_110049
Link_41049
Link_110049
DMS_Expanded.DoorClosedSensor @ Door 4_171:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
DMS_Expanded.DoorLockedSensor @ Door 1_138:DoorLockedSensor
1 «block» power:intoutput
DMS_Expanded.DoorLockedSensor @ Door 4_174:DoorLockedSensor
1 «block» power:intoutput
DMS_Expanded.DoorLockActuator @ Door 1_142:DoorLockActuator
1 «block,VaryingPart»
power:int
control
DMS_Expanded.DoorLatchActuator @ Door 4_177:DoorLatchActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorClosedSensor @ Door 2_147:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
DMS_Expanded.DoorLockActuator @ Door 4_178:DoorLockActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorLatchActuator @ Door 2_153:DoorLatchActuator
1 «block,VaryingPart» power:int
control
Link_90084
DMS_Expanded.RDC @ Door 4_179:RDC
1 «block,VaryingPart»
latency:float=50.0
power:float=15.0 Opera tio ns
power:intdevice
network
Link_90086
Link_90088
Link_90049
Link_90089
Link_90084
Link_90086
Link_90088
Link_90049
Link_90089
DMS_Expanded.RDC @ Door 2_155:RDC
1 «block,VaryingPart»
weight:float=0.138
analog:int
Opera tio ns
power:int
device
network
Link_72070Link_72049
Link_72066
Link_72070Link_72049
Link_72066
DMS_Expanded.DoorClosedSensor @ Door 5_207:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
Link_81077
DMS_Expanded.DoorLockedSensor @ Door 3_162:DoorLockedSensor
1 «block» power:intoutput Link_81077
DMS_Expanded.DoorLockedSensor @ Door 5_210:DoorLockedSensor
1 «block» power:intoutput
DMS_Expanded.Switch @ Switch Bay 1_108:Switch
1 «block,VaryingPart» power:int
network[NumOfPorts]
Link_44049
Link_81044
Link_44049
Link_81044
DMS_Expanded.DoorLatchActuator @ Door 5_213:DoorLatchActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorLatchActuator @ Door 1_141:DoorLatchActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorLockActuator @ Door 5_214:DoorLockActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorLockedSensor @ Door 2_150:DoorLockedSensor
1 «block» power:intoutput
Link_72068Link_72068
Link_100097
DMS_Expanded.RDC @ Door 5_216:RDC
1 «block,VaryingPart» power:intdevice
network
Link_100098
Link_100095Link_100093 Link_100044
Link_100097Link_100098
Link_100095Link_100093 Link_100044
Link_81075
DMS_Expanded.DoorClosedSensor @ Door 3_159:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
Link_81075
Link_110103
DMS_Expanded.DoorClosedSensor @ Door 6_220:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
Link_110103
DMS_Expanded.DoorLockActuator @ Door 2_154:DoorLockActuator
1 «block,VaryingPart» power:intcontrolLink_72071Link_72071
DMS_Expanded.DoorLatchActuator @ Door 3_165:DoorLatchActuator
1 «block,VaryingPart» power:intcontrolLink_81079Link_81079
DMS_Expanded.RDC @ Door 1_145:RDC
1 «block,VaryingPart» power:intdevice
network
Link_65062
Link_65059
Link_65061
Link_65044
Link_65062
Link_65059
Link_65061
Link_65044
Link_110104
DMS_Expanded.DoorLockedSensor @ Door 6_222:DoorLockedSensor
1 «block» power:intoutput Link_110104
Link_40044
DMS_Expanded.Controller @ Avionics Bay_102:Controller
1 «block,VaryingPart» power:intnetwork Link_40044
DMS_Expanded.DoorLockActuator @ Door 6_226:DoorLockActuator
1 «block,VaryingPart» power:intcontrol
Link_110107Link_110107
DMS_Expanded.DoorClosedSensor @ Door 1_136:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
Link_65058Link_65058
© 2012 IBM Corporation 3 Do not distribute
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
© 2012 IBM Corporation 4 Do not distribute
Key concern:
– System Complexity is increasing – manual decisions no longer possible
Architectural Design
© 2012 IBM Corporation 5 Do not distribute
Key concern:
– System Complexity is increasing – manual decisions no longer possible
Solution approaches:
– Levels of Abstraction
Architectural Design
Implementation
Layer 1
Layer i
Layer i + 1
© 2012 IBM Corporation 6 Do not distribute
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)
Architectural Design
Implementation
Layer 1
Layer i
Layer i + 1
© 2012 IBM Corporation 7 Do not distribute
Key concern:
– System Complexity is increasing – manual decisions no longer possible
Solution approaches:
– Levels of Abstraction
– Separation of concerns
Architectural Design
© 2012 IBM Corporation 8 Do not distribute
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
Architectural Design
© 2012 IBM Corporation 9 Do not distribute
Key concern:
– System Complexity is increasing – manual decisions no longer possible
Solution approaches:
– Levels of Abstraction
– Separation of concerns
– Tools
Architectural Design
© 2012 IBM Corporation 10 Do not distribute
Key concern:
– System Complexity is increasing – manual decisions no longer possible
Solution approaches:
– Levels of Abstraction
– Separation of concerns
– Tools
• Modeling
– Component Based Design
Architectural Design
© 2012 IBM Corporation 11 Do not distribute
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
Architectural Design
© 2012 IBM Corporation 12 Do not distribute
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)
Architectural Design
© 2012 IBM Corporation 13 Do not distribute
1. Talking Systems Engineers language, applying the best optimization tools
Objective
© 2012 IBM Corporation 14 Do not distribute
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
© 2012 IBM Corporation 15 Do not distribute
AOW Vision: Accelerate Smarter Architectural Decisions
time
Definition of design
alternatives
Analysis
Review
Architectural template
definition
Automated Design
Space Exploration
Review Manual process
– Mostly based on individual undocumented experience
– Lots of reuse of previous designs
– No assurance for solution optimality
– Each additional design – linear effort
No formal capture of designs
– Modeling for specific analysis types
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
NO
W
Wit
h A
OW
© 2012 IBM Corporation 16 Do not distribute
IBM’s Architecture Optimization Workbench Concept
© 2012 IBM Corporation 17 Do not distribute
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
AOW uses Concise Modeling
DMS_Technical
«block»
switches1..*
power
switchToSwitchConnector
RDCs1..*
power
network
doorClosedSensors1..*power
output
latchActuators1..*power
control
controllers1..*
power
network
powerBays2
power
doorLockedSensors1..*poweroutput
doorLatchedSensors1..*
power
output
lockActuators1..*
power control
switchToSwitchConnector
DMS_Expanded.DoorLatchActuator @ Door 6_225:DoorLatchActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.RDC @ Door 6_229:RDC
1 «block,VaryingPart» power:intdevice
network
Link_110106Link_110106
DMS_Expanded.DoorLockActuator @ Door 3_166:DoorLockActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.Controller @ Avionics Bay_105:Controller
1 «block,VaryingPart» power:intnetwork
Link_81080
DMS_Expanded.RDC @ Door 3_167:RDC
1 «block,VaryingPart» power:intdevice
network
Link_81080
DMS_Expanded.Switch @ Switch Bay 1_113:Switch
1 «block,VaryingPart» power:int
network[NumOfPorts]
Link_41049
Link_110049
Link_41049
Link_110049
DMS_Expanded.DoorClosedSensor @ Door 4_171:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
DMS_Expanded.DoorLockedSensor @ Door 1_138:DoorLockedSensor
1 «block» power:intoutput
DMS_Expanded.DoorLockedSensor @ Door 4_174:DoorLockedSensor
1 «block» power:intoutput
DMS_Expanded.DoorLockActuator @ Door 1_142:DoorLockActuator
1 «block,VaryingPart»
power:int
control
DMS_Expanded.DoorLatchActuator @ Door 4_177:DoorLatchActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorClosedSensor @ Door 2_147:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
DMS_Expanded.DoorLockActuator @ Door 4_178:DoorLockActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorLatchActuator @ Door 2_153:DoorLatchActuator
1 «block,VaryingPart» power:int
control
Link_90084
DMS_Expanded.RDC @ Door 4_179:RDC
1 «block,VaryingPart»
latency:float=50.0
power:float=15.0 Opera tio ns
power:intdevice
network
Link_90086
Link_90088
Link_90049
Link_90089
Link_90084
Link_90086
Link_90088
Link_90049
Link_90089
DMS_Expanded.RDC @ Door 2_155:RDC
1 «block,VaryingPart»
weight:float=0.138
analog:int
Opera tio ns
power:int
device
network
Link_72070Link_72049
Link_72066
Link_72070Link_72049
Link_72066
DMS_Expanded.DoorClosedSensor @ Door 5_207:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
Link_81077
DMS_Expanded.DoorLockedSensor @ Door 3_162:DoorLockedSensor
1 «block» power:intoutput Link_81077
DMS_Expanded.DoorLockedSensor @ Door 5_210:DoorLockedSensor
1 «block» power:intoutput
DMS_Expanded.Switch @ Switch Bay 1_108:Switch
1 «block,VaryingPart» power:int
network[NumOfPorts]
Link_44049
Link_81044
Link_44049
Link_81044
DMS_Expanded.DoorLatchActuator @ Door 5_213:DoorLatchActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorLatchActuator @ Door 1_141:DoorLatchActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorLockActuator @ Door 5_214:DoorLockActuator
1 «block,VaryingPart» power:intcontrol
DMS_Expanded.DoorLockedSensor @ Door 2_150:DoorLockedSensor
1 «block» power:intoutput
Link_72068Link_72068
Link_100097
DMS_Expanded.RDC @ Door 5_216:RDC
1 «block,VaryingPart» power:intdevice
network
Link_100098
Link_100095Link_100093 Link_100044
Link_100097Link_100098
Link_100095Link_100093 Link_100044
Link_81075
DMS_Expanded.DoorClosedSensor @ Door 3_159:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
Link_81075
Link_110103
DMS_Expanded.DoorClosedSensor @ Door 6_220:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
Link_110103
DMS_Expanded.DoorLockActuator @ Door 2_154:DoorLockActuator
1 «block,VaryingPart» power:intcontrolLink_72071Link_72071
DMS_Expanded.DoorLatchActuator @ Door 3_165:DoorLatchActuator
1 «block,VaryingPart» power:intcontrolLink_81079Link_81079
DMS_Expanded.RDC @ Door 1_145:RDC
1 «block,VaryingPart» power:intdevice
network
Link_65062
Link_65059
Link_65061
Link_65044
Link_65062
Link_65059
Link_65061
Link_65044
Link_110104
DMS_Expanded.DoorLockedSensor @ Door 6_222:DoorLockedSensor
1 «block» power:intoutput Link_110104
Link_40044
DMS_Expanded.Controller @ Avionics Bay_102:Controller
1 «block,VaryingPart» power:intnetwork Link_40044
DMS_Expanded.DoorLockActuator @ Door 6_226:DoorLockActuator
1 «block,VaryingPart» power:intcontrol
Link_110107Link_110107
DMS_Expanded.DoorClosedSensor @ Door 1_136:DoorClosedSensor
1 «block,VaryingPart» power:intoutput
Link_65058Link_65058
© 2012 IBM Corporation 18 Do not distribute
Component library Requirements & Constraints
Optimization Auto-Generation
P1: whenever [E] occurs [SC] holds during following [I]
P2: whenever [E1] occurs [E2] implies [E3] during following [I]
P3: whenever [E1] occurs [E2] does not occur during following [I]
P4: whenever [E] occurs [E/SC] occurs within [I]
P5: [SC] during [I] raises [E]
P6: [E1] occurs [N] times during [I] raises [E2]
P7: [E] occurs at most [N] times during [I]
P8: [SC] during [I] implies [SC1] during [I1] then [SC2] during [I2]
Automatic
Generation
Optimization Problem
Formulation (CPLEX)
par [block] EPS_Technical [Cost_Algebra]
PDB
«block,catalog»
TotalCost:RhpReal
«catalog»
SystemCost:RhpReal
«Attribute»
PowerCable
«block,catalog»
TotalCost:RhpReal
«optimized»
EPS_Technical.CF:CostFormulae
1 «ConstraintProperty»
Constraints
System_Cost = PDB_Costs->sum() + Cables_Costs->su...System_Cost:RhpReal
Cables_Costs[1..*]:RhpReal
PDB_Costs[1..*]:RhpReal
Objectives
DMS_Technical
«block»
switches1..*
power
switchToSwitchConnector
RDCs1..*
power
network
doorClosedSensors1..*power
output
latchActuators1..*power
control
controllers1..*
power
network
powerBays2
power
doorLockedSensors1..*poweroutput
doorLatchedSensors1..*
power
output
lockActuators1..*
power control
switchToSwitchConnector
DMS_Functional.doors_R:DoorFunctionality4 «Function»
Locking1 «Function»
LatchSensing1 «Function»
Latching1 «Function»
LockSensing1 «Function»
CloseSensing
1 «Function»
Functional::DMS_Functional.ctrl_R:Control1 «Function»
Functional::DMS_Functional.ctrl_L:Control1 «Function»
Technical::DMS_Technical
«block»
latchActuators:DoorLatchActuator1 «expand,catalog»
«allocate»
controllers:Controller1 «expand,catalog»
«allocate»
«allocate»
doorLockedSensors:DoorLockedSensor
1 «expand,catalog»
«allocate»
lockActuators:DoorLockActuator
1 «expand,catalog»
«allocate»
doorLatchedSensors:DoorLatchedSensor
1 «expand,catalog»
«allocate»
doorClosedSensors:DoorClosedSensor
1 «expand,catalog»
«allocate»
«allocate»
«allocate»
«allocate»«allocate»
«allocate»
«allocate» «allocate»
© 2012 IBM Corporation 20 Do not distribute
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.
EADS, Doors Management System
© 2012 IBM Corporation 21 Do not distribute
DMS: From user story to model
Geometrical
Functional
Technical
DMS_Physical
Sw itchPlaceholders1 CtlPlaceholders1 RDCPlaceholders1ClosedSensorPlaceholders1 LatchActuactorPlaceholders1LockActuatorPlaceholders1 LockedSensorPlaceholders1 LatchedSensorPlaceholders1
DMS_Technical
RDCs1..*
«allocate»
sw itches1..*
«allocate»
controllers1..*
«allocate»
latchActuators1..*
«allocate»
doorClosedSensors1..*
«allocate»
lockActuators1..*
Attributes
«allocate»
doorLatchedSensors1..*
Attributes«allocate»
doorLockedSensors1..*
Attributes
«allocate»
«allocate»
«allocate»
«allocate»
«allocate»
«allocate»
«allocate»
«allocate»
«allocate»
DMS_Functional.doors_R:DoorFunctionality4 «Function»
Locking1 «Function»
LatchSensing1 «Function»
Latching1 «Function»
LockSensing1 «Function»
CloseSensing
1 «Function»
Functional::DMS_Functional.ctrl_R:Control1 «Function»
Functional::DMS_Functional.ctrl_L:Control1 «Function»
Technical::DMS_Technical
«block»
latchActuators:DoorLatchActuator1 «expand,catalog»
«allocate»
controllers:Controller1 «expand,catalog»
«allocate»
«allocate»
doorLockedSensors:DoorLockedSensor
1 «expand,catalog»
«allocate»
lockActuators:DoorLockActuator
1 «expand,catalog»
«allocate»
doorLatchedSensors:DoorLatchedSensor
1 «expand,catalog»
«allocate»
doorClosedSensors:DoorClosedSensor
1 «expand,catalog»
«allocate»
«allocate»
«allocate»
«allocate»«allocate»
«allocate»
«allocate» «allocate»
Mapping
Allocation
© 2012 IBM Corporation 22 Do not distribute
1. SysML modeling
2. Run Optimization and show alternatives
3.Visualize the alternatives DMS: Results [1/2]
© 2012 IBM Corporation 23 Do not distribute
1. SysML modeling
2. Run Optimization and show alternatives
3.Visualize the alternatives DMS: Results [2/2]
© 2012 IBM Corporation 24 Do not distribute
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
© 2012 IBM Corporation 25 Do not distribute
1. Talking Systems Engineers language, applying the best optimization tools
2. Library of reusable pluggable Analysis Viewpoints
Objective
© 2012 IBM Corporation 26 Do not distribute
1. Talking Systems Engineers language, applying the best optimization tools
2. Library of reusable pluggable Analysis Viewpoints
Objective
Do we really have repeating types of analysis?
Does current optimization modeling support building the libraries?
What should be the methodology and supportive framework?
Questions
© 2012 IBM Corporation 27 Do not distribute
Use Case 1 – EADS Development and Analysis of a Doors and Slides Control System
27
Sensor
Actuator
Data
Concentrator
Controller
Data
Concentrator
Cable (Data and Power)
Switch
Switch
Cable (Data)
SwitchEthernet
Cable
Ethernet
Cable
Eth
erne
t
Cab
le
Virtual Link
DC 1 BusBar
DC 2 BusBar
Power Cable
Door
DoorDoor
DoorEmergenc
y
Emergenc
y
Avionics BayLanding Gear Bay
Controllers
SensorsActuators
RDC
Switches
Power Cables
Weight, Cable length, Power distribution, Mapping, Allocation, Reliability …
Structure
Functional Geometrical
Design metrics
Sense
Control
Actuate
•Passenger Doors, Emergency Exits, and Cargo Doors
© 2012 IBM Corporation 28 Do not distribute
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
Design metrics:
– Mapping
– Weight
– Cost
– Cable length
– Reliability requirements
– Power efficiency
Use Case 2 – UTC Power Distribution System
EPS_Technical
«block»
LeftAC_Bus:AC_Bus1
PowerOut[1..*]
PowerIn[1..*]
LeftDC_Bus:DC_Bus1
PowerOut[1..*]
PowerIn[1..*]
RightAC_Bus:AC_Bus1
PowerOut[1..*]
PowerIn[1..*]
RightDC_Bus:DC_Bus1
PowerOut[1..*]
PowerIn[1..*]
PDBs:PDB
1 «optimized»
DCIn
«TypedConnector,optimized» «TypedConnector,optimized»
ACIn
«TypedConnector,optimized»«TypedConnector,optimized»
ModeIn
ACOut[*]
DCOut[*]Loads:Load
1 «inventory»
DCIn
«TypedConnector,optimized»
ACIn
«TypedConnector,optimized»
itsController:Controller
1 «inventory»
Network
Outputs[1..*]
«TypedConnector,optimized»
SensorsIn[1..*]
PowerIn
«TypedConnector,optimized» «TypedConnector,optimized»
«TypedConnector,optimized»«TypedConnector,optimized»
«TypedConnector,optimized»
«TypedConnector,optimized»
«TypedConnector,optimized»
© 2012 IBM Corporation 29 Do not distribute
Complex system topology
Optimal mapping of SW components to ECUs
Use Case 3 – Automotive
mapping
SwC1
SwC3
SwC2
ECU1 ECU2
Design metrics:
• Mapping
• Reliability
• Cost
• Power
• Timing/schedulability
• Data communication
• Operational
scenarios
© 2012 IBM Corporation 30 Do not distribute
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.
Use Case 4 - INCOSE 2012 Tool Vendor Challenge Forest Fire Fighting
Design metrics:
• Resource allocation
• Cost
• Timing
• Data communication
• Scenarios
© 2012 IBM Corporation 31 Do not distribute
INCOSE 2012 Tool Vendor Challenge - Forest Fire Fighting, Results
1. SysML modeling
2. Run Optimization and show alternatives
3.Visualize the alternatives
© 2012 IBM Corporation 32 Do not distribute
Airbus, Cabin Configuration Find Optimal Cabin Architecture
fulfilling different airlines requirements
by Minimize cost, weight, power and
voltage drop, and redundancy
DANSE, Sensor positioning in
System of Systems context
Assign the possible antenna bridge
positions , Estimate the coverage
area for each antenna
UTC, Power Distribution System
Draw power from sources and distribute
to the loads and PBC, optimal selection,
allocation, connections, and placement
Automotive, E/E usecase T1/T2 suppliers provide software modules
with their hardware, OEMs are required to
allocate each module to an ECU
EADS, Doors Management System Find Optimal architecture, and geo
allocation considering cost, cable length,
weight and reliability aspects.
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
Use cases we have explored so far
Bus (e.g. ARINC/AFDX)
Remote Data Concentrators (RDC)
Cables
Controller
Controller
IT Architecture design Build IT architecture based on
applications requirements,
interconnection, application, software and
hardware catalogues
© 2012 IBM Corporation 33 Do not distribute
1. Talking Systems Engineers language, applying the best optimization tools
2. Library of reusable pluggable Analysis Viewpoints
Objective
Do we really have repeating types of analysis?
Does current optimization modeling support building the libraries?
What should be the methodology and supportive framework?
Questions
© 2012 IBM Corporation 34 Do not distribute
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
© 2012 IBM Corporation 35 Do not distribute
Example
Requirement Layer Layer
Sensing1 Controlling1 Actuating1
Architecture Layer Layer
© 2012 IBM Corporation 36 Do not distribute
Minimize totalCost
Subject to
𝑡𝑜𝑡𝑎𝑙𝐶𝑜𝑠𝑡 =
𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒 𝑗 . 𝐶𝑜𝑠𝑡 ∙ 𝑠𝑒𝑛𝑠𝑜𝑟 𝑖 𝑗
𝑖∈𝑆𝑒𝑛𝑠𝑜𝑟𝑠𝑗∈𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒𝑠
+ ⋯
+ 𝑆𝑤𝑖𝑡𝑐ℎ𝑇𝑦𝑝𝑒 𝑗 . 𝐶𝑜𝑠𝑡 ∙ 𝑠𝑤𝑖𝑡𝑐ℎ 𝑖 𝑗
𝑖∈𝑆𝑤𝑖𝑡𝑐ℎ𝑒𝑠𝑗∈𝑆𝑤𝑖𝑡𝑐ℎ𝑇𝑦𝑝𝑒𝑠
…
// Mapping
𝑠𝑒𝑛𝑠𝑖𝑛𝑔2𝑠𝑒𝑛𝑠𝑜𝑟[𝑙] 𝑖 𝑗
𝑖∈𝑆𝑒𝑛𝑠𝑜𝑟𝑠𝑗∈𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒𝑠
= 1 ∀ 𝑙 ∈ 𝑆𝑒𝑛𝑠𝑖𝑛𝑔𝐹𝑢𝑛𝑐𝑡𝑖𝑜𝑛𝑠
totalCost Journey
© 2012 IBM Corporation 37 Do not distribute
Requirement for using several types of sensors
– thermal and volume sensors
– each having its own attributes and a catalog of available types
𝑡𝑜𝑡𝑎𝑙𝐶𝑜𝑠𝑡 =
𝑇ℎ𝑒𝑟𝑚𝑎𝑙𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒 𝑗 . 𝐶𝑜𝑠𝑡 ∙ 𝑡ℎ𝑒𝑟𝑚𝑎𝑙𝑆𝑒𝑛𝑠𝑜𝑟 𝑖 𝑗
𝑖∈𝑇𝑒𝑟𝑚𝑎𝑙𝑆𝑒𝑛𝑠𝑜𝑟𝑠𝑗∈𝑇𝑒𝑟𝑚𝑎𝑙𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒𝑠
+ 𝑉𝑜𝑙𝑢𝑚𝑒𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒 𝑗 . 𝐶𝑜𝑠𝑡 ∙ 𝑣𝑜𝑙𝑢𝑚𝑒𝑆𝑒𝑛𝑠𝑜𝑟 𝑖 𝑗
𝑖∈𝑇𝑒𝑟𝑚𝑎𝑙𝑆𝑒𝑛𝑠𝑜𝑟𝑠𝑗∈𝑉𝑜𝑙𝑢𝑚𝑒𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒𝑠
+ ⋯
+ 𝑆𝑤𝑖𝑡𝑐ℎ𝑇𝑦𝑝𝑒 𝑗 . 𝐶𝑜𝑠𝑡 ∙ 𝑠𝑤𝑖𝑡𝑐ℎ 𝑖 𝑗 .
𝑖∈𝑆𝑤𝑖𝑡𝑐ℎ𝑒𝑠𝑗∈𝑆𝑤𝑖𝑡𝑐ℎ𝑇𝑦𝑝𝑒𝑠
totalCost Journey
© 2012 IBM Corporation 38 Do not distribute
Cable component connects other architectural components
– new type – Cable
– cables’ costs are also dependent on the geometrical layout
𝑡𝑜𝑡𝑎𝑙𝐶𝑜𝑠𝑡 =
𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒 𝑗 . 𝐶𝑜𝑠𝑡 ∙ 𝑠𝑒𝑛𝑠𝑜𝑟 𝑖 𝑗 [𝒌]
𝒌∈𝑪𝒐𝒎𝒑𝒂𝒓𝒕𝒎𝒆𝒏𝒕𝒔𝑖∈𝑆𝑒𝑛𝑠𝑜𝑟𝑠𝑗∈𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒𝑠
+ ⋯
+ 𝐶𝑎𝑏𝑙𝑒𝑇𝑦𝑝𝑒 𝑗 . 𝐶𝑜𝑠𝑡 ∙ 𝑐𝑎𝑏𝑙𝑒 𝑖 𝑗 𝒌
𝒌∈𝑺𝑷𝒂𝒕𝒉𝒔𝑖∈𝐶𝑎𝑏𝑙𝑒𝑠𝑗∈𝐶𝑎𝑏𝑙𝑒𝑇𝑦𝑝𝑒𝑠
.
totalCost Journey
© 2012 IBM Corporation 39 Do not distribute
Safety requirements
– functions and functional links could be implemented by several redundant
channels
𝑠𝑒𝑛𝑠𝑖𝑛𝑔2𝑠𝑒𝑛𝑠𝑜𝑟 𝑙 [𝒓] 𝑖 𝑗
𝑖∈𝑆𝑒𝑛𝑠𝑜𝑟𝑠𝑗∈𝑆𝑒𝑛𝑠𝑜𝑟𝑇𝑦𝑝𝑒𝑠
= 𝑟𝑒𝑑𝑢𝑛𝑑𝑎𝑛𝑐𝑦𝐶ℎ𝑎𝑛𝑛𝑒𝑙 𝑙 [𝑟]
∀ 𝑙 ∈ 𝑆𝑒𝑛𝑠𝑖𝑛𝑔𝐹𝑢𝑛𝑐𝑡𝑖𝑜𝑛𝑠, 𝒓 ∈ 𝑹𝒆𝒅𝒖𝒏𝒅𝒂𝒏𝒄𝒚𝑪𝒉𝒂𝒏𝒏𝒆𝒍𝒔
totalCost Journey
© 2012 IBM Corporation 40 Do not distribute
1. Talking Systems Engineers language, applying the best optimization tools
2. Library of reusable pluggable Analysis Viewpoints
Objective
Do we really have repeating types of analysis?
Does current optimization modeling support building the libraries?
What should be the methodology and supportive framework?
Questions
© 2012 IBM Corporation 41 Do not distribute
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
© 2012 IBM Corporation 42 Do not distribute
Algebraic style depends on element sets from system’s viewpoints
– designers constantly revise the optimization model ensuring its consistency
with system’s engineering model
Problem Analysis
© 2012 IBM Corporation 43 Do not distribute
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.
Problem Analysis
© 2012 IBM Corporation 44 Do not distribute
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
New Approach
© 2012 IBM Corporation 45 Do not distribute
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
New Approach
© 2012 IBM Corporation 46 Do not distribute
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”
Classification-by-Property API
– Attributes
o variables
o parameters
– isSelected
– isContainedIn(instance)
– isMapped
– couldBeMapped(instance)
DSE Ontology
© 2012 IBM Corporation 47 Do not distribute
totalCost 𝑖
= isSelected 𝑗 ∙ Cost 𝑗 ∀ 𝑖 ∈ Scope totalCost
𝑗∈Scope({Cost, isContainedIn 𝑖 })
// Mapping
isMapped(𝑖)(𝑗) = 𝑖𝑠𝑆𝑒𝑙𝑒𝑐𝑡𝑒𝑑(𝑖)
𝑗∈Scope couldBeMapped 𝑖
∀ 𝑖 ∈ Scope(isRequirementsElement)
totalCost journey – Magic of the New Approach
© 2012 IBM Corporation 48 Do not distribute
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
totalCost journey – Magic of the New Approach
dseCapacity 𝑖 𝑗 ≥ isMapped 𝑘 𝑗 ∙ dseRequest 𝑖 𝑘
𝑘∈Scope dseRequest 𝑖
∀ 𝑖 ∈ dseResources, 𝑗 ∈ Scope dseCapacity 𝑖
© 2012 IBM Corporation 49 Do not distribute
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
© 2012 IBM Corporation 50 Do not distribute
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
© 2012 IBM Corporation 51 Do not distribute
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)
Main Findings
© 2012 IBM Corporation 52 Do not distribute
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
Main Recommendations
© 2012 IBM Corporation 53 Do not distribute
Extending the proposed approach to dynamic systems
– reusable state charts / activity diagrams
Optimization patterns in building Analysis Viewpoints constraints
– symmetry breaking
Future directions
IBM Research - Haifa
© 2012 IBM Corporation
© 2012 IBM Corporation 55 Do not distribute
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
Where can we use this approach?