SysML v2 in Practice: From Migration to Requirements and Analysis
Go beyond the webinar with Dr. Bruce Powel Douglass in a live four-hour masterclass on what to keep and what to rethink when your models move to SysML v2, with requirements and analysis cases worked through in practice.
🗓️ Sat 14 Nov, 11 AM ET · 20% off
✍️ From the editor’s desk
Welcome to the 70th issue of Deep Engineering!
At GitHub Universe on October 28, GitHub launched Copilot Fusion, and its new Octoverse report found that more than 40% of pull requests in September began with an agent’s first draft. Software delivery is being rebuilt around agents that read and write code as text, and Satya Nadella said that GitHub is “redefining the SDLC for the agentic era.”
That shift is possible in part because software already lives as text in repositories, where an agent can read it, change it and open a pull request. Engineers designing aircraft, satellites and medical devices also use models to describe the requirements, architecture and behavior of the wider system. And SysML v1 has no standard textual notation for authoring those models, which makes the text-based workflows familiar from software development harder to reproduce across modeling tools.
But SysML v2 changes that. And so for today’s issue, we’re asking the question directly, which is whether SysML v2 really is better than v1, and what it takes to move. Earlier this month we hosted a webinar featuring Dr. Bruce Powel Douglass, principal at A Priori Systems and one of the authors of the SysML v1 standard, on exactly that topic. And today’s feature brings you his answer in his own words, along with the full video and his slides.
Bruce is also the author of SysML v2 Masterclass from Packt, which also publishes Deep Engineering.
Let’s get started.
Before you add another agent, give them all the same context
PlayerZero is the AI orchestration and context platform for engineering teams
Code isn’t the bottleneck anymore. Context and review are. Every agent your team adds starts from its own partial picture, and your senior engineers end up filling the gaps by hand.
PlayerZero builds one engineering world model from your code, tickets, and telemetry, then orchestrates agents across product, engineering, QA, support, and SRE on top of it. Work moves between teams with full context attached. When an agent reaches the edge of what it should decide, it pulls in the right person with the investigation already done. That decision goes back into the model, so the next agent inherits it.
Key Data doubled its release velocity. Cayuse catches 90% of issues before production.
🧠 Expert Insight
So Is SysML v2 Really Better Than v1? What Does That Mean for Systems Engineering?
Webinar hosted by Denim Pinto, featuring Dr. Bruce Powel Douglass.
Adapted by the Deep Engineering editors from the webinar presentation, accompanying slides and audience Q&A, with edits for length and clarity.
Whenever a new standard comes out, the same question comes up. Does it make my life better, and are there things I can do now that I couldn’t do so well before?
Full disclosure, I’m one of the authors of the SysML v1 standard, though I wasn’t involved in developing v2. I have followed it closely, and I’ve written a fairly large book about it. My short answer is yes, SysML v2 really is better than v1. It is also a different language, and you should treat it that way.
A new language, not v1 with more added
SysML v1 was wildly popular, the 800-pound gorilla for representing requirements, architectures and designs in systems engineering. But because it’s a profile of UML, it brings along some baggage from its UML heritage, including imprecise bits and things that are fairly convoluted to express. The Object Management Group redesigned it for precision and expressiveness, consistency, interoperability with other engineering tools, usability, extensibility and a migration path for v1 users.
It’s important to understand that SysML v2 is not just SysML v1 with more stuff. When UML went from version 1 to version 2, I worked on both as one of the contributing authors, and that really was UML++, the existing framework with new things added. That’s not true here.
SysML v2 is built on KerML, a kernel modeling language designed for precise model semantics, and some concepts mean different things. Interfaces, for example, are wildly different. In v1 an interface block describes a contract about what can be exchanged across a port, and in v2 it’s a kind of connection that is semantically different. If you know v1 well and don’t recognize those differences, they will trip you up.
Definition and usage, everywhere
The architecture is more regular, and that’s on purpose. In v1 we had blocks and part properties, activities and actions, constraint blocks and constraint properties, and requirements as stereotypes, which was a similar idea with an inconsistent vocabulary. In v2 there’s one pervasive pattern, so you have part def Wheel and part frontLeft : Wheel, action def Brake and action braking : Brake, state def Armed and state armed : Armed. A definition is a reusable kind, and a usage is that meaning in a particular context.
Once you learn that pattern, it repeats across parts, actions, states, ports, requirements, cases and calculations. It’s not completely regular, because there’s no def and usage for quantity kinds and units, for example. But it’s far more regular than v1, and similar pictures do not guarantee similar semantics.
You cannot model in PowerPoint
I’ve been arguing this for decades. The model is not the diagram. A diagram is a visualization of some aspect of the model, chosen to answer some question. You don’t do CAD with crayons, and you don’t do modeling in PowerPoint or Visio. Those tools draw pictures, and each picture stands alone. As far as I’m concerned, PowerPoint engineering is an insult, and I use it when I’m mad at somebody.
The model is the interconnected semantic data, the elements, their types, units, ownership, constraints and relationships, conforming to the syntax and semantics of the language. Diagrams are just views of it, and you need a modeling tool to build it. SysML v1 had no standard textual notation. SysML v2 has one without giving up graphics, so text and diagrams are two notations for the same underlying model. The text is actually more complete, because some things, such as imports, can’t be shown graphically. I go back and forth all the time, using diagrams to understand how an algorithm flows and text for the detailed properties.
There is a practical limitation when moving models into Git. In the Cameo 2026x workflow I described, exporting the model as text preserves its semantics but loses the geometry of the diagrams. The model information and the exact layout of a diagram are different things to preserve.
Text gives AI something real to work with
Having a standard textual notation makes AI much easier to apply. For the second edition of my book Agile Systems Engineering with SysML v2 and AI, I have used a lot of prompts and personas to build and stress models. Here is the delivery-drone prompt from the session.
Create valid SysML v2 text for a delivery drone.
Define a DeliveryDrone part with payloadMass as a mass quantity.
Create requirement DR-24, "Payload Limit".
Make the DeliveryDrone the requirement subject.
Require payload mass to be no greater than 5 kg.
Include the imports needed for mass and kg.
Return only the model text.The following model is adapted from the example output shown in the presentation.
package DroneRequirements {
public import ISQ::*;
public import SI::*;
part def DeliveryDrone {
attribute payloadMass :> ISQ::mass;
}
requirement <'DR-24'> PayloadLimit {
subject drone : DeliveryDrone;
require constraint {
drone.payloadMass <= 5 [kg]
}
}
}There’s no diagram scraping and no proprietary click automation, just model semantics in text that you can paste into your model and syntax-check. But don’t trust your AI. It hallucinates syntax and semantics, and it’s like a really happy intern just out of college who is very confident in their conclusions and very often wrong, in ways big or small. Human engineering review remains mandatory.
Requirements finally carry real semantics
This is where I think v2 is unambiguously better. In v1, a requirement is essentially a stereotyped UML class, and the ID and text dominate. Text has all kinds of problems, from ambiguity to a lack of verifiability. In v2, requirement definitions are constraint definitions, and the subject, parameters, assumptions and formal constraints can all live in the requirement itself.
The treadmill example brings together a subject, speed limits, units, assumptions and a formal constraint, and expresses the permitted commanded speeds in increments of 0.1 miles per hour.
calc isInteger {
in attribute x : Real;
return result : Boolean;
comment /* Use the standard floor() function from library
QuantityCalculations. If x equals its own floor,
it has no fractional part. */
x == floor(x)
}
requirement BeltSpeedRange {
subject treadmill : Treadmill;
attribute minSpeed : SpeedValue = 0 ['mi/h'];
attribute maxSpeed : SpeedValue = 15 ['mi/h'];
in attribute resolution : SpeedValue = 0.1 ['mi/h'];
require constraint {
treadmill.belt.commandedSpeed >= minSpeed and
treadmill.belt.commandedSpeed <= maxSpeed and
isInteger((treadmill.belt.commandedSpeed - minSpeed) / resolution)
}
assume constraint {
minSpeed >= 0 and maxSpeed >= 0 and maxSpeed > minSpeed
}
doc /* The treadmill shall allow the user to set any belt speed between
* minSpeed and maxSpeed in increments of specified resolution. */
}The speed values come with real units from the standard libraries. The assume constraint states the conditions under which the requirement applies. The require constraint bounds the commanded speed and checks that its distance from the minimum is an integer number of resolution steps.
The shall statement can remain as useful documentation for stakeholders, while the formal constraint gives the permitted values a precise meaning. This example constrains commanded speed. Verifying that a user can select every permitted value requires additional verification of that behavior.
Numerical evaluation depends on the modeling tool’s support for the standard quantity and function libraries.
More of the engineering lives in the model
V1 gave us use cases. V2 makes use cases one kind of case, alongside analysis cases that ask how well a design performs and verification cases that build the evidence that you met your requirements. There’s even standard machinery for trade studies.
Calculations get cleaner too. calc definitions have explicit inputs and a returned result, behave like pure functions, and carry typed quantities and units, so more of the calculation can be expressed directly in the language.
Then there’s the standard Systems Modeling API, which is easy to underestimate. In v1, everybody did their own thing, with lots of fragile point-to-point integrations. Now there’s a standard way for tools, scripts, simulations and AI to query and build models, and the model becomes a platform, not just a file. Add 94 standard libraries, and the ones I import in almost every package are ScalarValues, ISQ and SI, plus USCU when I need US customary units.
Better doesn’t mean simpler
Here’s the honest caveat. The KerML specification runs to 454 pages, the SysML specification to 691 and the API specification to 107. You have to learn a textual notation, a graphical notation that looks familiar but isn’t quite the same, a fair amount of subtle semantics and the libraries. SysML v1 let you be productive while ignoring much of the UML machinery underneath. SysML v2 puts more of the semantic machinery directly in front of you.
I think of this as conceptual burden, which is the volume of things you need to know multiplied by their average complexity. V2 has a higher conceptual burden than v1. It’s not hugely higher, but it’s significant, and in return you get more precision and more engineering power. That’s a win, as long as you don’t expect to walk in with v1 knowledge and have everything just work.
Start new programs in v2
A migration path exists, but it requires judgment. Some state-machine constructs do not have direct equivalents in v2. History pseudostates are one example, so if your models rely on them, you will need another way to express that behavior.
My advice is practical. If a program is almost done or only needs light maintenance, stay in v1, because migration will be non-trivial, expensive and somewhat error-prone.
If you are starting a new model-based systems engineering program today, start in v2. Choose a tool that supports the analysis, simulation and verification your program needs. The commercial tools I have used, particularly Cameo 2026x, are good enough to begin serious engineering work, and I am pleasantly surprised by their quality for such a new standard. I expect every new MBSE program to use v2 within five years.
So my answer to the title question is yes. SysML v2 is better engineered, more precise and far better suited to automation. It’s also a different language, so treat it that way.
👀 In case you missed it
🛠️ Tool of the Week
SysML v2 Pilot Implementation - The open source reference implementation of SysML v2 and KerML, built alongside the specifications to validate them.
Catch syntax errors and unresolved references while editing textual models.
Explore small models interactively through a dedicated Jupyter kernel.
Reuse the supplied standard libraries for quantities, units and scalar types.
View generated diagrams through its PlantUML integration.
📎 Tech Briefs
Agentic AI Foundation adds four open projects - Agent Skills, Open Responses, OpenEnv and OpenSandbox join AAIF under its open, vendor-neutral governance model.
Claude research model finds 62 Chrome vulnerabilities - Anthropic says its unreleased research model found 62 critical or high-severity Chrome vulnerabilities, now patched.
Gemini Robotics ER 2 enters Google Cloud preview - Public preview supports robot task planning and video-based progress checks across simulated and physical workflows.
NVIDIA Vera CPUs arrive on Oracle Cloud - Vera CPUs support agent tool calls, code execution and data retrieval between model calls on OCI.
GitHub adds four million CPU cores - Capacity added this year includes 160 PB of storage, while migration to multiple Azure regions continues.
That’s all for this week. If you take one thing from Bruno, answer his two questions in writing before the week is out.
Keep building,
Saqib Jan, Editor-in-Chief, Deep Engineering
Partner with Deep Engineering
If your company wants to reach senior developers, software engineers, and technical decision-makers, speak to us about partnering with Deep Engineering