Module 1: Foundations
What SysML v2 is, where it came from, and the foundational KerML layer that makes it precise. After this module, you will understand the "why" behind the language design.
What is SysML v2?
Imagine building a large factory. Before construction starts, you need many drawings — floor plans, electrical diagrams, plumbing layouts… each describes one aspect of the factory. Systems engineering is the same. Engineers building complex systems (aircraft, rockets, medical devices) need a structured language to describe every aspect of the system before it is built. SysML v2 is that language.
SysML v2 is a standardised modelling language for engineers to describe and design complex systems — just as architects use CAD software, systems engineers use SysML v2.
Who created SysML v2?
SysML v2 was created by the Object Management Group (OMG) in collaboration with INCOSE (the International Council on Systems Engineering). It was officially released in 2024 as OMG specification ptc/2024-05-04 — the most current version.
SysML v2 ships with a companion API standard that allows different tools to exchange model data. This was not available in earlier versions and is one of the most important improvements.
What was wrong with SysML v1?
SysML v1 was released in 2006. It was adapted from UML (a software design language), which brought a lot of historical baggage irrelevant to systems engineering. SysML v2 is a clean redesign from first principles.
| SysML v1 limitation | SysML v2 improvement |
|---|---|
| Inherited many UML concepts unrelated to systems | Clean redesign based on KerML — no UML dependency |
| Many concepts had imprecise meanings, causing ambiguity | Strict mathematical definitions — unambiguous semantics |
| Only graphical notation | New textual notation (STN) — both graphical and textual |
| Tools could not exchange model files | Standard API — tools can interoperate |
| Behavioural modelling was awkward | Unified, cleaner behaviour modelling |
| Allocation had no standard syntax | Allocation has a defined, formal syntax |
KerML — The Language Foundation
Imagine building a city. Before any building goes up, you need foundations, roads, and utilities — the infrastructure that governs rules for every building. KerML is exactly this for SysML v2: it defines the most fundamental rules, and everything in SysML v2 is built on top of it.
KerML stands for Kernel Modeling Language. It is itself an independent OMG standard (ptc/2024-05-05). You usually do not write KerML directly — just as you do not build a water treatment plant before renovating your house — but understanding KerML's key concepts helps you understand why SysML v2 works the way it does.
KerML is the "unsung hero." It provides precise mathematical definitions that make the language rigorous and consistent. When SysML v2 feels organised and logical, you are feeling the effect of KerML.
KerML core concepts — step by step
Each concept below builds on the one before it.
Step 1 Element
📖 Simple: Everything in a model with a name.
🏠 Analogy: Like a "file or folder" in a file system — everything is one or the other.
📐 Technical: The root type. All KerML constructs are subtypes of Element. Carries name (declared name) and qualifiedName (fully qualified path).
Step 2 Namespace
📖 Simple: An Element that can contain other Elements — a container or scope.
🏠 Analogy: Like a folder on your computer — the folder itself is also a file, but it can hold other files.
📐 Technical: An Element that can own other Elements. Package, Type, and Feature are all subtypes of Namespace.
Step 3 Type
📖 Simple: A template describing "what a category of thing is like" — e.g. "the shared properties of all engines".
🏠 Analogy: Like a cookie cutter — the cutter itself is not a cookie, but it defines the shape. Many identical cookies can be made from one cutter.
📐 Technical: A Namespace that classifies things. Features describe the properties and behaviours of its instances. The isAbstract property controls whether the type can be instantiated directly.
Step 4 Feature
📖 Simple: A specific property or behaviour of a Type — e.g. the "power" attribute of an engine, or the "start" action.
🏠 Analogy: Like the entries on a CV — "name", "age", "work history" are all features of that CV.
📐 Technical: A typing attribute of a Type. Can be structural (attribute/part) or behavioural (action/step). Carries direction (in/out/inout), and whether it is composite (isComposite).
Step 5 Classifier
📖 Simple: A special Type whose instances are things that actually exist or happen (not abstract concepts).
🏠 Analogy: If Type is the concept of "animal", Classifier is specific categories like "mammal" or "bird" — things that actually exist in nature.
📐 Technical: A Type whose instances are things that exist or occur — structures, behaviours, events. The isSufficient property determines whether having all features is enough to classify something as this type.
Step 6 Class / DataType / Behavior
📖 Simple: Three kinds of Classifier: persistent objects (Class), pure values (DataType), time-unfolding processes (Behavior).
🏠 Analogy: A washing machine is a Class (it persists); its power rating "800W" is a DataType (a pure number, no identity); the wash cycle is a Behavior (it unfolds over time and ends).
📐 Technical: Class: instances have persistent identity (structures, existing over time). DataType: instances have no identity (pure values — numbers, strings). Behavior: instances are events that occur over time (actions, processes, functions).
Step 7 Connector
📖 Simple: A bridge linking two Features, describing the relationship between them.
🏠 Analogy: Like a wire in an electrical diagram — the wire itself is neither the power source nor the lamp, but it connects the two.
📐 Technical: A Feature that links Feature instances to each other. The semantic foundation for Connection, BindingConnector, and Flow. isDirected controls whether it has direction.
Step 8 Relationship (and its three subtypes)
📖 Simple: A bridge describing the relationship between two Elements. The three most important are: Specialisation (one is a subtype of another), Subsetting (one feature's values are a subset of another's), Redefinition (replace a parent feature in a subtype).
🏠 Analogy: Specialisation = "a cat is a type of mammal"; Subsetting = "my friend group is a subset of all people"; Redefinition = "I adapted my parent's method into my own version".
📐 Technical: Relationship: an Element associating two or more Elements. Specialisation: a specific Type inherits all instances of a general Type. Subsetting: all values of a sub-feature are also values of the parent feature. Redefinition: replaces a parent feature in a specialisation context — stronger than subsetting.
Summary of KerML core construct relationships
The diagram below shows how all KerML core constructs relate. You do not need to memorise it immediately — as you progress through the series, each box will become familiar.
Reading guide: hollow triangle arrows mean "specialises" (subtype → supertype); dashed blue arrows mean "subsetting"; blue boxes are abstract types, green boxes are concrete types.
SysML v2 Language Architecture
Think of a tall building: foundations (L0) → structural frame (L1 / KerML) → rooms and layouts (L2 / SysML language) → furniture and fittings (L3 / standard library). Each layer depends on the one below, but you live on the top floor — you do not need to think about the concrete mix. SysML v2's four layers work the same way.
SysML v2 is organised into four layers:
| Layer | Name | Description |
|---|---|---|
| L3 | SysML v2 Standard Library | Ready-made "toolbox": pre-defined international units (metres, kilograms, amperes), ISQ quantities, geometric relationships etc. Use them directly without redefining. |
| L2 | SysML v2 Language (core) | All the keywords you use day-to-day: part, item, port, action, requirement, connection, etc. |
| L1 | KerML (Kernel Modeling Language) | Provides precise semantic definitions for everything in L2. Like Word's underlying file format — you don't see it, but it ensures every concept has a clear meaning. |
| L0 | Mathematical foundation (set theory) | Uses set theory to precisely define "type", "instance", "feature value" etc. For language designers — beginners do not need to study this. |
As a beginner, 90% of your time is in L2 (SysML language layer) — modelling with part, action, port keywords. L3 (standard library) gives you ready-made units. L1 (KerML) helps you understand why. L0 is for language designers only.
Definitions vs Usages
Think about a pizza.
[Definition] The menu card says: Pizza = dough + tomato sauce + cheese + toppings. That card is the definition — it describes what a pizza is, but it is not itself a pizza.
[Usage] Today the chef made three pizzas: one Margherita, one Hawaiian, one Pepperoni. Those three real pizzas are usages — concrete instances of the definition, in a specific context (tonight's menu).
In SysML v2: part def Battery is the definition (menu card); part battery : Battery is the usage (tonight's actual battery).
Definitions — describing "what something is"
A definition is a reusable template. Write it once, reference it in many places. Key SysML v2 definition keywords:
part def— defines a structural component (like a blueprint for a part)item def— defines something that flows between parts (signals, data, fluids)port def— defines a connection point (like a socket standard)action def— defines an action or function (like defining an operation step)state def— defines a state machine behaviourrequirement def— defines a requirement type (template format)attribute def— defines a value type or attribute (e.g. temperature, mass)
Usages — describing "where it is used"
Usages place a definition into a specific context. Usage keywords correspond one-to-one with definition keywords — just remove def:
part— a specific structural component (this system's particular part)item— a specific flowing elementport— a specific connection point on a partaction— a specific operation step in a flowstate— a specific state in a state machinerequirement— a specific requirementattribute— a specific attribute slot (waiting to be assigned a value)
A complete example
// ── Step 1: Definitions (write the 'menu') ─────────────────────
part def Battery {
attribute capacity : Real; // battery has a capacity (Wh)
attribute voltage : Real; // battery has a voltage (V)
}
part def Motor {
attribute maxRPM : Real;
port powerIn : ~ElectricalPort; // motor has a power input port
}
part def Drone {
part battery : Battery; // usage — drone has one Battery
part motor1 : Motor; // usage — drone has four Motors
part motor2 : Motor;
part motor3 : Motor;
part motor4 : Motor;
}
// ── Step 2: Usage (place a 'order') ───────────────────────────
part missionDrone : Drone; // this is one specific mission drone
def = template, write once, use many times. Usage (no def) = one concrete application of the template, in a specific context. Both are essential: no definition means no specification; no usage means the definition never leaves the page.
SysML v2 Textual Notation (STN)
SysML v1 only had a graphical language (boxes and arrows). SysML v2 adds a standard textual notation called STN (SysML Textual Notation). Benefits: can be written in any text editor, version-controlled in Git, and processed by code.
Music can be written as a score (graphical) or as tablature (text) — both describe the same song. SysML v2's graphical and textual notations work exactly like this: interchangeable, fully equivalent.
Core syntax rules
| Syntax pattern | Meaning |
|---|---|
keyword name : type | The fundamental pattern. E.g. part battery : Battery means "there is a part called battery, typed by Battery". |
{ ... } | Curly braces contain what this element "owns" — sub-parts, attributes, actions, etc. |
// comment | Double slash starts a comment — human-readable annotation, no effect on model semantics. |
package Pkg { ... } | Defines a namespace (package) to organise related definitions together. |
import Pkg::*; | Imports all public contents of a package, so you can use them directly without writing the full path. |
:> (subset operator) | Means "is a subset of". E.g. part motor1 :> rotatingParts means motor1 is one of the rotating parts. |
:>> (redefine operator) | Means "replaces an inherited feature". Stronger than subsetting — the original feature is hidden. |
= expr (assignment) | Gives an attribute a default value or a binding expression. E.g. attribute voltage = 3.7 means voltage is always 3.7 V. |
Any conformant SysML v2 tool must support both graphical and textual forms, and must be able to convert between them losslessly. A model written in text will automatically generate diagrams; diagrams can be exported as text.
Mapping from SysML v1
If you have no prior SysML v1 experience, you may skip this section or treat it as a vocabulary preview. The table below shows common SysML v1 concepts and their SysML v2 equivalents.
| SysML v1 name | SysML v2 name | Key change |
|---|---|---|
| Block | part def | Clearer name, no UML Class heritage |
| Block Property | part / attribute (usage) | Explicit separation: part is structural, attribute is a value |
| Flow Port | Directional port | Direction (in/out/inout) specified directly in port def |
| Standard Port | port def with interface | Port described by its interface type |
| ValueProperty | attribute | Cleaner; can associate with ISQ international units |
| ConstraintBlock | constraint def | Constraints have formal mathematical expressions |
| Requirement (block) | requirement def | Requirements can be associated with a subject and stakeholders |
| satisfy / verify | satisfy / verify | Now first-class relationships with typed semantics |
| Activity | action def | Unified behaviour modelling, no longer depends on UML Activity |
| StateMachine | state def | State machine and action semantics are unified and consistent |
| IBD (Internal Block Diagram) | Part usage tree / interconnections | No separate diagram type needed; usage trees show structure directly |
Module Summary
Congratulations on completing Module 1! Here is a recap of the core ideas:
- SysML v2 is a standardised "drawing language" for engineers to design complex systems, released by OMG in 2024.
- SysML v2 is not based on UML — it is built on a new foundation, KerML (Kernel Modeling Language), with more precise concepts.
- KerML defines the most fundamental constructs: Element, Type, Feature, Classifier, Connector, Relationship.
- SysML v2 has four layers: mathematical foundation (L0) → KerML (L1) → SysML language (L2) → standard library (L3). You work in L2 day-to-day.
- The most important distinction: definition (
def) = template; usage (nodef) = one concrete application in a specific context. - SysML v2 adds a textual notation (STN) — graphical and textual forms are interchangeable.
- If you know SysML v1: Block →
part def, Activity →action def, most concepts have direct equivalents.