SysML v2 tools: what to check before you choose one

Why SysML v2 tools need their own evaluation

SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. v2 is a new language, not a revision of SysML v1 (how SysML v1 and v2 differ compares them in detail). It has a textual notation as well as a graphical one, a formal semantic base in KerML, a standard library of quantities, units and view kinds, and a standard API for reading and writing models. A tool can claim SysML v2 support and still cover only part of this, and the parts it leaves out may be the ones your program depends on.

The specification is large, and every tool implements it in steps. That is normal. What matters in an evaluation is that you know which steps a tool has taken, which it has not, and whether the vendor tells you so plainly. The checks below apply to any SysML v2 tool, whatever its price or deployment, and the test model gives you the same input for each candidate.

To find candidates, start from the list of SysML v2 tools kept by the OMGObject Management Group The standards body that maintains UML, SysML, UAF and XMI. and the SysML v2 tool capability summary that INCOSEInternational Council on Systems Engineering The professional society for systems engineering. It publishes the Systems Engineering Handbook. and the OMG published to support the move from SysML v1. Both are starting points: read them for names, then test each tool yourself.

What to check

Language coverage, and how gaps are documented

Ask for a coverage statement: each area of the language (packages, definitions and usages, specialization and redefinition, multiplicities, values and units, constraints, structure, actions, states, requirements, use cases, analysis and verification cases, views, metadata, variability, individuals and time slices) with a level for each. Useful levels separate four cases:

• the tool parses, checks and uses the construct;
• it does so with named limits;
• it keeps the construct exactly as written but gives it no meaning (it survives a round trip but nothing checks or computes it);
• it does not accept it.

A vendor that publishes known gaps is easier to plan around than one that lists only features. Treat "supports SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. v2" without a coverage table as unknown, and test the constructs your models use.

Textual notation: editing and checking

The textual notation is where SysML v2 differs most from v1, and it is where tools differ most. Check:

• Editing: syntax coloring, completion of names and keywords, go to definition, rename across the model, find and replace.
• Checking as you type: syntax errors are the minimum. A useful checker also resolves every name through imports, reports duplicate and ambiguous names, checks redefinitions against what is inherited, compares unit dimensions, and compares port and flow directions across connections.
• The text is the model: after an edit, does every other view see the change, or is the text a file the tool imports now and then?
• Text the tool did not write: load text written by hand or by another tool. Comments, documentation and layout of the text should survive.

Graphical views, and text and diagram sync

In SysML v2 a view is a model element: it states what it exposes and filters, and the tool renders it. The standard library defines General, Interconnection, Action Flow, State Transition, Sequence and Grid views. Check which of these the tool draws, which it can edit in, and how it handles the layout, which the specification leaves to the tool.

The key test is the sync in both directions. Rename a part in the text and look at every diagram that shows it. Add a connection in a diagram and read the text it produced. Then change both sides at once, if two people can, and see what the tool does with the conflict.

Standard library

Much of SysML v2's meaning lives in its standard library: scalar values, the International System of Quantities, SIInternational System of Units The metric system of units: meter, kilogram, second, ampere, kelvin, mole and candela, plus derived units. and US customary units, the standard view definitions, and the KerML kernel libraries. A tool should ship the library, resolve names against it, and evaluate with it. Check that ISQ quantity kinds and SI units resolve, that the library cannot be changed by accident, and which version of the library the tool uses.

The Systems Modeling API

The Systems Modeling API is the standard REST interface to a model repository: projects, branches, commits and elements. It lets tools exchange models without files, and it lets your own scripts read models. A tool can take part in two roles, and either can be read-only:

• Client: the tool pulls from and pushes to another repository that offers the API.
• Server: the tool offers the API so that other tools read, and perhaps write, its models.

Ask which role, which routes, and whether writes, queries, diffs and older commits are offered. A read-only server is still useful for reporting and for feeding analysis tools; it is not enough when another tool must change the model.

JSON interchange and round trip

Besides the text, models move between tools as SysML v2 JSON: the element format of the API, with an id for each element. Ids matter: text carries none, so a tool that re-imports text can only match elements by name, while JSON keeps identity across an exchange. Test a round trip: export from tool A, import into tool B, export again and import into A. Then compare element counts, names, values with units and relationships, and read how each tool reports what it dropped. Element kinds a tool does not support are where round trips lose data.

Migration from SysML v1

There is no lossless automatic translation from v1 to v2: the languages differ in structure, and v1 diagrams carry layout and stereotypes that have no single v2 equivalent. Ask how the tool brings in v1 models (usually XMIXML Metadata Interchange An OMG XML format for exchanging UML and SysML models between tools. with the SysML 1.x profile), what it maps blocks, parts, ports, activities, state machines and requirements to, and whether it produces a report of what did not convert. Try it on one of your own v1 models, not on the vendor's sample.

Collaboration and version control

Systems models are team work. Check whether several people can edit at once and how conflicts are shown and resolved, which roles exist (edit, review, view), how history and baselines work, and whether you can compare two versions element by element and as text. If your organization keeps models in a repository, check branches, merges and how the tool's own version history relates to the repository's commits.

Requirements and verification on the model

SysML v2 makes a requirement a constraint on a subject, with satisfy and verify relationships to the design and the verification cases. Check that the tool keeps the requirement text and the constraint together, evaluates the constraint against the model's values, and builds a verification matrix from the verify links. Check also what the tool keeps outside the language: requirement status, approvals, test results and suspect links after a change. These are not part of SysML v2 text, so ask where they are stored and whether they travel with an export.

Analysis and evaluation with units

Every value in a SysML v2 model can carry a unit, and expressions combine them. Check that the tool evaluates expressions with units (a total mass from three part masses, in kilograms), reports a dimension mistake as an error, and evaluates requirement constraints against the result. Then check the larger analysis features you need: parametric solving, budgets and rollups, trade studies, simulation of action flows or state machines. Ask what is evaluated from the model and what needs extra tool-specific data.

Deployment: cloud or self-hosted

Check where the model lives and who runs the tool: a hosted service, a desktop installation, or a server in your own environment. For controlled or export-restricted data, ask about self-hosting, data location, sign-in options and how AI features, if any, are configured or turned off.

Licensing and cost

Compare the total cost for your team, not the list price per seat: viewers and reviewers, academic or evaluation use, the cost of an API or server option, and what happens to your models if you stop paying. Check whether an export in the standard formats is available on every plan, so that your models stay yours.

Training

SysML v2 is new to most engineers, including those fluent in v1. Look for reference documentation that covers the notation as the tool supports it, worked examples, a demo model you can explore, and guided material for the tool's own screens. Language training and tool training are different needs; check that both are covered.

An evaluation checklist

Score each candidate with the same questions and the same input. "Shown" means you saw it work on the test model or your own model, not on a slide.

A test model to load into any candidate

This model is small enough to type and still touches most of what an evaluation needs: imports from the standard library, part definitions and usages with redefined values and units, conjugated ports, connections and a binding, a state machine, an action with successions, two requirements with constraints, a satisfy, a verification case, and two views. Save it as pump-station.sysml and load it into each tool.

The system is a solar-powered water pump: a panel feeds a controller, the controller drives the pump. The unit must weigh no more than 25 kg, and the panel's peak power must exceed the pump's rated power by at least 20 %. If the notation is new to you, the SysML v2 tutorial introduces each construct this model uses.

package PumpStation {
  doc /* A solar-powered water pump: a small probe model for evaluating SysML v2 tools. */

  private import ScalarValues::*;
  private import ISQ::*;
  private import SI::*;

  port def PowerPort {
    out attribute voltage : ElectricPotentialValue;
  }

  port def WaterPort {
    out attribute pressure : PressureValue;
  }

  part def SolarPanel {
    attribute mass : MassValue;
    attribute peakPower : PowerValue;
    port powerOut : PowerPort;
  }

  part def Controller {
    attribute mass : MassValue;
    port powerIn : ~PowerPort;
    port motorOut : PowerPort;
  }

  part def Pump {
    attribute mass : MassValue;
    attribute ratedPower : PowerValue;
    port powerIn : ~PowerPort;
    port outlet : WaterPort;
  }

  item def StartSignal;
  item def StopSignal;

  state def PumpModes {
    entry; then idle;
    state idle;
    state pumping;
    transition first idle accept StartSignal then pumping;
    transition first pumping accept StopSignal then idle;
  }

  action def DeliverWater {
    action convertSunlight;
    action regulatePower;
    action driveImpeller;
    first start then convertSunlight;
    first convertSunlight then regulatePower;
    first regulatePower then driveImpeller;
    first driveImpeller then done;
  }

  part def PumpUnit {
    part panel : SolarPanel {
      attribute redefines mass = 12 [kg];
      attribute redefines peakPower = 400 [W];
    }
    part controller : Controller {
      attribute redefines mass = 2 [kg];
    }
    part pump : Pump {
      attribute redefines mass = 9 [kg];
      attribute redefines ratedPower = 300 [W];
    }
    port outlet : WaterPort;

    connect panel.powerOut to controller.powerIn;
    connect controller.motorOut to pump.powerIn;
    bind outlet = pump.outlet;

    attribute totalMass : MassValue = panel.mass + controller.mass + pump.mass;
    exhibit state modes : PumpModes;
  }

  part pumpUnit : PumpUnit {
    perform action delivery : DeliverWater;
  }
}

package PumpRequirements {
  private import PumpStation::*;
  private import ScalarValues::*;
  private import ISQ::*;
  private import SI::*;

  requirement def <'PS-1'> MassLimit {
    doc /* The pump unit shall weigh no more than the mass limit, so that one person can carry it. */
    subject unit : PumpUnit;
    attribute limit : MassValue;
    require constraint { unit.totalMass <= limit }
  }

  requirement def <'PS-2'> PowerMargin {
    doc /* The panel's peak power shall exceed the pump's rated power by at least 20 %. */
    subject unit : PumpUnit;
    require constraint { unit.panel.peakPower >= 1.2 * unit.pump.ratedPower }
  }

  requirement pumpSpec {
    subject unit : PumpUnit;
    requirement mass : MassLimit {
      attribute redefines limit = 25 [kg];
    }
    requirement power : PowerMargin;
  }

  satisfy pumpSpec by pumpUnit;

  verification def <'VC-1'> WeighUnit {
    doc /* Weigh the assembled pump unit on a calibrated scale. */
    subject unit : PumpUnit;
    objective {
      verify pumpSpec.mass;
    }
    return verdict : Boolean = unit.totalMass <= pumpSpec.mass.limit;
  }
}

package PumpViews {
  private import PumpStation::*;
  private import StandardViewDefinitions::*;

  view unitConnections : InterconnectionView {
    expose PumpStation::PumpUnit;
  }

  view pumpStates : StateTransitionView {
    expose PumpStation::PumpModes;
  }
}

What a tool that supports these constructs should show:

• No errors and no warnings. A tool that reports problems here either lacks a construct or reads the standard library differently; ask which.
• totalMass evaluates to 23 kg: 12 kg + 2 kg + 9 kg.
• Both requirements hold: 23 kg is within 25 kg, and 400 W is more than 1.2 × 300 W = 360 W.
• unitConnections draws the panel, the controller and the pump with their ports, the two connections, and the outlet bound to the unit's boundary.
• pumpStates draws two states with an initial transition and two triggered transitions.
• A verification matrix lists PS-1 verified by VC-1, and PS-2 without a verification case.

Two probes for the checker

A checker earns its keep on mistakes. Load each probe on its own; each holds exactly one problem.

The first gives a power a value in kilograms. A tool that checks dimensions reports an error on the value:

package UnitProbe {
  private import ISQ::*;
  private import SI::*;

  part def Pump {
    attribute ratedPower : PowerValue;
  }

  part pump : Pump {
    attribute redefines ratedPower = 300 [kg];
  }
}

The second parses and resolves cleanly, but its requirement does not hold: the unit weighs 11 kg against a limit of 10 kg. A tool that evaluates requirement constraints reports it; one that only parses accepts it in silence.

package RequirementProbe {
  private import ISQ::*;
  private import SI::*;

  part def Pump {
    attribute mass : MassValue;
  }

  part def Unit {
    part pump : Pump {
      attribute redefines mass = 9 [kg];
    }
    attribute totalMass : MassValue = pump.mass + 2 [kg];
  }

  requirement def Light {
    subject unit : Unit;
    require constraint { unit.totalMass <= 10 [kg] }
  }

  part unit : Unit;
  requirement light : Light;
  satisfy light by unit;
}

Both probes were checked with a language engine, like the test model: the model gives no problems, and each probe gives exactly the one problem described.

Running the evaluation

1. Write down your needs first. Which constructs your models use, which views your reviewers read, which tools must exchange models, and where the data may live. Weight the checklist rows by them.
2. Read each vendor's coverage statement and known gaps. Mark each row of the checklist as claimed, not claimed, or not stated.
3. Load the test model and the probes into every candidate. Record what each tool reports, word for word.
4. Load one of your own models. A real model finds problems no sample does: size, naming, odd constructs.
5. Do one round trip with the tool you exchange with most.
6. Have a new user build the test model from the tool's documentation alone, and time it.

Keep the evidence (screenshots, exported files, the messages each tool gave) with the scores. A decision record that shows what was tested is worth more to a review board than a feature matrix copied from vendor material.

Holarch's answers to the checklist

Holarch is the tool used for the screenshots on this page, so here are its own answers, each with the page that backs it. "Partial" and "Not yet" mean what they say.

Try it in Holarch

1. Save the test model as pump-station.sysml.
2. Open Model → Import and Export, choose Into a new SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. v2 project and drop the file. See import files into a new project.
3. Open Model → Editor. The status line reads "No problems", and each package is a document.
4. Open the Diagrams list and click unitConnections or pumpStates.
5. Open Verification → RVTMRequirements Verification Traceability Matrix A table of each requirement with how it is verified, the tests that verify it and their latest result. to see the requirements with the case that verifies them.

Where to go next

• SysML v2 tutorial: build a larger model step by step in the textual notation.
• SysML v1 vs v2: what changes between the two languages and what a migration involves.
• SysML v2 language coverage: Holarch's full coverage table and known gaps.
• SysML v2 projects in Holarch: text, views and engineering pages on one model.