The Definitive Guide to SysML v2 Textual Notation

Systems Modeling Language version 2 (SysML v2) marks a massive shift in systems engineering. By moving away from the rigid, UML-based graphical constraints of SysML v1, SysML v2 introduces a language-driven, textual syntax. This syntax treats structure, behavior, requirements, and analysis as deeply integrated text elements.

This comprehensive guide breaks down the core pillars, concepts, and syntax of SysML v2 using a concrete AutonomousDrone design example.

1. The Core Paradigm: Definitions vs. Usages

The single most important architectural concept in SysML v2 is the strict separation between Definitions (blueprints) and Usages (contextual instances).

• The def Keyword: Indicates a reusable definition, type, or element blueprint. It does not exist as a physical object until it is used.

• No def Keyword: Indicates a usage. It represents an actual occurrence or component instance within a specific parent system.

// DEFINITION: A reusable blueprint for any battery
part def Battery;

// USAGE: A specific instance of a battery inside our drone system
part powerSource : Battery;

This distinction allows engineers to define a component once and reuse it across multiple subsystems with different names, configurations, and internal connections.

2. Structural Architecture: Parts, Items, and Ports

SysML v2 divides physical or logical architectures into components, the things that flow through them, and the interfaces connecting them.

Parts and Items

• part def (Block / Component): Defines a structural, physical, or logical system component.

• item def (Flow Item): Defines non-fixed elements—such as data streams, fluids, force, or electricity—that flow between parts.

Ports and Interfaces

• port def (Interface Specification): Defines an interface boundary, explicitly dictating what data or items can enter (in) or exit (out).

Here is how these components are declared and nested inside a system namespace:

package DroneSystemExample {
    private import ScalarValues::*;
    private import SI::*;

    // Base Blueprints (Definitions)
    item def Power; 

    port def PowerOutPort {
        out item powerElec : Power;
    }
    
    port def PowerInPort {
        in item powerElec : Power;
    }

    part def FlightController;
    part def PropulsionSystem;
    part def Battery;

    // Integrated System Context
    part def AutonomousDrone {
        // Attributes / Value properties
        attribute enduranceActual : Real;

        // Sub-part Usages (Instantiating the definitions)
        part flightController : FlightController;
        part propulsionSystem : PropulsionSystem;
        part powerSource : Battery;

        // Port Usages (Instantiating the interfaces)
        port pBatteryOut : PowerOutPort;
        port pPropulsionIn : PowerInPort; 
    }
}

3. The Requirement Pillar (Problem Space)

In SysML v1, requirements were often text blocks isolated from engineering math. In SysML v2, requirements are first-class text definitions containing metadata, descriptive text, and strongly-typed attributes for automated verification.

requirement def RangeRequirement {
    doc /* The drone must maintain a continuous flight endurance of at least 45 minutes. */
    attribute enduranceTarget : Real = 45.0; 
}

Traceability with satisfy

To close the loop between the problem space (requirements) and the solution space (structure), SysML v2 uses explicit relationship keywords like satisfy directly inside the part context:

part def AutonomousDrone {
    // Instantiates a requirement usage to satisfy the definition mapping cleanly
    satisfy requirement : RangeRequirement;
}

4. The Behavior Pillar (Execution Space)

SysML v1 forced a clean split between structure (Internal Block Diagrams) and behavior (Activity Diagrams). SysML v2 completely removes this barrier by making actions and control flows native, in-scope structural elements.

Sequential Actions and Control Flow

Using the action keyword, you can declare functions that accept inputs (in) and pass outputs (out). Control flows are written linearly using the then keyword, eliminating the need for complex control flow diagrams.

action executeMission {
    in targetCoordinates;
    out missionStatus;
    
    action sTakeoff;
    then action sNavigate;
    then action sLand;
}

5. Functional Allocation: Connecting Behavior to Structure

Allocation answers the fundamental systems engineering question: Which component performs which function?

SysML v2 handles this cleanly using the perform keyword within a part usage block. Using Dot Notation (.), you can reach deep into nested action loops to map operations directly to physical hardware.

part def AutonomousDrone {

    // Sub-parts allocate behavior by explicitly 'performing' their assigned steps
    part flightController : FlightController {
        perform executeMission.sNavigate;
    }
    
    part propulsionSystem : PropulsionSystem {
        perform executeMission.sTakeoff;
    }

    // Embedded behavior definition
    action executeMission {
        action sTakeoff;
        then action sNavigate;
        then action sLand;
    }
}

Summary of Core Keywords

Full Example of the SysML V2: Three Pillars