Module 3: The Modelling Language
What modelling languages are, why they matter, and a survey of SysML v1, SysML v2, UML, and other options — without teaching any one language in depth.
Prereq: MBSE Module 2What is a Modelling Language?
Before you can build a model, you need a language to express it in. A modelling language is not a programming language — it does not run on a computer to produce software. Instead, it provides a structured way to describe a system: its parts, behaviours, requirements, and relationships.
Every language — whether human or modelling — has three fundamental aspects:
- Syntax — the grammar rules that define what constructs are allowed and how they can be combined.
- Semantics — the meaning behind those constructs. Two syntactically correct sentences can mean very different things.
- Notation — the visual or textual representation used to write down expressions of the language.
Think of the English language. It has grammar (syntax) — rules like "subject + verb + object." It has meaning (semantics) — the sentence "The car accelerates" conveys a specific idea. And it is written in the Latin alphabet (notation) — but the same meaning could be expressed in Cyrillic or Chinese characters. A modelling language works the same way: syntax defines what you can write, semantics defines what it means, and notation defines how it looks on the page or screen.
| Concept | Human Language Example | Modelling Language Example |
|---|---|---|
| Syntax | Subject – Verb – Object ordering | A block must have a name; ports connect to connectors |
| Semantics | "The pump delivers fluid" has a specific meaning | A part typed by a part def means "this is an instance of that definition" |
| Notation | Written in the Latin alphabet (A, B, C…) | A box with a label (graphical) or part pump : Pump (textual) |
Table 1 — Three aspects of a language: human vs modelling
When evaluating any modelling language, ask: Is the syntax well-defined? Are the semantics precise and unambiguous? Does the notation support the way my team works?
SysML v1: The Established Standard
SysML v1 (Systems Modeling Language, version 1) was published by the OMG in 2007. It was designed as a profile of UML — meaning it extended and customised UML's software-centric constructs for systems engineering. For nearly two decades, SysML v1 has been the most widely used modelling language in MBSE.
The nine diagram types
SysML v1 organises models into nine diagram types, grouped into three categories:
| Category | Diagram | Purpose |
|---|---|---|
| Structure | Block Definition Diagram (BDD) | Defines blocks and their relationships (composition, generalisation) |
| Internal Block Diagram (IBD) | Shows internal structure — parts, ports, and connectors within a block | |
| Package Diagram | Organises model elements into packages (namespaces) | |
| Parametric Diagram | Captures constraint equations linking value properties | |
| Behaviour | Activity Diagram | Models workflows, data/control flows, and actions |
| Sequence Diagram | Shows message exchanges between parts over time | |
| State Machine Diagram | Models states, transitions, and events for a block | |
| Use Case Diagram | Captures actors and their interactions with the system | |
| Cross-cutting | Requirement Diagram | Traces requirements and their satisfy/verify/refine relationships |
Table 2 — The nine SysML v1 diagram types
Strengths
- Widely supported — every major MBSE tool (Cameo, Rhapsody, Enterprise Architect, Papyrus) supports SysML v1.
- Large community — extensive training materials, conferences, and practitioner networks.
- Many textbooks and standards references — well-documented in both academic and industrial literature.
Limitations
- Inherited UML baggage — many UML constructs are irrelevant to systems engineering but cannot be cleanly removed.
- Imprecise semantics — some concepts (e.g., allocation) lack rigorous definitions, leading to inconsistent interpretation across tools.
- No standard API — models are locked inside proprietary tool formats; interoperability requires custom export/import.
This module surveys SysML v1 at a high level. We do not teach its diagram syntax in depth here — the goal is to understand what it is and where it fits in the MBSE landscape.
SysML v2: The Next Generation
SysML v2 is a ground-up redesign of the systems modelling language, released by the OMG in 2024. Rather than extending UML, SysML v2 is built on its own foundation — KerML (Kernel Modeling Language) — which provides precise, mathematically grounded semantics.
Key innovations
- Textual notation — a standard textual syntax (STN) that can be written in any text editor and version-controlled in Git.
- KerML foundation — all language constructs have precise semantic definitions, eliminating the ambiguity problems of v1.
- Standard API — a companion API specification enables tool interoperability: models can be exchanged between conformant tools.
- Unified behaviour modelling — actions, states, and interactions share a coherent semantic framework.
- No UML dependency — a clean-sheet design free from legacy software-engineering constructs.
SysML v1 vs v2 comparison
| Dimension | SysML v1 | SysML v2 |
|---|---|---|
| Foundation | UML profile (inherits UML metamodel) | KerML — independent, mathematically grounded |
| Notation | Graphical only | Graphical + standard textual notation (STN) |
| Semantics | Informal, often ambiguous | Precise, formally defined by KerML |
| Interoperability | No standard API; tool-locked formats | Standard API for model exchange |
| Behaviour modelling | Multiple disconnected diagram types | Unified action/state/interaction framework |
| Maturity | Mature (2007); wide tool support | New (2024); ecosystem growing rapidly |
Table 3 — SysML v1 vs SysML v2 comparison
For a deep dive into SysML v2, see our dedicated SysML v2 Tutorial Series. It covers the language from foundations through advanced topics in nine modules.
Other Modelling Languages
SysML is the most general-purpose systems modelling language, but it is not the only option. Depending on your domain, a domain-specific language (DSL) may be more appropriate — or may be used alongside SysML to address specialised concerns.
| Language | Domain | Notation Type | Key Strength |
|---|---|---|---|
| UML | Software engineering | Graphical | Comprehensive software design; 14 diagram types |
| AADL | Real-time / embedded systems | Textual + graphical | Precise modelling of timing, scheduling, and resource budgets |
| Modelica | Physics / simulation | Textual (equation-based) | Multi-domain physical simulation (thermal, electrical, mechanical) |
| EAST-ADL | Automotive | Graphical (UML-based) | Automotive-specific abstractions aligned with AUTOSAR |
| Capella / Arcadia | Systems architecture | Graphical (method-driven) | Tightly integrated method + tool; guided architecture workflow |
Table 4 — Survey of modelling languages beyond SysML
The key takeaway: SysML is the most general-purpose systems modelling language and the de facto standard for MBSE. However, domain-specific languages exist for good reason — they encode domain knowledge that a general-purpose language cannot. In practice, organisations often use SysML for system-level architecture and a DSL for detailed domain modelling.
This is not an exhaustive list. Other notable languages include BPMN (business processes), ArchiMate (enterprise architecture), and various safety-specific notations (e.g., fault trees, STPA diagrams). The right choice depends on your domain and engineering context.
Choosing a Language
Selecting a modelling language is not a purely technical decision. The language must fit your domain, your team, your tools, and your organisational context. Most importantly, the language does not exist in isolation — it must work together with the modelling method (Module 4) and the modelling tool (Module 5). These three pillars are interdependent.
Decision factors
| Factor | Questions to Ask |
|---|---|
| Domain fit | Does the language support the types of models your domain requires? (e.g., real-time constraints, physical simulation, safety analysis) |
| Team familiarity | Does your team already know this language? What is the training investment required? |
| Tool support | Is the language supported by the tools your organisation uses or can procure? |
| Standard compliance | Does your industry or customer require a specific standard? (e.g., defence contracts often mandate SysML) |
| Interoperability | Can models be exchanged with suppliers, partners, or other tools in your ecosystem? |
| Ecosystem maturity | Are there textbooks, training courses, community forums, and consulting support available? |
Table 5 — Decision factors for choosing a modelling language
In many organisations, the answer is straightforward: SysML (v1 or v2) is the default choice for general-purpose MBSE, supplemented by domain-specific languages where needed. But the choice should always be deliberate, not accidental.
Remember: the language is only one of the three MBSE pillars. A well-chosen language with a poor method will still produce poor models. In the next module, we turn to Pillar 2 — The Modelling Method.