Date
18 June 2026
Category
Blog, Collaborative Engineering, Concurrent Design, Engineering, MBSE
No comments
In this latest article about SysML v2, we take a step back before diving into the model itself. Now comes the moment many practitioners rush past: preparation.
Before opening a tool and before writing a single package declaration, there are questions every modeller team should answer. Get them right before you model and the language will work for you. This is not a perfect guide, nor a substitute for a full model-based system engineering (MBSE) methodology, but it is a practical checklist that will support your systems modelling practice.
By Anh Toan Bui Long, CD & MBSE Expert
SysML v2 represents a significant leap forward in systems modelling. Before writing a single ‘package’ declaration or drawing your first ‘part def’, you need to have the right foundations in place.
What is the System of Interest?
The first question to ask yourself might be obvious: “What exactly are we modelling?”
The System of Interest (SoI) defines the boundary of your model. Without it, you risk modelling everything and therefore expending effort uselessly. It’s important to establish early on:
- The physical and logical boundaries of the system: where it starts and where it ends
- What is inside the model scope (your SoI) versus the rest: for example, what belongs to the environment, operators or external systems.
This will set up your context and drive your modelling. SysML v2’s package and namespace constructs make scoping explicit. Use them intentionally to mirror your SoI decomposition, not just as administrative folders.
A poorly defined SoI leads modellers to include neighbouring systems, legacy interfaces or aspirational features that don’t belong in the current effort.
What is the purpose of the model?
This comes with the System of Interest definition. What do you want to achieve with your model? Before any structural or behavioural content is created, the team must explicitly answer: “Why does this model exist and what decisions will it support?”
Modelling may include subjects such as:
- Requirements traceability: capturing and deriving stakeholder needs down to design elements
- Architecture exploration: comparing alternatives and trade-offs
- Interface definition: formalising data, energy and material flows between components
- Verification planning: linking test cases to requirements via ‘verify’ relationships
- Communication to stakeholders: producing views and matrices for reviews and audits.
The declared purpose(s) drives everything downstream: which SysML v2 diagrams matter, which levels of detail are necessary and which packages need to exist. It also governs what can be intentionally left abstract – a model built for architecture exploration may not need the same interface granularity as one built for verification planning.
At the beginning, not all objectives can be seen at a glance. Often, as a project goes on, a model originally built for architecture or trade-off analysis may be expected to support verification and validation activities, safety analyses or integration with simulation tools.
When multiple users contribute to a shared model, they often bring their own domain-specific languages, analysis tools and naming conventions. These can produce package name conflicts, incompatible type hierarchies and semantic misalignments that are expensive to resolve after the fact. The declared purpose, combined with a model governance plan, is the mechanism that controls this: it determines which domain libraries are authoritative, which naming conventions apply and who resolves conflicts when they arise.
Who will model the system?
A SysML v2 model is a team artifact and its quality depends as much on the people building it as on the language itself. This question therefore has two dimensions: “Who has the authority to define what gets modelled?” and “Who has the skills to model it correctly?”
Typical users include:
- Model owner: administrator of the model – accountable for overall consistency, scope and release decisions
- Domain engineers: contribute content in their area (mechanical, electrical, software, safety) – they do not need to be SysML experts, but they must validate what is modelled about their domain
- Model readers: stakeholders who read but do not write the model – their needs shape viewpoints.
Similarly, as in programming languages, is there a modelling style guide so that five engineers do not produce five incompatible modelling styles in the same package?
Again, as in programming languages, because SysML v2 is based on text files, it eases the versioning: is there a versioning system in place to trace modifications and merge files?
In the scope of large systems, the modelling task cannot be handled by a single person. Domain engineers must be involved: otherwise the model becomes a parallel universe that no one maintains nor understands.
Which software should be used?
Tooling is not the first question, but it is a real one. Thanks to SysML v2 textual notation and API, the SysML v2 standard is tool agnostic.
Differences rely, then, in the additional features tools give, such as:
- Integration with your existing domain-specific tool (real-time analysis, structural analysis, etc.)
- Collaborative modelling support, such as concurrent access, version control, conflict resolution
- Data restriction in the model: in the scope of extended enterprise, you might want to restrict information in the model.
The choice of modelling tool is often made because the company is already using it. However, the switch to SysML v2 can also provide the impetus to learn a new language, especially as SysML v2 is tool independent.
What is the methodology?
We’ve set up the full context to model. Now, how will you model? As with any MBSE process, if you do not have a plan to use the language, how will it be consistent?
The language tells you how to express a model; it does not tell you what to model, in what order, or from which engineering perspective to start. That is the role of an MBSE methodology and choosing one is a prerequisite before any modelling.
Here are two examples:
- The Arcadia methodology offers a rigorous operational-to-physical decomposition process; it is an architecture-centric method that, when applied properly, allows for effective modelling of multi-domain systems. However, this methodology is tightly correlated to a language and a tool (Capella). A public library for SysML v2 is nonetheless available.
- The European Space Agency proposes its methodology (essr.esa.int/project/esa-sysml-solution) to model with European Cooperation for Space Standardization (ECSS) standards concepts for European space systems. This was developed with SysML v1 but a pilot implementation onto SysML v2 is available.
Selecting a methodology before opening any tool is therefore not optional: it determines the structure of your packages, the order in which model elements are created and, ultimately, whether the model reflects a coherent engineering argument or simply a collection of diagrams.
Conclusion
These questions are not a checklist to rush through: they are the engineering discipline that determines whether your SysML v2 model becomes a trusted design authority or an abandoned artifact. Define your System of Interest precisely and then define the target(s) to achieve, how to achieve it/them and the roles for each user. When the scope is well defined, the model stops being a deliverable and becomes the engineering conversation itself, moving from document-centric engineering to model-centric engineering.
Do you want to learn more?
If your team or organisation is interested in MBSE, if you would like to learn more about SysML v2 to implement it in your projects, or if you simply work on the space sector and want to stay up to date with the latest digital developments that will set the course for future missions, follow Starion on LinkedIn and sign up to our MBSE and SysML v2 newsletter. Now is the perfect time to start exploring SysML v2, test out new tools and define transition plans to adopt the new version in your modelling activities.
You can also reach out to our team for guidance and support.
