Comprehensive Guide: SysML v1 vs. SysML v2

Key Differences, Core Enhancements, and Practical Examples

SysML v2 represents a foundational evolution of the Systems Modeling Language. While SysML v1 was built as a UML profile optimized for graphical diagrams, SysML v2 is a standalone modeling language designed for modern Model-Based Systems Engineering (MBSE). It introduces a formal textual syntax, native requirement modeling, explicit semantics, and a clear separation between the underlying model and its visual representations.

This guide breaks down the key differences, explains the rationale behind each change, and provides practical examples to help systems engineers transition from v1 to v2.

1. Foundational Paradigm Shifts

Example: Textual vs. Graphical Workflow

In v1, you manually draw a Block Definition Diagram (BDD) and update it when the model changes. In v2, you define the model textually, then generate a General View that automatically renders the structure. If you change the model, all dependent views update instantly.

2. Terminology & Semantic Mapping

SysML v2 refines terminology to eliminate ambiguity and align with formal modeling principles.

3. Core Language Enhancements (with Examples)

3.1 Removal of Plain UML Ports

SysML v1 allowed untyped “standard” UML ports, which often led to ambiguous connections. SysML v2 removes them. Every port must be explicitly typed via an interface or used as a proxy port.

SysML v2 Textual Example:

// 1. Define the types
item def HouseholdOutlet;
item def HouseholdDevice;

interface def ApplianceConnection {
    end port outlet : HouseholdOutlet;
    end port device : HouseholdDevice;
}

part def CoffeeMaker {
    port powerIn : ApplianceConnection;
}

Note: In v2, interfaces are specialized connections. Every interface is also a valid connection, but not vice versa.

3.2 Item Flows Integrated into Connections

• v1: You draw a connector, then separately attach an ItemFlow to specify what passes through it.

• v2: Flow properties are defined directly within the connection, reducing modeling steps and improving traceability.

SysML v2 Example:

// 1. Define missing types
item def TankPort;
item def EnginePort;
item def MaterialFlow;
connection def FuelLine {
    end part source : TankPort;
    end part target : EnginePort;

    // 2. flow syntax
flow Fuel : MaterialFlow from source to target;
}

The flow Fuel is now an intrinsic property of FuelLine, not a separate annotation.

3.3 Explicit Inheritance & Specialization

SysML v1 relied on implicit generalization arrows in diagrams. v2 provides explicit syntax, improving model clarity, tool validation, and reuse.

SysML v2 Example:

part def Vehicle { }
part def ElectricVehicle specializes Vehicle { }
part def HybridVehicle    specializes Vehicle { }

The specializes keyword makes the relationship machine-readable and traceable across tools.

3.4 Native Requirement Modeling

• v1: Requirements are modeled using «Requirement» stereotypes on blocks or classes, requiring custom profiles and often breaking traceability.

• v2: Requirements are first-class modeling elements with built-in relationships (satisfies, verifies, refines, derives).

SysML v2 Example:

// 1. Define the Performance category
attribute def Performance;

requirement req_001 {
// 2. Use 'doc'
doc /* The pump shall deliver a minimum flow rate of 10 L/min. */

// 3. Use 'attribute' keyword
attribute category = Performance;
}

part def HydraulicPump {
// 4. Use 'satisfy' followed by the requirement name
satisfy req_001;
}

No stereotypes. No custom profiles. Native traceability from day one.

4. Diagram Evolution: BDD/IBD → Views

How Views Work in v2

Instead of drawing a diagram, you define a Viewpoint (rules/filters) and then generate a View:

package ArchitectureModel {

// 1. Define the blueprints (Definitions)
part def Engine;
part def Transmission;
connection def ShaftLink;

// 2. Create the actual system parts (Usages)
part e1 : Engine;
part t1 : Transmission;
connection s1 : ShaftLink;

// 3. Define a viewpoint to constrain and organize views
viewpoint def ArchitecturalView {
requirement filterRequirement {
doc "Filter elements by types: Part, Connection, and Requirement."
}
}

// 4. Define a view based on the viewpoint
view SystemArchitectureView : ArchitecturalView {
satisfy filterRequirement;

// Expose the defined elements in this view
expose e1;
expose t1;
expose s1;
}
}

This ensures that stakeholders always see consistent, model-driven representations tailored to their needs.

5. Enhanced Instance & Lifecycle Modeling

SysML v2 introduces formal constructs to model how systems behave and evolve over time:

SysML v2 Conceptual Example:

occurrence def BatteryCycle_01 {
    doc /* Lifecycle of a battery cell from initial state to end-of-life after 5,000 hours. */
    snapshot InitialState {
        doc /* Battery is at full charge and nominal capacity at time zero. */
        attribute T = 0;
    }
    timeslice DegradationPhase {
        doc /* Gradual capacity degradation due to cyclic stress and aging. */
        // Define duration within the timeslice
        attribute startT = 0;
        attribute endT = 5000;
    }
    snapshot EndOfLife {
        doc /* Battery capacity has degraded below acceptable threshold. */
        attribute T = 5000;
    }
}

These constructs enable precise temporal analysis, digital twin alignment, and lifecycle traceability.

6. New Capabilities: View/Viewpoint & Verification

🔹 View & Viewpoint Capability

• Enables stakeholder-specific model projections without duplicating elements.

• Supports automated filtering, layout rules, and consistency checks.

• Example: A safety engineer sees only failure modes and verifies relationships; a manufacturing engineer sees only Part instances and Connection routing.

🔹 Formal Verification

• SysML v2 integrates constraint validation and requirement verification directly into the language.

• Tools can run model checkers, evaluate OCL-like constraints, and flag requirement gaps automatically.

• Example: constraint def MaxTemp { condition = sensor.temperature <= 85.0; } can be automatically verified against simulation or design data.

Exanple: Safety Critical

1. Stakeholder-Specific View (Safety Engineer)

package SafetyProjections {
	private import ScalarValues::*;
	// 1. Define the Viewpoint (The "Rules" for the view)
	viewpoint def SafetyViewpoint {
		doc /* Filter only parts with 'safety_critical = true' and their relationships. */
	}

	// 2. Define the System Parts
	part def BrakeSystem {
		attribute isSafetyCritical : Boolean = true;
	}
	
	part def Radio {
		attribute isSafetyCritical : Boolean = false;
	}

	// 3. The View (The actual stakeholder projection)

	view BrakeSafetyView {
		viewpoint safety_vp : SafetyViewpoint;
		expose BrakeSystem;
		// Note: Radio is NOT exposed here, filtering the model for the stakeholder.
	}
}

2. Formal Verification (Temperature Constraint)

package ThermalVerification {
	private import ScalarValues::*;
	private import ISQ::*;

	constraint def MaxTempLimit {
		in temp : Real;
		temp <= 85.0
	}

	requirement <'R1'> OperatingTempRequirement {
		doc /* The processor must operate below 85 degrees celsius. */

		assert constraint MaxTempLimit {
			in temp = processor.currentTemp;
		}
	}

	part processor {
		attribute currentTemp : Real;
	}

	satisfy OperatingTempRequirement by processor;

}