Skip to main content

SysML v2: The Next Frontier in Automotive System Modeling

· 7 min read
Blagoje Mrkic
Blagoje Mrkic
Model based Systems Architect

Future of MBSE is SysML v2

SysML v2: The Next Frontier in Automotive System Modeling and why.

Welcome back to MBSE Explained! As systems engineers and architects in the automotive world, we’re constantly navigating the immense complexity of modern vehicles, especially EVs. For years, Model-Based Systems Engineering (MBSE) with SysML v1.x has been our trusted language for taming this complexity, allowing us to define requirements, architectures, and behaviors in a structured way. From my own experience architecting powertrain and converter systems, SysML has been invaluable.

However, as we race towards the era of the Software-Defined Vehicle (SDV), the limitations of our current tools are becoming more apparent. The seams between hardware and software development are stretching, and the dream of seamless interoperability between different engineering tools often feels just out of reach.

Enter SysML v2. It’s not just an update; it’s a fundamental rethinking of how we model and interact with complex systems. This post will explore why SysML v2 is the next frontier for automotive MBSE and how it’s poised to finally bridge the gap between software and hardware development, paving the way for more integrated and innovative EVs.

The Challenge with SysML v1.x in Modern Automotive Design​

SysML v1.x has served us well, but it was designed for a different era. Today's automotive architectures are a dizzying blend of distributed ECUs, high-performance computers, and millions of lines of code. When trying to model this reality with SysML v1.x, we often run into a few common roadblocks:

  • Tool-Centric Silos: While SysML is a standard, its implementation can vary significantly between tools. Exchanging models via XMI (XML Metadata Interchange) is often a painful, error-prone process that feels more like a data conversion project than a collaboration.
  • A Steep Learning Curve: The graphical-first nature of SysML v1.x can be intimidating for engineers outside the systems domain, particularly software developers who are more comfortable with text-based languages.
  • The Software-Hardware Disconnect: It can be difficult to precisely define the intricate interfaces between software components and the hardware they run on. This ambiguity often leads to integration issues late in the development cycle—a costly problem in any automotive project, especially those governed by standards like ISO 26262.

Imagine trying to model an Over-The-Air (OTA) update mechanism. With SysML v1.x, you can capture the high-level sequence, but defining the precise data packets, memory allocation, and processor interrupts in a way that’s directly usable by both firmware and hardware teams is a challenge.

What is SysML v2 and Why is it a Game-Changer?​

SysML v2 is a major evolution designed to address these challenges head-on. It introduces three core concepts that will fundamentally change how we practice MBSE in the automotive industry.

1. A Standard Textual Syntax​

For the first time, SysML has a standardized, human-readable textual notation alongside its traditional graphical diagrams.

Image1

Image taken from Sys Git.

Think of it as a programming language for your system model. This is a massive win for a few reasons:

  • Version Control: You can now treat your models like code. Storing them in Git, tracking changes, branching, and merging becomes straightforward. This revolutionizes collaboration among large, distributed teams.
  • Automation & Scalability: Text is easy to parse and generate. We can now write scripts to create, modify, and validate parts of our model automatically, dramatically improving efficiency.
  • Accessibility: Software engineers can now engage with the system model in a language they are comfortable with, breaking down the barrier between systems and software engineering.

Image1

Example from OMG Systems Modeling Language.

2. Formal Semantics​

SysML v2 is built on a formal mathematical foundation. This sounds academic, but its practical implication is huge: a model’s meaning is now unambiguous and verifiable. It ensures that a requirement or an interface defined in one tool means the exact same thing in another. This precision is critical for safety-critical systems (ISO 26262) and for enabling true, reliable interoperability between tools.

3. A Standard API​

SysML v2 specifies a standard Application Programming Interface (API). This allows tools and scripts to programmatically access and manipulate the model data in a consistent way, regardless of the vendor. This opens the door to a connected ecosystem where your MBSE model becomes the central hub, integrating with:

  • Simulation tools (e.g., MATLAB/Simulink)
  • Requirements management tools (e.g., JAMA, DOORS)
  • Software development tools (e.g., ALM, CI/CD pipelines)
  • Custom analysis and reporting scripts

Bridging the Software-Hardware Divide with SysML v2​

So, how do these new features help us build better cars? Let's go back to our OTA update example.

With SysML v2, a systems architect can define the OTA process using the new textual syntax.

Hardware Perspective: The model can specify a hardware component, like an UpdateController, with precise properties: part updateController : UpdateController { attribute requiredMemory : MemorySize = 512.MB; }

Software Perspective: The software team can see this requirement directly in the model and define a software component that allocates and uses this memory. They can define the data packet structure textually, ensuring it aligns perfectly with the hardware's capabilities. package OTA_Data { import SI_Units::*; structure UpdatePacket { public sourceId : Integer; public payload : stream; public checksum : Integer32; } }

The Connection: Using the API, we can automatically run a script that verifies if the software's memory requirements exceed the hardware's allocation. We can also auto-generate C-header files or AUTOSAR configuration XML directly from the model, ensuring the software and hardware teams are working from the exact same "source of truth." This tight integration eliminates ambiguity, reduces integration errors, and accelerates the entire development lifecycle.

The Road Ahead: Adopting SysML v2 in Your Automotive Workflow​

The transition to SysML v2 won't happen overnight. Tool vendors are actively working on implementations, and engineering teams will need training to adapt to the new text-based paradigms.

My advice is to start small. Identify a pilot project—perhaps a new EV charger interface or an ADAS feature—and explore how SysML v2 can solve a specific, nagging problem. Focus on leveraging the textual syntax for version control and the API for a simple automation task, like generating documentation or validating a set of interfaces. These early wins will build momentum and demonstrate the immense value of this new standard.

Conclusion​

SysML v2 is more than an incremental update; it’s a modern language for a modern discipline. By introducing a textual syntax, formal semantics, and a standard API, it provides the foundation for a more integrated, automated, and collaborative approach to systems engineering. For the automotive and EV industry, this means faster innovation, higher quality, and the ability to finally manage the exploding complexity of the software-defined vehicle.

What are your thoughts on SysML v2? Are you excited about its potential, or do you have concerns about the transition? Share your thoughts in the comments below!

At MBSE Explained, we’re committed to simplifying systems for smarter EVs, and we believe SysML v2 is a giant leap in that direction.