Intro To The SysML v2 Language-Graphical Notation

SST
Introduction to the SysML v2 Language

Graphical Notation
(2021-12-13)
T h i s p r e s e n t a t i o n o f t h e S y s M L v 2 l a n g u a ge u s e s t h e p ro p o s e d
g ra p h i c a l m o d e l i n g n o t a t i o n t h a t c o m p l e m e n t s t h e t ex t u a l s y n t a x .
T h e g ra p h i c a l n o t a t i o n i s b e i n g fo r m a l l y s p e c i f i e d i n t h e S y s M L v 2
s p e c i f i c a t i o n . I t i s s t i l l i n p ro c e s s, a n d t h e r e a r e p o t e n t i a l e r ro r s a n d
i n c o n s i s t e n c i e s s i n c e t h e n o t a t i o n i s ge n e ra t e d m a n u a l l y w i t h V i s i o.
C o p y r i g h t © 2 0 2 1 by S a n f o r d Fr i e d e n t h a l
Licensed under the Creative Commons Attribution 4.0 International License.
To v i e w a c o p y o f t h i s l i c e n s e, v i s i t h t t p : / / c r e a t i v e c o m m o n s . o rg / l i c e n s e s / by / 4 . 0 / o r
s e n d a l e t t e r t o C r e a t i v e C o m m o n s, P O B ox 1 8 6 6 , M o u n t a i n V i e w, C A 9 4 0 4 2 , U S A .
Updates since 2021-09-18 SST
2021-09-21: Slide 83 – changed include on use case
2021-09-23: Slide 69 - refer to default
2021-09-23: Slide 70 – changed body to result
2021-09-23: Slide 77 – changed body to expression
2021-09-23: Slide 99 – updated view (PartUsage) and viewpoint (stakeholder)
2021-09-30: Slides 99-102 – updated view/viewpoint based on discussion at joint track lead session on 9/30
2021-11-02 Slides 81-82 – replace square brackets with angle bracket on req’t id
2021-11-02 New Slide 18 – element import notation
2021-11-06 Slide 19 – updated alias notation
2021-11-02 Slide 37 – added binding connection
2021-11-02 Slide 39 – updated interfaces compartment
2021-11-02 Slide 50 – updated input/output flows
2021-11-02 Slide 51 – updated parallel notation
2021-11-03 Slide 70 – changed ‘=>’ to ‘=‘
2021-11-04 Slides 49-50 – change parameter notation – change from flow to binding on delegations
2021-11-04 Slides 57-59 – remove slash from entry, do, and exit actions
2021-11-06:Slide 19 – added reference to filter criteria for package import
2021-12-12: Slide 27 – changed blue to Colors::blue
2021-12-12: Slide 86 – changed objective function to evaluation function
2 13 Dec 2021
SysML v2 Functional Areas SST
1. Packages & Element Names 13. Expressions & Calculations
2. Definition Elements 14. Quantities & Units
3. Usage Elements 15. Constraints
4. Part Decomposition 16. Requirements
5. Part Interconnection 17. Use Cases
6. Variability 18. Analysis Cases
7. Actions 19. Verification Cases
8. Action Flow 20. Dependency & Allocation Relationships
9. States 21. Annotations
10. Interactions 22. Element Filters
11. Individuals 23. View & Viewpoint
12. Timeslices & Snapshots 24. Language Extension (not implemented yet)
3 13 Dec 2021
General Caveats SST
The graphical representation is intended to complement the textual noation

¡ The
textual notation has been formally specified
¡ The graphical notation is being formally specified using graphical BNF
¡ The graphical visualization in this presentation is captured in Visio, but will need
to be rendered in a more precise way to reflect the specification in the future
¡ Two visualization prototypes are under development (Tom Sawyer and
PlantUML)
SysML v2 Marker
¡ Some of the more significant SysML v2 changes in functionality and terminology
relative to SysML v1 are designated with the SysML v2 marker
4 Copyright © 2021 by Sanford Friedenthal 13 Dec 2021

Overview

SysML v2 Objectives SST
Increase adoption and effectiveness of MBSE

by enhancing…
Precision and expressiveness of the language

Consistency and integration among language concepts
Interoperability with other engineering models and tools
Usability by model developers and consumers
Extensibility to support domain specific applications
Migration path for SysML v1 users and implementors
6 13 Dec 2021
Key Elements of SysML v2 SST
New Metamodel that is not constrained by UML

¡ Preserves
most of UML modeling capabilities with a focus on systems modeling
¡ Grounded in formal semantics
Robust visualizations based on flexible view & viewpoint specification and

execution
¡ Graphical, Tabular, Textual
Standardized API to access the model
7 13 Dec 2021
SysML v2 Language SST
Capabilities
Updated
Requirements
Behavior
- function-based Analysis
- state-based - analysis cases
- sequence-based - expression language
- use cases SysML v2
Structure
Language
- decomposition Verification
- interconnection - verification cases
- classification
View & Viewpoint
8 13 Dec 2021
Definition and Usage SST
Reuse Pattern
A definition element defines an element such as a part, action, or requirement
A usage element is a usage of a definition element in a particular context
¡ Therecan be different usages of the same definition element in either different
contexts or the same context
Pattern is applied consistently throughout the language
«usage» «usage»
context1 context2
«usage» «usage»
usage1 usage2 notation
defined by
:
:
«definition»
«definition»
DefinitionA
DefinitionA
9 13 Dec 2021
SysML v2 to v1 SST
Terminology Mapping (partial)
SysML v2 includes consistent usage/definition terminology
SysML v2 SysML v1
part / part def part property / block
attribute / attribute def value property / value type
port / port def proxy port / interface block
action / action def action / activity
state / state def state / state machine
constraint / constraint def constraint property / constraint block
requirement / requirement def requirement
connection / connection def connector / association block
10 13 Dec 2021
SysML v2 Notation (1 of 2) SST
Textual and Graphical
package 'Vehicle Parts Tree' {
part vehicle {
attribute mass;
perform providePower;
part engine {
attribute mass;
perform generateTorque;
part cylinders [6];
}
part transmission {
attribute mass;
perform amplifyTorque;
}
}
}
package 'Vehicle Action Tree'{
action providePower {
action generateTorque;
action amplifyTorque;
}
}
11 13 Dec 2021
SysML v2 Notation (2 of 2) SST
Textual and Graphical
interface def Drive {
end enginePort : DrivePort;
end transmissionPort : ~DrivePort;
}
part vehicle : Vehicle {

part engine : Engine { port drivePort : DrivePort; }
part transmission : Transmission { port drivePort : ~DrivePort; }
interface : Drive
connect engine.drivePort to transmission.drivePort;
}
«part»
vehicle : Vehicle
: Drive «part»
«part»
transmission :
engine: Engine
Transmission
drivePort : drivePort :
DrivePort ~DrivePort
Tom Sawyer Visualization Prototype

12 13 Dec 2021
Module 1
Packages & Element Names

Model Organization [1 of 3] SST
A hierarchy of packages, where packages can contain other packages and elements
Packages are namespaces that contain member elements that may be owned or unowned
A package can import members of another package as unowned members, where deletion
semantics do not apply, and they can be referred to by their local name
SimpleVehicleModel
VehicleConfigurations
VehicleConfiguration_a
SysML
Standard KerML
Definitions
Libraries Libraries
VehicleConfiguration_b
SI ScalarValues
VehicleAnalysis «import»
Requirements PartsTree
ISQ ScalarFunctions
VehicleVerification
ActionTree States
14 13 Dec 2021
semantics do not apply, and they can be referred to by their unqualified name
¡ Nested import notation enables flexible organization
SimpleVehicleModel
SysML Standard
VehicleConfigurations Libraries
«import»
SI
Definitions
«import»
ISQ
VehicleAnalysis
KerML
Libraries
Requirements PartsTree
«import»
VehicleVerification ScalarValues
ActionTree States
«import»
ScalarFunctions
ScalarFunctions
15 13 Dec 2021
semantics do not apply, and they can be referred to by their unqualified name
¡ Nested import notation enables flexible organization
SimpleVehicleModel
SimpleVehicleModel
SysML Standard
VehicleConfigurations Libraries
«import» SysML SI
SI Standard KerML
Definitions
Libraries Libraries
«import»
ISQ
ISQ
SI ScalarValues
VehicleAnalysis «import»
KerML
Libraries
Requirements PartsTree ScalarValues
ISQ ScalarFunctions
«import»
VehicleVerification ScalarValues
ScalarFunctions
ActionTree States
«import»
ScalarFunctions
ScalarFunctions
16 13 Dec 2021
Definitions Package SST
Example: Definitions package contains packages to define different kinds of

elements
¡ Ellipsis indicates there is more content
Definitions
PartDefinitions ItemDefinitions ActionDefinitions
AttributeDefinitions SignalDefinitions StateDefinitions
PortDefinitions InterfaceDefinitions RequirementDefinitions
…
17 13 Dec 2021
Import Notation SST
no star is element import «import»

«import» *
single star is package import (content of package)
«import» **
double star is recursive including outer package
Imports can apply to any namespace, but

packages are most commonly used
A package import can include filter criteria to
select elements based on their metadata
18 13 Dec 2021
Element Names SST
A qualified name of a model element is prepended by the name of its owner

followed by a double colon (::)
A fully qualified name is prepended by the concatenated names of its owners in
its containment hierarchy separated by double colons (::)
An element can have one or more aliases
Each element includes a UUID and optionally other id’s, such as a URI and a
human-readable id
¡ UUID: universally unique identifier
¡ URI: Uniform Resource Identifier B
A
«part def»
Sports Utility Vehicle
B «alias» SUV
B::C
A::B::C «part def»
C
B
«part def»
«alias» SUV
19
13 Dec 2021
Module 2
Definition Elements

Part Definition SST
A Part Definition can contain features such «part def»
as attributes, ports, actions, and states Vehicle
attributes
¡ A modular unit of structure mass:>ISQ::mass
dryMass
cargoMass
electricalPower
position
velocity
acceleration
...
ports
pwrCmdPort
...
vehicleToRoadPort
perform actions
providePower
provideBraking
...
controlDirection
exhibit states
vehicleStates
21 13 Dec 2021
Other Kinds of Definition Elements SST
Terminology
Each kind of definition element can contain specific kinds of features
¡ Attribute definition
§ Data type that defines a set of data values
«attribute def»
§ Primitive attribute definitions include integer, Real, Complex, Boolean, String, …. Real
§ Can include quantity kinds such as Torque with units «attribute def»
Torque
§ Can include complex data types such as vectors
«port def»
¡ Port definition ~ ~ FuelCmdPort
directed features
§ Defines a connection point on parts that enable interactions in item fuelCmd:FuelCmd
§ Contain kinds of features including directed features with in, out, and in/out attributes
x:Real
§ Ports can be conjugated (i.e., reverse direction of directed features) «item def»
FuelCmd
¡ Item definition
§ Defines kind of entity that may be acted on, such as a flow, or a stored item «item def»
Fuel
¡ Action definition «action def» attributes

ProvidePower fuelMass:>ISQ::mass
§ Defines kind of behavior that transforms inputs and outputs parameters
in pwrCmd:PwrCmd
¡ State definition out torqueToWheels:Torque [*]
«state def»
§ Defines kind of behavior that responds to events VehicleStates
§ Enables entry, exit, and do actions actions

do providePower
22 13 Dec 2021
Specialization SST
Definition elements can be specialized

¡ Subclassinherits features of superclass and can add new features
¡ Can be subclassed by more than one superclass (i.e., multiple inheritance)
«part def»
Axle
attributes
mass
«part def»
FrontAxle
attributes
inherited ^mass
new steeringAngle
23 13 Dec 2021
Redefinition and Subsetting SST
An inherited feature can be redefined by a «port def»

PwrCmdPort
feature whose definition is more specialized directed features

in item pwrCmd:PwrCmd
¡ The more specialized feature overrides the

inherited feature «port def»
FuelCmdPort
¡ Symbol for redefines (:>>) directed features

in item fuelCmd:FuelCmd redefines pwrCmd
«part def»
An inherited feature can be subsetted by one Engine
or more features with a more constrained parts
cylinders:Cylinder [4..8]
multiplicity
¡ The Engine4Cyl contains a subset of the
cylinders contained by Engine «part def»
Engine4Cyl
¡ First redefine multiplicity to 4 parts
cylinders [4] redefines cylinders
¡ Then identify the subsetting features cylinder1 [1] subsets cylinders
cylinder2 [1] subsets cylinders
¡ Symbol for subsets (:>) cylinder3 [1] subsets cylinders
cylinder4 [1] subsets cylinders
24 13 Dec 2021
Module 3
Usage Elements

Other Usage Elements SST
Terminology
Other kinds of usage elements are defined by specific kinds of definition

elements
¡ Attributes defined by attribute definition
¡ Ports defined by port definition
¡ Items defined by item definition
¡ Actions defined by action definition
¡ States defined by state definition
26 13 Dec 2021
Enumeration SST
A data type whose range is restricted to a set of discrete values

¡ Without units
«enum def»
§ Definition: enum def Colors {red; blue; green;} Colors
enums
§ Usage: attribute color1: Colors = Colors::blue; red
blue
green
¡ With units:
§ Definition: enum def DiameterChoices :> ISQ::LengthValue {
enum = 60 [mm]; «enum def»
DiameterChoices
enum = 70 [mm]; enums
=60 [mm]
enum = 80 [mm]; =70 [mm]
=80 [mm]
}
§ Usage: attribute cylinderDiameter: DiameterChoices = 80 [mm];
27 13 Dec 2021
Usage Elements Defined By SST
Default Definition Elements
A definition element is a subclass of the most general definition element in the
SysML v2 library (e.g., Part)
A usage element is defined by a definition element
¡ defined by is a kind of specialization
A usage element that is not provided a definition by the modeler is a subset of
the most general usage element in the library (e.g., parts)
Default part Default Part Definition
SysML v2 «part»
parts [0..*] : «part def»
Part
Library
part without «part»

definition vehicle_b
defined by
::
part with «part» «part def»
definition vehicle_b:Vehicle Vehicle
28 13 Dec 2021
Module 4
Part Decomposition

SysML v1 Decomposition in SysML v2 SST
Can create the equivalent of SysML v1 block decomposition using part definitions
¡ No part to part relationships in SysML v1
«part def»
Vehicle
engine transmission driveshaft rearAxleAssembly fuelTank

«part def» «part def» «part def» «part def» «part def»
Engine Transmission Driveshaft AxleAssembly FuelTank
differential rearAxle rearWheel1 rearWheel2

«part def» «part def» «part def»
Differential Axle Wheel
30 13 Dec 2021
Parts Decomposition SST
A parts tree is a composition of a part from other parts

¡ SysML v1 only supports block decomposition
¡ Definition element can serve as black-box specification that is not decomposed
§ Does not commit to an internal structure (e.g., decomposition)
¡ Can provide significant advantages (more intuitive, less ambiguous, easier to
modify a design configuration)
«part»
vehicle_b:Vehicle
«part» «part» «part» «part» «part»

engine:Engine transmission:Transmission driveshaft:Driveshaft rearAxleAssembly:AxleAssembly fuelTank:FuelTank
«part» «part» «part» «part»

differential:Differential rearAxle:Axle rearWheel1:Wheel rearWheel2:Wheel
31 13 Dec 2021
Parts Tree Reuse & Modification SST
Subsetting a Part
A part can be a subset of another part
¡ Equivalent to specializing a part
¡ Inherits the part decomposition and other features
¡ Can modify inherited parts and features through redefinition and subsetting
¡ Can add new parts
subsets
«part» «part»
vehicle_c:Vehicle vehicle_b:Vehicle
«part» «part» «part» «part» «part» «part»

bodyAssy:BodyAssy engine:Engine transmission:Transmission driveshaft:Driveshaft rearAxleAssembly:AxleAssembly fuelTank:FuelTank

differential:Differential rearAxle:Axle rearWheel1:Wheel rearWheel2:Wheel
32 13 Dec 2021
References SST
A part can refer to other parts that are part of another decomposition
¡ Not composite (i.e., lifetime semantics do not apply)
¡ Bind the reference usage «part»
vehicle-trailer-system
«part» «part» «part»

vehicle trailerHitch trailer
reference bind bind reference

= =
hitchBall hitchBall trailerCoupler trailerCoupler
A part can refer to an item that it stores

«part»
fuelTank
«item»
fuel
33 13 Dec 2021
Multiplicity SST
Defines the number of features (e.g., parts) in a particular context

¡ Defines a range with a lower bound and upper bound
¡ Lower and upper bounds are integers
¡ Default multiplicity is [1..1]
¡ Optional multiplicity [0..1]
«part»
bodyAssy:BodyAssy

doors:Door [2..4] body sunroof:Sunroof [0..1]
34 13 Dec 2021
Module 5
Part Interconnection

Connecting Parts SST
Parts can be connected via their ports or without ports
¡ Parts can be connected directly without connecting to the composite part
¡ Ports can contain nested ports
¡ Flows can be shown on connections
¡ References are dashed
¡ Conjugate port
¡ Binding connection
Interconnection view [vehicle interconnection]
«part»
vehicle_b:Vehicle
«part»
fuelTank:FuelTank
«item»
fuel:Fuel
«part»
rearAxleAssembly:AxleAssembly
p1 : FuelOutPort
fuel
p2 : ~FuelOutPort «part»
rearWheel1:Wheel
«part» «part» «part» «part» «part»
engine:Engine transmission:Transmission driveshaft:Driveshaft differential:Differential rearAxle:Axle
fuelCmd «part»
rearWheel2:Wheel
«part»
vehicleSoftware
engineStatus
«part»
vehicleController
36 13 Dec 2021
Interfaces [1] SST
A connection definition connects two usage elements (e.g., two parts)
An interface definition is a connection definition whose ends are compatible ports
¡ Can
contain item flows
¡ Can contain other kinds of features
An interface defined by an interface definition is used to connects parts

¡ Ports on parts must be compatible with the interface definition
«part»
fuelTank:FuelTank
«item»
«interface def» fuel:Fuel
FuelTankToEngine_IF
ports p1 : FuelOutPort
: FuelOutPort fuel:Fuel
:FuelTankToEngine_IF
: ~ FuelOutPort
item flows p2 : ~FuelOutPort

:Fuel
«part»
engine:Engine
37 13 Dec 2021
Interfaces [2] SST
Connecting a Wheel to a Hub
Wheel Fastener interface species a compatible
connection between a lug nut and shank
¡ Specifies attributes needed for a compatible connection
Wheel to Hub interface specifies a compatible connection

between a wheel and hub (i.e., 5 lug nuts and 5 shanks)
¡ Decomposes into 5 Wheel Fastener interfaces
Usage of Wheel to Hub interface definition connects

wheel to hub «part» :WheeltoHub_IF «part»
wheel:Wheel lugNutPorts:LugNutPort[5] shankPorts:ShankPort[5] hub:Hub
«interface def»
WheelFastener_IF
ports «interface def»

lugNutPort:LugNutPort WheeltoHub_IF
shankport:ShankPort
ports
attributes lugNutPorts:LugNutPort[5]
threadDia = 14 [mm] shankPorts::ShankPort[5]
threadPitch = 1.5 [mm]
shaftLength = 70 [mm] interfaces
maxTorque = 90 [ft-lbs] WheelFastener_IF [5] connect
lugNutPorts:LugNutPort[5] to shankPorts:ShankPort[5]
38 13 Dec 2021
Module 6
Variability

Variability SST
Vehicle family is the superset model (150%)

Variation points represent elements that can vary
¡ Can be applied to all definition and usage elements
A variant represents a particular choice at a variation point
A choice at one variation point can constrain choices at other variation points
A system can be configured by making choices at each variation point
«part»
vehicleFamily
«variation»
«variation» «variation»
«part»
«part» «part»
engine
engine transmission
«variant» «variant» «variant» «variant»

40 «part» «part» «part» «part»
engine4cyl engine6cyl transmissionAuto transmissionManual
constraints
engine==engine::engine4cyl xor (engine==engine::engine6cyl and transmission==transmissionAuto)
13 Dec 2021
Selected Vehicle Configuration SST
vehicle_a subsets vehicleFamily to represent a particular design configuration

parts are selected that conform to variability constraints
¡ model is invalid if constraints are not satisfied
¡ Variability modeling applications can automate the selection of valid configurations
«part»
vehicleFamily
«part»
vehicle_a
«part» «part»
engine=engine6cyl transmission=transmissionAuto
41 13 Dec 2021
Behavior

Module 7
Actions

Actions SST
Actions are defined by action definitions

¡ Inherit
features (e.g., input and output parameters)
¡ Features can be redefined
«action»
providePower : «action def»
ProvidePower
parameters parameters
in fuelCmd:FuelCmd :>> pwrCmd in pwrCmd:PwrCmd
ôut torqueToWheels [*] out torqueToWheels:Torque [*]
44 13 Dec 2021
Action Decomposition SST
Actions can be decomposed in a similar way as parts
«action»
providePower
«action» «action» «action» «action»

generateTorque amplifyTorque distributeTorque transferTorque
45 13 Dec 2021
Part Performs Actions SST
A part that performs an action can refer to an action in an action tree
«part»
vehicle_b:Vehicle
perform actions
providePower
provideBraking
controlDirection «action»
providePower
«part»
engine:Engine «action» «action» «action» «action»
perform actions
generateTorque
46 13 Dec 2021
Module 8
Action Flow

Action Flows SST
Action flows can include control flows and input/output flows

Control nodes include decision, merge, fork, and join nodes
Actions can include send and accept actions
Swimlanes represent performers of actions
«action»
providePower
=
engineStarted
48 13 Dec 2021
Part SST
A part is a usage of a part definition
Part inherits its features from its definition
Inherited features can be redefined or subsetted, and new features can be added
«part»
vehicle_b:Vehicle
attributes
mass :>> mass = dryMass+cargoMass+fuelTank.fuel.fuelMass
redefined dryMass :>> dryMass=sum(partMasses)
cargoMass :>> cargoMass default 0 [kg]
new partMasses = ( ...
)
êlectricalPower
inherited ^position
^velocity
âcceleration
ports
fuelCmdPort:FuelCmdPort :>> pwrCmdPort
vehicleToRoadPort :>> vehicleToRoadPort
wheelToRoadPort1:WheelToRoadPort
wheelToRoadPort2:WheelToRoadPort
perform actions
^providePower
^provideBraking
^controlDirection
exhibit states
^vehicleStates
49 13 Dec 2021
Input/Output Flows SST
A flow is a kind of connection that transfers items from a source output to a
target input
¡ A flow is a transfer that continues while the source and target actions execute
(this is the default)
¡ A succession flow is a transfer that only occurs after the source action ends and
before the target action starts
«action»
providePower
=
engineStarted
50 13 Dec 2021
Controlling Actions [1] SST
A start action and done action represent the start and end of an action sequence
A succession asserts that the target action can start execution only after the
source action ends execution
A conditional succession asserts that the target action can start only if the guard
condition is true (if…then). If the guard is false, the target action cannot start
«action»
transportPassenger
[vehicleStarted]
«action» «action» «action» «action» «action»
unlockDoor openDoor enterVehicle closeDoor startVehicle
start
join1
fork1
«action»
driveVehicle
merge1
decision1
openDoor exitVehicle closeDoor lockDoor [else]
«action» done
providePower [anotherDestination]
51 13 Dec 2021
Control nodes are kinds of actions (with names) that control outgoing
successions in response to incoming successions
¡ Decision node
§ 1 incoming succession and 1.. many outgoing successions
§ One outgoing succession is selected based on the guard condition that is
satisfied (“else” condition is the complement of all other guard conditions)
¡ Merge node
§ 1.. many incoming successions and 1 outgoing succession [vehicleStarted]
§ The outgoing succession occurs when any of its incoming successions occur
join1
fork1
«action»
driveVehicle
merge1
decision1
«action» done
52 13 Dec 2021
¡ Fork node
§ 1 incoming succession and 1.. many outgoing successions
§ All outgoing successions occur when its incoming succession occurs
¡ Join node
§ 1.. many incoming successions and 1 outgoing succession
§ Outgoing succession occurs when all its incoming successions occur
Note: Control nodes cannot currently be applied to input/output flows
join1
fork1
«action»
driveVehicle
merge1
decision1
«action» done
53 13 Dec 2021
Accept actions and send actions
¡ When a send action executes, it transfers an item to a target part
¡ When a triggering input item is received, an accept action executes and can
transfer the input item to another action
«action»
startVehicle
«part»
driver:Driver
«part»
vehicle:Vehicle
Driver and vehicle are
in a shared context
vehicleStart vehicleStart
«action»
startEngine
engineStartStatus engineStartStatus
54 13 Dec 2021
Module 9
States

States SST
States are defined by state definitions

¡ Inherit
features (e.g., entry, exit, and do actions) from its state definition
¡ Features can be redefined
«state»
vehicleStates : «state def»
VehicleStates
actions actions
entry
do
exit
56 13 Dec 2021
State-based Behavior [1] SST
States decompose into nested states (without regions, which were in SysML v1)
¡A parallel state decomposes into concurrent states
¡ A non-parallel state (default) decomposes into sequential/exclusive states
Transitions between sequential states

¡ Triggered by events
¡ Can include guard and action

«state»
vehicleStates
«parallel»
«state» «state»
operatingStates healthStates
vehicelOff «state»
«state» «state» «state»
on
off normal maintenance
do providePower
...
vehicleStart
[brakePedalDepressed]
/ send engineHealthStatus to driver
«state» «state»
...
starting
[vehicleStarted]
degraded
57 13 Dec 2021
State-based Behavior [2] SST
States can have entry, exit, and do actions that can refer to actions in action
trees or be defined locally
States can include constraints (i.e. SysML v2 state invariants)
«state»
operatingStates
«state»
on
«state» vehicleOff
entry performSelfTest
off
do providePower
exit applyParkingBrake
vehicleStart
assert constraints
[brakePedalDepressed] {electricalPower <= 500 @[W]}
/ send engineHealthStatus to driver
«state»
starting
do startEngine [vehicleStarted]
exit send engineStartStatus to driver
58 13 Dec 2021
Part Exhibits States SST
A part that exhibits states can refer to state-based behavior
«part»
vehicle_b:Vehicle «state»
vehicleStates
perform actions «parallel»
providePower «state» «state»

operatingStates healthStates
applyParkingBrake «state»
«state» vehicelOff «state» «state»
performSelfTest off
on
do providePower
normal maintenance
...
vehicleStart
exhibit states [brakePedalDepressed]
vehicleStates / send engineHealthStatus to driver
«state» «state»
...
starting
[vehicleStarted]
degraded
59 13 Dec 2021
Module 10
Interactions

Sequences SST
Represents a sequence of messages between send and accept actions

¡ Asynchronous – sender does not wait for reply
¡ Synchronous – sender waits for reply (under discussion)
«part»
missionContext
perform action startVehicle
«part» «part»
driver:Driver vehicle_b:Vehicle
vehicleStart
engineHealthStatus
startEngine
engineStartStatus
61 13 Dec 2021
Module 11
Individuals

Individuals SST
An individual definition is a unique member of a class with identity

¡A specialization of a class, having only one member
¡ Has a unique lifetime
An individual is a usage that is defined by an individual definition

¡ Can subset a part to represent a particular configuration
¡ Can have different configurations across Vehicle-1 lifetime
«part»
engine:Engine
«part»
vehicle_b:Vehicle : «part def»
Vehicle
attributes
vin:Integer
mass
«indvidual»
vehicle_b:Vehicle-1 : «Individual def»
Vehicle-1
attributes
vin :>> vin = 1
^mass
63 13 Dec 2021
Module 12
Timeslices & Snaphots

Lifetime with SST
Snapshots and Time Slices
Each individual definition has a unique lifetime «Individual def»
Vehicle-1
¡ Begins when it is created attributes

vin :>> vin = 1
^mass
¡ Ends when it is destroyed
Individual usage exists over some portion of «individual»
vehicle_b:Vehicle-1
Vehicle-1 lifetime
Individual lifetime can be segmented into timeslices
(i.e., durations of time) «timeslice»
vehicle_b-t0->t1:Vehicle-1
attributes
A timeslice whose duration is zero is a snapshot ^vin = 1
¡ Beginning and ending snapshot of a time slice is

designated as start and done snapshot
The condition of an individual for a timeslice or «snapshot»
«snapshot»
snapshot can be specified in terms of the values of vehicle_b-t0:Vehicle-1 vehicle_b-t1:Vehicle-1
attributes
attributes
its features tstart = 0 [min] tdone =1 [min]
^vin = 1
^vin = 1
mass = 1550 [kg] mass = 1549.9 [kg]
position = 0 [m] position = 1 [km]
velocity = 60 [km/hr] velocity = 60 [km/hr]
acceleration = 0 acceleration = 0
65 13 Dec 2021
Individuals Playing Different Roles SST
An individual can play different roles and have different configurations in different timeslices
§ Individual wheel (wheel-1) is left front wheel during vehicle_b_t1-t2 timeslice
§ Individual wheel (wheel-1) is right front wheel during vehicle_b_t2-t3 timeslice
«part»
vehicle_b:Vehicle
part «part»
leftFront:Wheel
«part»
rightFront:Wheel
redefine «indvidual»
vehicle_b:Vehicle-1
temporal
Individual timeslice
«timelice»
vehicle_b_t1->t2
«timeslice»
vehicle_b_t2->t3
decomposition
«individual» «individual»
individual leftFront:Wheel-1 rightFront:Wheel-1 individual
«individual»
rightFront:Wheel-2
«individual»
leftFront:Wheel-2
66 13 Dec 2021
Module 13
Expressions and Calculations

Expressions SST
Used to compute a result

Default value means value can be over-ridden using redefinition
Library of mathematical functions (e.g., sum, max, …)
¡ Includes arithmetic operators that also apply to vectors and tensors
«part»
vehicle_b:Vehicle
attributes
mass ::>> mass=dryMass+cargoMass+fuelTank::fuel::fuelMass
dryMass :>> dryMass=sum(partMasses)
cargoMass :>> cargoMass default 0 [kg]
partMasses=(fuelTank.mass,frontAxleAssembly.mass,rearAxleAssembly.mass,engine.mass,transmission.mass,driveshaft.mass)
68 13 Dec 2021
Calculations SST
A kind of behavior generally used to represent reusable mathematical functions

«calc def»
¡ Inputs Force
«calc» «calc»
force:Force force:Force
¡ Expression parameters parameters
parameters
in m :> ISQ::mass in m=1500 [kg]
in a=9.806 [m/s^2] in m=1500 [kg]
¡ Returns a single result in a :> ISQ::acceleration return :> ISQ::force in a=9.806 [m/s^2]
return :> ISQ::force return :> ISQ::force = m*a
result
result m*a
m*a Do not repeat expression
in usage if in definition
Represent a calculation using the textual notation
¡ calc
def Force (m:>ISQ::mass, a:>ISQ::acceleration) :>ISQ::force = (m * a);
Evaluate usage
¡ Bind values to input parameters. Then evaluate expression and return a result
¡ calc force : Force (m=1500 [kg], a=9.806 [m/s^2]) f;
¡ f = Force (m=1500 [kg] , a = 9.806 [m/s ^2])
Usage can be owned by a part, action, constraint, package, ….

69 13 Dec 2021
Binding Connection SST
A binding is a kind of connection where both sides of the connection are asserted
to be equal at all times
¡ Symbol is «bind» or =
¡ If both sides are not equal, the model is invalid (e.g., 3=4) is invalid
¡ A tool could make both sides equal if the values are not the same
§ In the above example, the values can be set to (3=3) or (4=4)

§ For y = x+3, when x is 1, then y can be set to 4 so that both sides are equal
¡ Different from the Boolean operator ‘==’, which evaluates whether both sides
of the ‘==’ have the same value or not, and returns a value of true or false
(e.g., {3==4} returns a value of false)
Binding is used more broadly to establish equality of any kind of feature
¡ A part can be set to be the same value (e.g., engine = engine4cyl)
¡ A port on a composite part can be bound to a port on a nested part to

constrain them to have equal values
70 13 Dec 2021
Module 14
Quantities & Units

Quantities and Units SST
Quantity is an attribute (e.g., mass)

Quantity is defined by an attribute def of a quantity kind (e.g., MassValue)
Units conform to the quantity kind
Units are associated with the value
A change in a unit will apply the unit conversion factor (if a tool supports this)
¡ attribute m:MassValue = 25 [kg] (if kg is changed to lbs, the value is changed to 55.1 [lbs])
¡ In
SysML v1, a change in unit requires a change in the value type
Complex quantities and units can be derived from primitive quantities and units
Libraries
¡ International System of Quantities (ISQ)
¡ International System of Units (SI)
¡ US Customary Units (USCustomaryUnits)
72 13 Dec 2021
Module 15
Constraints

Constraint Expression [1] SST
A Boolean expression that evaluates to true or false, which includes

¡ Constraint operators (==), (>), (>=), (<), (<=), (!=)
§ Used to compare expressions (e.g., {a < b})
¡ Boolean operators include and (&), or (|), xor (^), not (!)
§ Used to logically combine expressions (e.g., {A and B or C})
Asserting a constraint to be true means the evaluation must be true for the model to be valid
part def FuelTank { «part def»

FuelTank
attribute mass :> ISQ::mass;
ref item fuel:Fuel{ constraints
assert {fuelMass<=fuelMassMax}
attribute redefines fuelMass;
}
«item»
attribute fuelMassMax:>ISQ::mass; fuel:Fuel
assert constraint {fuel.fuelMass<=fuelMassMax}
}
74 13 Dec 2021
Constraint Expression [2] SST
Usage inherits constraint expression
«part def»
FuelTank «part»
fuelTank:FuelTank
constraints constraints
assert {fuelMass<=fuelMassMax} âssert {fuelMass<=fuelMassMax}
«item» «item»
fuel:Fuel fuel1:>>fuel
75 13 Dec 2021
Constraint Definition SST
A reusable constraint expression

Default parameter direction is ‘in’
Can assert a constraint on the usage
Bind parameters on the usage
Identify dependent parameters as derived
«constraint def» «assert constraint»

StraightLineDynamics
sld:StraightLineDynamics
parameters subject=vehicle_b
power :> ISQ::power
m :> ISQ::mass parameters
delta_t :> ISQ::time power = engine.peakHorsePwr
x_in :> ISQ:: length
m=mass
v_in:>ISQ:: speed
x_out :> ISQ::length delta_t = delta_t
v_out :> ISQ::speed x_in = position
a_out :> ISQ::acceleration v_in = speed
expression
/x_out = position_delta_t
a_out == power/(mass*v_avg) & /v_out = speed_delta_t
v_out == v_in +a_out*delta_t & /a_out = acceleration
x_out == x_in+v_avg*delta_t
76 13 Dec 2021
Binding Constraints SST
Equivalent to SysML v1 parametric diagram
«part»
context
«part»
«assert constraint» vehicle_b:Vehicle
sld:StraightLneVehicleDynamics
= «attribute»
/a_out
acceleration
power
«part»
=
engine:Engine
«attribute»
«assert constraint» power
= peakHorsePwr
fec:FuelEconomy
77 13 Dec 2021
Module 16
Requirements

Requirement Definition SST
A constraint definition that a valid design solution must satisfy that can include:
¡ Identifier
¡ Shall statement
¡ Constraint expression that can be evaluated to true or false

§ can apply to performance, functional, interface and other kinds of requirements if desired
¡ Assumed constraint expression that is asserted to be true for the requirement to be valid
¡ Attributes of the constraint expressions
«requirement def»
MassRequirement
doc The actual mass shall be less than
the required mass.
79 13 Dec 2021
Requirement Specification SST
A tree of requirements that contains nested requirement usages
¡ Requirement group can own or reference other requirements
¡ Subject of nested requirements is the kind of entity being specified
¡ Requirement features can redefine features of the requirement definition
requirement group «requirement group»

vehicleSpecification
subject subject v:Vehicle
«requirement» «requirement group»

<1> massReqt:MassRequirement reqt id <2> fuelEconomyRequirements
doc The actual vehicle mass shall be

less than the required vehicle mass.
«requirement» «requirement»
<2_1> city:FuelEconomyRequirementl <2_2> highway:FuelEconomyRequirement
assumption
80 13 Dec 2021
Satisfying a Requirement SST
The vehicleSpecification is used to impose constraints on the vehicle

¡ The modeler can assert the vehicle mass satisfies the mass requirement
§ Bind the vehicle mass to massActual of the requirement
«requirement group»
subject v:Vehicle
«requirement»
<1> massReqt:MassRequirement «part»
vehicle_b:Vehicle
doc The actual vehicle mass shall be
less than the required vehicle mass. attributes
:>>mass = dryMass + fluidMass
:>>dryMass=sum(partMasses)
:>>fluidMass = 36 @[kg]
…
requirements
constraints
satisfy vehicleSpecification
^require {massActual<=massRequired}
massReqt.massActual = mass
assume {massFluid<=40 @[kg]}
massReqt.massFluid = fluidMass
81 13 Dec 2021
Module 17
Use Cases

Use Case SST
A kind of case
¡ Subject of the use case (often the system of interest)
¡ Objective is to provide value to one or more stakeholders
§ Stakeholders are typically external to the system of interest referred to as actors
¡ Actions/steps performed by actors and subject are required to achieve the objective
¡ Include use cases are always performed as part of the base use case
«use case def» «subject»
TransportPassenger ^vehicle
subject vehicle:Vehicle
objective
doc Deiver passenger to destination
safely, comfortably, and within
accecptable time
^driver:Driver «use case» «actor»
transporttPassenger:TransportPassenger road:Road
^passengers:Passenger [0..4] «include» «include»
«use case» «use case»

getInVehicle:GetInVehicle getOutOfVehicle:GetOutOfVehicle
83 13 Dec 2021
Module 18
Analysis Cases

Analysis Case SST
A set of steps with an objective to evaluate a
«analysis»
result about a subject of the analysis fuelEconomyAnalysis
subject v = vehicle_b
¡ A kind of behavior
¡ Each step can be an action, calc, or an
analysis case that can contain
§ subject
§ objective
§ input and output parameters
§ Single return parameter (i.e., the result)
§ Attributes bound to calculations and/or
constraints to be solved by a solver
§ Bind input & output parameters to the
subject convert to liters / 100 km
«analysis»
vehicleAnalysis
«analysis» «analysis»
straightLineDynamics fuelEconomyAnalysis
85 13 Dec 2021
Trade-off Analysis SST
A kind of analysis case

¡ Trade study objective is to select preferred solution
that maximizes or minimizes some evaluation function
¡ Subject of the trade study are the vehicle alternatives «analysis»
engineTradeOffAnalysis:TradeStudy
with different engines subject vehicleAlternatives [2]) :> vehicle_b
§ Alternatives can be modeled as variants objective :MaximizeObjective
¡ Evaluate evaluation function for each alternative doc Select vehicle alternative with the engine
whose evaluation function returns the max value
§ Criteria are parameters of evaluation function
alternatives
§ Each criteria may require separate analysis vehicle_b_engine4cyl:>vehicleAlternatives
vehicle_b_engine6cyl:>vehicleAlternatives
¡ Rationale is a kind of annotation
calcs
:>> evaluationFunction {
in part vehicle:>vehicle_b;
return attribute eval:Real=EngineEvaluation
(vehicle.engine.mass,
vehicle.engine.peakHorsePower,
vehicle.engine.fuelEfficiency,
vehicle.engine.cost)}
86 13 Dec 2021
Module 19
Verification Cases

Verification Case SST
A set of steps with an objective to «part»
evaluate whether the subject of the verificationContext
verification satisfies one or more

requirements «part»
vehicle_b:Vehicle
attributes
¡ A kind of behavior :>>mass = dryMass + fluidMass «part»
:>>dryMass=sum(partMasses)
verificationSystem
¡ Steps typically include collect data,
:>>fluidMass = 36 @[kg]
process/reduce data, evaluate result … requirements

«perform»
satisfy vehicleSpecification «verification»

¡ Input is the subject of the verification massReqt::massActual = mass
massReqt::massFluid = fluidMass
«verify»
massVerificationTest
subject v:Vehicle:>vehicle_b
¡ Returns a result called a verdict

objective
doc Verify massRequirement is satisfied
whose value is pass, fail, inconclusive, actions

or error collectData
processData
evaluateResult
¡ Verify relationship binds verification
case to subject
¡ Verification case is performed by a «verification»
massVerificationTest
verification system in a context v:Vehicle verdict
«action» «action» «action»
collectData processData evaluateResult
88 13 Dec 2021
Module 20
Dependency and Allocation
Relationships

Dependency SST
A directed relationship where the element on the client end may be impacted
when the element on the supplier end changes
¡ Example: Use of dependency to represent traceability between specification
and source document
¡ Can have 1.. many clients and 1.. many suppliers
«item»
supplier
marketSurvey
dependency
client «requirementGroup»
90 13 Dec 2021
Allocation SST
A statement of intent that assigns responsibility
from one set of elements to another set of elements
¡ A kind of mapping (1 to n) «part» «allocate» «part»
torqueGenerator powerTrain
¡ Includes definition and usage
perform actions
generateTorque
¡ Can include suballocations
Examples «part»
«allocate» engine:Engine
¡ Actions to components
perform actions
¡ Logical components to physical components
generateTorque
¡ Logical connections to physical connections

The torque generator
¡ Budget allocation (e.g. weight budget) Is allocated to the powertrain,
¡ Software to hardware and realized by the engine
¡ Requirements to design elements
¡…
91 13 Dec 2021
Module 21
Annotations

Annotations SST
«part»
An Annotating Element is an Element that is used to provide vehicle_b:Vehicle
additional information about other elements «comment»
¡ Can be named Refer to document xyz

for full description
¡ Can apply to 0.. many elements

An annotation is a kind of relationship that relates the «action»
generateTorque
annotating element to the element being annotated
«rep»
Kinds of annotating elements language MATLAB
body {
¡ Comment x= ….
y= …
§ Documentation is an owned comment }.
¡ Textual representation (e.g., opaque expression)

«analysis»
§ Includes name of language and body straightLineDynamics
¡ Annotating feature «metadata»
§ Used to add structured metadata ToolMetadata

toolName = “Tool_X”
toolURL = “…”
behaviorName = “Compute vehicle state”.
93 13 Dec 2021
Metadata SST
Use metadata to mark elements

¡ Identify parts that are Security or Safety parts (e.g., members of Security of Safety group)
¡ Can add additional security and safety information
«part»
vehicle_b:Vehicle

engine:Engine transmission:Transmission driveshaft:Driveshaft
«part» «part»
interior:Interior bodyAssy:BodyAssy
«part» «part» «part» «part» «part» «part» «part» «part» «part»

frontSeat [2] seatBelt [2] driverAirBag alarm sunroof:Sunroof [0..1] doors:Door [2..4] body bumper [2] keylessEntry
metadata metadata metadata attributes metadata metadata
Safety Safety Security color:Colors Safety Security
isMandatory=true isMandatory=false isMandatory=true
Marked as a security part

Marked a safety part
Additional info: isMandatory
94 13 Dec 2021
Module 22
Element Filters

Element Filters SST
Used to select elements from a group of elements
¡ Create a package
¡ Import the part of the model that contains the elements of interest
§ Use a recursive import to include all nested elements

¡ Define the filter expression to select the imported elements based on the
selection criteria
Safety
Safety Security Safety &
Parts
Parts Parts Security Parts
filter @Safety filter @Security filter @Safety & @Security
Parts Tree Parts Tree Parts Tree
Filter selects parts marked with Safety metadata
96 13 Dec 2021
Module 23
View & Viewpoint

View and Viewpoint SST
A Viewpoint reflects the concerns of one more stakeholders in terms of what they care
about relative to a domain of interest
A View specifies an artifact to present to a stakeholder to satisfy their viewpoint
¡ Exposes the scope of the model to be viewed
¡ Filters the model to select a particular subset based on a scope and filter criteria
¡ Renders the filtered results using a particular presentation form and style
¡ Intended to support document generation (e.g., OpenMBEE)
«view» «viewpoint»
vehiclePartsTree
structure
viewpoint
«expose» stakeholders
Requirements PartsTree structure
architect
concerns
system breakdown
ActionTree States
Include rendering
in view compartment
98 13 Dec 2021
SysML v2 Views and Diagrams SST
A view artifact (e.g., diagram, table, document) is a rendering of a set of model
elements that is specified by a view usage
¡ Frame represents a view that renders model elements which are exposed and filtered
¡ View definition (e.g., diagram kind)
¡ View name (e.g., diagram name)
¡ View content
view vehicle requirements : Requirements Tree
«requirement group»
subject vehicle:Vehicle
«requirement» «requirement group»

[1] massReqt:MassRequirement [2] fuelEconomyRequirements
text
The actual vehicle mass shall be less
than the required vehicle mass.
«requirement» «requirement»
[2.1] city:FuelEconomyRequirementl [2.2] highway:FuelEconomyRequirement
99 13 Dec 2021
SysML v2 Diagrams / Views SST
Standard diagram kinds / view definitions (topology and filter)

§ Relationship view (general graph with navigable nodes and
edges)
§ Tree/ hierarchy view (i.e., a relationship view that filters on
membership)
§ Nested/interconnection view
§ Tabular/Matrix view
§ Textual view
§ Additional constraints (temporal, spatial ordering, swim lanes)
A diagram/view can contain nested diagrams/views (e.g., sub views)
User defined views and view definitions
¡ Users are not constrained by the standard views
100 13 Dec 2021
SysML v2 Compartments SST
Compartments are views of the element represented by the node «part def»
Vehicle
Compartment names represent view definitions attributes
mass:>ISQ::mass
Standard compartments / view definitions dryMass
cargoMass
electricalPower
¡ List view of contained elements of a particular kind (e.g., position
velocity
attributes, actions, ports) acceleration
...
¡ List view of elements at the other end of relationships (e.g., ports
pwrCmdPort
allocation, specialization, …) ...

vehicleToRoadPort
perform actions
A compartment can be rendered using textual (e.g., list view) or providePower
provideBraking
graphical notation ...
controlDirection
Nested view is a kind of graphical compartment where elements exhibit states

vehicleStates
are represented as graphical symbols
Ports are connectable nodes on the boundary of a part
101 13 Dec 2021

Module 24
Language Extension

Language Extension SST
In Process
SysML Model
Provides ability to extend concepts in SysML v2 to Library
address domain-specific concepts and
terminology «item»
items
Define concept by subclassing an element in the
SysML Model Library
«itemUsage»
Apply the concept to an element define the concept failure mode
«part»
Tire
apply the concept «failure mode»

flatTire
104 13 Dec 2021

Summary

Contrasting SysML v1 with SysML v2 SST
Simpler to learn and use More expressive
¡ Systems engineering concepts designed ¡ Variant modeling
into metamodel versus added-on ¡ Analysis case
¡ Consistent definition and usage pattern ¡ Trade-off analysis
¡ More consistent terminology ¡ Individuals, snapshots, time slices
¡ Ability to decompose parts, actions, … ¡ More robust quantitative properties
More precise (e.g., vectors, ..)
¡ Textual syntax and expression language ¡ Filter expressions
¡ Formal semantic grounding More extensible

¡ Requirements as constraints ¡ Simpler language extension capability
¡ Reified relationships (e.g., membership, § Based on model libraries
annotation) More interoperable
¡ Standardized API
106 13 Dec 2021

References SST
Monthly Release Repository (release 2021-08)

¡ https://github.com/Systems-Modeling/SysML-v2-Release
SysML v2 Specification (revised submission)

¡ Note: refer to Annex B for Example Vehicle Model using textual notation
Introduction to the SysML v2 Language Textual Notation (release 2021-08)
Friedenthal S., Seidewitz E., A Preview of the Next Generation System Modeling
Language (SysML v2), Project Performance International (PPI), Systems
Engineering Newsletter, PPI SyEN 95 27 November, 2020
107 13 Dec 2021

Intro To The SysML v2 Language-Graphical Notation

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Intro To The SysML v2 Language-Graphical Notation

Uploaded by

Copyright:

Available Formats

SST

Introduction to the SysML v2 Language

 The graphical representation is intended to complement the textual noation

4 Copyright © 2021 by Sanford Friedenthal 13 Dec 2021

5 Copyright © 2021 by Sanford Friedenthal 13 Dec 2021

Increase adoption and effectiveness of MBSE

 Precision and expressiveness of the language

 New Metamodel that is not constrained by UML

 Robust visualizations based on flexible view & viewpoint specification and

 Standardized API to access the model

 SysML v2 includes consistent usage/definition terminology

part vehicle : Vehicle {

Tom Sawyer Visualization Prototype

13 Copyright © 2021 by Sanford Friedenthal 13 Dec 2021

 Example: Definitions package contains packages to define different kinds of

PartDefinitions ItemDefinitions ActionDefinitions

AttributeDefinitions SignalDefinitions StateDefinitions

PortDefinitions InterfaceDefinitions RequirementDefinitions

 no star is element import «import»

 Imports can apply to any namespace, but

 A qualified name of a model element is prepended by the name of its owner

20 Copyright © 2021 by Sanford Friedenthal 13 Dec 2021

¡ Action definition «action def» attributes

§ Enables entry, exit, and do actions actions

 Definition elements can be specialized

 An inherited feature can be redefined by a «port def»

feature whose definition is more specialized directed features

¡ The more specialized feature overrides the

¡ Symbol for redefines (:>>) directed features

25 Copyright © 2021 by Sanford Friedenthal 13 Dec 2021

 Other kinds of usage elements are defined by specific kinds of definition

¡ Ports defined by port definition

¡ Items defined by item definition

¡ Actions defined by action definition

¡ States defined by state definition

 A data type whose range is restricted to a set of discrete values

part without «part»

29 Copyright © 2021 by Sanford Friedenthal 13 Dec 2021

engine transmission driveshaft rearAxleAssembly fuelTank

differential rearAxle rearWheel1 rearWheel2

 A parts tree is a composition of a part from other parts

«part» «part» «part» «part» «part»

«part» «part» «part» «part»

¡ Can add new parts

«part» «part» «part» «part» «part» «part»

«part» «part» «part» «part»

«part» «part» «part»

reference bind bind reference

 A part can refer to an item that it stores

 Defines the number of features (e.g., parts) in a particular context

¡ Default multiplicity is [1..1]

¡ Optional multiplicity [0..1]

«part» «part» «part»

35 Copyright © 2021 by Sanford Friedenthal 13 Dec 2021

 An interface defined by an interface definition is used to connects parts

item flows p2 : ~FuelOutPort

 Wheel to Hub interface specifies a compatible connection

 Usage of Wheel to Hub interface definition connects

ports «interface def»

39 Copyright © 2021 by Sanford Friedenthal 13 Dec 2021

 Vehicle family is the superset model (150%)

«variant» «variant» «variant» «variant»

 vehicle_a subsets vehicleFamily to represent a particular design configuration

The graphical representation is intended to complement the textual noation

Precision and expressiveness of the language

New Metamodel that is not constrained by UML

Robust visualizations based on flexible view & viewpoint specification and

Standardized API to access the model

SysML v2 includes consistent usage/definition terminology

Example: Definitions package contains packages to define different kinds of

no star is element import «import»

Imports can apply to any namespace, but

A qualified name of a model element is prepended by the name of its owner

Definition elements can be specialized

An inherited feature can be redefined by a «port def»

Other kinds of usage elements are defined by specific kinds of definition

A data type whose range is restricted to a set of discrete values

A parts tree is a composition of a part from other parts

A part can refer to an item that it stores

Defines the number of features (e.g., parts) in a particular context

An interface defined by an interface definition is used to connects parts

Wheel to Hub interface specifies a compatible connection

Usage of Wheel to Hub interface definition connects

Vehicle family is the superset model (150%)

vehicle_a subsets vehicleFamily to represent a particular design configuration

Actions are defined by action definitions

Actions can be decomposed in a similar way as parts

A part that performs an action can refer to an action in an action tree

Action flows can include control flows and input/output flows

States are defined by state definitions

Transitions between sequential states

A part that exhibits states can refer to state-based behavior

Represents a sequence of messages between send and accept actions

An individual definition is a unique member of a class with identity

An individual is a usage that is defined by an individual definition

Used to compute a result

A kind of behavior generally used to represent reusable mathematical functions

Usage can be owned by a part, action, constraint, package, ….

Quantity is an attribute (e.g., mass)

A Boolean expression that evaluates to true or false, which includes

Usage inherits constraint expression

A reusable constraint expression

Equivalent to SysML v1 parametric diagram

The vehicleSpecification is used to impose constraints on the vehicle

A kind of analysis case