Modeling with SysML v2

SysML v2 is the second version of the Systems Modeling Language, a standard of the Object Management Group (OMG). It defines the concepts of a system model, a textual and a graphical notation for them, and an API to exchange models.

This page explains the core SysML v2 concepts for a newcomer and shows the ArcLang element each one maps to, using the home heating model of the tutorial. Then it exports that model to SysML v2 text. If you already know SysML v2, the tables are the quickest way in.

Definitions and usages

The first idea of SysML v2 is the difference between a definition and a usage.

A definition describes a kind of thing: a room sensor has an output port and an accuracy. It is written part def, port def, action def, and so on.
A usage is one occurrence of a definition in a particular system: the living room sensor, accurate to 0.2 K. It is written part, port, action.

In ArcLang, the elements you declare in the levels (components, nodes, functions, ports) are usages. A type is a definition: an element takes it with is:, inherits its attributes and ports, and must provide what the type requires.

parts.arc

type "Room sensor" {
  required: ["accuracy"]
  port out reading
}

logical_architecture "Sensors" {
  component "Living room sensor" { id: "LC-LIVING" is: "Room sensor" accuracy: 0.2 K }
  component "Bedroom sensor" { id: "LC-BED" is: "Room sensor" accuracy: 0.5 K }
}

$ arclang export -f sys-ml parts.arc -o parts.sysml
Exporting parts.arc to SysML format...
✓ Export successful
  Input: parts.arc
  Output: parts.sysml
  Format: SysML

$ sed -n "/abstract part def 'Room sensor'/,/^        }/p" parts.sysml
        abstract part def 'Room sensor' {
            doc /* instances must provide: accuracy */
            out port reading : 'Data port';
        }

$ sed -n "/part <'LC-LIVING'>/,/^        }/p" parts.sysml
        part <'LC-LIVING'> 'Living room sensor' : Types::'Room sensor' {
            attribute accuracy : ThermodynamicTemperatureValue = 0.2 [K];
        }

The type becomes an abstract part def, and each component a part typed by it (: Types::'Room sensor'). Quantities, types and constraints covers types in full.

The core concepts

SysML v2 concept	What it is	ArcLang
`part def`, `part`	A kind of system element, and one occurrence of it	`type`; `component`, `node`, `actor`, `entity`, `system_component`
`port def`, `port`	A connection point on a part, and what passes through it	`port in`, `port out`, `port inout` on a component or node; a `type` taken by a port
`connection`, `interface`	A link between the ports of two parts	`component_exchange`, `physical_link`
`action def`, `action`	Something done, with inputs and outputs	`function` (each level), `activity`
`flow`	Something that passes from one action to another	`functional_exchange`
`perform`	A part carries out an action	a function written inside a component
`allocate`	Assign an element to another, for example software to hardware	`deploys`, `allocates` trace
`requirement`	A condition the system must meet	`req` in a `requirements` block
`satisfy`	An element meets a requirement	`satisfies` trace
`verification`, `verify`	A case that checks a requirement	`test_case` with `verifies:`
`constraint`, `assert`	A Boolean expression that must hold	`constraint` with `assert:`
`state`, `transition`	Behavior as states and the transitions between them	`state_machine`, `state`, `mode`, `transition`
`use case`	What the system offers to its actors	`mission`, `capability`, `operational_capability`
`item def`	What flows: data, energy, matter	`exchange_item`, `class`
`package`	A namespace that groups elements	a level block (`system_analysis`, `logical_architecture`...)

The metamodel gives the SysML v2 construct of every ArcLang element kind, and the SysML v2 page the full mapping of the export.

Parts, ports and connections

A part is a piece of the system's structure. Parts have ports, and connections link ports. In the heating model, the thermostat, the controller and the burner unit are parts, connected through their ports:

$ sed -n '/component "Thermostat"/,/^  }/p' heating.arc
  component "Thermostat" {
    id: "LC-THERMO"
    function "Sense the temperature" { id: "LF-SENSE" realizes: "SF-MEASURE" latency: 500 ms }
    function "Show and set the temperature" { id: "LF-SET" realizes: "SF-SET" }
    port out readings
  }

$ grep 'component_exchange "Readings and set point"' heating.arc
  component_exchange "Readings and set point" { id: "CE-READINGS" from_port: "LC-THERMO.readings" to_port: "LC-CTRL.readings" }

These lines come from the tutorial's logical_architecture block. Exported, the component is a part with an out port, its functions are performed actions, and the exchange is a connection:

$ arclang export -f sys-ml heating.arc -o heating.sysml
Exporting heating.arc to SysML format...
✓ Export successful
  Input: heating.arc
  Output: heating.sysml
  Format: SysML

$ sed -n "/part <'LC-THERMO'>/,/^        }/p" heating.sysml
        part <'LC-THERMO'> Thermostat {
            out port readings : 'Data port';
            perform action <'LF-SENSE'> 'Sense the temperature' {
                attribute latency : DurationValue = 500 [ms];
            }
            perform action <'LF-SET'> 'Show and set the temperature';
        }

$ grep "connection <'CE-READINGS'>" heating.sysml
        connection <'CE-READINGS'> 'Readings and set point' connect 'LC-THERMO'.readings to 'LC-CTRL'.readings;

Actions and flows

An action is something done. It has input and output items and passes them to other actions through flows. ArcLang functions are actions; their ports are the items, and functional exchanges are the flows:

$ sed -n "/action <'SF-DECIDE'>/,/^        }/p" heating.sysml
        action <'SF-DECIDE'> 'Decide the heating demand' {
            attribute latency : DurationValue = 200 [ms];
            in item temperature : Data::Data;
            in item setpoint : Data::Data;
            out item demand : Data::Data;
        }

$ grep "flow <'FE-TEMP'>" heating.sysml
        flow <'FE-TEMP'> 'room temperature' of Data::Data from 'SF-MEASURE'.temperature to 'SF-DECIDE'.temperature;

A functional chain is an action whose steps specialize the functions it runs, in order, with its budget as an attribute:

$ sed -n "/#Chain action <'FC-HEAT'>/,/^        }/p" heating.sysml
        #Chain action <'FC-HEAT'> 'Reading to burner' {
            attribute latency_budget : DurationValue = 2 [s];
            action step1 :> 'SF-MEASURE';
            then action step2 :> 'SF-DECIDE';
            then action step3 :> 'SF-BURN';
        }

Requirements and verification

A requirement in SysML v2 is a condition with a text. A part satisfies it, and a verification case verifies it. ArcLang writes the same three things as req, a satisfies trace and a test_case:

$ sed -n "/requirement <'REQ-002'>/,/^        }/p" heating.sysml
        requirement <'REQ-002'> 'Reaction time' {
            doc /* The system shall start or stop the burner within 2 s of a reading that crosses the set temperature */
            attribute priority : String = "Medium";
        }

$ grep "satisfy Requirements::'REQ-002'" heating.sysml
    satisfy Requirements::'REQ-002' by 'Logical Architecture'::'LC-BURNER';

$ sed -n "/verification 'TC-002'/,/^    }/p" heating.sysml
    verification 'TC-002' {
        doc /* The latencies along the chain Reading to burner fit its budget */
        attribute method : String = "analysis";
        objective {
            verify Requirements::'REQ-002';
        }
        assert 'CST-HEAT';
    }

TC-002 is an analysis that asserts a constraint. In SysML v2 the verification asserts the same constraint, whose expression is the sum of the latencies along the chain.

States

A state usage describes behavior: the states a part can be in and the transitions between them. ArcLang's state_machine has states and modes (Arcadia distinguishes a mode, a behavior chosen on purpose, from a state, a condition undergone). Here are the modes of the heating system, added to the tutorial model:

heating_modes.arc

import "heating.arc"

state_machine "Heating modes" {
  id: "SM-HEAT"
  initial: "Idle"
  mode Idle { description: "Room warm enough, burner off" }
  mode Heating { description: "Burner on" }
  state Fault { description: "Burner locked out" }
  transition Idle -> Heating { trigger: "SF-DECIDE" guard: "temperature < set point" }
  transition Heating -> Idle { trigger: "SF-DECIDE" guard: "temperature >= set point" }
  transition Heating -> Fault { trigger: "SF-BURN" guard: "flame lost" }
}

$ arclang export -f sys-ml heating_modes.arc -o heating_modes.sysml
Exporting heating_modes.arc to SysML format...
✓ Export successful
  Input: heating_modes.arc
  Output: heating_modes.sysml
  Format: SysML

$ sed -n "/state <'SM-HEAT'>/,/^        }/p" heating_modes.sysml
        state <'SM-HEAT'> 'Heating modes' {
            entry; then Idle;
            #Mode state Idle {
                doc /* Room warm enough, burner off */
            }
            #Mode state Heating {
                doc /* Burner on */
            }
            state Fault {
                doc /* Burner locked out */
            }
            transition t1 first Idle then Heating {
                attribute guard : String = "temperature < set point";
                attribute trigger : String = "SF-DECIDE";
            }
            transition t2 first Heating then Idle {
                attribute guard : String = "temperature >= set point";
                attribute trigger : String = "SF-DECIDE";
            }
            transition t3 first Heating then Fault {
                attribute guard : String = "flame lost";
                attribute trigger : String = "SF-BURN";
            }
        }

Modes are marked #Mode; the trigger and the guard are kept as attributes of each transition.

Export the tutorial model

arclang export -f sys-ml writes the whole model as SysML v2 text, in one package per Arcadia level, marked #OA, #SA, #LA, #PA or #EPBS, with the requirements in a package of their own. The file written above holds these packages:

$ grep -n "package" heating.sysml
2:package <HomeHeating> 'Home heating' {
7:    library package ArcadiaProfile {
42:    package Data {
45:    #OA package 'Operational Analysis' {
62:    #SA package Requirements {
76:    #SA package 'System Analysis' {
114:    #LA package 'Logical Architecture' {
141:    #PA package 'Physical Architecture' {
184:    package ArcLangUnits {

The SysML v2 page explains the profile used by the export and how the output is validated by the OMG pilot implementation.

Read SysML v2 back

arclang import -f sysml reads SysML v2 text into ArcLang. Reading back the file just exported gives a model that compiles:

$ arclang import -f sysml heating.sysml -o heating_back.arc
Importing from SysML: heating.sysml...
  2 activities
  3 capabilities and missions
… (22 more lines)

$ arclang check heating_back.arc
Checking heating_back.arc...
✓ No compilation errors

Constraints:
  ✓ Chain within budget — "SF-MEASURE".latency + "SF-DECIDE".latency + "SF-BURN".latency <= "FC-HEAT".latency_budget  [1.7 s vs 2 s]

In the workbench, a .sysml file opens directly, and File › Save as... writes SysML v2.

Modeling with Arcadia explains the levels the export uses as packages.
The SysML v2 page gives the full mapping and the import.
The language tour covers every construct of ArcLang.

Every ArcLang sample on this page is compiled, and every command is run, with the released compiler when the site is built.