1. SysML 2.0 Formalism: Semantics Introduction, Requirements & Benefits/Use Cases
Formalism WG
March 21, 2017

2. Overview Language Definition Introduction
Language Definition Requirements & Benefits/UseCases
Language Feature Requirements (Status)

3. Overview Language Definition Introduction
Language Definition Requirements & Benefits/UseCases
Language Feature Requirements (Status)

4. Language Definition = Syntax + Semantics + Vocabulary
Concrete: What you see (rectangles, lines, text).
Abstract: What you say (“block”, “item flow”)
Interchange/API: What computers read/write.
Semantics
What’s possible to conclude about the things being modeled when using the syntax.
Vocabulary (libraries)
(Predefined) model elements (Engine, Propellor, weight).

5. Example: Natural Language
Syntax = grammar
Concrete: Verbs appear between nouns (in English)
Abstract: ‘Verb’, ‘Noun’, ‘subjectNoun’, ‘objectNoun’.
Interchange/API: UNICODE
Semantics
Verbs between nouns => Objects described by the nouns are involved in behaviors described by the verbs.
Vocabulary (dictionary) = words
Particular nouns (‘mountain’, ‘road’) and verbs (‘climb’, ‘drive’).

6. Example: Natural Language
Concrete
Syntax
Verbs appear between nouns
subject
Langauge
Definition
Abstract
Syntax
Verb
predicate
Sentence
Noun
object
Objects described by nouns are involved in behaviors described by verbs
Semantics
Model
(as CS)
(as AS)
«lib»
Dog
Chase
predicate
subject
object
chases cat
‘Dog chases cat’
Cat
Using the
Language
«isA»
Things
Described By Words
Fido
Fluffy
Fido chases Fluffy at 2pm ET March 1, 2017
‘Operations’
«describedBy»
Semantics
Applied
to Things
Being
Described
Fido and Fluffy are involved in a chasing behavior

7. Fido chases Fluffy at 2pm ET March 1, 2017
Example: SysML
Property names appear at the end of association lines
Concrete
Syntax
Langauge
Definition
Abstract
Syntax
type
Model
(as CS)
chases
owned
attribute
Cat
Dog
«instanceOf»
Using the
Language
(as AS)
type
Block
Property
Properties have values on things
modeled by their owning block. The values are modeled by the property’s type
Semantics
‘Operations’
Things
Being Modeled
Fido
Fluffy
Fido chases Fluffy at 2pm ET March 1, 2017
«instanceOf»
chases
Fido must be a dog and Fluffy must be a cat
Semantics
Applied
to Things
Being
Modeled

8. Benefit: Uniform Interpretation
Formally defined, eg, Diagram Definition
Concrete
Syntax
Langauge
Definition
Abstract
Syntax
Formally defined
= about the things
being modeled
Semantics
Using the
Language
Model
«instanceOf»
SysML Semantics
Interpreting the
Language
«interprets»
«implementedBy»
Semantics Applied Manually to Things Being Modeled
‘Operations’
Things
Being Modeled

9. Benefit: Uniform Interpretation (Automated)
Formally defined, eg, Diagram Definition
Concrete
Syntax
Abstract
Syntax
Langauge
Definition
Formally defined
= about the things
being modeled
Semantics
Using the
Language
Model
SysML
Semantics
‘Operations’
Things
Being Modeled
Interpreting the
Language
«interprets»
«controlledBy»
Semantics Applied
Automatically to Things Being Modeled
«implementedBy»
By Tooling Built Manually

10. Informal Semantics Syntactic metaphors that suggest formal semantics
Inheritance (suggesting generalization semantics)
Token flow (suggesting temporal semantics)
Shorthand expansions
Property means property of a block (instead of property semantics).
Application/methodology
Requirement, design, test (instead of classification semantics)

11. Overview Language Definition Introduction
Language Definition Requirements & Benefits/UseCases
Language Feature Requirements (Status)

12. Requirements (General)
Uniform syntactic interpretation
Everyone looking at SysML diagrams should
Describe them the same way (using SysML terminology).
Agree on whether they are“legal” SysML (well-formedness).
Uniform semantic interpretation
Reach the same conclusions about the things being modeled.
Including whether it is possible to draw any conclusions at all (consistency).
Everyone = Modelers, teachers, consultants, spec writers, modeling / execution / analysis tool builders

13. Requirements Review (FML 1)
SysML 2.0 shall have a declarative semantics expressed in mathematical logic and/or other semantics with a translation to declarative semantics in mathematical logic.
Benefits:
Reduced ambiguity: Semantics expressed in natural language causes miscommunication between users, and diverging implementations. This requirement (combined with S2) enables vendors to build tools for model checking, execution/simulation, and analysis that give the same results for the same models. Then users can learn a consistent SysML semantics by using these services on their models.
More integrated language: Some engineering concepts are inherently different but must be integrated, such as structure and behavior. This requires abstractions that apply to both, but are not engineering-specific, i.e. mathematical, enabling SysML to integrate its concepts better.

14. Mathematical Logic Example
UML Generalization
From UML 2.5 Specification:
Vehicle
“Every instance of car is an instance of vehicle”
Car
How can this be specified more precisely?

15. Mathematical Logic Example
OWL SubClassof
subset of
Vehicles
SubClassOf(Car, Vehicle)
Cars
= a thing
From OWL 2 Direct Semantics:
CE denotes a class expression; ⋅ C is the class interpretation function that assigns to each class C ∈ VC a subset (C)C ⊆ ΔI

16. Benefit: Uniform Interpretation (Automated)
subset of
Abstract
Syntax
Langauge
Definition
Formal
Semantics A = B
Using the
Language
Model
SysML
Semantics
«interprets»
SysML
Semantics
Semantics Applied
Automatically to Things Being Modeled
By Tooling Built Manually
«implementedBy»
Interpreting the
Language
«implementedBy»
«controlledBy»
Things
Being Modeled
‘Operations’

17. Requirements Review (FML 2)
SysML 2.0 semantics shall be modeled in domain-independent SysML 2.0 model libraries that are automatically used when models are created.
Benefits:
Makes the mathematical semantics of S1 accessible to non-mathematicians.
Simplifies the language when model libraries can be used without additional abstract syntax (reduces the amount of abstract syntax).
Enables SysML to be improved and extended more easily by changes and additions to model libraries, rather than always through abstract syntax.

18. Requirements Review (FML 3)
SysML 2.0 abstract syntax shall be independent of notation.
Benefits:
Support non-SysML visualizations: Engineers and project managers need a wide variety of visualizations for information captured in models, including non-SysML graphics, tables, and reports. SysML’s abstract syntax should not inhibit creating these visualizations.
Simpler model and tool construction: Sometimes the same notion has multiple standard notations in SysML, such as temporal precedence in interations, state machines, and activities. The abstract syntax should represent these notions once. This makes is it easier for modelers to keep diagrams consistent and for vendors to construct tools that operate on models (model checking, execution/simulation, analysis).

19. Requirements Review (FML 4)
SysML 2.0 syntax shall be modeled formally (including syntactic constraints).
Benefits:
Reduced ambiguity: Syntax expressed in natural language, such as abstract syntax constraints, causes miscommunication between users, and diverging implementations. This requirement enables vendors to build tools for model construction and checking that give the same results. Then users can learn SysML consistently across tools.

20. Requirements Review (FML 5)
Any SysML 2.0 concrete syntax shall include a model and interchange format/API for diagram/text information that is not included in the abstract syntax, but is linked to the abstract syntax (e.g., DD).
Benefits:
Enables diagrams to look the same across tools, at least for those aspects that modelers control (e.g., node positioning and line routing).

21. Requirements Review (FML 6)
All examples of notation in the SysML 2.0 specification shall be accompanied by instances of the syntax models. 
Benefits:
The Model Interchange Working Group (MIWG) found that most tool interchange problems were due to differences in translating graphics to instances of abstract syntax. Providing models for all diagrams in the specification will help iron out these differences.

22. Requirements Review (FML 7)
Where SysML 2.0 is extensible, the syntax, semantics, and model libraries shall all be extensible.
Benefits:
Language specification includes syntax, semantics, and vocabulary, so extending a language requires all of these to be extensible.

23. Requirements Review (FML 8)
SysML 2.0 syntax shall be specified in a subset of SysML 2.0.
Benefits:
Enables SysML to be defined, implemented, and extended without learning a separate language.

24. Overview Language Definition Introduction
Language Definition Requirements & Benefits/UseCases
Language Feature Requirements (Status)

25. Language Features Requirements
Requirements on the language itself rather than how it is defined.
Inspired by formal approaches.
Currently considering:
Graphical specification of derived properties and relationships
Distinguish classification vs capabilities
Learning curve reduction & model sketching
Logic modeling

26. Graphical specification of derived properties and relationships26

27. Classification vs Capability Features
Are block features always available?
Classification: No.
Capability: Yes.
If I have a plane with tail # “ER284H”, can it be
given a crew? Maybe, if it’s not an UAV.
flown? Yes, otherwise it’s not a plane.
Plane
crew : Person [0..*]
flown : Flight [0..*]
tail# : String
ER284H : Plane
crew = ?
flown = ?
tail# = “ER284H”
UAV
crew : Person [0]
^flown : Flight [0..*]
Plane
crew : Person [0..*]
flown : Flight [0..*]
UAV
crew : Person [0]
^flown : Flight [0..*]
FlownPlane
^crew : Person [0..20]
flown : Flight [1..*]
UnflownPlane
^crew : Person [0..20]
flown : Flight [0]

28. Figure 9.15 - Usage example of item flows in internal block diagrams
Item Flow Example
Figure Usage example of item flows in internal block diagrams
Modeler thought the upper right item flow meant any fluid could flow (capability), not just water, as indicated by the flow properties.
It’s actually only a classification.

29. Figure 9.16 - Usage example of item flow decomposition
Item Flow Example
Figure Usage example of item flow decomposition
Only pistons, crankshafts, and cams flow, not any engine part.

30. Logic Modeling
Results
Graphical Logic Modeling
Benefits

31. Formalism Use Cases (Hybrid SUV)
Engineers identify a set of hazards associated for the vehicle. They capture this material in the system model, along with potential mitigations that are tied to elements of the design. Throughout the design process, the engineers put together analyses (fault trees, formal verification, etc.), while the SME automatically constructs the assurance case arguments (using the hazards, mitigations, analyses and design information tied to the mitigations) which expresses whether or not the system is safe to use.
Engineers identify undesirable events (combinations of states, actions, interactions, values, etc.) during design and use the SME to automatically generate fault trees to study how they can improve the design to avoid these events.

32. Formalism Use Cases (Hybrid SUV)
Engineers for the Hybrid SUV acquire a model for a component they would like to use with their design. The documentation references the verification of the design obtained by using reasoning tool that the engineers do not have. When the engineers download the model and integrate it with theirs, they know any inconsistencies found by their own reasoners are not due to flaws internal to the component’s design.

33. Questions/Comments?