The MBSE Landscape

Languages, Methodologies, and Approaches

MBSE is a practice. To practice it, you need a language — a formal notation with defined semantics for expressing system models. You may also adopt a methodology — a prescribed process that tells you what to model, when, and in what order. Some approaches bundle language and methodology together; others separate them.

This lesson surveys the major options. The goal is not to pick a winner — there is no universal best. The goal is to understand the landscape well enough to make an informed choice based on your domain, organizational context, and what you need the model to do.

SysML v1

Origin: Object Management Group (OMG), 2007. A profile of UML (Unified Modeling Language) tailored for systems engineering.

What it provides: Nine diagram types organized across four pillars — structure (Block Definition Diagrams, Internal Block Diagrams), behavior (Activity Diagrams, Sequence Diagrams, State Machine Diagrams, Use Case Diagrams), requirements (Requirement Diagrams), and parametrics (Parametric Diagrams). Blocks replace UML classes as the fundamental structural element. Requirement and parametric diagrams are unique to SysML (not inherited from UML).

Strengths:

• The most widely adopted MBSE language, particularly in defense and aerospace
• Broad tool support — Cameo Systems Modeler, Rhapsody, Enterprise Architect, Papyrus, and others all implement SysML v1
• Large community of practitioners, extensive training material, and a deep body of published case studies
• Expressive enough to model complex systems across multiple domains
• Standardized by OMG, which provides a degree of tool interoperability through XMI exchange

Limitations:

• Complexity and steep learning curve — nine diagram types, extensive metamodel, many stereotypes and constraints inherited from UML
• Diagramming can overshadow modeling — teams sometimes focus on creating visually complete diagrams rather than building well-structured underlying models
• No standard API for programmatic access to model data. Access is tool-dependent, which creates vendor lock-in for any automation or integration built on top of the model
• XMI exchange between tools is theoretically standardized but practically unreliable — models rarely transfer cleanly between different SysML v1 tools

Where it is used: Dominant in U.S. defense and aerospace programs. Strong adoption in automotive (particularly for system architecture and safety analysis), medical devices, and large-scale industrial systems.

SysML v2

Origin: Object Management Group (OMG), in development. A complete rewrite of SysML — not an extension or profile update of v1.

What it provides: A new kernel modeling language (KerML) with SysML v2 defined on top of it. Textual notation (in addition to graphical) — models can be expressed as text, enabling version control workflows similar to source code. A standard API (SysML v2 API and Services) for programmatic access to model data, independent of tool vendor. More precise semantics — fewer ambiguities than v1 in how model elements are interpreted.

Strengths:

• Standard API enables tool-agnostic access to model data. Automation, integration, and migration are no longer locked to one vendor's proprietary interface
• Textual notation supports diff, merge, and version control workflows that engineering teams already use for code — lowering the barrier to collaborative modeling
• Cleaner, more precise semantics reduce the interpretation ambiguities that plagued v1 models exchanged between teams
• Better support for analysis integration — constraint expressions are more powerful, and the API enables direct data exchange with simulation and analysis tools

Limitations:

• Still maturing — the specification is not yet finalized, and production-grade tool support is limited
• Migration from v1 is nontrivial. There is no automatic translation because v2 is architecturally different, not just syntactically different
• The community is smaller than v1's, and training material is still being developed
• Organizations that have invested heavily in v1 face a real transition cost with uncertain timing

Where it is used: Pilot projects in defense and aerospace organizations evaluating the next generation of MBSE infrastructure. Research institutions and standards bodies contributing to specification development. Early adopters building v2-native toolchains.

Arcadia / CAPELLA

Origin: Thales (French defense and transportation company), contributed to the Eclipse Foundation as open source. CAPELLA is the tool; Arcadia is the methodology.

What it provides: A method-driven approach with four architecture levels that guide what to model and in what order: Operational Analysis (what users need to accomplish), System Analysis (what the system must do), Logical Architecture (how the system is organized internally), and Physical Architecture (how the system is implemented). The methodology prescribes a progression from operational context through implementation — you know what to model at each stage.

Strengths:

• Methodological guidance is built into the tool — practitioners are guided through what to model when, reducing the "blank canvas" problem that SysML teams often face
• Open source (Eclipse Public License), which eliminates license costs and reduces vendor lock-in
• Strong adoption in European defense and transportation, with a growing global community
• The four-level architecture progression is intuitive and maps well to how systems are actually conceived and designed

Limitations:

• Less flexible than SysML — the methodology constrains how you model, which is an advantage for consistency but a disadvantage when your system does not fit the prescribed progression
• Smaller community outside Europe, with less available training material in English
• Different vocabulary and concepts from SysML, which creates a translation barrier when working with organizations that use SysML
• The tool ecosystem is narrower — fewer integrations out of the box compared to mature SysML tools

Where it is used: Thales programs across defense, transportation, and space. European defense programs. Growing adoption in automotive and industrial systems, particularly where open-source tooling is valued.

AADL

Origin: Society of Automotive Engineers (SAE), AS5506 standard. Architecture Analysis and Description Language.

What it provides: A domain-specific language for modeling the architecture of embedded, real-time, safety-critical systems. Components are typed by their role (processor, memory, bus, device, process, thread, data). Connections model data flow and control flow between components. Binding declarations allocate software to hardware. Annexes extend the core language for specific analysis types (behavior, error model, ARINC653 partitioning).

Strengths:

• Precise enough for automated analysis — schedulability analysis, latency analysis, reliability analysis, and resource consumption analysis can be performed directly on the AADL model
• The language semantics encode real-time and embedded domain knowledge, so the model carries analytical meaning beyond just architectural description
• Strong in avionics (ARINC653 support) and other safety-critical embedded domains

Limitations:

• Narrow domain scope — designed for embedded real-time systems. Not appropriate for general-purpose systems engineering where the system includes non-embedded components (civil infrastructure, organizational processes, service systems)
• Smaller user community than SysML or CAPELLA
• Limited tool ecosystem compared to SysML

Where it is used: Avionics, automotive embedded systems, space systems, and other safety-critical real-time domains where automated architectural analysis is essential.

OPM (Object-Process Methodology)

Origin: Dov Dori, Technion — Israel Institute of Technology. Standardized as ISO 19450.

What it provides: A single diagram type — the Object-Process Diagram (OPD) — that represents both structure (objects) and behavior (processes) in a unified view. Objects are things that exist; processes are things that happen. Objects can be in states. Processes transform objects (create, consume, change state). The textual equivalent (OPL — Object-Process Language) generates automatically from the diagram and vice versa.

Strengths:

• Simpler than SysML — one diagram type instead of nine. The learning curve is significantly shorter
• The unified representation of structure and behavior in a single view reduces fragmentation and makes it easier for non-specialists to understand the model
• Good for communication across disciplines and with stakeholders who are not modeling experts
• ISO standardized (19450)

Limitations:

• Less tool support than SysML or CAPELLA — fewer commercial and open-source tools implement OPM
• Less expressive for complex systems where the richness of multiple diagram types (detailed state machines, parametric constraints, interaction sequences) is needed
• Smaller practitioner community, which means less shared experience, fewer published patterns, and a narrower consulting ecosystem

Where it is used: Academic research, early-stage concept exploration, and organizations that prioritize communication clarity over modeling depth. Some adoption in Israeli defense and industry.

How to Choose

There is no universal best language or methodology for MBSE. The choice depends on factors specific to your context:

Domain fit. If you are modeling embedded real-time systems and need automated schedulability analysis, AADL is purpose-built for that. If you need general-purpose systems modeling with maximum tool choice, SysML v1 has the broadest ecosystem. If you want built-in methodological guidance, Arcadia/CAPELLA prescribes what to model when.

Organizational context. What does your supply chain use? If your customer mandates SysML deliverables, that constrains your choice. If your organization values open source, CAPELLA removes license costs. If your team is small and non-specialist, OPM's simplicity may outweigh SysML's expressiveness.

Tool ecosystem. What tools do you already have? What tools do your partners use? Integration cost is real — a language with a rich tool ecosystem in your existing infrastructure may be more practical than a theoretically superior language with no integration path.

What the model must do. If the model is primarily for communication and design documentation, simplicity matters most. If the model must support automated analysis, the language must have sufficient precision and tool support for that analysis. If the model must integrate with a broader digital engineering pipeline via API, SysML v2's standard API is a significant differentiator.

The most important decision is not which language to pick — it is to be deliberate about the choice rather than defaulting to whatever the first tool vendor you talk to happens to sell.

Assessment