Ran Wei / SysML v2 Series / Module 1
中文
SysML v2 — Ran Wei

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.

1

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.

💡 One-sentence summary

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.

NOTE

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 limitationSysML v2 improvement
Inherited many UML concepts unrelated to systemsClean redesign based on KerML — no UML dependency
Many concepts had imprecise meanings, causing ambiguityStrict mathematical definitions — unambiguous semantics
Only graphical notationNew textual notation (STN) — both graphical and textual
Tools could not exchange model filesStandard API — tools can interoperate
Behavioural modelling was awkwardUnified, cleaner behaviour modelling
Allocation had no standard syntaxAllocation has a defined, formal syntax
Table 1 — SysML v1 limitations and v2 improvements
2

KerML — The Language Foundation

🏠 ANALOGY

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.

💡 For beginners

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.

[KerML Taxonomy Diagram — see docx version for embedded image]
3

SysML v2 Language Architecture

🏠 ANALOGY

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:

LayerNameDescription
L3SysML v2 Standard LibraryReady-made "toolbox": pre-defined international units (metres, kilograms, amperes), ISQ quantities, geometric relationships etc. Use them directly without redefining.
L2SysML v2 Language (core)All the keywords you use day-to-day: part, item, port, action, requirement, connection, etc.
L1KerML (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.
L0Mathematical foundation (set theory)Uses set theory to precisely define "type", "instance", "feature value" etc. For language designers — beginners do not need to study this.
Table 2 — SysML v2 language layers (L0 is the foundation, L3 is the application layer)
💡 Which layer do you actually need?

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.

4

Definitions vs Usages

🏠 ANALOGY

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:

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:

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
💡 The golden rule

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.

5

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.

🏠 ANALOGY

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 patternMeaning
keyword name : typeThe 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.
// commentDouble 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.
Table 3 — SysML v2 core textual notation syntax
NOTE

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.

6

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 nameSysML v2 nameKey change
Blockpart defClearer name, no UML Class heritage
Block Propertypart / attribute (usage)Explicit separation: part is structural, attribute is a value
Flow PortDirectional portDirection (in/out/inout) specified directly in port def
Standard Portport def with interfacePort described by its interface type
ValuePropertyattributeCleaner; can associate with ISQ international units
ConstraintBlockconstraint defConstraints have formal mathematical expressions
Requirement (block)requirement defRequirements can be associated with a subject and stakeholders
satisfy / verifysatisfy / verifyNow first-class relationships with typed semantics
Activityaction defUnified behaviour modelling, no longer depends on UML Activity
StateMachinestate defState machine and action semantics are unified and consistent
IBD (Internal Block Diagram)Part usage tree / interconnectionsNo separate diagram type needed; usage trees show structure directly
Table 4 — SysML v1 to SysML v2 concept mapping
7

Module Summary

Congratulations on completing Module 1! Here is a recap of the core ideas:

Up Next

Module 2 — Core Language Concepts — Namespaces, packages, import/visibility, specialisation chains, multiplicity, and the full feature model.