What’s the Difference Between SysML v1 and SysML v2?

SysML v1 is a profile of UML — a set of stereotypes layered on a software-modeling language. SysML v2 is a new language built from scratch on its own foundation (KerML), with a usage-focused way of modeling, a standard textual notation alongside diagrams, and a standard API for tool-to-tool exchange. It is not an upgrade to v1; it is a rebuild, and the differences show up everywhere from the metamodel to your daily workflow.

We model in SysML v1 in Cameo every working day, and we’ve spent real time in the public SysML v2 specification and pilot tooling. Here’s the difference as it actually lands on a working modeler — not the marketing version.

v1 is UML wearing a systems costume

When OMG adopted SysML v1 back in 2006, the fastest route to a systems language was to reuse UML. So v1 is technically a UML profile: a block is a stereotyped UML class, a requirement is a stereotyped class, a value property is a UML property with extra rules. That pragmatic choice got MBSE off the ground, and we covered the family resemblance in What’s the Difference Between SysML and UML?.

But it means every v1 model drags UML’s software heritage around. The semantics of your systems model are defined across two specifications — the UML spec plus the SysML profile on top — and where they interact you get corner cases that even experienced modelers argue about. It also means your learning curve includes UML machinery you’ll never use for systems work.

v2 stands on its own foundation

SysML v2 is not a profile of anything. It is built on KerML, the Kernel Modeling Language — a small core language of classifiers, features, specialization, and connections, with formally defined semantics. SysML v2 then layers the systems vocabulary on top: parts, attributes, ports, actions, states, requirements, constraints, analyses.

Because everything in v2 is constructed the same way from the same kernel, the language is far more regular. Learn how one construct works and you’ve mostly learned how they all work. If you’re curious about that foundation layer, we go deeper in What Is KerML and Do I Need to Learn It?.

Definitions and usages replace the block/part split

This is the change a v1 modeler feels first. In v1, a block and a part property are different metamodel animals: you define a FlightController block, then create a part property typed by it inside your Quadcopter block. Context-specific detail — say, the battery in this particular drone has a 5000 mAh capacity — requires awkward v1 patterns like property-specific types.

In v2, everything is either a definition or a usage, and usages are first-class citizens. You write a part def FlightController, then use it: part fc : FlightController inside your quadcopter. Crucially, a usage can be refined right where it sits — you can nest structure under it, redefine attributes, and add context-specific values without inventing new definitions. In textual notation, the drone’s structure reads like this:

• part def Quadcopter { part fc : FlightController; part esc : ESC[4]; part motor : Motor[4]; part battery : Battery; }

Four ESCs and four motors declared with a multiplicity, context detail added in place. The block/part dichotomy that generates so many v1 modeling debates simply isn’t there.

Textual notation is standard, not an afterthought

v1 is a graphical language. The model lives in your tool’s repository, and diagrams are the only standardized human-readable view. v2 defines a textual notation and a graphical notation as co-equal, interchangeable views of the same underlying model.

That sounds academic until you try to review a model change. Text means you can diff two versions line by line, review model changes the way software teams review code, and paste a model fragment into an email or a document and have it be precise. For teams that already live in version control, this is the single most attractive thing about v2.

A standard API replaces file-drop exchange

v1 tool interoperability rests mostly on XMI file export/import, which is notorious for dropping information in transit — we unpack why in Why Does Model Exchange Between MBSE Tools Lose Information?. SysML v2 comes with a standard Systems Modeling API: a defined way to query, fetch, and commit model elements over a service interface, independent of any one vendor’s file format.

If tools implement it faithfully, exchanging model data stops being “export a file and pray” and becomes a query against a well-defined interface. That’s the promise, anyway — how completely each vendor implements it will decide how much of it you feel.

What this means for a working v1 modeler

Here’s our practical read, as a team whose paycheck depends on v1 models today:

• Your thinking transfers completely. Structure, behavior, requirements, and parametric analysis all exist in v2. Decomposing a drone into flight controller, ESCs, motors, and battery is the same intellectual act in either language.
• Your models do not transfer automatically. Migration is a mapping exercise between two different metamodels, not a file conversion. Some v1 constructs map cleanly; some don’t.
• Your tool skills partially transfer. Diagramming instincts carry over; the textual notation will be new muscle memory.
• There is no urgency cliff. v1 tools are mature, widely deployed, and will be supported for years. v2 tooling is arriving in stages.

The mistake we see teams make is treating this as a version bump, like SysML 1.5 to 1.6. It isn’t. Plan for it the way you’d plan for adopting a new language that happens to share your language’s worldview.

Where to go from here

If your team is modeling in v1 today and wondering how v2 should shape your roadmap — what to standardize now, what to avoid, when to pilot — that’s exactly the conversation we have in CameoMagic advisory engagements. The easy first step is a free 30-minute model review: bring your model, and we’ll look at where you stand and what v2 readiness means for you specifically.