How to Architect System Models for Cross-Program Reuse

Many organizations invest in MBSE but struggle to reuse system models beyond a single project. Architectures, behaviors, and patterns are recreated instead of being leveraged, leading to rework and inconsistencies. This article explains why model reuse across programs is challenging and how to overcome those challenges successfully.

We will first explore the different types of system models that can be reused, from simple types and interfaces to full mission-level architectures, to understand why reuse becomes increasingly difficult as model complexity and context grow. Then, we will examine the root causes that make reuse so challenging in SysML, and walk through practical strategies for both homogeneous and cross-organizational environments, showing how SysML v2 can address these issues.

👉 What you'll learn in this article:

• What can realistically be reused →
• Why model reuse often fails →
• Why complexity makes reuse harder →
• How SysML creates reuse challenges →
• Best practices for reuse within a homogeneous environment →
• How to reuse models across tools and organizations →
  
• How SysML v2 improves model reuse →

The Reality of Model Reuse Today

Model-Based Systems Engineering (MBSE) was supposed to change the way we manage complexity. One of its central promises was that systems models would become reusable assets, much like software libraries, allowing engineering teams to assemble new programs from proven, pre-validated components.

The reality on the ground is often very different. In practice, the inherent challenges of model reuse often cause it to devolve into “copy-paste engineering”. Entire projects are cloned and modified rather than properly reused.

Copying and modifying are the lowest and least desirable level of “reuse”. The cloned model indeed loses its association with the original (a pattern known as “clone and own”), where semantics may no longer be preserved, and further quality updates and useful evolutions to the origin will not reach the clone.

This undermines the very idea of a single source of truth. It results in redundant modeling efforts and requires rework on the cloned model. To fix this, we need to examine why model reuse is so challenging, in general, but also specifically within a SysML context.

Why Are Some System Models Easier to Reuse Than Others?

Not all strategies for model reuse are equal. The challenges vary significantly with the granularity (in other words, the size and complexity) of what we're trying to reuse, from atomic types at the smallest scale to entire mission architectures at the largest.

Here is a four-level framework that categorizes reusable model assets:

Level 1: Types & Interfaces (High Volume, Low Complexity)

At this level, reuse is largely a solved problem. Reusing atomic elements such as value types and standard interfaces is the most accessible entry point. Common data types for domains like avionics, along with standard interfaces for sensors and actuators, help ensure that independently designed components integrate successfully. This level is best managed through strictly governed, enterprise-level model libraries, which is a standard practice for organizations with basic MBSE maturity.

Level 2: Low-Level Components & COTS (High Reusability, Medium Complexity)

At this level, individual components, such as radar sensors, cameras, and power supplies, are reused across programs. Industry frameworks like AUTOSAR and Sensor Open Systems Architecture (SOSA™) provide specifications for these as model library elements. These are typically reused as "black boxes" via their ports: consumers interact only through the external interfaces, without seeing the internal design. However, their behavioral properties remain essential for system-wide simulation. Success depends on maintaining clear interfaces with minimal external dependencies.

Reuse at this level is achievable but demands more rigor than Level 1.

Level 3: Subsystem Architectures & Patterns (Medium Reusability, High Complexity)

This is where reuse starts to become more challenging. At this level, organizations attempt to reuse entire board-level subsystems, LRUs, or ECUs, as well as complete avionics or automotive reference architectures.

And unlike the previous levels, this is what we call "white-box reuse". It means that the internal design is visible and must be understood to support redefinition and extension. A common practice is to specify abstract reference architectures that are meant to be further specialized and customized. This is where a product line approach may be useful, by specifying 150% models^[1] with variation points. Managing these models typically requires dedicated Product Line Engineering (PLE) tools and a high level of organizational maturity. While complex, this approach remains the primary strategy for system upgrades where changes are limited or incremental.

When reuse fails at this level, the cost is high. Teams often spend months re-modeling subsystems that already existed in a previous program.

^[1] A "150% model" is a model that contains more than any single product variant requires. It includes all possible features, options, and configurations for an entire product family. Specific variants are then derived by selecting the applicable subset. The term "150%" reflects the fact that the model is deliberately oversized: no single real product uses everything it contains.

Level 4: Use Cases & Operational Specifications (High Strategic Value)

At the highest level, reuse is more aspirational than a proper real-world practice.

This level focuses on mission-level functional specifications, such as the USAF F2T2EA (kill chain) operational models. These specify "mission sequences" via activity or sequence diagrams – often using the UAF framework – and serve as templates for functional interactions rather than direct designs.

While SysML v1 often limited this to "cloning and modification," SysML v2 provides the behavioral redefinition and parameterization required to reuse these high-level mission patterns effectively. "Cloning and owning" may result in a costly practice, where entire mission threads may be duplicated across programs, with no traceability back to the original.

This results in expensive maintenance of such multi-program specifications.

📖 Read also: SysML v1 vs SysML v2: What Changes for Engineering Teams?

The higher the level, the harder reuse becomes. Let’s now look at why SysML models struggle at every level of this spectrum.

Why Does SysML Model Reuse Fail in Practice?

SysML v1 has fundamental limitations that make model reuse difficult across the board: from how models are structurally organized, to how variability is managed, and to how little intellectual property is protected.

Here is a condensed summary of the primary inhibitors:

Monolithic Architectures

Models are frequently built as tightly coupled monoliths (large, indivisible models where everything depends on everything else) rather than modular libraries. Because SysML tools typically don't enforce strict boundaries, simple "drag-and-drop" actions often create entangled webs of dependencies between graphs, making it impossible to extract one component without dragging dozens of others along.

Interface-Implementation Entanglement

In SysML, the same Block both specifies what a component looks like from the outside (its ports and interfaces) and how it works internally (its parts and behaviors). Because SysML does not enforce the separation between these two concerns, teams often need to import the entire subsystem model when they only want to reuse its interface, bringing along many unnecessary dependencies.

Intellectual Property (IP) Exposure

When sharing software, teams can distribute compiled binaries that hide the source code. SysML models, by contrast, are inherently “white boxes”. So sharing a model for reuse means exposing the complete proprietary design. Modeling tools lack support for "private content" or obfuscation, creating a significant barrier to reuse across programs and organizations.

Behavioral Inheritance Gap

While SysML supports structural inheritance (of blocks and properties), it does not allow effective refinement or extension of behaviors such as state machines or activities. This creates a "copy-paste" scenario where behaviors are duplicated and manually adjusted, resulting in unnecessary rework and maintenance debt.

Product Line Complexity

Managing product variants in SysML is highly challenging. Teams must either rely on inheritance, which does not scale for a large number of variants, or build “150% models” containing a superset of the various permutations across the variants using variation points. SysML does not have provisions to manage such variation points directly. It typically requires third-party Product Line Engineering (PLE) tools, adding significant licensing costs and toolchain complexity that many organizations prefer to avoid.

Model Configuration Management Scalability

Reusing model fragments through branching and merging (sometimes called "managed cloning") does not scale well. While CM tools like Teamwork Cloud or Rhapsody Model Manager facilitate update propagation, the sheer complexity of tracking versions and merging variants across branches becomes unmanageable over time.

Cross-tool interchange limitations

XMI (XML Metadata Interchange), the standard format for exchanging UML/SysML, often fails to support reliable model exchange across different tools. Moving a model from one vendor to another requires heavy scripting and manual fine-tuning. Digrams are almost always lost in the process, killing cross-tool reuse.

📖 Read also:  Converting models to Cameo Systems Modeler: Publisher vs. XMI import

Taken together, these limitations explain why organizations struggle to reuse models across programs. As dependencies, variants, and toolchains grow, reuse gradually collapses into duplication and re-modeling.

Fixing Model Reuse Within Your Organization - Best Practices for Homogeneous Environments

Reusing models within a single tool and organization offers the highest level of control and the best chance of success.  Here is a condensed guide for maximizing efficiency in that environment with five practices that help you make a difference.

1. Establish a Layered Package Hierarchy

Organize models into a layered package architecture to eliminate circular dependencies.  This is critical to enable the reuse of modules without having to pull large model fragments that are functionally unnecessary.

Cleanly separate foundational libraries from program-specific implementations. note that obtaining a layered structure is typically not enforced by tools and requires discipline. This can be supported by model validation checks designed to detect such entanglements.

2. Use model libraries for reuse

Highly reusable elements, especially the Level 1 and Level 2 assets described earlier, should be organized into shared organizational model libraries imported by every domain model to promote their reuse within the organization and program.

These libraries consist of standard types, interfaces, and granular domain implementation blocks. Shared model libraries are essential for promoting the reuse of Level 1 and Level 2 model elements across programs and teams.

3. Enforce Interface/Implementation Separation

Approach SysML like software code by separating "header files" from "source files”. For instance, define a Specification Block (containing only ports and external properties) as the component's public interface and a separate Realization Block for the internal design.

The specification block can be easily reused without implementation dependencies. By packaging these independently, consumers only need to load the lightweight specification library to integrate against the component.

4. Master Feature Redefinition

Leverage structural feature redefinition to specialize reusable models without duplicating them.

SysML offers a mechanism called structural feature redefinition that is particularly useful here. It allows you to inherit an abstract Block (e.g., a generic "Power Source") and refine its properties for a specific context (e.g., a "12V Battery"). This mechanism allows teams to safely reuse abstract designs and progressively specialize them as the design matures.

Reusing individual components is relatively manageable. However, reusing and governing entire product variants is significantly more complex.

5. Adopt a Product Line Approach

For programs with numerous variants, I recommend using Product Line Engineering (PLE) through "150% models" containing all possible features. 

In SysML, this typically requires integration with tools such as pure::variants. While SysML v2 supports simple product lines natively, complex families still benefit from dedicated variability management tools to handle configuration logic. Once internal discipline is established, the next challenge is extending reuse beyond organizational boundaries.

Extending Reuse Across the Supply Chain - Best Practices for Hybrid and Heterogeneous Environments

Achieving model reuse across different tools and organizational boundaries is much more challenging than within an organization that shares a single modeling tool. It requires interoperability across tools, enabling both effective model exchange and traceability across the engineering lifecycle.

Yet this scenario is inevitable in a modern supply chain, and it requires a targeted strategy based on the direction of data flow and the sensitivity of the intellectual property (IP).

Prerequisite: Master the Homogeneous Basics

All the practices covered in the homogeneous scenario must be in place before organizations can successfully pursue reuse across heterogeneous, multi-organization environments.

Models must be modular, well-structured, and organized in layers, so that reusable model fragments can be exchanged independently. This is critical in terms of simplifying data exchange and preserving organizational IP. You cannot safely share models externally if they are entangled internally.

Integrator to Supplier (Low IP Risk)

When an OEM or integrator defines a subsystem, they only need to share the external specification (the interface block, ports, and boundary constraints) with the supplier. Because the internal design has not yet been developed, IP exposure is generally not the primary concern. Instead, the main challenge is ensuring that the supplier can accurately interpret and consume the specification in their own modeling environment.

Supplier to Integrator (High IP Risk)

The IP challenge becomes most significant when a supplier shares a completed model for system-level validation. Standard SysML models are "white boxes", meaning their internal design is fully visible. Current modeling tools provide limited support for hiding or protecting proprietary content So, handing them may expose the supplier's proprietary trade secrets.

To mitigate this risk, teams use the Functional Mock-up Interface (FMI) standard. Suppliers export their model behavior as a Functional Mock-up Unit (FMU). This provides the integrator with a compiled, black-box asset that can be simulated within the larger system architecture without exposing the underlying design logic.

Achieving cross-tool interoperability

Since SysML XMI-based interchange is limited, tossing SysML files "over the wall" simply does not work seamlessly.

Here are a few guidelines to make model exchange actually work:

To achieve actual reuse across tool boundaries, a higher precision tool than raw XMI is needed. Such solutions typically rely on tool-specific connectors that preserve semantics and refine model exchanges across different modeling environments. The key objective here is to preserve the semantics of the original model fragment in the reusing tool. Such a specialized tool is aware of the semantic intricacies of how each modeling tool interprets and represents SysML constructs. In addition, this tool should also be able to interchange graphical diagrams, based on the respective tool- specific representation.

A common industry solution for this very challenge is SodiusWillert Publisher. Publisher provides dedicated connectors for the major SysML modeling tools used across the industry, including Cameo, IBM Rhapsody, SparxEA, and many others. It enables seamless interoperability of SysML models across those tools.

Learn more about our complete Publisher suite of plug-ins here:

• Cameo Model Importer for IBM Rhapsody

• IBM Rhapsody to Cameo Systems Modeler

• IBM Rational Software Architect to Cameo Systems Modeler

• UNICOM System Architect to Cameo Systems Modeler

• SPARX Enterprise Architect to Cameo Systems Modeler

Another fundamental aspect of interoperability is the ability to maintain traceability across tools through standards such as Open Services for Lifecycle Collaboration (OSLC). OSLC enables critical traceability between newly created designs and their original reference architecture or base design, even when those designs originate from different modeling tools. In connected environments, this allows reused modules to maintain links back to their source of truth across the engineering lifecycle