How long is a piece of
string?
Quantifiable aspects of
Architecture Frameworks
Matthew Hause: PTC
Lars-Olof Kihlström: Syntell AB
Presenters
• Matthew Hause: PTC
– GTM Solutions Specialist, Fellow at PTC
– Co-Chair UPDM Group at OMG
– Member of SysML development team
– OMG Architecture Board Member
– Consultant, trainer, mentor of MBSE and Enterprise Architecture
• Lars-Olof Kihlström: Syntell AB
– Principal consultant at Syntell
– Member of the UPDM group since its inception
– Project manager for the MODAF re-engineering work that resulted in MODEM
– Member of the NAF revision syndicate (while it existed), responsible for NAF 3.0 and
3.1 on behalf of the Swedish Armed Forces
– Member of the IDEAS group (while it existed) on behalf of the Swedish Armed Forces
– Primarily engaged as mentor, coach and developer concerning model based system
engineering and enterprise architecture
2
Quantifiable aspects of MBSE and enterprise
architecture
• Model-Based Systems Engineering (MBSE) means that communication of
system requirements can be improved with models rather than relying on
“just words”.
• The Systems Modeling Language (SysML) was developed by INCOSE
and the Object Management Group (OMG) to enable MBSE.
• It supports the specification, analysis, design, verification and validation of
a broad range of systems and systems-of-systems.
• Systems engineers have been trying to get more out of their models by
making them executable to answer questions or obtain results.
– The greatest concentration of work on executable models has concentrated on
behavioral execution using code generation.
• This can also be done in modeling languages based on UML such as
SysML and versions of the Unified Profile for DoDAF and MODAF
(UPDM).
3
Is behavioral aspects all that is important?
• Behavioural aspects could be only a small part of the overall system
requirements. Requirements can be non-functional, performance,
structural, domain, cost, user interface, organizational, safety,
interoperability and so forth.
– Rather than just considering models as execution of behavior, it is important to look at
a model as a means of getting at quantitative and qualitative analysis results as well
as behavioural ones.
• In order to fully grasp how different types of elements operate in different
scenarios, it is important to take a look at aspects of use, performance,
cost etc. from an overall point of view.
• Significant benefits can be realized by making use of architecture
frameworks as a means of exploring these issues and tie the lessons
learned from this into a direct MBSE development.
• In order to fully make use of quantifiable aspects a clear appreciation of
what is meant is required.
4
UPDM version 1
MODAF v1.2.003
UML
profile
based
NAF v3.0
1.1
DoDAF 1.5
• There was a bit of SysML in MODAF and the implementation of UPDM could
choose between a pure UML or UML and SysML approach.
• UPDM contained both a profile as well as a domain meta-model that
explained the meaning of the elements in the profile.
5
UPDM version 2
MODAF v1.2.004
UML
profile
based
NAF v3.1
IDEAS
based
2.1
DoDAF 2.02
• There was still a bit of SysML in MODAF and the implementation of UPDM
could choose between a pure UML or UML and SysML approach.
• UPDM contained both a profile as well as a domain meta-model that
explained the meaning of the elements in the profile.
6
UPDM version 3
UML profile
based
MODAF
v1.2.004
MODEM
IDEAS
based
DMM
3.0
NAF v4.0
DoDAF 2.02
change 1
DNDAF
Other
influences…
7
Framework developments
• UPDM RFP requirement: ” The UPDM V3.0 domain metamodel shall be
derived from MODEM and DM2, both of which are based upon the
International Defence Enterprise Architecture Specification Foundation
[IDEAS].”
• Mandatory requirements (excerpt):
– Provide Domain Metamodel (Abstract Syntax and Constraints) derived from
MODEM and DM2
– An Architecture Framework Profile Using SysML
– Enable the Expression Of Business Process Models
– Use of SysML Requirements Elements and Diagrams
– Use of SysML Parametrics Elements and Diagrams Mapped to Measurements
– Traceability Matrix to Supported Frameworks
• Non mandatory features (excerpt):
–
–
–
–
UML Profile for NIEM
Information Exchange Packaging Policy Vocabulary (IEPPV)
Viewpoints in Support of SoS Life Cycle Processes and Analyses
Support for Additional Viewpoints beyond those defined in DoDAF, MODAF/
MODEM, NAF, and the Security Viewpoint from DNDAF.
– Human Systems Integration (HSI)
8
Quantifiable aspects?
• IDEAS and MODEM is based on the mathematical concept of sets.
9
An example of a categorical property and measure
10
The SAR distress scenario
11
E3 Capability Dependencies (CV-4/ StV-4)
CV-4 [Capability] SAR
Owning
Capability
«Capability»
«block»
Search And Rescue
Required
Capability
DSM : Distress Signal Monitoring
Capability
dependencies
provide context for
capability phases
and resource
deployment
SC2 : SAR C2
Inf : Inform
MIC2 : Military C2
Capability
Dependency
Srch : Search
Asst : Assistance
Rec : Recovery
12
MODEM Capability Dependencies
13
Lp Actual Project (PV-2/ AcV-2)
PV-3 [Architectural Description] Actual Projects
«Project»
SAR Manual Project I : Development
«Project»
SAR Manual Project II : Development
startDate
2010-01-01 00:00:00
endDate
2010-12-01 00:00:00
responsibleResource
«Organization» Department Of Transport : Government Department
«IncrementMilestone»
MRU v1 INC
endDate
2010-01-01 00:00:00
resource
«System» Maritime Rescue Unit v1
«DeployedMilestone»
MRU v1 UK DEP
endDate
2010-04-01 00:00:00
resource
«System» Maritime Rescue Unit v1
usedBy
«Organization» Maritime & Coastguard Agency
«Organization» Volunteer Rescue Organization
«DeployedMilestone»
MRU v1 EU DEP
endDate
2010-07-01 00:00:00
resource
«System» Maritime Rescue Unit v1
usedBy
«Organization» Coastguard
«NoLongerUsedMilestone»
MRU v1 NLU
endDate
2010-09-01 00:00:00
resource
«System» Maritime Rescue Unit v1
noLongerUsedBy
«Organization» Maritime & Coastguard Agency
«Organization» Volunteer Rescue Organization
«Organization» Coastguard
«RetirementMilestone»
MRU v1 OOS
endDate
2010-11-01 00:00:00
resource
«System» Maritime Rescue Unit v1
«Project»
SAR Automation Project : Development
startDate
2010-08-01 00:00:00
«ProjectSequence»
2011-05-28 00:00:00
startDate
2010-06-01 00:00:00
endDate
endDate
2011-02-01 00:00:00
responsibleResource
«Organization» Department Of Transport : Government Department
«IncrementMilestone»
MRU v2 INC
endDate
2010-08-01 00:00:00
resource
«System» Maritime Rescue Unit v2
responsibleResource
«Organization» Department Of Transport : Government Department
«IncrementMilestone»
ARU Beta Unit INC : Development Milestone
endDate
2011-08-01 00:00:00
resource
«System» Automated Rescue Unit v1
«DeployedMilestone»
MRU v2 DEP
endDate
2010-10-01 00:00:00
resource
«System» Maritime Rescue Unit v2
usedBy
«Organization» Maritime & Coastguard Agency
«Organization» Volunteer Rescue Organization
«Organization» Coastguard
«DeployedMilestone»
ARU INC : Development Milestone
endDate
2011-08-01 00:00:00
resource
«System» Automated Rescue Unit v1
«NoLongerUsedMilestone»
MRU v2 NLU
«RetirementMilestone»
ARU OOS : Development Milestone
endDate
2011-01-01 00:00:00
resource
«System» Maritime Rescue Unit v2
noLongerUsedBy
«Organization» Maritime & Coastguard Agency
«Organization» Volunteer Rescue Organization
«Organization» Coastguard
endDate
2012-01-01 00:00:00
resource
«System» Automated Rescue Unit v1
themeValues
Equipment = Complete
Training = Complete
Concepts & Doctrine = Not Applicable
Personnel = Complete
Information = Complete
Organization = Complete
Infrastructure = Not Applicable
Logistics = Complete
Interoperability = Not Applicable
«RetirementMilestone»
MRU v2 OOS
endDate
2011-05-01 00:00:00
resource
«System» Maritime Rescue Unit v2
themeValues
Equipment = Complete
Training = Complete
Concepts & Doctrine = Not Applicable
Personnel = Complete
Information = Complete
Organization = Complete
Infrastructure = Not Applicable
Logistics = Complete
Interoperability = Not Applicable
Actual
Project
«MilestoneSequence»
Milestone
Dependency
Actual
Milestone
Definition of
projects, subprojects,
milestones
and
dependencies
14
Lp Project Detail (PV-2/ AcV-2)
Resource
Resource
Used By
Project
«Project»
SAR Manual Project I : Development
startDate
2010-01-01 00:00:00
endDate
2010-12-01 00:00:00
responsibleResource
«Organization» Department Of Transport : Government Department
Organization/
Person
Responsible
Theme
Statuses
«DeployedMilestone»
MRU v1 UK DEP
endDate
2010-04-01 00:00:00
resource
«System» Maritime Rescue Unit v1
usedBy
«Organization» Maritime & Coastguard Agency
«Organization» Volunteer Rescue Organization
themeValues
Equipment = Complete
Training = In Test
Concepts & Doctrine = In Progress
Personnel = Complete
Information = In Progress
Organization = Complete
Infrastructure = Complete
Logistics = Not Applicable
Interoperability = In Progress
Milestone
15
Lp Themes
16
Lp Project Timelines
Project
Timeline
Milestone
Dependency
Milestone
Dashboard view
provides project
status at a glance:
generated from
model
17
AV-3 Measurements Definitions
AV-3 [Architectural Description] Measurements (Class)
Measurement
Set
«MeasurementSet»
«valueType»
Standard SAR Measurements
Measurements
Definition of
metrics for
reuse
throughout the
architecture.
«Measure» areaCoverage : Coverage
«Measure» findTime : Elapsed Time
«Measure» persistence : Elapsed Time
«Measure» searchCoverage : Coverage
«Measure» weatherConditions : Weather Conditions
Measurement
Sub-Type
«MeasurementSet»
«valueType»
Maritime SAR Measurements
«MeasurementSet»
«valueType»
Land SAR Measurements
«Measure» seaConditions : Sea State
«Measure» terrain : Terrain Type
18
AV-3 Actual Measurements
• Specific metric values
Actual
Measurement
AV-3 [Architectural Description] Measurements (Actual)
«ActualMeasurementSet»
{intention = Estimate}
Initial Values : Maritime SAR Measurements
seaConditions : Sea State = Sea State 6
areaCoverage : Coverage = 500
findTime : Elapsed Time = <8 hours
persistence : Elapsed Time = >15 hours
searchCoverage : Coverage = 400
weatherConditions : Weather Conditions = Heavy Rain
«ActualMeasurementSet»
{intention = Result}
Final Values : Maritime SAR Measurements
seaConditions : Sea State = Sea State 8
areaCoverage : Coverage = 650
findTime : Elapsed Time = <4 hours
persistence : Elapsed Time = >20 hours
searchCoverage : Coverage = 550
weatherConditions : Weather Conditions = Stormy
«ActualMeasurementSet»
{intention = Required}
Required Values : Maritime SAR Measurements
seaConditions : Sea State = Sea State 8
areaCoverage : Coverage = 600
findTime : Elapsed Time = <5 hours
persistence : Elapsed Time = >20 hours
searchCoverage : Coverage = 500
weatherConditions : Weather Conditions = Stormy
«ActualMeasurementSet»
{intention = Estimate}
UPDM : Standard SAR Measurements
Measurement
Values
intention
Estimate
areaCoverage : Coverage = 10
findTime : Elapsed Time = 20
persistence : Elapsed Time = 50
searchCoverage : Coverage = 60
weatherConditions : Weather Conditions = 70
19
Ep Capability Phasing (Fragment) (CV-3/ StV-3)
Timeline
Capability Gap
Capabilities
Coverage
Summarizes how and
when capabilities will
be realized as well as
metrics. Identifies
capability gaps.
Capability
Metrics
Realizing
Resource
20
Showing cost vs. time vs. capability (2)
• Pres
21
System Configuration Trade-Off Analysis
Owned
System
bdd [Package] System Structure [Airborne System Structural Breakdown]
«block»
Data Radio
1
1
«block»
UAV Airborne Systems
Ground Radio
«block»
GPS Receiver
1
UAV Airborne Elements
«block»
Airframe
1
1
values
Mass : kg = 1.1
Power : W = 12
GPS
«block»
Sensors
20
Sensors
1
Airframe
1
Propulsion System
values
Mass : kg = 0.15
Power : W = 0.12
1
«block»
Battery Power Supply
Power Supply
values
Mass : kg = 20
«block»
Propulsion System
values
Mass : kg = 22
Power : W = 110
«block»
Flight Control Hardware Flight Control Hardware
values
Mass : kg = 11
Power : W = 22
1
Value
Properties
1
1
Digital Data Radio
values
Mass : kg = 1.1
Power : W = 11.0
«block»
Antenna Type
Antenna
values
Mass : kg = 2.0
Power : W = 25
1
Tranceiver Terminal
«block»
Digital Camera
Camera
values
Mass : kg = 1.1
Power : W = 11.0
1
Subsystem
1
values
Mass : kg = 3.0
«block»
Data Radio
«block»
Simple UAV
1
«block»
Tranceiver Type
values
Mass : kg = 0.6
Power : W = 22
1
«block»
Onboard Computer
Onboard Computer
values
Mass : kg = 0.75
1
1
«block»
Airborne Software
airSW
22
System configuration
23
System configuration
24
System Configuration Trade-Off Analysis
25
Parametrics – Trade-Off Analysis
• Used to express constraints (equations) between value properties
– Provides support to engineering analysis
• e.g. performance, reliability, etc
• Constraint block captures equations
– Expression language can be formal
• e.g. MathML, OCL …
– or informal
– Computational engine is defined by applicable analysis tool
• and not by SysML
• Parametric diagram represents the usage of the constraints in an
analysis context
– Binding of constraint usage to value properties of blocks
• e.g. vehicle mass bound to F= m * a
26
SysML Parametrics – Mean Response Time
bdd [Package] Parametrics
«block»
MeanResponseTimeAnalysis
Context
values
meanResponseTime : Hours
rescueTime : Hours
searchTime : Hours
BDD for
Mean
Response
Time
Analysis
1
1 helicopter
1
1
1
1 command
«block»
Aircraft
sea
values
signalResponseTime : Hours
1
yacht
1
1
lifeboat
«block»
Boat
Boat and Yacht
Values
Command
Center Values
«block»
CommandCenter
values
scanWidth : Miles
speed : MilesPerHour
Aircraft
Values
1
values
locationXY : Miles [2]
speed : MilesPerHour
«block»
MarineEnvironment
values
conditions : Sea State
totalArea : SquareMiles
Environmental
Values
27
SysML Parametrics
par [block] MeanResponseTimeAnalysis_PAR
Context
meanResponseTime : Hours
command : CommandCenter
signalResponseTime : Hours
Equation for
calculating
mean
response
times
helicopter : Aircraft
t : Hours
width : Miles
searchTime : Hours
scanWidth : Miles
mst1 : MeanSearchTime
constraints
{t = area / 2 / speed / width}
t1 : Hours
t : Hours
speed : MilesPerHour
speed : MilesPerHour
t2 : Hours
area : SquareMiles
sea : MarineEnvironment
Property of
System
totalArea : SquareMiles
constraints
{t = t1 + t2 + t3}
area : SquareMiles
seastate : Real
conditions : Sea State
Value
Property
trt1 : TotalResponseTime
mrt1 : MeanRescueTime
t3 : Hours
constraints
{t = 0.4 * pow(area,0.5) *
pow(seastate,0.5) / speed}
lifeboat : Boat
t : Hours
rescueTime : Hours
speed : MilesPerHour
speed : MilesPerHour
Parameter
Parametric
Equation
28
SysML Parametrics – Tradeoff Analysis
Analysis01 : MeanResponseTimeAnalysis
Initial values
and ranges
set by
engineer.
meanResponseTime : Hours
searchTime : Hours
rescueTime : Hours
helicopter = RN_ASR_Helicopter
lifeboat = RNLI_Lifeboat
command = CommandCenter01
sea = Sea01
command
helicopter
CommandCenter01
RN_ASR_Helicopter
signalResponseTime : Hours = 0.5
scanWidth : Miles = 0.25
speed : MilesPerHour = ...
lifeboat
RNLI_Lifeboat
Solution
Values
speed : MilesPerHour = 25.0
locationXY : Miles = 2.0, 5.0
sea
Sea01
totalArea : SquareMiles = 400.0
conditions : Sea State = 4.0
29
SysML Parametrics – Solution
Optimized
solution
provided by
equation solver
30
L2 Operational Nodes (Performers) (OV-2)
Operational
nodes with
needlines and
flows
Context
Node
Flow
31
L3 Operational Resource Flow Matrix (Fragment) (OV-3)
Overlap
Ov-2
Overlap
Type DIV-2
Producing
Performer
OV-2
Producing
Activity OV-5
Connection
OV-2
Consuming
Performer Consuming
Activity OV-5
OV-2
Generated
automatically
from the
architecture
32
Comms Metrics Definition and Instances
33
Messages with Added Metrics
34
Metrics
35
L2 Operational nodes
36
L2 Information flows
37
Conclusions
• The purpose of a model is to answer one or more questions
– Before you start, agree on the question
• Assessment criteria should be agreed prior to starting the model
• A well-documented process is essential for success
• Executable architectures should look at more than just behavior.
• Executing an architecture requires data
– (You can’t execute a PowerPoint slide.)
• In order to ensure that the data is semantically correct a “wash” through
an IDEAS based ontology is a good idea.
38
Questions, Comments, Discussion
39