SysML v2 Tutorial: Build Your First MBSE Model with PLM Integration

Last Updated: October 2026

The first thing that surprises engineers who open SysML v2 after years of SysML v1 is that the model is a text file. You can read it in a diff, review it in a pull request and parse it with a script, and the boxes-and-lines diagrams are generated views of that same underlying model rather than the model itself. That sounds like a cosmetic change, but it is the reason SysML v2 can finally take part in a PLM digital thread instead of being an island of drawings that someone re-keys into a requirements tool.

The timing matters. The Object Management Group (OMG) formally adopted SysML v2, the Kernel Modeling Language (KerML) and the Systems Modeling API and Services in mid-2025, and by October 2026 every major commercial modeling tool has either shipped v2 support or published a roadmap. The older tutorials on this topic, including the first version of this one, mix real facts with rumor, so this rewrite re-checks the dates, the vendor claims and the integration mechanics.

By the end you will have written a small but complete IoT gateway model in textual notation, understood what KerML adds underneath it, called the standard REST API, and designed the trace links that connect model elements to parts, requirements and change orders in a PLM system.

What this covers: the verified status of the v2 specifications, KerML and the definition/usage pattern, a worked gateway model with requirements and verification, the Systems Modeling API, three PLM integration patterns with what is and is not verified for Teamcenter, Windchill and 3DEXPERIENCE, a v1-to-v2 migration plan, and failure modes.

Context and Background

SysML v1 was a UML profile. It reused UML’s class, block and activity machinery and added stereotypes to say “this class is a requirement” or “this class is a block”. The approach was pragmatic in 2006 and increasingly painful afterwards. Semantics were informal, so two tools could read the same file differently; the XMI interchange format was famously fragile; and there was no standard way for another program to ask a SysML model a question. Teams that wanted a digital thread ended up writing point-to-point plugins per tool, which is the situation the PLM world knows well from CAD.

The replacement took years. OMG’s announcement on the final adoption of the SysML v2 specification, dated 21 July 2025, says the work took seven years and covers three specifications: SysML v2.0, KerML 1.0 and Systems Modeling API and Services 1.0. The community release repository records the formal OMG adoption date as 30 June 2025 and notes that the documents were editorially updated in March 2026 for submission to ISO. Two dates, one event: the board action and the press release are weeks apart. Treat “2025” as the adoption year and ignore claims that the language was “ratified in 2023”. In 2023 the work was at the beta stage, and tools built then targeted a moving target.

The specification set has a clean division of labour:

KerML defines the semantic foundation: a small formal language of types, features, relationships and behaviors, with a textual notation.
SysML v2 is a systems engineering language built on KerML. It adds parts, ports, actions, states, requirements, analysis cases and verification cases, plus a graphical notation.
Systems Modeling API and Services defines how programs create, query and version models. It has a platform-independent model and a REST/HTTP binding.

SysML v2 also ships with a second part, a transformation specification for moving v1 models to v2, which we return to in the migration section.

Who actually builds on it? The OMG release names Ansys, Dassault Systemes (through CATIA Magic), IBM, Intercax (whose Syndeia platform says it was the first commercial product to support the Systems Modeling API, starting in 2021), MathWorks, PTC, Siemens, Obeo (the open-source SysON web modeler) and Sensmetry among others. Defense customers are paying attention too: a February 2026 transition information sheet from the US Department of Defense engineering office advises programs to write a transition plan, learn the textual notation and the API, and run a pilot before committing.

For readers coming from the IoT side, the relevant link is the lifecycle one. A system model is the upstream source for the structure that a digital twin architecture later instantiates: the parts that exist, the interfaces between them and the requirements each must meet. If those definitions live in a drawing, the twin’s data model is rebuilt by hand. If they live in an API-addressable model, the twin can be generated from it and kept in sync. That is the argument this tutorial builds toward, and the reason the API matters more than the syntax.

One warning before the mechanics. Throughout this post, claims about what a vendor’s product “supports” come from vendor pages and press releases and are labelled that way. Conformance to the 1.0 API is exactly the kind of claim that varies by version, and the OMG community is still building the conformance test suite that would settle it.

The SysML v2 Architecture: KerML, the Language and the API

Direct answer. SysML v2 is three stacked layers. KerML supplies formal semantics, SysML v2 supplies systems engineering vocabulary on top of it, and the Systems Modeling API exposes any conforming model over a standard service interface. Textual and graphical notations are two views of one model, so the API sees the same elements whichever notation authored them.

Figure 1: The SysML v2 stack. Everything above KerML is built from its types and features, and everything that touches the model from outside goes through the API.

Figure 1 shows the layering. The point to hold onto is that the arrows from tools and PLM point at the API, not at the notation. A PLM integration that parses .sysml text files is a workaround; one that calls the API is the intended design.

KerML: why a formal kernel matters

KerML replaces UML as the foundation. Its core concepts are few. An element is anything in the model. A type classifies things. A feature is something a type has, such as an attribute, a part or a connection end, and every feature has its own type and multiplicity. A classifier is a type that classifies things that exist in the world (things, behaviors, associations), and relationships such as specialization and subsetting tie them together.

Two ideas do most of the work. First, specialization has precise set semantics: if Gateway specializes Device, every gateway is a device, and a feature redefined in the subtype must be compatible with the original. Second, KerML models are meant to be given a mathematical meaning, expressed through a formal semantic layer based on first-order logic, so that “does this model satisfy this constraint” is a question with a defined answer rather than a tool-specific behavior. The practical benefit shows up as fewer interchange surprises, not as a day-one feature you will click on.

The definition and usage pattern

The pattern you will see in every SysML v2 file is a definition (a reusable type, written part def) and a usage (a feature that occurs inside some context, written part). A part def Wheel says what wheels are. A part frontLeft : Wheel inside a car definition says that this car has a wheel in this role. SysML v1 achieved the same split with blocks and part properties, but v2 makes it uniform across every kind of element: port def and port, action def and action, requirement def and requirement, state def and state.

The uniformity pays off in reuse. A usage can be specialized or redefined in a deeper context: the generic gateway has a power port, and a battery-backed variant redefines the supply feeding it. In a PLM mindset, definitions map naturally to part masters (the thing in the catalog) and usages map to occurrences or BOM lines (the thing in a particular assembly). That is the analogy we will use to build trace links later.

Textual and graphical notation as views

SysML v2 defines a standard textual notation and a standard graphical notation. Both are projections of the same abstract syntax, and the OMG material is explicit that they represent the same underlying model. In practice a tool might offer a text editor, a tree, and diagram views of several kinds: general view, interconnection, action flow, state transition, sequence and a few more. Edits in one should reflect in the others.

Textual notation is the practical entry point for a PLM engineer because it is diffable and scriptable. Graphical notation is where reviewers and stakeholders live. Expect teams to use both, and expect round-trip fidelity between them to be one of the first things to test in any tool you evaluate.

Libraries: units, quantities and scalar values

SysML v2 ships with a standard model library written in the language itself. It includes scalar values, quantities and units (an implementation of the ISO/IEC 80000 quantity system called ISQ, plus SI units) and base behavior libraries. This is a significant quiet improvement. In v1, a “mass” attribute was a real number with a note in a comment; in v2 you can write 0.45 [kg] and the tool knows it is a mass. Unit-aware models make PLM exchange safer, because the number that arrives in the BOM carries its dimension.

Hands-On: Your First SysML v2 Model, an IoT Gateway

Direct answer. A first useful SysML v2 model needs five things: a package, reusable definitions for parts and ports, usages that assemble them, a requirement with a checkable constraint, and a satisfy relationship tying the two together. The gateway below does all of it in about sixty lines of textual notation that you can paste into any v2 editor.

The scenario is a small industrial IoT gateway: a board with a CPU module, a power supply and a radio, reading temperature sensors and publishing readings upstream. We will model structure first, then interfaces, then a mass requirement, then behavior.

A note on tooling and trust. The syntax below follows the textual notation as published in the 2025 specification and its example libraries, but I have not machine-validated this exact file in a specific tool for this post, so treat it as a template to load into the free SysON web modeler, the Eclipse and Jupyter pilot implementation from the SysML v2 release repository, or a commercial editor, and let the parser tell you about any detail that has drifted. Library element names such as ISQ::mass and SI::kg are standard-library names; if your tool’s library differs in minor ways, adjust the imports.

Step 1: structure with definitions and usages

package GatewayModel {
    private import ScalarValues::*;
    private import ISQ::*;
    private import SI::*;

    // ---- Interface definitions ----
    port def SensorBusPort {
        in attribute sample : Real;
    }
    port def UplinkPort {
        out attribute payload : String;
    }
    port def PowerPort {
        attribute supplyVoltage : Real;
    }

    // ---- Part definitions ----
    part def TemperatureSensor {
        attribute sensorId : String;
        attribute mass : MassValue;
        port bus : ~SensorBusPort;
    }

    part def PowerSupply {
        attribute ratedPower : PowerValue;
        attribute mass : MassValue;
        port out28 : PowerPort;
    }

    part def Gateway {
        attribute mass : MassValue;
        part cpuModule {
            attribute mass : MassValue;
            port bus : SensorBusPort;
            port uplink : UplinkPort;
            port powerIn : PowerPort;
        }
        part psu : PowerSupply;
        part sensors : TemperatureSensor[1..8];
        port uplink : UplinkPort;
    }
}

Read it top down. The three port def blocks name the interfaces. The tilde on ~SensorBusPort marks a conjugated port: the sensor sits on the opposite side of the interface, so where the CPU module receives a sample the sensor sends one. This replaces v1’s flow-direction annotations with a single, checkable idea. TemperatureSensor[1..8] is a multiplicity: a gateway has between one and eight sensors, and a validator can enforce it.

Step 2: connect the parts and bind values

Definitions say what can exist. Usages inside a concrete system say what does exist. Add a configured instance that connects the pieces:

package GatewayModel {
    // continued: a concrete configuration
    part gw : Gateway {
        attribute :>> mass = psu.mass + cpuModule.mass + 0.12 [kg];

        part :>> psu {
            attribute :>> ratedPower = 60 [W];
            attribute :>> mass = 0.30 [kg];
        }
        part :>> cpuModule {
            attribute :>> mass = 0.08 [kg];
        }

        // wire the power supply to the compute module
        connect psu.out28 to cpuModule.powerIn;

        // wire the first sensor to the sensor bus
        connect sensors[1].bus to cpuModule.bus;

        // uplink bound through to the gateway boundary
        bind uplink = cpuModule.uplink;
    }
}

Three operators deserve attention. :>> is redefinition: it says “this feature is the same feature as the inherited one, with a more specific value or type”. connect ... to ... creates a connection between two ports, and the interface compatibility (a conjugated port on one end) is checked. bind states that two features always have the same value, which is how the internal uplink is exposed at the gateway boundary. The mass computation is a binding expression, so the roll-up is part of the model rather than a spreadsheet beside it.

Hand-check the numbers. With the PSU at 0.30 kg, the CPU module at 0.08 kg and an assumed 0.12 kg for housing and cabling, the gateway mass is 0.30 + 0.08 + 0.12 = 0.50 kg. That is exactly at a 0.5 kg budget, which will matter in a moment: it is a deliberate edge case that shows how a requirement check behaves at the boundary.

Figure 2: Structure of the gateway model. Part definitions are reusable types; usages inside gw are the configured occurrences that connect through typed ports.

Figure 2 renders the structure as a diagram. A graphical tool would draw the same thing as an interconnection view, and clicking any box would lead to the textual declaration above. The long-description version: the gateway contains a CPU module, a power supply and up to eight temperature sensors, with a power link from supply to CPU, a sensor-bus link from sensor to CPU, and an uplink port exposed at the outer boundary.

Step 3: requirements and satisfaction

Now add a requirement. In v2 a requirement definition has a subject (the thing it constrains) and one or more constraints that evaluate to true or false:

package GatewayRequirements {
    private import GatewayModel::*;
    private import ISQ::*;
    private import SI::*;

    requirement def MassLimitReq {
        doc /* The gateway shall not exceed its mass budget. */
        attribute massBudget : MassValue;
        subject gateway : Gateway;
        require constraint { gateway.mass <= massBudget }
    }

    requirement gwMassLimit : MassLimitReq {
        attribute :>> massBudget = 0.5 [kg];
    }

    // The satisfy relationship: the configured gateway claims to meet it
    satisfy gwMassLimit by GatewayModel::gw;
}

The requirement is a typed, parameterized object, not a paragraph in a document. satisfy is a first-class relationship, so a query such as “every requirement that has no satisfier” is a model query, not a spreadsheet filter. For our numbers the constraint evaluates 0.50 <= 0.50, which passes, and bumping the housing allowance to 0.13 kg breaks it. A tool with an evaluation engine will show that immediately.

Be careful with what “satisfy” asserts. It records a claim and, where the constraint is computable from model values, can be evaluated. It does not by itself prove the physical product meets the requirement. That evidence belongs to verification, which the next step addresses.

Step 4: behavior and verification

Behavior in v2 is composed of actions with typed inputs and outputs. A minimal sampling loop:

package GatewayBehavior {
    private import ScalarValues::*;

    action def ReadSensors   { out readings : Real[1..8]; }
    action def Aggregate     { in readings : Real[1..8]; out summary : Real; }
    action def PublishUplink { in summary : Real; }

    action def SamplingCycle {
        action read : ReadSensors;
        then action agg : Aggregate;
        then action pub : PublishUplink;

        flow read.readings to agg.readings;
        flow agg.summary   to pub.summary;
    }
}

then imposes ordering and flow moves values between action pins. This is intentionally simple. The point is the contract: a later model can allocate SamplingCycle to the CPU module, attach a time-bound requirement to it, and give a test or analysis case something concrete to verify. Verification itself is expressed as a verification case that has a subject, an objective naming the requirements it checks, and a verdict result. A mass check by weighing the first production unit, or a thermal check by analysis, are two verification methods that attach to the same requirement. In a PLM thread, the verdict is exactly the record a quality or certification workflow wants to ingest.

Running the model

To exercise this, use whichever of three routes suits you. The Eclipse-based pilot implementation and the Jupyter kernel from the release repository parse the notation and can render diagrams; SysON gives a browser experience; and commercial editors add evaluation consoles, simulation and integrations. Whichever you choose, the first test is not diagrams but a parse-clean file, then a connection check (are the port directions compatible), then the requirement evaluation. If your tool can only draw and not evaluate, you are testing a drawing tool rather than a v2 modeling environment.

The Systems Modeling API: How Tools and PLM Talk to the Model

Direct answer. The Systems Modeling API and Services specification defines a platform-independent model (PIM) of the services a model repository must offer, and a REST/HTTP platform-specific model (PSM) that binds them to JSON over HTTP. Its repository semantics are version-control semantics: projects, commits, branches and tags, with each model element addressed by a stable identity across commits.

That repository model is the single most important design decision in the ecosystem, because it makes models behave like source code. Every change creates an immutable commit; a branch points at a commit; a tag names one. An element has a stable identity that survives edits, and each commit records a new version of the element’s data. A PLM engineer will recognize the pattern immediately: identity is the master, the commit snapshot is the revision, and a baseline is a tag.

Figure 3: A read-transform-write synchronization loop. The integration service pins a commit, extracts a BOM-relevant slice and records the commit id on the PLM side.

Figure 3 shows the shape of a synchronization. The integration service asks the repository for the head commit of a branch, reads only the elements it cares about at that commit, writes the corresponding parts and attributes into PLM, and stores the commit id as provenance. Pinning the commit is what makes the exchange reproducible: you can always say which model state produced which part revision.

What the services cover

The specification groups its operations into services for projects, commits and branches, element retrieval and navigation, and queries. The pilot implementation’s Swagger documentation and the community API cookbook, a set of Jupyter notebooks, cover project, commit, branch and tag handling, element create/update/delete within a commit, fetching owned elements, multi-constraint queries, and navigating requirement, structure and behavior decomposition. The cookbook is the fastest way to see real traffic.

A caveat on endpoint paths. The REST binding is published as an OpenAPI description, and I have not re-fetched every path for this post. The sketch below uses the resource layout I understand the 1.0 binding to follow, with projects, commits and elements as nested resources. Check each route against the OpenAPI document served by your own repository before coding against it.

A minimal client

import requests

BASE = "https://sysml-repo.example.com"   # your Systems Modeling API server
S = requests.Session()
S.headers.update({"Accept": "application/json"})

def head_commit(project_id: str, branch_id: str) -> str:
    # A branch points at a head commit.
    r = S.get(f"{BASE}/projects/{project_id}/branches/{branch_id}")
    r.raise_for_status()
    return r.json()["head"]["@id"]

def elements(project_id: str, commit_id: str, kind: str):
    # Fetch every element of one metaclass at a pinned commit.
    r = S.get(f"{BASE}/projects/{project_id}/commits/{commit_id}/elements")
    r.raise_for_status()
    return [e for e in r.json() if e.get("@type") == kind]

if __name__ == "__main__":
    pid, bid = "PROJECT-UUID", "BRANCH-UUID"
    commit = head_commit(pid, bid)
    parts = elements(pid, commit, "PartUsage")
    for p in parts:
        print(commit[:8], p.get("declaredName"), p.get("@id"))

Everything is JSON with an @type discriminator naming the metaclass (PartUsage, PartDefinition, RequirementUsage, and so on) and an @id carrying the element’s identity. Because PartUsage and PartDefinition are separate metaclasses, the same query distinguishes catalog items from occurrences, which is the split a BOM extractor wants.

Writing is also a commit. A client posts a commit whose body lists changes, each wrapping a payload element with the identity it applies to. Because a commit is atomic, a half-applied edit never appears to other readers. It also means concurrent writers need a merge strategy: the specification gives you branches and commits, and conflict resolution is up to the repository and tooling.

Pagination, scale and performance

Real models are big. A vehicle-scale model can have millions of elements, and fetching them in one call is the first thing that breaks an integration. The REST binding supports paged element retrieval, so a robust client follows continuation links rather than assuming a full list. Design integrations to read narrow slices: elements of one metaclass under one owner, as of a pinned commit. Cache by commit id, since a commit never changes, which makes the cache trivially correct.

Worked arithmetic helps size this. Suppose a subsystem model has 40,000 elements and your client retrieves pages of 200. That is 200 round trips; at 80 ms each, 16 seconds, and almost all of it is wasted if only 600 elements are parts. Filtering by metaclass on the server, or using a query that returns only part usages under a given owner, collapses it to a handful of calls. The numbers here are illustrative, not benchmarks.

Standards neighbors: OSLC and XMI

Two other integration routes are worth naming. OSLC (Open Services for Lifecycle Collaboration) links resources across tools by URL and is widely used for requirements and change management; PTC’s documentation, for example, describes OSLC integration between its Modeler and Windchill. The OMG specification page I checked describes the PIM and generic PSMs and did not list OSLC as a normative binding, so treat an OSLC bridge as a vendor-supplied integration layered on top, not as part of the API standard. XMI interchange also remains, and the release repository publishes XMI versions of the normative libraries, but XMI is a file exchange route and lacks the query and versioning behavior that makes the API useful.

Connecting SysML v2 to PLM: Three Patterns and What Is Verified

Direct answer. There are three working patterns for joining a SysML v2 model to PLM: a link-only integration that stores references both ways, a synchronized-attributes integration that copies selected values and revisions across, and a model-driven BOM that generates part structure from the model. Start with links, because they carry the least risk and deliver the traceability auditors and change boards actually ask for.

Figure 4: Integration architecture. The model repository, an integration layer and the PLM system exchange references and attribute values; a commit id is the shared baseline.

Figure 4 puts the pieces in one picture. The integration layer is a deliberate component: it holds the mapping tables, runs the synchronization and records provenance, so neither the modeling tool nor the PLM system needs to know the other’s schema.

Pattern 1: link-only trace

The lightest integration stores a URL or identifier on each side. A requirement in PLM, or in a linked requirements tool, carries the API address of the model element that satisfies it, including the commit id. The model element carries the PLM object reference as metadata. No attribute values move.

This gives you the questions that matter at a design review. Which requirements have a satisfier? Which model elements have no requirement? When this change order modifies part 4411-B, which model elements and requirements are affected? Impact analysis is a graph traversal over those links. The cost is low and the failure mode is mild: links go stale if a model element is deleted, which a nightly integrity check catches.

Pattern 2: synchronized attributes

The next step copies agreed attributes: mass, rated power, supplier, interface identifiers. The direction of authority must be fixed per attribute. Mass allocation budgets usually originate in the model, while measured mass of the released part comes from PLM. Two-way sync of the same field is the classic recipe for silent overwrites, so define a single source of truth for every mapped property and implement the opposite direction as a read-only comparison that raises a flag.

A useful discipline is to separate design intent from realized data. The model holds the target (mass budget 0.5 kg); PLM holds the actual (0.47 kg weighed). A computed margin then lives in a report, not in either source. This reflects a recurring lesson from digital thread projects: the problem is rarely moving the data, it is agreeing on which side is allowed to change it.

Pattern 3: model-driven BOM

The most ambitious pattern derives a PLM structure from the model’s part tree. A PartDefinition maps to a part master, a PartUsage inside an assembly maps to a BOM line with a quantity taken from the multiplicity, and a connection between ports maps to an interface object or a relationship. It is attractive because the architecture and the engineering BOM stop diverging. It is also where integrations most often fail, because the logical architecture is not the physical product structure: one logical function may be implemented by two physical parts, and one purchased part may serve three functions.

The safe approach is an explicit allocation layer. Rather than assume model structure equals product structure, model the logical architecture, the physical architecture and the allocation between them, and generate the BOM from the physical side only. This is also how the digital twin gets its structure, as described in the digital twin and MES reference architecture.

What is verified for Teamcenter, Windchill and 3DEXPERIENCE

Vendor claims need a hard edge, so here is what I could confirm as of October 2026, and what I could not.

Siemens and Teamcenter. Siemens announced Systems Modeler for SysML v2 Standard on 3 June 2025, described as web-based and powered by IBM Rhapsody Systems Engineering, and said it would integrate with Teamcenter to connect a systems-focused digital thread. The announcement used future tense. I could not verify a specific generally available Teamcenter feature set, field mapping or API version in public documentation, so ask Siemens for the current integration scope and test it against your Teamcenter version.
PTC and Windchill. PTC announced SysML 2 capabilities in PTC Modeler starting with release 10.x, rolled out incrementally. A 4 August 2026 PTC post on release 10.3 describes a textual notation exporter to .sysml files, a simplified user role, and single sign-on across OSLC integrations for Windchill PLM, Codebeamer and Modeler. The earlier OSLC integration between Modeler and Windchill is documented in PTC’s help for release 10.2. I could not confirm API-level v2 element synchronization to Windchill parts; the documented route is OSLC links.
Dassault and 3DEXPERIENCE. Dassault’s CATIA SysML v2 page claims support for the full v2 standard in the 2026x generation of CATIA Magic, says Teamwork Cloud conforms to the SysML v2 API and Services specification, and describes integration of Teamwork Cloud with the 3DEXPERIENCE platform. These are vendor statements, not independently tested here, and the page also lists proprietary evaluation services beyond the standard.

The sober reading: the standard API is real and several repositories implement it, but each PLM vendor’s integration depth varies, and OSLC link-level integration is the best documented common denominator. Plan a pilot on your own versions instead of relying on a roadmap slide.

Designing trace links that survive change

Links decay unless you design for stability. Use the element’s stable identity, not its name, as the link target; names change, identities do not. Always include the commit id (or the tag for a released baseline) so a link says “this requirement was satisfied by this element at baseline R3”. Store a short hash of the satisfying element’s relevant attributes alongside the link, so a later check can tell the link target changed in a way that affects the claim. And decide who owns link creation, because links created by hand by three groups produce three conventions.

SysML v1 vs v2 and a Realistic Migration Plan

SysML v2 is not an upgrade in the sense of a service pack. It is a new language with a different metamodel, and the compatibility story is a transformation, not a file open. The table summarizes the differences that affect day-to-day work.

Aspect	SysML v1.x	SysML v2
Foundation	UML profile with stereotypes	KerML formal kernel, no UML dependency
Primary notation	Graphical, with tool-specific text	Standard textual and graphical notations over one model
Structure concept	Block plus part property	Definition plus usage, uniform across all element kinds
Requirements	Stereotyped classes with text	Typed requirement definitions with subject and constraints
Units and quantities	Informal or tool library	Standard ISQ and SI libraries in the language
Programmatic access	Tool-specific APIs, XMI	Standard API with projects, commits, branches, tags
Interchange	XMI, version-sensitive	API plus textual files, XMI for libraries
Versioning	Tool repository	Model-level commit semantics, git-friendly text

The specification’s second part defines a v1-to-v2 transformation, and vendors have built migration tooling on it; Dassault’s page, for instance, references a migration path available from the 2026x generation. Expect the transformation to carry structure, requirements and relationships well, and to need manual rework for tool-specific profiles, custom stereotypes and diagram layout.

A phased plan

Pilot in parallel (4 to 8 weeks). Pick a bounded subsystem and model it fresh in v2. Do not migrate a flagship model first. The goal is to learn the textual notation, library conventions and your tool’s evaluation features.
Define the integration contract. Write down which properties flow between model and PLM, in which direction, and what the link format is. This is the work that survives any tool change.
Automate the baseline. Put model text in git or in the repository, tag baselines, and have the integration service record commit ids in PLM on release.
Migrate selectively. Use the transformation for models with active programs where continuing in v1 costs more than conversion. Leave archived programs in v1 with a read-only viewer.
Train reviewers, not only authors. Reviewers need to read the textual form and the diagram views, and to trust queries.

The US Department of Defense guidance recommends nearly the same sequence: a strategic transition plan, learning the notation and API, then a pilot. The agreement of a defense engineering office and a PLM practitioner on a pilot-first order is a good sign that it is the sensible one.

What changes for the people

Systems engineers move from drawing to modeling, which is closer to programming than to PowerPoint. Teams that already use pull requests and continuous integration have an advantage, because model text can be linted, diffed and tested in a pipeline. PLM administrators, in turn, need to learn that a model is addressable data. The shared vocabulary of identity, revision and baseline is the bridge between them.

Trade-offs, Gotchas, and What Goes Wrong

Honest limits come first. Tool maturity varies. The standard is final, but implementations of the full language, the evaluation semantics and especially the API differ in coverage. A vendor claim of full standard support is a starting point for a test, not a result, and the community conformance test suite was still being built when the standard was adopted.

Text is not automatically better. Large textual models are hard to navigate without good tooling. Diffs of generated or reordered text can be noisy, and an engineer who edits the text of a model produced by a graphical tool may disturb layout metadata. Agree on one authoring path per model.

Round-trip loss. When a PLM tool imports only part of the model, or a transformation drops unrecognized elements, you get silent data loss. Insist on integrity checks: counts of elements by metaclass before and after, and a periodic reconciliation report.

Identity drift. Delete a part and recreate it with the same name and you have a new identity. Links pointing at the old one break. Teach authors to rename and redefine rather than delete and recreate, and have the integration service flag dangling links.

Two-way sync collisions. The most common production incident is two systems both editing a shared attribute. Define a single owner per property, write it into the mapping table, and make the opposite direction a comparison only.

Logical-physical confusion. Generating a BOM directly from the logical model produces a BOM that reflects functions rather than purchasable parts. Use the allocation layer discussed earlier.

Security and access. A model repository holds design intent that is often export-controlled or commercially sensitive. API access needs the same authentication, authorization and audit as your PLM, and the integration service account should have the narrowest scope that works. Industrial environments should also consider network zoning, as discussed in the IEC 62443 zones and conduits guide.

Performance cliffs. Unfiltered element retrieval over a large model, or recomputing roll-ups on every read, will make an integration crawl. Pin commits, filter on the server, cache by commit id.

Organizational debt. The hardest failure is cultural: a modeling team that produces a beautiful model nobody consults. A model earns its place when a change board, a test plan or a supplier requirement actually reads from it.

Practical Recommendations

If you are starting now, optimize for learning and for a defensible integration contract rather than for completeness. Model one subsystem end to end, including requirements, satisfy relationships and one verification case, because the full loop exposes tooling gaps early. Keep the model text in version control or in a repository that offers commit semantics, tag every released baseline, and record the baseline identifier in PLM.

Choose tooling by testing three things: round-trip between text and diagrams, requirement evaluation on a model with units, and the API calls your integration will need, run against your own PLM version. Ask each vendor for a written statement of which API version and which operations they support.

Design the link format before you design the sync. A stable link containing project, element identity and baseline is cheap and compatible with every pattern in this post. Add attribute synchronization only for properties with a clear single owner, and add model-driven BOM generation last, behind an allocation layer.

Checklist for the first ninety days:

[ ] Pilot subsystem chosen and modeled in textual notation
[ ] Standard libraries imported and units used for every physical quantity
[ ] Requirement definitions with subjects and constraints, not free text
[ ] Satisfy and verification relationships present for every top-level requirement
[ ] Model stored with commit and tag semantics
[ ] Link format agreed with PLM owners, using identity plus baseline
[ ] One source of truth documented for each synchronized property
[ ] Integrity report comparing element counts and link validity, run nightly
[ ] Vendor statements on API version and PLM integration scope obtained in writing
[ ] Reviewers trained on both textual and graphical views

Frequently Asked Questions

Is SysML v2 an official standard yet?

Yes. OMG announced final adoption of SysML v2.0, KerML 1.0 and Systems Modeling API and Services 1.0 on 21 July 2025, and the community release repository records formal adoption on 30 June 2025. The documents received an editorial update in March 2026 for submission to ISO. Tools implement the standard to different degrees, so confirm coverage with your vendor rather than assuming that adoption of the specification implies a finished product.

What is the difference between SysML v2 and KerML?

KerML is the Kernel Modeling Language, a small formal language of types, features and relationships that defines semantics. SysML v2 is built on top of KerML and adds systems engineering constructs such as parts, ports, requirements, actions, states and verification cases, plus a graphical notation. You can think of KerML as the foundation and SysML v2 as the vocabulary you actually use when modeling a product or system.

Can I use SysML v2 textual notation without a commercial tool?

Yes. The community publishes a pilot implementation with Eclipse editor plugins and a Jupyter kernel in its release repository, and Obeo’s open-source SysON provides a browser-based modeler. Those are enough to learn the notation, parse models and render diagrams. Commercial tools add evaluation consoles, simulation, collaboration and enterprise integrations, which matter when you scale a program or connect to PLM.

Does SysML v2 integrate natively with Teamcenter, Windchill or 3DEXPERIENCE?

Vendors describe integrations, with varying maturity. Siemens said its SysML v2 modeler would integrate with Teamcenter, PTC documents OSLC integrations between its modeler and Windchill, and Dassault says Teamwork Cloud conforms to the SysML v2 API and integrates with 3DEXPERIENCE. Public documentation does not settle exact feature scope, so run a pilot on your own versions and ask for written statements of supported operations.

How is the Systems Modeling API different from OSLC?

The Systems Modeling API is a repository interface for SysML v2 models: projects, commits, branches, element retrieval and queries, with a REST/HTTP binding. OSLC is a general lifecycle-linking approach that connects resources across tools by URL. They complement each other. Use the API to read and write model data, and use OSLC-style links where a PLM or requirements tool expects them.

Should I migrate my SysML v1 models now?

Not wholesale. Start a v2 pilot on a bounded subsystem, define your PLM integration contract and learn the tooling. Migrate active programs selectively using the v1-to-v2 transformation and vendor migration tools, and expect manual rework for custom profiles and diagram layout. Leave archived programs in v1 with a read-only viewer. A phased approach limits risk and matches the defense transition guidance.