Most teams that build a family of related systems start with a copy. Someone takes the model for last year's platform, saves it under a new name, and starts deleting the parts the new variant won't have. Six months later there are eleven of these forked models, each drifting away from the others, and a change to a shared sensor interface has to be made eleven times. That copy-and-modify habit is exactly what model-based product line engineering, or MBPLE, is meant to kill. With SysML v2 arriving with native variability support, the approach is getting a second look from teams who tried it on v1 and gave up.
Why product lines break MBSE
A single-system model has one answer to every question. What sensors are on the bus? Here they are. MBSE tools are built around that assumption, and they work well for it.
A product line has many answers. The base platform ships in a commercial trim and a military trim. The military trim has three regional sub-variants. Two of those share a radio, one uses a different one for export reasons. Now "what sensors are on the bus" has no single answer, and a model that represents only one configuration can't describe the family. Clone-and-own is the path of least resistance, and it's a trap, because the shared 80% of the design now lives in a dozen places that have to be kept in sync by hand.
MBPLE separates two things that clone-and-own tangles together: the assets that make up the systems, and the choices that decide which assets go into a given product. You model the superset once and configure it many times.
The 150% model and the feature model
The core MBPLE construct is the 150% model. It's a superset that holds every asset any member of the family could need, including parts that are mutually exclusive. The commercial radio and the military radio both live in it, even though no single product ships with both. Because it contains more than any one product does, it's more than 100%, hence the name.
You never ship the 150% model. You derive from it. The derivation is driven by a feature model, which is a separate, deliberately simple tree of the choices that define a product: trim level, region, radio type, optional payloads. A configuration is a set of selections against that feature model. Point the configuration at the 150% model, resolve the variation points, and you get a 100% model for one specific product.
The discipline that makes this work is keeping the feature model and the system model apart. Features describe what a customer or program can choose. The system model describes how the design realizes those choices. Tangle them and you're back to editing the architecture every time marketing renames a trim level.
What SysML v2 actually changes
Teams tried MBPLE on SysML v1 and many walked away. The reason was mechanical. v1 had no native concept of a variant, so variability was bolted on through profiles, stereotypes, and third-party tools that stored the feature logic outside the model. The variation lived in a plugin's database, not in the language, and interchange between tools was painful.
SysML v2 puts variation into the language itself. The metamodel has first-class constructs for variation points and variant selection, so a part, a requirement, or a behavior can be declared as varying, with its alternatives expressed in the same model. The 2025 INCOSE work on next-generation MBPLE by Tim Weilkiens and colleagues shows feature modeling built directly on these constructs, using the SysML v2 API to connect the feature layer to the system model rather than gluing them together through a proprietary bridge. That API matters as much as the notation. It means a feature model, a configuration, and the resolved product model can move between tools as data instead of as screenshots.
This is why teams that bounced off v1 are worth a second conversation. The thing that made it brittle, variability living outside the language, is the thing v2 fixes.
Tooling is uneven right now
Native SysML v2 variant support is real in the specification, but tool coverage is still catching up, and honest teams are running mixed setups. Dedicated variability managers like pure::variants remain common for the feature-model side and integrate with several MBSE tools. Established modelers such as Dassault Systemes Cameo Systems Modeler carry mature v1 variant workflows that many programs still depend on. Newer SysML v2-native environments, Dalus among them, build on the v2 metamodel and its API from the start. The practical question for a program isn't which tool is best in the abstract, it's which combination covers your feature modeling, your derivation, and your existing model investment without forcing a rewrite.
Airbus offers a useful reference point for scale. Its MBSE architecture framework, R-MOFLT, was extended with a feature-based product line layer to handle aircraft variability, and the team's own writing describes variability as having four distinct dimensions rather than a single on-off switch. That's a reminder that a real product line has more moving parts than a demo.
What MBPLE won't solve
MBPLE is an organizing discipline, not a magic wand, and it has costs worth naming before you commit.
It front-loads work. Building a clean 150% model and a well-formed feature model is more expensive than forking a single system, and the payoff only arrives once you have enough variants and enough change traffic to amortize it. For a two-variant product with a stable design, clone-and-own may honestly be cheaper.
It doesn't fix a messy architecture. If your variation points are scattered and your interfaces aren't clean, encoding that mess as a 150% model just makes the mess configurable. MBPLE assumes you've already found the natural seams in the design.
It adds a governance burden. Someone has to own the feature model, decide what's a legitimate variation point versus a one-off hack, and prevent the superset from accreting dead options. Without that ownership the 150% model grows toward 200% and nobody trusts the derivations.
And it doesn't erase configuration testing. Deriving a product model is not the same as verifying it. Each configuration you ship is still a system that has to be checked, and the number of valid combinations can grow faster than your test budget.
Bottom line
MBPLE is the answer to a specific pain: a growing family of related systems where clone-and-own has quietly turned every shared change into a dozen edits. Model the superset once, drive derivation from a clean feature model, and keep the two layers separate. SysML v2 is what makes the approach worth revisiting, because it moves variability out of plugins and into the language and its API, which is where interoperability actually lives. Just go in clear-eyed. The method rewards teams with enough variants and change traffic to pay back the up-front modeling, and it punishes teams who reach for it to avoid cleaning up an architecture that needed the work anyway.