Transcript Systems Modeling Language (SysML)

INCOSE Evaluation:
Systems Modeling Language (SysML)
SysML Submission Team (SST)
13, 15, 20 December 2005
SST Chair: Sanford Friedenthal
[email protected]
Topics




Introduction
MDSD Actions
Specification Updates
Specification Highlights







Sample Problems



Language Architecture
Compliance Approach
Structural Constructs
Behavioral Constructs
Cross-cutting Constructs
Appendixes
HSUV Example from Appendix B
Distiller Example (response to D. Oliver example)
Summary
2
Introductory Statement

Two competing specifications* submitted to the OMG
on November 14, 2005 from:


SysML Submission Team (SST) chaired by S. Friedenthal
SysML Partners chaired by C. Kobryn
* Available at http://syseng.omg.org/SysML.htm


This highlights updates and selected features of the
SST SysML Specification v0.98 (ad/2005-11-01)
A vote for adoption should occur at the next OMG
meeting the week of February 13, 2006
3
What is SysML?



A graphical modeling language in response to the UML
for Systems Engineering RFP developed by the OMG,
INCOSE, and AP233
 a UML Profile that represents a subset of UML 2 with
extensions
Supports the specification, analysis, design, verification
and validation of systems that include hardware,
software, data, personnel, procedures, and facilities
Supports model and data interchange via XMI and the
evolving AP233 standard (in-process)
SysML is Critical Enabler for Model Driven SE
4
SysML Background




UML for SE RFP issued – 28 March 2003
SysML Partners Kickoff meeting – 6 May 2003

Chaired by S. Friedenthal and C. Kobryn
3rd revised submission (v0.9) to OMG – 10 Jan 2005

Addendum stereotypes chapter – 30 May 2005
SysML Submission Team announced split from SysML Partners on August 30,
2005 to finalize the specification


Both teams started from a common baseline




Differences in process, issue prioritization and resolutions
V0.9 plus Addendum Profiles chapter
Blocks/Parametrics approach
Satisfied most of the requirements of the UML for SE RFP
Submitted revised submissions on November 14, 2005 with planned vote for
adoption at next OMG meeting in Feb ‘06
5
SysML Submission Team (SST)

Members
 Industry & Government


Vendors


American Systems, BAE SYSTEMS, Boeing,
EADS-Astrium, Eurostep, Lockheed Martin,
NIST, oose.de, Raytheon, THALES
Artisan, EmbeddedPlus, IBM, I-Logix, Mentor
Graphics, Sparx Systems, Vitech Corp
Neutral Collaborators
Deere & Company
 Georgia Institute of Technology
 NASA/JPL
SST broad based team of multiple
 INCOSE, AP233
end-users and tool vendors

6
SST Philosophy

Deliver solution to the users without delay





SysML 0.90 widely regarded as an “80% solution”
Systems engineering users demanding this language
Incorporate user and vendor feedback in future
revisions
Provide sufficient features to make the
language useful for systems engineers
Reuse UML at the package level to maintain
language integrity

Limit fine grain selection of UML elements at this
time
7
UML for SE RFP
Requirements Summary

Structure


Behavior


e.g., test cases, verification results
Other


e.g., requirements hierarchy, traceability
Refer to SST Req’ts
Traceability Matrix
in Appendix E.
Verification


e.g., parametric models, time property
Requirements


e.g., function-based behavior, state-based behavior
Properties


e.g., system hierarchy, interconnection
e.g., roles, views, relationship types, diagram types
Optional

e.g., trade studies, other behavior modeling paradigms
SST submission provides robust solution
that addresses most of the RFP requirements
8
SST Design Principles (Section 4.1)

Requirements driven


UML reuse


The package is the basic unit of partitioning in this specification. The
packages partition the model elements into logical groupings which
minimize circular dependencies among them.
Layering


SysML extends UML as needed to satisfy the requirements of the RFP. The
primary extension mechanism is the UML 2 profile mechanism as further
refined in the SysML Profiles & Model Libraries chapter of this specification.
Partitioning


SysML reuses UML wherever practical to satisfy the requirements of the
RFP, and when modifications are required, they are done in a manner that
strives to minimize changes to the underlying language. Consequently,
SysML is intended to be relatively easy to implement for vendors who
support UML 2 or later revisions.
UML extensions


SysML is intended to satisfy the requirements of the UML for SE RFP.
SysML packages are specified as an extension layer to the UML metamodel.
Interoperability

SysML inherits the XMI interchange capability from UML. SysML is also
intended to be supported by the ISO AP233 data interchange standard to
support interoperability among other engineering tools.
9
Highlights of SST Approach (1 of 3)

Coherent and consistent language
architecture essential for integration with
UML, model interchange, and standardized
implementations



Utilizes UML solution for specifying profiles
(e.g. subsetting UML via reference metamodel)
Reuse UML at the package level (vs. metaclass) to
avoid breakage and maintain language integrity
Compliance approach that allows vendor to
clearly state compliance and users to assess
compliance


Consistent with UML
Unambiguous compliance points
10
Highlights of SST Approach (2 of 3)

Usefulness of the language to practicing SE’s

Maintain basic capability for modeling physical
systems


deep nesting, design values with distributions, units tied in
with dimensions, instance diagram for unique
configurations, item flows, moe’s/objective function
integrated with parametrics, timing diagram, explicit
allocation for swim lanes (activity partitions), requirements
refinement via models, …
Ensure understandability

Distinct flow port notations, requirements callout notation,
elaborated diagram element tables, diagram conventions,
…
11
Highlights of SST Approach (3 of 3)


Multi-vendor solution (Artisan, EmbeddedPlus/IBM,
I-Logix, Sparx Systems) that is being implemented
Leverages broad based specification author team
to maintain quality and completeness across
chapters

This includes chapters that were reused by the other
submission team such-as activities, allocations, and
profiles & model libraries
12
Evaluating the Specifications

Specifications and RFP available at:


http://syseng.omg.org/SysML.htm
Specification review guidance

Use the SST Highlights & Comparison Matrix and the following
slides to help understand the differences between the submissions


Review the following chapters in the SST Introduction





Overviews
Diagram elements (look for completeness)
UML extensions (targeted to tool vendors / language implementers)
Usage examples (consistent with Appendix B sample problem)
Review the SST Sample Problem in Appendix B


Language architecture and Compliance
Review the following subsections in each SST chapter


Available on INCOSE Evaluators Site or request from SST Chair
Provides overview of how language can be used
Review the following appendixes as time permits



Diagrams
Non-Normative Extensions
Model Interchange
13
UML for SE RFP Evaluation Criteria











6.8.1 Ease of use
6.8.2 Unambiguous
6.8.3 Precise
6.8.4 Complete
6.8.5 Scalable
6.8.6 Adaptable to different domains
6.8.7 Capable of complete model interchange
6.8.8 Evolvable
6.8.9 Process and method independent
6.8.10 Compliant with UML metamodel
6.8.11 Verifiable
14
Language Feature Summary
(Refer to SST Highlights & Comparison Matrix 051201-revb)
No.
1
2
3
4
5
6
6a
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Language Feature
Impact/Priority RFP Evaluation Criteria
Language Architecture
Compliance
Views & Viewpoints
Value Types, Units & Dimensions
Property Specific Types
Instance Diagram
Deep Nesting
Item Flows
Flow Port Features
Flow Port Compatibility Rules
Parametric Diagram
Timing Diagram
Allocation Types
Allocate Activity Partition
Requirement Callout Notation
Refine Requirements Relationship
Containment Symbol
Diagram Conventions
MOE’s & Objective Function
Requirements Classification
BNF Notation
Chapter Updates
H
H
M
H
M
M
H
H
M
M
H
M
M
M
H
H
L
M
H
L
M
M
6.8.2, 6.8.8, 6.8.11
6.8.11
6.8.5
6.8.2, 6.8.3
6.8.1
6.8.4, 6.8.5 (RFP reqt 6.8.4)
6.8.1, 6.8.10
6.8.1, 6.8.4, 6.8.10
6.8.1, 6.8.2
6.8.1, 6.8.3
6.8.1
6.8.4, 6.8.12 (RFP reqt 6.5.2.4.1)
6.8.1, 6.8.2
6.8.1
6.8.1, 6.8.5
6.8.4
6.8.11
6.8.1, 6.8.2
6.8.3, 6.8.4
6.8.2
6.8.2, 6.8.9
6.8.2
Selected Language Features To Contrast Submissions
15
SysML SST Specification Outline



Preface
 Part I of RFP Response
 Part II of RFP Response
 Part III of RFP Response
Part I – Introduction
 Scope
 Normative references
 Additional information
 Language Architecture
 Compliance
 Language Formalism
Part II – Structural Constructs
 Model Elements
 Blocks
 Ports and Flows
 Parametrics



Part III – Behavioral Constructs
 Activities
 Interactions
 State Machines
 Use Cases
Part IV – Crosscutting Constructs
 Allocations
 Requirements
 Profiles & Model Libraries
Part V Appendices
 Diagrams
 Sample Problem
 Non-Normative Extensions
 Model Interchange (AP233 & XMI)
 Requirements Traceability
 Terms and Definitions
 BNF Diagram Syntax Definitions
16
MDSD Recommendations & Response
From INCOSE IW Jan 29-30, 2005
MDSD Recommendations & Response
INCOSE IW – Jan ‘05

Improve SysML tutorial



emphasize 5 Core diagrams and be driven by Requirements
diagrams
replace UML-specific definitions with domain-specific explanations
present update at INCOSE Symposium (MDSD plenary)
RESPONSE: Will continue to elaborate and refine current tutorial
material and make available when adoption begins in February.

Increase readability of SysML specification for engineers and
tool vendors
replace UML-specific definitions with domain-specific explanations
RESPONSE: Current specification includes a superset of terms in
Appendix F that includes definitions from the UML for SE RFP, UML
2, and the SysML extensions. This superset needs to distilled and
refined to include the relevant terms needed for the tool vendors
and end users.

include a domain metamodel
RESPONSE: Use the SE Concept Model to express basic domain
concepts. Will work with INCOSE MDSD to capture additional key
SysML concepts such as usage/roles, etc.

18
MDSD Recommendations & Response (cont.)

Include a model library for Requirement taxonomy


RESPONSE: Updated requirements taxonomy (refer to Appendix C.2)
include MeasureOfEffectiveness (MOE; properties: weight,
optimizationDirection)


RESPONSE: Defined an MOE stereotype which integrates with parametrics to
support engineering analysis (refer to Appendix C.3)
MOE may also include a complementary Parametric construct to effect
MOE constraints

RESPONSE: Defined a general purpose objective function stereotype which
integrates with parameterics to support engineering analysis and optimization
(refer to Appendix C.3)
19
MDSD Recommendations & Response (cont.)

Include a model library for Assemblies that includes
PhysicalAssembly (properties: supplier, modelNumber,
serialNumber, lotNumber)


RESPONSE: Example included in Fig 17-10 in Profiles & Model
Libraries chapter.
Harmonize concepts, constructs, and usage examples for
Allocations

make implicit Allocations explicit


Section 15.3.3.3)
test usability of multiple UI options via vendor prototypes


RESPONSE: Made swim lanes explicit form of allocation (Fig 15-2,
RESPONSE: Multiple UI options explored and incorporated including
allocation/requirement compartments, callout, and tabular formats
(refer to diagram extensions in 15.3.1 and 16.3.1)
Encourage and promote vendor SysML prototypes at INCOSE
Symposium vendor exhibits

RESPONSE: Multi-vendor prototype demonstrations at INCOSE
Symposium in July ‘05 at MDSD and on exhibitor floor
20
Specification Updates
Progress On Issues

Resolved open issues from v0.9


Resolved previously identified critical issues
Resolved 237 issues from original issue list


4 deferred/5 to incorporate into v1.0
Incorporated issue resolutions into v0.98
22
Refer to Slide 15: No. 21
Specification Updates


Updated Specification Outline
Refined chapters





Simplified chapter organization
Improved overviews, descriptions, diagram
extensions, and usage examples
Elaborated diagram element tables to include
more complete concrete syntax
Aligned usage examples with sample problem
appendix
Updated for consistency with language
architecture and compliance approach
Enhanced Completeness, Consistency and
Understandability of SST Specification v0.98
23
SysML Specification Outline - Authors






Preface
Part I – Introduction – Alan Moore/Sandy Friedenthal
Part II – Structural Constructs

Model Elements - Tim Weilkiens with inputs from Roger Burkhart

Blocks - Alan Moore with inputs from Roger Burkhart

Ports and Flows - Eran Gery

Parametrics – Alan Moore with inputs from Roger Burkhart
Part III – Behavioral Constructs

Activities – Conrad Bock

Interactions – Cory Bialowas/Bran Selic

State Machines - Cory Bialowas/Bran Selic

Use Cases – JD Baker
Part IV – Crosscutting Constructs

Allocations – Rick Steiner

Requirements – Laurent Balmelli

Profiles & Model Libraries – Alan Moore
Part V Appendices

Diagrams – Sandy Friedenthal

Sample Problem – Rick Steiner

Non-Normative Extensions – Conrad Bock/Sandy Friedenthal

Model Interchange (AP233 and XMI) – Bran Selic, Dwayne Hardy/David Price

Requirements Traceability – Sandy Friedenthal

Terms and Definitions – Sandy Friedenthal

BNF Diagram Syntax Definitions – Roger Burkhart
24
Specification Updates Refer to Slide 15: No. 21
Technical Content Change Summary


Redefined Language Architecture and Compliance approach
Structure










Behavior



Refined/updated activity extensions*
Included protocol state machines
Cross cutting





Unified class and assembly into blocks*
Specified property subclasses for part, reference, and value
Provided mechanism for part specific subclasses to support design values
Replaced quantity with value type, units, dimensions, and distributions
Redefined ports to include UML (i.e. client-server) ports and flow ports *
Refined item flow semantics and notation
Refined parametric notation and semantics (constraint blocks and properties)
Updated View/Viewpoint to be consistent with IEEE 1471
Updated diagram taxonomy to include package & instance diagram
Refined requirements semantics
Refined allocation semantics
Harmonized callout notation between requirements and allocations
Updated profiles per RTF *
Appendixes







Updated diagram frames & headings conventions
Significantly elaborated sample problem appendix and integrated with usage examples in chapters
Refined non-normative extensions for EFFBD profile*, requirements subclasses, and measures of
effectiveness (MOE’s)*
Refined approach for XMI and AP233 harmonization
Updated requirements traceability matrix in Appendix E
Identified terms for glossary
* Work started prior to split on Aug 30, 2005
Added BNF Diagram Syntax Definition appendix
25
SST Specification Highlights
Specification Highlights
Specification Topic






Language Feature #
(From Slide 15)
Language Architecture
Compliance Approach
Structural Constructs
Behavioral Constructs
Cross Cutting Constructs
Appendixes
1
2
3-10, 18
11
12-16, 19
17-20
Refer to the Topic in the Following Slides for Details
on the Referenced Language Features from Slide 15 27
Language Architecture
Relationship Between SysML and UML
UML 2
UML4SysML
SysML
UML
UML
reused
by 2
Reuse
SysML
SysML
extensions to
UML
(1, 2)
UML
not required
by SysML
(UML UML4SysML)
SysML Profile
29
SysML Diagram Taxonomy
SysML Diagram
Behavior
Diagram
Use Case
Diagram
Activity
Diagram
Requirement
Diagram
Timing
Diagram
Sequence
Diagram
Block Definition
Diagram
State Machine
Diagram
Structure
Diagram
Internal Block
Diagram
Instance Diagram
Parametric
Diagram
Package Diagram
Same as UML 2
Modified from UML 2
New diagram type
30
SysML v0.9 Language Architecture

Issues

Reuse of UML was imprecisely defined



Profile structure was confusing




Only partial list of required meta-classes
UML2 Profiles chapter not clear on specification and
application of UML subset
Contained sub-packages with no extensions
Package partitioning was inconsistent with chapters
Not tied in with compliance
Impacts



XMI and Interoperability
Ability to integrate UML applications with SysML
Ambiguity affects vendor ability to implement
31
Language Architecture Approach

Worked with UML2 RTF on profiles approach and
used to define language architecture




Apply reuse at package level vs metaclass level



Create UML2 Subset using merge
Reference this subset from the SysML profile
Define fine-grained restrictions on features in constraints
Merge only works at package level
Easier to ensure that subset is well-formed with no dangling
references
Profile structure redefined


Consistent with SysML chapter structure
Only introduce sub-profile if chapter contains extensions
32
Reuse of UML 2 – UML4SysML
CompleteActions
InformationFlows
«merge»
StructuredClasses
«merge»
«merge»
Time
«merge»
Fragments
CompleteStructuredActivities
«merge»
«merge»
«metamodel»
UML4SysML
«merge»
«merge»
Profiles
«merge»
ExtraStructuredActivities
«merge»
«reference»
«merge»
ProtocolStateMachines
CompleteActivities
«modelLibrary»
StandardProfileL1
«import»
«profile»
SysML
PowerTypes
SysML Profile Retains UML Integrity
33
SysML Profile Package
«profile»
SysML
«profile»
Blocks
«profile»
Activities
«modelLibrary»
Blocks
«import»
«profile»
ConstraintBlocks
«profile»
ModelElements
«modelLibrary»
ControlValues
«import»
«profile»
Ports&Flows
«profile»
Allocations
«profile»
Requirements
Modular & Cohesive Package Structure
34
Applying SysML Profile to a User Model
pkg ModelingDomain [Establishing HSUV Model]
«profile»
SysML
«apply» {strict}
«apply»
{strict}
«import»
«modelLibrary»
SI Unit Types
HSUVModel
35
SysML Compliance
V0.9 Compliance

Issues


Criteria for basic/advanced choice unclear
Basic/Advanced approach too coarse for likely
vendor and user community





Difficult for non-UML tools to state compliance
Didn’t fit with UML tool-vendors plans for UML
implementation
Levels didn’t reflect break down of SysML language
domains
Compliance based on Concrete Syntax
Impact



Difficult to get closure on Basic/Advanced subsets
Users unable to get simple compliance statements
from SysML tool vendors
Hard to partition abstract syntax for compliance 37
Compliance Approach

Compliance Levels

Introduce compliance levels into UML4SysML


Further compliance levels for SysML Profile



Each sub-profile is separate compliance level
Asserts minimal compliance on UML4SysML level
Reuse UML definitions of compliance



Strict subsets of UML compliance levels (L1, L2, L3)
Abstract syntax
Concrete syntax
Compliance Statements
No
 Partial (requires feature support statement)
 Yes
Compliance approach allows vendor to clearly state
compliance and users to assess compliance

38
Compliance Summary Example
Compliance level
Abstract Syntax
Concrete Syntax
UML4SysML Level 1
YES
YES
UML4SysML Level 2
PARTIAL
YES
UML4SysML Level 3
NO
NO
Activities (without Probability)
YES
YES
Activities (with Probability)
NO
NO
Allocations
PARTIAL
PARTIAL
Blocks
YES
YES
Constraint Blocks
YES
YES
Model Elements (without Views) YES
YES
Model Elements (with Views)
NO
NO
Ports & Flows (w/o Item Flows)
YES
YES
Ports & Flows (with Item Flow)
NO
NO
Requirements
YES
YES
39
Feature Support Statement
Feature Support Statement
Compliance Level
Detail
Abstract
Syntax
Concrete
Syntax
Semantics
UML4SysML::Level 2
StateMachines::BehaviorStateMachines
Note (1)
YES
Note(2)
SysML::Blocks
Block
YES
Note (3)
YES
Note (1): States and state machines are limited to a single region. Shallow history pseudostates not supported
Note (2): FIFO queueing in event pool
Note (3): Don’t show Blocks::StructuredCompartment notation
40
Structural Constructs
Structural Constructs




Model Elements
Blocks
Ports and Flows
Parametrics
42
Model Elements
Model Elements


Includes fundamental modeling
constructs such as model elements,
packages, and dependencies
Used to organize model



Package diagram used to group model
elements into a name space
SysML extension for view and viewpoint
Rational stereotype can be applied to
any model element to capture decision
44
Organizing the User Model
pkg HSUVModel
HSUVUseCases
HSUVBehavior
DeliverPower
Behavior
«access»
HSUV
Requirements
HSUVStructure
HSUVAnalysis
«requirement»
Performance
HSUVInterfaces
«block»
Automotive
Domain
«access»
«access»
HSUVViews
«access»
«view»
OperationalView
«viewpoint»
Operational
Viewpoint
«view»
Performance
View
«viewpoint»
Performance
Viewpoint
Package Diagram Used to Organize the Model
45
Views and Viewpoints



Consistent with IEEE 1471
Viewpoint represents stakeholders, their
concerns/purpose/intent, and
construction rules for specifying a view
View is a read only mechanism that
captures the model subset that
addresses the stakeholder concerns


Realizes the viewpoint
Relationships between model elements
established in model and not between
views
46
IEEE 1471

IEEE 1471 (section 5.3) prescribes that a
viewpoint contains:





a) A viewpoint name
b) The stakeholders to be addressed by the
viewpoint
c) The concerns to be addressed by the
viewpoint
d) The language, modeling techniques, or
analytical methods to be used in constructing a
view based upon the viewpoint
e) The source, for a library viewpoint (the source
could include author, date, or reference to other
documents, as determined by the using
47
organization)
SST View/Viewpoint
Viewpoint as a stereotyped class
Functional Viewpoint
«viewpoint»
stakeholders="..."
purpose="..."
construction rules="..."
«view»
Security View
Relationship between Viewpoints
«viewpoint»
Security Viewpoint
View realizes a viewpoint
48
Performance View Example
pkg [package] HSUVViews [Performance View]
«view»
PerformanceView
Performance Viewpoint
Drive Car
Driver
«moe»
HSUValt1.Fuel
Economy
«moe»
HSUValt1.Quar
terMileTime
<<requirement>>
Performance
id = 2
Text = The Hybrid SUV
shall have the braking,
acceleration, and off-road
capability of a typical SUV,
but have dramatically better
fuel economy.
«viewpoint»
Functional Viewpoint
«constraint»
UnitCostEquation
«moe»
HSUValt1.Zero
60Time
«constraint»
CapacityEquation
«moe»
HSUValt1.Car
goCapacity
«constraint»
EconomyEquation
«moe»
HSUValt1.Cos
tEffectiveness
«viewpoint»
stakeholders="customer"
purpose="Highlight the performance of the
system."
construction rules="show performance
requirements, test cases, MOE, constraint
models, etc.; includes functional viewpoint"
«testCase»
EPAFuel
EconomyTest
49
Rationale
«requirement»
Power
«deriveReqt»
«requirement»
PowerSourceManagement
«rationale»
Power delivery must happen by coordinated
control of gas and electric motors.
reference= “Hybrid Design Guidance”
Rationale can link to a
trade study or analysis report
Rationale can be attached to any Model Element or
Relationship to Capture decisions
50
Blocks
Blocks Highlights






Unification of classes and assemblies
Property subclasses
Deep nesting
Design values
Specification of value types with units,
dimensions, and probabilities
Instance diagrams
Resolution of Blocks Issues Resulted in Solid
Structural Foundation for SST Submission
52
Blocks Unify Class & Assembly from v0.9

Blocks provides a unifying concept to describe
the structure of an element




Based on UML class from UML Composite Structures
Block definition diagram describes the
relationship among blocks (e.g. composition,
association, classification, ..)
Internal block diagram describes the internal
structure of a block in terms of its properties
and connectors
Behavior can be allocated to blocks
53
Power Subsystem Breakdown
bdd [block] HSUV [PowerSubsystem Breakdown]
«block»
WheelHubAssembly
«block»
PowerSubsystem
lfw
«block»
BrakePedal
«block»
accelerator
«block»
BatteryPack
«block»
FuelTankAssembly
«block»
PowerControlUnit
«block»
InternalCombustionEngine
«block»
ElectricalPowerController
«block»
ElectricMotor
Generator
rfw
«block»
FrontWheel
«block»
Differential
4
«block»
FuelPump
«block»
FuelInjector
«block»
Transmission
Block Definition Diagram Used to Specify System
Hierarchy and Classification
54
Power Subsystem IBD
Part
ibd [block] PowerSubsystem [Alternative 1 - Combined Motor Generator]
epc:ElectricalPower
<>
Controller
ctrl
bp:BatteryPack
<>
i2:Electric
Current
i1:Electric
Current
emg:ElectricMotor
Generator
<>
Enclosing
Block
<>
I_TRSMData
I_IEPCData
I_EPCCmd
torquein:Torque
c2
rightHalfShaft
I_TRSMData
g1:Torque
torqueOut:Torque
<>
t1:Torque
epc trsm
ecu:PowerControlUnit
ice
rfw:ChassisSubsytem
.FrontWheel
spline
<>
ctrl
trsm:Transmission
c3
t2:Torque
I_TRSMCmd
<>
I_IEPCData I_IEPCCmd
acl:accelerator
<>
I_TRSMCmd
dif:Differential
ice:InternalCombustionEngine
I_ICEData
ctrl
c1
4
fi:FuelInjector
fdist
<>
Connector
bp:BrakeSubsystem
.BrakePedal
Port:ICEFuelFitting
ft:FuelTankAssy
Port:FuelTankFitting
fp:FuelPump
<>
fuelSupply:Fuel
leftHalfShaft
I_ICECmds
<>
I_ICEData
<>
I_ICECmds
lfw:ChassisSubsytem
.FrontWheel
fuelDelivery
fuelReturn:Fuel
Internal Block Diagram Used to Specify Interconnection
Among Parts in Context of Enclosing Block
55
Property Subclasses

Property is a structural feature of a block which
is further sub-classed in SysML

Part property aka. part (typed by a block)



Value property (typed by value type)



Usage of a block in the context of the enclosing block
Example - right-front:wheel
Defines a value with units, dimensions, and probability
distribution
Example - tirePressure:psi {distribution=Uniform
(min=27,max=29)}
Reference property (typed by a block)


A part that is not owned by the enclosing block
Example - logical interface between 2 parts
56
Simple Example of Deep Nesting
Connecting a Tire to a Road
No need for modeler to
specify intermediate
connections
env : Environment
ibd block Automotive Domain
vehicle : HSUV
2
front : Tire
road : Road
2
rear : Tire
Deep Nesting Provides Intuitive Modeling of
Physical Systems and does not Impose Process
57
Design Values Example
bdd Car Design
Car
1
2
1
front 2
back
Wheel
tyrePressure : psi
SUV
ibd SUV
«part»
back : [Wheel]
2
[] Indicates part-specific
block
Properties
tyrePressure : psi {distribution=Uniform (min=27,max=29)}
«part»
front : [Wheel]
2
Supports different values &
distributions for each part
Properties
tyrePressure : psi {distribution=Uniform (min=25,max=27)}
Design Values Ease Ability to Specify Different
Values/Distributions on Parts in Same Context
58
Units and Dimensions
ins [package] SI Units
«metaclass»
DataType
«block»
second:Unit
value
dimension
InstanceSpecification
0..1
«stereotype»
ValueType
*
«block»
time:Dimension
{ instance of Dimension from Units model library}
bdd [package] SI Unit Types
*
unit
InstanceSpecification
0..1
{ instance of Unit from Units model library}
s
«value»
Real
«value»
unit=second
dimension=time
«modelLibrary»
Blocks
«block»
Unit
«value»
Real
dimension
0..*
0..1
«block»
Dimension
bdd [package] Objects
Obj
«value»
Complex
realPart: Real
imaginaryPart: Real
values
t1:s
t2:s
Units Tied Explicitly to Dimensions
59
Units Model Library
pkg SEToolkit
«import»
«modelLibrary»
SI Units
«modelLibrary»
Units
z
«import»
«modelLibrary»
SI Unit Types
Volume
Density
Length
«valueType»
dimension = VolumeDim
«valueType»
dimension = DensityDim
«valueType»
dimension = LengthDim
«modelLibrary»
Physical
«block»
PhysicalObject
«import»
SIVolume
«valueType»
unit= M3
SIDensity
«valueType»
unit = KgPerM3
SILength
«valueType»
unit = M
density: SIDensity
volume: SIVolume
supplier: String
modelNumber: String
serialNumber: String
lotNumber: String
Model Library Can be Expanded
to Address Domain Needs
60
SST Instance Diagram


Instances are a fundamental aspect of UML
classes which is the foundation for blocks
Instances provide a means for uniquely
identifying a member of a “class” (block)




System configuration with unique serial number/id
Specific examples with unique values
Specific items under test with test results (e.g.
failed item for causal analysis)
….
61
Test Result Instance
ins SUV_EPA_Fuel_Economy_Test_Result
Satisfies
«requirment»Emissions
TestVehicle1/hsuv:HSUV
b12345/
b:BodySubsystem
c34567/
c:Chassis
Subsytem
bk45678/
bk:Brake
Subsystem
i23456/
int:Interior
Subsystem
lt56789/
lt:Lighting
bSubsystem
Verifies
«requirment»Emissions
«testCase»
testRun060401/
epaTest:EPAFuel
EconomyTest
p67890/p:PowerSubsystem
eid78901/
ice:InternalComb
ustionEngine
sn89012/
t:transmission
sn90123/
emg:ElectricalMot
orGenerator
VIN = G12345
Example Use of Instance Diagram for Specifying
a Unique System Test Configuration and Values
62
Ports and Flows Issues
Ports

V0.9 Issue



Did not have ability to specify what can
flow in or out of a block (I/O)
Did not include UML port capability
Impact

Could not specify what flows in or out of a
block independent of its usage


e.g. fluid can flow in or out of a tank
Did not meet needs of service oriented
designs and integration with software
64
Ports Approach



Ports represent block interaction points via which Blocks provide
or consume data/material/energy or services
Support specification of interfaces on a block independent of a
specific usage (e.g. this component requires 110 volts of power
input)
Approach is to specialize two port types

Flow ports




Port type specifies what can flow in our out of block/part
A connection point through which there is a flow of information,
material, or energy (I/O)
Typically asynchronous flow where producer is not aware when/who
consumes the flow
Client server ports




Service oriented (request-reply) peer2peer interaction
Typically synchronous communication
Specified similar to UML2.0 ports using required/provided interfaces
detailing the set of provided/required services
Allow signal exchanges for compatibility
2 Distinct Port Types that Support
Different Interface Concepts
65
FlowPorts

Additional considerations




Simple (natural) way for SEs to specify I/O via the port
Address the common case of atomic FlowPorts
Allow both signal flow and data/block instance flow
FlowPorts Specification


I/O is specified using an interface stereotyped FlowSpecification
FlowSpecification consists of properties stereotyped FlowProperties




Atomic FlowPorts




FlowProperty has a direction attribute: in, out, inOut
FlowProperties can be typed by ValueTypes, Block, and Signals
isConjugate promotes reuse of flowSpecifications
It is common that a FlowPort flows a single item type
In this case the port is directly typed by the item type (Block or Value)
Direction property specify the direction
Compatibility rules on ports facilitate interface compatibility
66
Item Flows Approach



Distinct from what can flow via the port specification
Supports compact and intuitive modeling of physical
flows
Supports top down description of flows without
imposing behavioral method (e.g. activities, state,
interactions)



Is aligned with behavior thru refinement and allocation
Facilitates flow allocations from an object node,
message, or signal from a behavioral diagram
Properties of item flow can be specified and
constrained in parametric diagram
Item Flow Representation is Classical SE Modeling
Paradigm to Represent What Flows in a Particular Context
67
Power Subsystem IBD
<>
i1:Electric
Current
<>
Flow port
I_IEPCData I_IEPCCmd
I_TRSMCmd
acl:accelerator
ctrl
trsm:Transmission
c3
<>
I_TRSMData
I_IEPCData
I_EPCCmd
torquein:Torque
c2
rightHalfShaft
I_TRSMData
g1:Torque
torqueOut:Torque
<>
t1:Torque
epc trsm
ecu:PowerControlUnit
ice
rfw:ChassisSubsytem
.FrontWheel
spline
<>
i2:Electric
Current
emg:ElectricMotor
Generator
t2:Torque
epc:ElectricalPower
<>
Controller
ctrl
bp:BatteryPack
Item flow
<>
ibd [block] PowerSubsystem [Alternative 1 - Combined Motor Generator]
<>
I_TRSMCmd
dif:Differential
ice:InternalCombustionEngine
I_ICEData
<>
I_ICEData
ctrl
c1
4
fi:FuelInjector
Connector
I_ICECmds
fdist
Client server port
<>
bp:BrakeSubsystem
.BrakePedal
Port:ICEFuelFitting
ft:FuelTankAssy
Port:FuelTankFitting
fp:FuelPump
leftHalfShaft
<>
fuelSupply:Fuel
<>
I_ICECmds
lfw:ChassisSubsytem
.FrontWheel
fuelDelivery
fuelReturn:Fuel
Specifying Interfaces on an IBD
in Terms of Connectors, Ports and Flows
68
Parametrics &
MOE’s/Objective Functions
Parametrics

Used to express constraints (equations) between value properties




Constraint block defined as a simple extension of block





Provides support to engineering analysis (e.g. performance, reliability, etc)
Reusable (e.g. F=m*a is reused in many contexts)
Non-causal (i.e. declarative statement of the invariant without specifying
dependent/independent variables)
Packages UML constraint so they are reusable and parameterized
Constraint and constraint parameters are specified
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)


Can use nested notation or dot notation
MOE’s and objective functions integrated with Parametrics to support
trade studies and engineering analysis
Parametrics Scalability & Integration with Engr
Analysis Validated by Georgia Tech
70
Defining Vehicle Dynamics
bdd [package] HSUVAnalysis [Definition of Dynamics]
«constraint»
StraightLine
VehicleDynamics
parameters
whlpowr:Real
Cd:Real
Cf:Real
tw:Real
acc:Real
vel:Real
incline:Real
«constraint»
PowerEquation
Constraints
{tp(hp) = whlpowr - (Cd*v)
- (Cf*tw*v)}}
parameters
whlpowr:Real
Cd:Real
Cf:Real
tw:Real
tp:Real
v:Real
i:Real
«constraint»
PositionEquation
Constraints
{x(n+1)=x(n)+dx(dt)=x(n)+v*dt}
{x(n+1)=x(n)+v*5280/3600*dt}
«constraint»
VelocityEquation
Constraints
{v(n+1)=v(n)+dv = v(n) + a*dt}
{v(n+1 =v(n)+a*32*3600/5280*dt}
parameters
dt:Real
v:Real
x:Real
parameters
dt:Real
v:Real
a:Real
«constraint»
AccelerationEquation
Constraints
{a(g) = F/m = P*t/m = (550/
32)*tp(hp)*delta-t*twi}
parameters
tw:Real
dt:Real
tp:Real
a:Real
Defining Reusable Equations for Parametrics
71
Evaluating Vehicle Dynamics
par [constraintBlock] StraightLineVehicleDynamics
tw
Cf
Cd
whlpwr
whlpwr
Cd
Cf
tw
tw
tp
incline
PowerEquation
i
tp
Accelleration
Equation
dt
acc
a
v
a
dt
VelocityEquation
«value»
globalTime.delta-t
vel
v
v
dt
PostionEquation
x
«value»
HSUV.position
Using the Equations in a Parametric Diagram to
Constrain the Value Properties
72
Evaluating Measures of Effectiveness
par [constraintBlock] MeasuresOfEffectiveness [HSUV MOEs]
f:
:EconomyEquation
Instance of
constraint block is
identical for each
alternative
«moe»
HSUValt1.FuelEconomy
p1:
q:
:MaxAcceleration
Analysis
«moe»
HSUValt1.QuarterMileTime
p3:
«objectiveFunction»
:MyObjectiveFunction
{CE = ∑ Wi*Pi}
CE:
«moe»
HSUValt1.CostEffectiveness
z:
«moe»
HSUValt1.Zero60Time
vc:
:CapacityEquation
uc:
:UnitCostEquation
p2:
p4:
p5:
«moe»
HSUValt1.CargoCapacity
«moe»
HSUValt1.UnitCost
MOE’s and objective function provide flexible support for
trade study analysis that is fully integrated with parametrics
73
Constraint Blocks - Comparison of Blockbased vs. Collaboration-based approach

Concrete Syntax


Abstract Syntax




More notational changes to default collaboration notation
required to support chosen Constraint Block notation
Additional abstract syntax required for deep-nested bindings
Need to relax UML Collaboration constraints in order to
support deep-nested bindings
CollaborationUse does not support inheritance or redefinition
Semantics

Constraint Blocks can denote objects to represent equations
with state


Collaboration Use cannot be a defining feature of a slot, so
cannot build instance specification hierarchy for blocks with
constraints
Connectors can specify multiplicities on bindings to multivalued parameters or properties
Blocks Based Approach Retains Structural Integrity
and Simplifies Language
74
Behavioral Constructs
Behavioral Constructs




Activities
Interactions
State Machines
Use Cases
76
Activities
Activities

Activities used to specify flow of I/O and
control

Input/Output represented by object node/pins that
are typed by blocks


Control flow represent enabling of activity


External I/O called a parameter
Control constructs include decision, merge, fork, join,
initial node, activity final, flow final
SysML extensions to Activities

Alignment of activities with EFFBD

Non normative appendix specifies specific execution rules
for EFFBD support


Does not explicitly support replication and resources
Support for continuous flow modeling
78
SysML EFFBD Profile
Refer to Appendix C.1 for Details & Execution Rules
«effbd»
act
2.4 Function in
Multi-exit
Construct
{cc#1}
Item 1
2.2 Multi-exit
Function
«optional»
{cc#2}
[ before third time ]
Item 2
External
Input
2.1 Serial
Function
«optional»
2.5 Function in
an Iterate
External
Output
[ after
third
time ]
Item 3
«optional»
2.6 Output
Function
2.3 Function in
Concurrency
«optional»
Item 4
Aligning SysML with Proven Systems Engineering Techniques
79
Distiller Example Provided by D. Oliver
Dirty water
@ 20 deg C
Heat Dirty water
To 100 deg C
Dirty water
@ 100 deg C
Steam
Pure
water
Condense
steam
Boil Dirty water
Residue
Heat to Dirty
water
Energy to
condense
Heat to Boil
water
and
and
Drain
Residue
Disposed
residue
80
Distill Water Activity Diagram (Initial)
«effbd»
act [activity] DistillWater [Simple Starting Point)
coldDirty:H2O
[liquid]
Note: these are
the same thing!
steam:H2O
[gas]
hotDirty:H2O
[liquid]
recovered:Heat
pure:H2O
[liquid]
a3:CondenseSteam
a1:HeatWater
a2:BoilWater
a4:DrainResidue
recovered:Heat
external:Heat
hiPress:Residue
loPress:Residue
Representing Distiller Example in SysML
Using EFFBD Profile
81
Distill Water Activity Diagram
(Continuous Flow Modeling)
act [activity] DistillWater [Parallell Continuous Activities)
loPress:Residue
«continuous»
coldDirty:H2O
[liquid]
«continuous»
steam:H2O
[gas]
hiPress:Residue
«continuous»
recovered:Heat
a4:DrainResidue
a1:HeatWater
a3:CondenseSteam
«continuous»
hotDirty:H2O
[liquid]
a2:BoilWater
«continuous»
external:Heat
Representing Distiller Example in SysML
Using Continuous Flow Modeling
«continuous»
pure:H2O
[liquid]
82
Interactions
Interactions

Sequence diagrams provide representations for
message based behavior

Represents flow of control




Less effective than activities for representing inputs from
multiple sources
UML 2 sequence diagrams significantly more scalable
by providing reference sequences, control logic, and
lifeline decomposition
Timing diagrams provide representations for
typical system timelines and value properties vs
time
No change to UML

Minor clarification on continuous time
representations
84
Black Box Interaction (Drive)
sd DriveBlackBox
driver:Driver
ref
hybridSUV:HybridSUV
StartVehicleBlackBox
par
alt controlSpeed
ref
[self.oclInState(idle)]
Idle
[self.oclInState(accelerating/cruising)]
ref
Accelerate/Cruise
[self.oclInState(braking)]
ref
ref
ref
Brake
Steer
Park/ShutdownVehicle
UML 2 Sequence Diagram More Scalable
by Supporting Control Logic and Reference Sequences
85
Black Box Sequence (StartVehicle)
sd StartVehicleBlackBox
hybridSUV:HybridSUV
ref StartVehicleWhiteBox
driver:Driver
turnIgnitionToStart
1: StartVehicle()
References Lifeline Decomp
For White Box Interaction
Simple Black Box Interaction
86
White Box Sequence (StartVehicle)
sd StartVehicleWhiteBox
ecu:PowerControlUnit
epc:ElectricalPowerController
1: StartVehicle
1.1: Enable
1.2:ready
Decomposition of Black Box
Into White Box Interaction
87
Trial Result of Vehicle Dynamics
tim MaxAcceleration [100 Wheel Horsepower]
Satisfies
«requirement»Acceleration
0.5
0.45
Accelleration (g)
0.4
0.35
«diagramDescription»
version=”0.1"
description=”Constant
100 wheel horsepower,
4000 lb vehicle weight,
simple drag"
reference=”Equations of
Motion”
completeness=”assumes
perfect tire traction”
0.3
0.25
0.2
0.15
0.1
0.05
0
0
5
10
15
20
Time (sec)
140
Velocity (mph)
120
100
80
60
40
20
0
0
5
10
15
20
15
20
Lifeline are
value properties
Time (sec)
1800
1600
Distance (ft)
1400
1200
1000
800
600
400
200
0
0
5
10
Time (sec)
Typical Example of a Timing Diagram
88
State Machines
State Machines

Supports event based behavior (generally
asynchronous)




Transition with event, guard, action
State with entry, exit and do-activity
Can include nested sequential or concurrent states
Two types of state machines


Behavior state machines is typical use
Protocol state machines used to specify sequence of
operations or signals


Can be used as a specification on a port
No change to UML
90
Operational States (Drive)
stm HSUVOperationalStates
Off
start
keyOff
Refines
«requirement»
PowerSource
Management
shutOff
Nominal
states only
Operate
Idle
stopped
accelerate
releaseBrake
Accellerating/
Cruising
Braking
engageBrake
Abnomal state
(accelerator
sticks) - abort
symbol
91
Use Cases
Use Cases



Provides means for describing basic
functionality in terms of usages of
system by actors
Generally elaborated via other
behavioral representations to describe
detailed scenarios
No change to UML
93
Top Level Use Cases
uc HSUVUseCases [TopLevelUseCases]
HybridSUV
Operate the
vehicle
Driver
Insure the
vehicle
InsuranceCompany
Registered
Owner
Register the
vehicle
Department
Of Motor
Vehicles
Maintain the
vehicle
Maintainer
94
Operational Use Cases
uc HSUVUseCases [Operational Use Cases]
HybridSUV
Start the vehicle
«extend»
Drive the vehicle
Driver
«include»
Accelerate
«include»
«include»
Park
«include»
Steer
Brake
95
Cross-cutting Constructs
Cross-cutting Constructs



Allocations
Requirements
Profiles & Model Libraries
97
Allocations
Allocations


Provides general relationship to map one
model element to another
Includes specific subclasses of allocation with
constraints on their usage





Behavioral
Structural
Flow
Explicit allocation of activities to swim lanes
(e.g. activity partitions)
Graphical and/or tabular representations
99
Different Allocation Representations
(Tabular Representation Not Shown)
to
Element
Name1
Element
Name2
«allocate»
:ElementName
«allocate»
ActivityName
from
to
Element
Name3
Allocate Relationship
Explicit Allocation of
Activity to Swim Lane
«block»
BlockName
«block»
BlockName
PartName
allocatedFrom
«elementType»ElementName
PartName
Compartment Notation
Callout Notation
allocatedFrom
«elementType»ElementName
100
Requirements
Requirements

Requirements represents a text based requirement


Minimal properties specified for id and text based on user
feedback
Stereotype mechanism used to categorize requirements (e.g.
functional, physical)



Stereotype of class (abstract) without instances
Requirements containment used to specify
requirements hierarchy as a collection of requirements
(e.g., a specification)


Able to specify constraints on what design elements can satisfy
the requirement (refer to Appendix C.2)
SST uses cross hairs notation vs black diamond composition to be
consistent with containment semantics
Requirements relationships based on subclasses of
dependency

Derive, Satisfy, Verify, Refine, ..
102
Dependencies

Used to specify relationships among
requirements (other uses as well)

Different concept for SE’s with arrow direction
reversed from typical requirements flow-down


Refer to next slide
Represents a relationship between client and
supplier elements

Client depends on supplier


A change in supplier results in a change in client
Application to requirements: A change in requirement
(supplier) results in a change in design element that
satisfies it (client) or requirement derived from it (client)
Dependency Relationship Is New Concept for Some SE’s
103
Example of Derive/Satisfy Requirement
Dependencies
«requirement»
OffRoadCapability
«requirement»
Accelleration
«requirement»
CargoCapacity
Supplier
«deriveReqt»
«deriveReqt»
«deriveReqt»
Client
«requirement»
Power
Supplier
«satisfy»
Client
«block»
PowerSubsystem
Arrow Direction Opposite Typical Requirements Flow-Down
104
Requirements & Allocations Alignment

V0.9 Issue

Inconsistent concrete syntax for cross-cutting
relationships


Limitations in displaying requirement relationships



Allocations used compartments/callouts, requirements did
not
Requirements needed to be shown on same diagram as
target of relationship –> cluttered diagrams
Requirements couldn’t be shown on internal block
diagrams.
Basis for cross-cutting relationships seemed
inconsistent, and needed to be unified


Requirements relationships were built on Trace
Allocation relationship was built on Usage
105
Representing Requirements and Allocation
Relationships
act ProvidePower [with Swimlane Allocation]
«allocate»
ElectricalPowerContr
oller
«allocate»
ElectricalMotorGener
ator
a3:Control
ElectricPower
a4:Provide
ElectricPower
«continuous»
eThrottle
«continuous»
driveCurrent
ibd [block] PowerSubsystem [Power Functional Allocation]
«continuous»
elecDrivePower
allocatedFrom
«objectNode»driveCurrent
epc:ElectricalPower
Controller
allocatedFrom
«activity»Control
ElectricPower
<>
<>
i2:Electric
Current
i1:Electric
Current
emg:ElectricalMotor
Generator
allocatedFrom
«activity»Convert
ElectricToPower
Satisfies
«requirement»Acceleration
allocatedTo
«itemFlow»i1:ElectricCurrent
Requirements callout notation
Allocations callout notation
Consistent and Compact Crosscutting Notations
106
Profiles & Model Libraries
Stereotypes & Model Libraries


Mechanisms for further customizing SysML
Profiles

Use of stereotype to extend meta-classes with
properties and constraints




Stereotype properties capture metadata about the model
element that is not instantiated
Profile is applied to user model
Profile can also restrict the subset of the model
that is applied
Model Libraries represent reusable libraries of
model elements
108
Stereotypes
«metaclass»
NamedElement
«configurationItem»
Engine
«stereotype»
ConfigurationItem
author=”John Doe”
version=”1.2"
lastChanged=Dec12, 2005
author: String
version: String
lastChanged: Date
Defining the Stereotype
Applying the Stereotype
109
Appendixes
Appendixes







Diagrams
Sample Problem
Non-Normative Extensions
Model Interchange
Requirements Traceability
Terms and Definitions
BNF Diagram Syntax Definitions
111
Appendix A
Diagrams
Diagram Appendix A

Provides general guidelines for the use
of diagrams

Diagram headings


Diagram descriptions


Capturing information about diagrams
Diagram usages


Naming of diagrams
Specifying unique diagram kinds
Other general guidelines (e.g. tabular
representations, use of rake symbol, ..)
113
Application of Diagram Guidelines
Example
A Diagram Description
(refer to App A)
Diagram Heading Names
(refer to App A)
bdd [package] DistillerStructure [Structural Breakdown]
«block»
Distiller
hx
«block»
HeatExchanger
bx
«block»
Boiler
«diagramDescription»
version=”0.1"
description=”initial structural
breakdown of distiller
system"
reference=”TBD”
completeness=”ItemFlows
and Connectors elided”
dv
«block»
DrainValve
114
Appendix B
Sample Problem
Sample Problem Appendix B


Highlights selected features of SysML
using a Hybrid SUV example
Refer to sample problem in later slides
116
Appendix C
Non-Normative Extensions
Non-Normative Extensions Appendix C

Provides set of non-normative
extensions that may become normative
in future revisions



EFFBD profile
Requirements categories
Measures of effectiveness (moe) and
objective function
118
Appendix D
Model Interchange
Model Interchange Appendix D

SysML Model Interchange Standards



XMI
AP233
XMI is the means for model exchange between SysML
conformant tools

SysML Profile metamodel defined in XMI 2.1


To be provided when XMI issues are sufficiently resolved in ballot 12
(TBD)
Model interchange with non-MOF/UML tools supported
using ISO-10303 AP233


Both file and API-based SysML-AP233 interchange approaches are
supported based on alignment with similar concepts in AP233
Provides gateway to model repositories that are based on schema
in use by



other engineering disciplines (e.g, mechanical - MCAD)
user domains (e.g, DoD architectures – DoDAF/CADM)
Supports INCOSE’s vision for model driven systems engineering
120
Appendix E
Requirements Traceability Matrix
Requirements Traceability Appendix E



Provides traceability from SysML to requirements in
UML for SE RFP
Section 6.2.1, of the RFP states "Submitters may
provide partial responses to these requirements, along
with a roadmap to address the complete requirements."
Most requirements satisfied in v0.9


Matrix updated to be consistent with SST v0.98
Small number of mandatory requirements in 6.5
deferred to v2.0



Modeling of verification (6.5.4.4) limited to “test case”. Initial
analysis showed “test case” is key element to integrate with
UML testing profile
Modeling of “Problem” (6.5.5) deferred to address causal
analysis
Modeling of “replication” and “resources” under function
(6.5.2.1.3) not fully implemented per EFFBD semantics
122
Appendix F
Terms and Definitions
Terms & Definitions Appendix F

Consists of a superset of terms from





UML for SE RFP
UML 2
SysML v0.9
SysML v0.98
Will provide distilled list to support tool
vendor implementation and user glossary



Reuse terms & definitions as-is
Refine others to be consistent with chapters
Delete others
124
Appendix G
BNF Diagram Syntax Definitions
BNF Diagram Syntax Definitions App G


A formalism provided by Deere & Company
(R. Burkhart) to support a more precise
mapping between the language abstract
syntax / semantics and the concrete syntax
(notation)
Initial input provided for Model Elements,
Blocks, and Constraint Blocks chapters


Provided valuable mechanism to define more
complete diagram syntax tables
Will be considered for broader application in
future revisions
126
HSUV Sample Problem
SST Appendix B
Sample Problem Examples

The following examples are extracted from
Appendix B of the SST Specification


Highlights selected features of SysML
Modeling artifacts from typical SE process




Slide ordering does not represent process sequence
Visio used as a vendor neutral format
Refer to Appendix B for a more complete
description of the sample problem
Contact the vendor reps on SST to see their
SysML implementations and sample problem
demo
128
Sample Problem Coverage






Organizing the model
Requirements
Behavior
Structure
Allocating behavior to structure
Analyzing performance & MOE’s
129
Setting up the User Model
pkg ModelingDomain [Establishing HSUV Model]
«profile»
SysML
«apply» {strict}
«apply»
{strict}
«import»
«modelLibrary»
SI Unit Types
HSUVModel
130
Organizing the User Model
pkg HSUVModel
HSUVUseCases
HSUVBehavior
DeliverPower
Behavior
«access»
HSUV
Requirements
HSUVStructure
HSUVAnalysis
«requirement»
Performance
HSUVInterfaces
«block»
Automotive
Domain
«access»
«access»
HSUVViews
«access»
«view»
OperationalView
«viewpoint»
Operational
Viewpoint
«view»
Performance
View
«viewpoint»
Performance
Viewpoint
131
Setting the Context
«Context Diagram»
ibd [block] AutomotiveDomain
«external»
driver:Driver
«system»
hybridSUV:HybridSUV
«external»
:Maintainer
«external»
:Environment
«external»
:Weather
«external»
:Passenger
«external»
:ExternalObject
«external»
:VehicleCargo
«external»
:Road
«diagramDescription»
version=”0.1"
description=”Initial concept to identify top level
domain entities"
reference=”Ops Concept Description”
completeness=”partial. Does not include gas
pump and other external interfaces.”
132
Top Level Use Cases
uc HSUVUseCases [TopLevelUseCases]
HybridSUV
Operate the
vehicle
Driver
Insure the
vehicle
InsuranceCompany
Registered
Owner
Register the
vehicle
Department
Of Motor
Vehicles
Maintain the
vehicle
Maintainer
133
Operational Use Cases
uc HSUVUseCases [Operational Use Cases]
HybridSUV
Start the vehicle
«extend»
Drive the vehicle
Driver
«include»
Accelerate
«include»
«include»
Park
«include»
Steer
Brake
134
Black Box Interaction (Drive)
sd DriveBlackBox
driver:Driver
ref
hybridSUV:HybridSUV
StartVehicleBlackBox
par
alt controlSpeed
ref
[self.oclInState(idle)]
Idle
[self.oclInState(accelerating/cruising)]
ref
Accelerate/Cruise
[self.oclInState(braking)]
ref
ref
ref
Brake
Steer
Park/ShutdownVehicle
135
Operational States (Drive)
stm HSUVOperationalStates
Off
start
keyOff
Refines
«requirement»
PowerSource
Management
shutOff
Nominal
states only
Operate
Idle
stopped
accelerate
releaseBrake
Accellerating/
Cruising
Braking
engageBrake
Abnomal state
(accelerator
sticks) - abort
symbol
136
Black Box Sequence (StartVehicle)
sd StartVehicleBlackBox
hybridSUV:HybridSUV
ref StartVehicleWhiteBox
driver:Driver
turnIgnitionToStart
1: StartVehicle()
137
White Box Sequence (StartVehicle)
sd StartVehicleWhiteBox
ecu:PowerControlUnit
epc:ElectricalPowerController
1: StartVehicle
1.1: Enable
1.2:ready
138
Requirements Breakdown
req [package] HSUVRequirements [HSUV Specification]
HSUVSpecification
«requirement»
Eco-Friendliness
«requirement»
Braking
«requirement»
Performance
«requirement»
FuelEconomy
«requirement»
Emissions
«requirement»
Ergonomics
«requirement»
OffRoadCapability
«requirement»
Accelleration
«requirement»
Qualification
«requirement»
SafetyTest
«requirement»
Capacity
«requirement»
CargoCapacity
«requirement»
PassengerCapacity
«requirement»
FuelCapacity
Id = R1.2.1
text = The vehicle shall meet Ultra-Low
Emissions Vehicle standards.
139
Requirements Derivation
req [package] HSUVRequirements [Requirement Derivation]
«requirement»
Braking
«requirement»
FuelCapacity
«requirement»
FuelEconomy
«deriveReqt» «deriveReqt»
«requirement»
OffRoadCapability
«requirement»
CargoCapacity
«deriveReqt»
«deriveReqt»
«deriveReqt»
«requirement»
RegenerativeBraking
«requirement»
Accelleration
«deriveReqt»
«deriveReqt»
«deriveReqt»
«requirement»
Range
«requirement»
Power
RefinedBy
HSUVStructure::HSUV.
HSUVOperationalStates
«deriveReqt»
«requirement»
PowerSourceManagement
«rationale»
Power delivery must happen by coordinated
control of gas and electric motors.
reference= “Hybrid Design Guidance”
140
Reqts Refinement/Verification
req [package] HSUVRequirements [Acceleration Requirement Refinement and Verification]
«requirement»
Acceleration
«refineReqt»
«deriveReqt»
«verify»
HSUVUseCases:
:Accelerate
«requirement»
Power
«testCase»
Max Acceleration
«satisfy»
«block»
PowerSubsystem
141
Requirements Tables & Trees
table [requirement] Capacity [Decomposition of Capacity Requirement]
id
name
4
4.1
4.2
4.3
text
The Hybrid SUV shall carry 5 adult passengers, along with
Capacity
sufficient luggage and fuel for a typical weekend campout.
The Hybrid SUV shall carry sufficient luggage for 5 people
CargoCapacity
for a typical weekend campout.
The Hybrid SUV shall carry sufficient fuel for a typical
FuelCapacity
weekend campout.
PassengerCapacity The Hybrid SUV shall carry 5 adult passengers.
table [requirement] Performance [Decomposition of Performance Requirement]
id
name
2 Performance
2.1 Braking
2.2 FuelEconomy
2.3 OffRoadCapability
2.4 Acceleration
text
The Hybrid SUV shall have the braking, acceleration, and offroad capability of a typical SUV, but have dramatically better
fuel economy.
The Hybrid SUV shall have the braking capability of a typical
SUV.
The Hybrid SUV shall have dramatically better fuel economy
than a typical SUV.
The Hybrid SUV shall have the off-road capability of a
typical SUV.
The Hybrid SUV shall have the acceleration of a typical
SUV.
table [requirement] Performance [Tree of Performance Requirements]
id
2.1
2.2
2.2
4.2
2.3
2.4
4.1
name
Braking
FuelEconomy
FuelEconomy
FuelCapacity
OffRoadCapability
Acceleration
CargoCapacity
relation
deriveReqt
deriveReqt
deriveReqt
deriveReqt
deriveReqt
deriveReqt
deriveReqt
id
d.1
d.1
d.2
d.2
d.4
d.4
d.4
name
RegenerativeBraking
RegenerativeBraking
Range
Range
Power
Power
Power
relation
id
deriveReqt d.2
deriveReqt d.2
deriveReqt d.2
name
PowerSourceManagement
PowerSourceManagement
PowerSourceManagement
142
Context/Enterprise Breakdown
bdd [package] HSUVStructure [Automotive Domain Breakdown]
«domain, block»
AutomotiveDomain
interactions
StartVehicleBlackBox
StartVehicleWhiteBox
driver
hybridSUV
«system, block»
HybridSUV
«external»
Driver
«external»
Maintainer
«external»
VehicleCargo
«external»
Environment
«external»
Passenger
«external»
Weather
«external»
ExternalObject
«external»
Road
143
System Breakdown
bdd [block] AutomotiveDomain [HybridSUV Breakdown]
«system, block»
HybridSUV
«block»
PowerSubsystem
«block»
BrakeSubsystem
«block»
BodySubsystem
«block»
InteriorSubsystem
«block»
LightingSubsystem
«block»
ChassisSubsytem
4
«block»
BrakePedal
«block»
WheelHubAssembly
144
System Internal Block Diagram
ibd [block] HybridSUV
ChassisSubsytem
BodySubsystem
InteriorSubsystem
BrakeSubsystem
LightingSubsystem
PowerSubsystem
145
Power Subsystem Breakdown
bdd [block] HSUV [PowerSubsystem Breakdown]
«block»
WheelHubAssembly
«block»
PowerSubsystem
lfw
«block»
BrakePedal
«block»
accelerator
«block»
BatteryPack
«block»
FuelTankAssembly
«block»
PowerControlUnit
«block»
InternalCombustionEngine
«block»
ElectricalPowerController
«block»
ElectricMotor
Generator
rfw
«block»
FrontWheel
«block»
Differential
4
«block»
FuelPump
«block»
FuelInjector
«block»
Transmission
146
Power Subsystem IBD
ibd [block] PowerSubsystem [Alternative 1 - Combined Motor Generator]
epc:ElectricalPower
<>
Controller
ctrl
bp:BatteryPack
<>
i1:Electric
Current
<>
i2:Electric
Current
emg:ElectricMotor
Generator
<>
I_TRSMData
I_IEPCData
I_EPCCmd
torquein:Torque
c2
rightHalfShaft
I_TRSMData
g1:Torque
torqueOut:Torque
<>
t1:Torque
epc trsm
ecu:PowerControlUnit
ice
rfw:ChassisSubsytem
.FrontWheel
spline
<>
ctrl
trsm:Transmission
c3
t2:Torque
I_TRSMCmd
<>
I_IEPCData I_IEPCCmd
acl:accelerator
<>
I_TRSMCmd
dif:Differential
ice:InternalCombustionEngine
I_ICEData
<>
I_ICEData
ctrl
c1
4
fi:FuelInjector
I_ICECmds
bp:BrakeSubsystem
.BrakePedal
<>
fdist
Port:ICEFuelFitting
ft:FuelTankAssy
Port:FuelTankFitting
fp:FuelPump
leftHalfShaft
<>
fuelSupply:Fuel
<>
I_ICECmds
lfw:ChassisSubsytem
.FrontWheel
fuelDelivery
fuelReturn:Fuel
147
Test Result Instance
ins SUV_EPA_Fuel_Economy_Test_Result
Satisfies
«requirment»Emissions
TestVehicle1/hsuv:HSUV
b12345/
b:BodySubsystem
c34567/
c:Chassis
Subsytem
bk45678/
bk:Brake
Subsystem
i23456/
int:Interior
Subsystem
lt56789/
lt:Lighting
bSubsystem
Verifies
«requirment»Emissions
«testCase»
testRun060401/
epaTest:EPAFuel
EconomyTest
p67890/p:PowerSubsystem
eid78901/
ice:InternalComb
ustionEngine
sn89012/
t:transmission
sn90123/
emg:ElectricalMot
orGenerator
VIN = G12345
148
Power Subsystem Interface Defn
bdd [block] PowerSubsystem [ICE Interface Definitions]
«interface»
I_ICEData
getRPM():integer
getTemperature():float
isKnockSensor():boolean
«interface»
I_ICECmds
setThrottle(throttlePosition:float):void
setMixture(mixture:float):void
149
Fuel System Definition
bdd [block] HSUV [PowerSubsystem Fuel Flow Definition]
«block»
Fuel
temperature:Real
pressure:Real
«block»
PowerSubsystem
«block»
FuelTankAssembly
«flowProperties»
in fuelSupply:Fuel
out fuelReturn:Fuel
«block»
InternalCombustionEngine
ICEFuelFitting:FuelFlow
<>
<>
FuelTankFitting:FuelFlow
«flowProperties» »
out fuelSupply:Fuel
in fuelReturn:Fuel
«flowSpecification»
FuelFlow
«flowProperties»
out fuelSupply:Fuel
in fuelReturn:Fuel
150
Fuel Flow Parametrics
par [Block]PowerSubsystem
ice.fi.FuelDemand:Rea
l
ice.ft.FuelFlowRate:Real
injectorDemand:Real
fuelflow:FuelFlow
flowrate:Real
constraints
{flowrate=press/(4*injectorDemand)}
ice.fr.fuel.FuelPressure::Real
press:Real
151
Fuel Subsystem Design
ibd [block] PowerSubsystem [Fuel Distribution Detail]
ice:InternalCombustionEngine
fi1:FuelInjector
fi2:FuelInjector
fi3:FuelInjector
allocatedFrom
«connector»fdist
fi4:FuelInjector
allocatedFrom
«connector»FuelDelivery
fra:FuelRail
4
fre:FuelRegulator
ft:FuelTankAssy
fuelFitting:Fuel
p1:Fuel
fuelSupplyLine
fp:FuelPump
fuelSupply:Fuel
p2:Fuel
fuelReturnLine
fuelReturn:Fuel
152
Overall Analysis Context
bdd [package] HSUVAnalysis [Analysis Context]
«constraint»
CapacityEquation
«constraint»
UnitCostEquation
«constraint»
EconomyEquation
«constraint»
StraightLine
VehicleDynamics
«block»
GlobalTime
constraints
{pcap = ∑ Vi}
parameters
V1:Real
V2:Real
V3:Real
«testCase,Interaction»
MaxAcceleration
«verify»
«domain, block»
HSUVStructure::
AutomotiveDomain
«constraint»
RollingFriction
Equation
«constraint»
AeroDragEquation
«requirement»
Acceleration
153
Performance View Definition
pkg [package] HSUVViews [Performance View]
«view»
PerformanceView
Performance Viewpoint
Drive Car
Driver
«moe»
HSUValt1.Fuel
Economy
«moe»
HSUValt1.Quar
terMileTime
<<requirement>>
Performance
id = 2
Text = The Hybrid SUV
shall have the braking,
acceleration, and off-road
capability of a typical SUV,
but have dramatically better
fuel economy.
«viewpoint»
Functional Viewpoint
«constraint»
UnitCostEquation
«moe»
HSUValt1.Zero
60Time
«constraint»
CapacityEquation
«moe»
HSUValt1.Car
goCapacity
«constraint»
EconomyEquation
«moe»
HSUValt1.Cos
tEffectiveness
«viewpoint»
stakeholders="customer"
purpose="Highlight the performance of the
system."
construction rules="show performance
requirements, test cases, MOE, constraint
models, etc.; includes functional viewpoint"
«testCase»
EPAFuel
EconomyTest
154
Evaluating Measures of Effectiveness
par [constraintBlock] MeasuresOfEffectiveness [HSUV MOEs]
f:
:EconomyEquation
Instance of
constraint block is
identical for each
alternative
«moe»
HSUValt1.FuelEconomy
p1:
q:
:MaxAcceleration
Analysis
«moe»
HSUValt1.QuarterMileTime
p3:
«objectiveFunction»
:MyObjectiveFunction
{CE = ∑ Wi*Pi}
CE:
«moe»
HSUValt1.CostEffectiveness
z:
«moe»
HSUValt1.Zero60Time
vc:
:CapacityEquation
uc:
:UnitCostEquation
p2:
p4:
p5:
«moe»
HSUValt1.CargoCapacity
«moe»
HSUValt1.UnitCost
155
Evaluating Fuel Economy
par [constraintBlock] EconomyEquation
«value»
HSUV.PayloadCapacity
incline
RegenBrake
EfficiencyEquation
AeroDragEquation
volume
Cd
pcap
acc
ebpwr
Cd
volume
acc
incline
RoadElevProfile
PayloadEquation
incline
psgrWt
StraightLine
VehicleDynamics
cgoWt
tw
cgoWt
Cf
«value»
InternalCombustionEngine.
ICEEfficiency
vel
whlpwr
ebpwr
n_ice
acc
vel
Fuel
whlpwr EfficiencyEquation
n_eg
n_em
mpg
mpg
tw
TotalWeight
tw
psgrWt
vdw
Cf
«value»
ElectricMotorGenerator.
GeneratorEfficiency
fw
RollingFriction
Equation
«value»
HSUV.VehicleDryWeight
«value»
ElectricMotorGenerator.
MotorEfficiency
«value»
FuelTank.FuelWeight
156
Evaluating Vehicle Dynamics
par [constraintBlock] StraightLineVehicleDynamics
tw
Cf
Cd
whlpwr
whlpwr
Cd
Cf
tw
tw
tp
incline
PowerEquation
i
tp
Accelleration
Equation
dt
acc
a
v
a
dt
VelocityEquation
«value»
globalTime.delta-t
vel
v
v
dt
PostionEquation
x
«value»
HSUV.position
157
Defining Vehicle Dynamics
bdd [package] HSUVAnalysis [Definition of Dynamics]
«constraint»
StraightLine
VehicleDynamics
parameters
whlpowr:Real
Cd:Real
Cf:Real
tw:Real
acc:Real
vel:Real
incline:Real
«constraint»
PowerEquation
Constraints
{tp(hp) = whlpowr - (Cd*v)
- (Cf*tw*v)}}
parameters
whlpowr:Real
Cd:Real
Cf:Real
tw:Real
tp:Real
v:Real
i:Real
«constraint»
PositionEquation
Constraints
{x(n+1)=x(n)+dx(dt)=x(n)+v*dt}
{x(n+1)=x(n)+v*5280/3600*dt}
«constraint»
VelocityEquation
Constraints
{v(n+1)=v(n)+dv = v(n) + a*dt}
{v(n+1 =v(n)+a*32*3600/5280*dt}
parameters
dt:Real
v:Real
x:Real
parameters
dt:Real
v:Real
a:Real
«constraint»
AccelerationEquation
Constraints
{a(g) = F/m = P*t/m = (550/
32)*tp(hp)*delta-t*twi}
parameters
tw:Real
dt:Real
tp:Real
a:Real
158
Trial Result of Vehicle Dynamics
tim MaxAcceleration [100 Wheel Horsepower]
Satisfies
«requirement»Acceleration
0.5
0.45
Accelleration (g)
0.4
0.35
«diagramDescription»
version=”0.1"
description=”Constant
100 wheel horsepower,
4000 lb vehicle weight,
simple drag"
reference=”Equations of
Motion”
completeness=”assumes
perfect tire traction”
0.3
0.25
0.2
0.15
0.1
0.05
0
0
5
10
15
20
15
20
15
20
Time (sec)
140
Velocity (mph)
120
100
80
60
40
20
0
0
5
10
Time (sec)
1800
1600
Distance (ft)
1400
1200
1000
800
600
400
200
0
0
5
10
Time (sec)
159
“ProvidePower” Functional Decomp
bdd [activity] Accelerate [Activity and Object Flow Breakdown]
«activity»
MeasureVehicle
Conditions
«activity»
ProvidePower
a1
a4
«activity»
ProvideElectric
Power
«activity»
ProportionPower
«activity»
MeasureVehicle
Velocity
«activity»
MeasureBattery
Condition
a2
drivePower
«activity»
ProvideGasPower
«block»
Power
a3
«activity»
ControlElectricPower
elecDrivePower
gasDrivePower
«block»
GasPower
«block»
ElecPower
160
“ProvidePower” Behavior & Allocation
«(UserDefined)Swimlane Diagram»
act ProvidePower [with Swimlane Allocation]
«allocate»
PowerControlUnit
«continuous»
speed
«allocate»
InternalCombustionEngi
ne
«allocate»
ElectricalPowerContr
oller
«allocate»
ElectricalMotorGener
ator
«continuous»
gasDrivePower
a2:ProvideGas
Power
«continuous»
vehCond
«continuous»
gThrottle
a3:Control
ElectricPower
«continuous»
drivePower
a4:Provide
ElectricPower
«continuous»
battCond
«continuous»
elecDrivePower
«continuous»
eThrottle
«continuous»
driveCurrent
a1:Proportion
Power
«continuous»
accelPosition
transModeCmd
keyOff
allocatedTo
«itemFlow»i1:ElectricCurrent
161
Multiple Allocations shown on IBD
ibd [block] PowerSubsystem [Power Functional Allocation]
allocatedFrom
«objectNode»driveCurrent
«diagramDescription»
version=”0.1"
description=”allocation of
behavior and connectors to
elements of power subsystem"
reference=”null”
completeness=”partial. Power
subsystem elements that have
no allocation yet have been
elided”
epc:ElectricalPower
Controller
<>
<>
i2:Electric
Current
i1:Electric
Current
allocatedFrom
«activity»Convert
ElectricToPower
<>
allocatedFrom
«activity»Control
ElectricPower
emg:ElectricalMotor
Generator
fp:FS_EPC
can:CAN_Bus
ecu:PowerControlUnit
allocatedFrom
«activity»Proportion
PowerLoad
<>
<>
<>
fp:FS_TRSM
<>
trsm:Transmission
allocatedFrom
«connector»c1
«connector»c2
«connector»c3
epc:IFS_EPC
ice:IFS_ICE
etrsm:IFS_TRSM
fp:FS_ICE
<>
ice:InternalCombustionEngine
allocatedFrom
«activity»ConvertGasToPower
162
Allocation Table w/Allocation Type
table [activity] ProvidePower [Allocation Tree for Provide Power Activities]
type
activity
activity
activity
activity
objectNode
name
a1:ProportionPower
a2:ProvideGasPower
a3:ControlElectricPower
a4:ProvideElectricPower
driveCurrent
end
from
from
from
from
from
relation
allocateBehavior
allocateBehavior
allocateBehavior
allocateBehavior
allocateFlow
end
to
to
to
to
to
type
block
block
block
block
itemFlow
name
PowerControlUnit
InternalCombustionEngine
ElectricalPowerController
ElectricalMotorGenerator
i1:ElectricCurrent
163
Distiller Example
David Oliver
12/7/05
An example to raise questions
Dave Oliver Preface
System View Interconnection
In my experience of watching the development of
OMT in GE and then UML, it appeared that the
many views introduced were not fully interrelated.
The view represented facets of reality, yet they did
not fully provide the interconnections that exist in
reality.

This example is presented to help ask similar
questions about SysML for the current review.
Consider an activity model for distilling dirty water.
A crude EFFBD is shown.

165
Distiller Example
(as provided by D. Oliver)
Dirty water
@ 20 deg C
Heat Dirty water
To 100 deg C
Dirty water
@ 100 deg C
Steam
Pure
water
Condense
steam
Boil Dirty water
Residue
Heat to Dirty
water
Energy to
condense
Heat to Boil
water
and
and
Drain
Residue
Disposed
residue
The ovals in the figure are I/O in AP233,
items in CORE and I believe object nodes in the submissions.
166
Questions
Q1: what is the list entities in the submission can be object nodes?
Q2: would the water, steam, etc be Blocks?
Q3: How would heat be represented?
The water has properties: vol = 1 liter, density 1 gm/cm3, temp 20 deg C,
specific heat 1cal/gm deg C, heat of vaporization 540 cal/gm.
Q4: do the submissions allow the application of parametrics to the object
nodes to calculate the heat required to heat the water, boil the water, and
condense the water?
167
Questions (cont.)
The questions above relate only to the activity diagram (EFFBD). One
does not have a design until the activities are allocated to physical
thins, probably Blocks.
Allocate heat dirty water and condense steam to a block Counter Flow
Heat Exchanger
Allocate boil dirty water to a block Boiler
Allocate drain residue to a block Drain
These allocations require that particular interconnections exist among
these three blocks.
Q5: How does the language support or enforce the existence of the
required interconnections among blocks? Does the engineer have to
build this correctly without language support?
168
Questions (cont.)
These allocations require that the object nodes are identical to the flows or
interface specifications (the labels) associated with these interconnections.
Q6: How does the language support or enforce the identity between the object
nodes and the labels associated with the interconnections? Does the engineer
have to build this correctly without language support?
169
Response to Dave’s Example
Distiller System
Distiller System – Package Overview
pkg [model] Distiller [Model Overview]
DistillerRequirements
DistillerBehavior
UnitTypes
DistillerUseCases
DistillerStructure
ItemTypes
Organizing the Model
171
Units Library
bdd [package] Unit Types
ºC
kg
m
«value»
unit=degreesCentigrade
dimension=temperature
«value»
unit=kilogram
dimension=mas
s
«value»
unit=meter
dimension=length
kg/m²
kg/s
cal/s
«value»
unit=kilogram/meter^2
dimension=pressure
«value»
unit=kilogram/second
dimension=massflow
«value»
unit=calory/second
dimension=energyflow
Defining the Units
172
Behavior Breakdown
bdd [package) DistillerBehavior [Distiller Behavior Breakdown]
coldDirty
a1
hotDirty
«activity»
DistillWater
a2
«activity»
HeatWater
«activity»
BoilWater
a3
a4
steam
«block»
ItemTypes::H2O
values
temp=*C
press=kg/m^2
pure
external
«activity»
CondenseSteam
«activity»
DrainResidue
recovered
«block»
ItemTypes::Heat
hiPress
loPress
«block»
ItemTypes::Residue
Distill Activity Decomposition and Types of Flows
173
H20 States
stm [block] H2O
Gas
Add Latent Heat
of Vaporization
Remove Latent Heat
of Vaporization
Liquid
Remove Latent Heat
of Liquification
Add Latent Heat
of Liquification
Solid
174
Distill Water Activity Diagram (Initial)
«effbd»
act [activity] DistillWater [Simple Starting Point)
coldDirty:H2O
[liquid]
Note: these are
the same thing!
steam:H2O
[gas]
hotDirty:H2O
[liquid]
recovered:Heat
pure:H2O
[liquid]
a3:CondenseSteam
a1:HeatWater
a2:BoilWater
a4:DrainResidue
recovered:Heat
external:Heat
hiPress:Residue
loPress:Residue
Representing Distiller Example in SysML
Using EFFBD Profile
175
Distill Water Activity Diagram
(Continuous Activity Modeling)
act [activity] DistillWater [Parallell Continuous Activities)
loPress:Residue
«continuous»
coldDirty:H2O
[liquid]
«continuous»
steam:H2O
[gas]
hiPress:Residue
«continuous»
recovered:Heat
a4:DrainResidue
a1:HeatWater
a3:CondenseSteam
«continuous»
hotDirty:H2O
[liquid]
a2:BoilWater
«continuous»
external:Heat
Representing Distiller Example in SysML
Using Continuous Flow Modeling
«continuous»
pure:H2O
[liquid]
176
Distill Water – Swim Lane Diagram
Allocated Behavior
act [activity] DistillWater [Swimlane Diagram]
«allocate»
hx:HeatExchanger
«allocate»
bx:Boiler
«allocate»
dx:DrainValve
«continuous»
coldDirty:H2O
[liquid]
loPress:Residue
«continuous»
steam:H2O
[gas]
hiPress:Residue
«continuous»
recovered:Heat
a4:DrainResidue
«streaming»
a1:HeatWater
«streaming»
a3:CondenseSteam
«continuous»
hotDirty:H2O
[liquid]
«streaming»
a2:BoilWater
«continuous»
external:Heat
«continuous»
pure:H2O
[liquid]
shutdown
Allocating the Activities to Swim Lane
that Represent Blocks
177
Distiller System Hierarchy (Top Level)
A Diagram Feature
Provided by SST Submission
(refer to App A)
bdd [package] DistillerStructure [Structural Breakdown]
«block»
Distiller
hx
«block»
HeatExchanger
bx
«block»
Boiler
«diagramDescription»
version=”0.1"
description=”initial structural
breakdown of distiller
system"
reference=”TBD”
completeness=”ItemFlows
and Connectors elided”
dv
«block»
DrainValve
Describing the Distiller System and Its Components
178
Distiller Internal Block Diagram
ibd: [block] Distiller [DistillerBlockDiagram - Unallocated]
hx:HeatExchanger
water_in:H2O
bx:Boiler
hx_water_out:H2O
dv:DrainValve
bx_sludge_out:Residue
:
sludge_out:Residue
:
bx_steam_out:H2O
heat_in:Heat
water_out:H2O
Describing the Interconnection of Parts
And the Item Flows Between Them
179
Distiller Internal Block Diagram
(with Allocations)
ibd: [block] Distiller [DistillerBlockDiagram - Allocated]
allocatedFrom
«objectNode»coldDirty:H2O
allocatedFrom
«objectNode»hotDirty:H2O
hx:HeatExchanger
Water_In:H2O
allocatedFrom
«activity»HeatWater:
«activity»CondenseSteam:
allocatedFrom
«objectNode»hiPress:Residue
bx:Boiler
hx_water_out:H2O
allocatedFrom
«activity»BoilWater:
allocatedFrom
«objectNode»loPress:Residue
dv:DrainValve
bx_sludge_out:Residue
allocatedFrom
«activity»DrainResidue:
Sludge_out:Residue
bx_steam_out:H2O
allocatedFrom
«objectNode»steam:H2O
Heat_in:Heat
Water_out:H2O
allocatedFrom
«objectNode»External:Heat
allocatedFrom
«objectNode»Pure:H2O
Showing the Allocations from Activities
and Object Nodes to Blocks and Item Flows
180
Heat Exchanger Interface Specs
bdd [block] HeatExchanger [HeatExchanger Flow Definition]
«block»
Fluid
«block»
HeatExchanger
values
temp=ºC
press=kg/m^2
values
thermalEfficiency:Real
«block»
Heat
values
dQ/dt=cal/s
vIn:VaporFlow
fIn:Fluid
qIn:HeatFlow
«block»
CoolantSide
<>
qOut:HeatFlow
«block»
CondensorSide
fOut:FluidFlow
fOut:Fluid
Constraints
{temp <= 220 ºC,
press <= 150 kg/m^2}
Constraints
{temp <=400 ºC,
press <= 1000 kg/m^2}
Describing the kind of things that can Flow (Fluid, Heat)
And Constraints on Flow Ports
181
Parametric Diagram – Thermal Analysis
(includes constraints on I/O)
par [block] Distiller [Simplified Isobaric Heat Balance Analysis}
{Qrate=(th-tc)*mRate/sh)}
water_in:H2O
mRate
«value»
temp
«value»
massFlowRate
tin
SinglePhaseHeatXFR
Equation
sh
tout
r1
Qrate
equivalent
{r1=r2}
hx_water_out:H2O
r2
ItemTypes::H2O
Qrate
«value»
temp
«value»
specificHeat
condensing:
SimplePhaseChange
Equation
«value»
massFlowRate
lh
«value»
latentHeat
mRate
bx_steam_out:H2O
«value»
massFlowRate
{Qrate=mRate*lh)}
r1
water_out:H2O
«value»
massFlowRate
equivalent
{r1=r2}
Qrate
r2
boiling:
SimplePhaseChange
Equation
lh
mRate
heat_in:Heat
«value»
dQ/dt
Defining the Thermal Equations
as Constraints on the Flow Properties
182
Analysis Results - Isobaric
«analysisResult»
IsobaricHeatBalance1 [Results of Isobaric Heat Balance]
mass flow rate gm/sec
temp °C
water_out
bx_steam_out
bx_water_in
hx_water_out
1
540
water_in
specific heat cal/gm-°C
latent heat cal/cm
6.75 6.75
1
1
1
20 100 100 100 100
dQ/dt cooling water cal/sec
dQ/dt steam-condensate cal/sec
condenser efficency
heat deficit
540
540
1
0
dQ/dt condensate-steam cal/sec
boiler efficiency
dQ/dt in boiler cal/sec
540
1
540
Note: Cooling water
needs to have 6x flow
of steam!
Need bypass between
hx_water_out and
bx_water_in!
Analysis Results Indicate Need for
Modification to Existing Desgin
183
Behavior Breakdown - Revised
bdd [package) DistillerBehavior [Revised Distiller Behavior Breakdown]
coldDirty
hotDirty
«activity»
DistillWater
a1
steam
a2
pure
«activity»
HeatWater
«activity»
BoilWater
«block»
ItemTypes::H2O
values
temp=*C
press=kg/m^2
hotDirty1
hotDirty2
a3
a4
external
«activity»
CondenseSteam
«activity»
DrainResidue
recovered
«block»
ItemTypes::Heat
a5
hiPress
«activity»
ReturnSome
loPress
«block»
ItemTypes::Residue
New Activity Required To Meet the Need
184
Swim Lane Diagram - Revised
act [activity] DistillWater [Revised Swimlane Diagram]
«allocate»
hx:HeatExchanger
«allocate»
bx:Boiler
«allocate»
dx:DrainValve
«continuous»
coldDirty:H2O
[liquid]
loPress:Residue
«continuous»
steam:H2O
[gas]
hiPress:Residue
«continuous»
recovered:Heat
a4:DrainResidue
«streaming»
a1:HeatWater
«continuous»
hotDirty:H2O
[liquid]
«streaming»
a3:CondenseSteam
a5:ReturnSome
«continuous»
hotDirty1:H2O
[liquid]
«streaming»
a2:BoilWater
«continuous»
external:Heat
«continuous»
pure:H2O
[liquid]
shutdown
«continuous»
hotDirty2:H2O
[liquid]
New Activity Shown in Swim Lane Diagram
185
Distiller Internal Block Diag - Revised
ibd: [block] Distiller [Revised DistillerBlockDiagram - Allocated]
allocatedFrom
«objectNode»hotDirty2:H2O
waste_water:H2O
allocatedFrom
«objectNode»coldDirty:H2O
allocatedFrom
«objectNode»hotDirty1:H2O
hx:HeatExchanger
Water_In:H2O
allocatedFrom
«activity»HeatWater:
«activity»CondenseSteam:
allocatedFrom
«objectNode»hiPress:Residue
allocatedFrom
«objectNode»loPress:Residue
bx:Boiler
dv:DrainValve
allocatedFrom
«activity»BoilWater:
allocatedFrom
«activity»DrainResidue:
bx_sludge_out:Residue
Sludge_out:Residue
bx_water_in:H2O
bx_steam_out:H2O
allocatedFrom
«objectNode»steam:H2O
Heat_in:Heat
water_out:H2O
allocatedFrom
«objectNode»External:Heat
allocatedFrom
«objectNode»Pure:H2O
Additional Item Flow Required To Support Change
186
Parametric Diagram – Thermal Analysis
(Revised)
par [block] Distiller [Detailed Heat Balance Analysis}
waste_water:H2O
«value»
massFlowRate
water_in:H2O
«value»
temp
mRate
«value»
massFlowRate
r3
r1
sum
{r1=r2+r3}
tin
SinglePhaseHeatXFR
Equation
tout
specificHeat
t1
«value»
temp
«value»
press
p1
t2
p2
«value»
massFlowRate
ItemTypes::H2O
Qrate
r2
bx_water_in:H2O
sh
latentHeat
qin
boiling:
PhaseChangeEquation
lh
rate
http://www.spiraxsarco.com/learn/
?redirect=html/2_15_01.htm
bx_steam_out:H2O
«value»
temp
t1
«value»
press
«value»
massFlowRate
r1
equivalent
{r1=r2}
water_out:H2O
«value»
temp
p1
t2
p2
qout
condensing:
PhaseChangeEquation
lh
rate
r2
«value»
press
«value»
massFlowRate
heat_in:Heat
«value»
dQ/dt
Revised Thermal Analysis To Support Change
187
Analysis Results – Non Isobaric
Example
«analysisResult»
PhaseChangeEquation [H20 - Mollier Diagram]
Update to Analysis Results
188
Summary
SST SysML Submission

Satisfies Most Requirements in the RFP




Critical Issues Resolved
Multi-vendor implementations
Our solution




Small number of remaining req’ts to be addressed
along with user/vendor feedback in future revisions
Architecturally sound & compatible with UML 2/ XMI
Implementable by multiple vendors
Meets the needs of SE’s
Refer to Highlights and Comparison Matrix and
these slides to contrast with SysML Partners
submission
190