We are currently in the process of evaluating SysML v2 for our systems engineering projects and are particularly interested in moving beyond static modeling toward a fully operational digital engineering environment. Our ultimate goal is to establish a model-centric workflow where our SysML v2 models become the single source of truth—not just for documentation, but for driving analysis, simulation, and integration with downstream engineering tools (e.g., CAD, PLM, and simulation platforms).
As we explore the emerging ecosystem of SysML v2 tools, we find ourselves grappling with the practical question of what it actually takes to make a model “work” in the sense of being executable, integratable, and maintainable over the entire system lifecycle.
We would greatly appreciate any insights from the community or the Sensmetry team on the following questions:
What toolchain do we need to actually make our SysML v2 models executable, analyzable, and integratable into our engineering workflow?
Does Sensmetry’s current toolset provide everything we need to make our SysML v2 models actually work (i.e., edit, automate, version, and eventually simulate/validate), or are we missing key pieces?
To provide a bit more context: we are particularly interested in understanding the integration story—how Sensmetry tools (Syside Modeler, Automator, and Sysand) connect with external simulation environments and whether we would need to build custom bridges ourselves (e.g., via Python scripting) or if there are existing integrations we can leverage.
We also noticed that Sensmetry does not currently offer a REST API for remote model access, which makes us wonder about the broader interoperability story with other enterprise tools.
Any guidance, references to case studies, or pointers to what others have done in similar situations would be highly valuable. We’re excited about the potential of SysML v2 and Sensmetry’s approach, but we want to make sure we’re not missing critical pieces before we commit to a specific toolchain.
Our main goal with Syside is exactly what you’re after: making the SysMLv2 model THE single source of truth. The development and roadmap of Syside are focused on giving you the most freedom in accessing the data that lives in the model, which enables integration with any other engineering tool — even ones that are internal to your organisation and that Sensmetry could never practically support officially.
Our vision has always been to bring modern DevOps and “as-code” practices to systems engineering. That’s why we’ve focused on the textual notation of SysMLv2 rather than model servers, and on providing powerful, performant APIs that don’t require any communication over an HTTP network. Together, this makes CI/CD pipelines and other automations possible.
The toolchain we strongly recommend is:
Syside Modeler for authoring SysMLv2 textual models.
GitHub / GitLab / Bitbucket (or any other version control system) to store and version-control the textual model files. These platforms also provide powerful collaboration and parallel-development features, letting you scale your systems engineering teams.
Python 3.12 or newer + Syside Automator for building model analysis and automation pipelines that integrate with your specific downstream tools. Syside Automator doesn’t stop at “read data from the model” — it gives you full access to modify and create models through Python. This lets your SysMLv2 models become the backbone of communication between multiple engineering tools: instead of a simulation or optimisation tool producing a PDF report that a human has to read, the tool can write its results straight back into the SysMLv2 model, which can then feed the most up-to-date data into the next tool. This is exactly how the ODE4HERA project uses Syside: https://www.youtube.com/watch?v=PPxtu2Hy194
Any other downstream engineering tool that supports structured data input/output or can be interfaced with through Python — that makes connecting SysMLv2 data to it much easier.
We recommend using SysMLv2 itself to model and manage your requirements, but if you need it, we also have ReqIF import and export. More integrations like this are on the way, driven by user feedback.
We believe it does. Textual editing is fully supported in Syside Modeler, with many convenience features — autocomplete, real-time validation, go-to-definition, and more — and we’re constantly adding to them. We also have model visualisation, both in diagrams and table views, so you’re not reading raw text all the time. The table views even let you edit the model directly, which makes managing things like requirements much easier.
Model automation is fully achievable through Syside Automator, both for reading data and writing it back. You can deploy Syside Automator in your CI/CD pipelines to ensure model quality and enable automated workflows.
For model versioning we recommend Git, especially if you work in a software-defined products area. This gives your software developers first-class access to your system models and reduces the “systems engineering vs. other engineering” silos that are common in solutions relying on model servers.
Syside also validates models according to the specification and beyond. For example, the specification doesn’t require any type checking, whereas Syside implements it. This significantly improves model quality and pushes you to model your systems in a way that’s easier to reason about and to simulate. Without these extra checks, it’s very likely you’d spend many hours building a system model, then try to simulate it only to discover you need significant refactoring before it can be executed.
At this particular moment, custom bridges are the way to go. That said, we’re always listening to users and identifying the integrations that are needed — this is exactly how the ReqIF integration came about: a user arrived with a specific use case, and we implemented it.
You’re right that there’s no “one-click REST API” available yet. However, it’s on our roadmap and we’re actively working towards it. Our current focus is on enabling Syside Automator to read from and write back to remote model servers. This will let you reuse the same Syside Automator scripts that currently work against local .sysml text files so that they also work against a REST API model server. It’s also worth noting that Syside Automator’s APIs are more expressive than the standard-compliant REST APIs, which makes scripts easier to develop and to verify. It is also magnitudes faster than any REST API that needs to communicate through a network, making it much more suited for automation.
As for the “read data from Syside through a REST API” use case, OpenMBEE has an open-source project called flexo_syside that integrates Syside into their Flexo model server, covering exactly that.
I hope this helps, and if you have any follow up questions feel free to ask!
P.S.: The YouTube video I shared above is from our 2025 edition of System-as-code-Fest. We have just wrapped up with the 2026H1 edition of the same conference and we will be uploading all the talks to YouTube in the near future. Keep an eye on our YouTube channel to hear more about how Syside is being used by other companies – the talk “Modernizing Model-Based Workflows: Automated feedback for all stages of system development/integration” by Cole Smith from Anduril should be of particular interest for you.
Thank you very much for your thorough and insightful response — we truly appreciate the time and thought you put into it.
Your explanation of the vision behind Syside resonates strongly with us. The emphasis on treating SysML v2 models as the single source of truth, combined with a DevOps/“as-code” philosophy, is exactly the direction we want to pursue. We’re particularly encouraged by the fact that Syside Automator not only reads model data but can also write back to the model, enabling a closed-loop data flow between engineering tools — that’s a powerful capability.
We also appreciate the clarity on the current state of integrations and REST API support. It’s good to know that custom Python bridges are the primary path today, and we’ll definitely keep an eye on the roadmap for future developments. The mention of the OpenMBEE flexo_syside integration is very helpful as a near-term option.
The video and the upcoming talks from the System-as-code-Fest also look interesting — we’ll be sure to watch them.
Overall, your response gives us confidence that we’re on the right track with our toolchain planning. We’ll likely start with Syside Modeler and Automator, and build custom integrations as needed while staying tuned for future updates from Sensmetry.
Thanks again for your time and for the helpful pointers. We may follow up with more specific questions as we get deeper into implementation, but for now, this has been extremely useful.