# SysML v2 and ARCADIA Capella metamodel comparison Research report for the development team 13 September 2026 ## Decision summary **Build on the compositional semantics of SysML v2 while preserving ARCADIA as an explicit architectural language and workflow.** SysML v2 is stronger when engineers need reusable definitions, constrained alternatives, mathematical relationships, behavioral detail, and temporal identity. Capella is stronger when engineers need to trace an operational need through functions, component responsibilities, interfaces, and physical implementation using a shared architectural vocabulary. This report documents **14 concrete comparison cases: eight advantages for SysML v2 and six for ARCADIA/Capella**. Every case gives a scenario, the relevant mechanism, the other side's available approach, and an observable development acceptance criterion. S1 retains the earlier motor example as a baseline; S2 through S8 add different capabilities. The advantages are not symmetrical. The Capella cases demonstrate architectural specificity and established modeling operations. They do not prove that SysML v2 cannot encode the same information. Conversely, a SysML language capability does not prove that a particular SysML editor implements its evaluation or supplies an equivalent engineering workflow. **Development priority:** preserve the identity and meaning of functions, their contextual participation, allocation, deployment, and exchange routing. Then combine those concepts with definitions and usages, constraints, variability, and analysis. A generic graph with familiar Capella labels would leave too much meaning in user conventions. ## Research basis The baseline is the formal SysML 2.0 language specification, whose inspected edition is dated March 2026, KerML 1.0, the published ARCADIA references, and Capella source documentation and metamodel files. Official SysML example models provide additional evidence for individual mechanisms. Repository citations are pinned to the inspected revisions. [1](https://www.omg.org/spec/SysML/2.0/Language/PDF) [2](https://www.omg.org/spec/KerML/1.0/PDF) [3](https://mbse-capella.org/resources/arcadia-reference/Arcadia%20Language%20-%20MetaModel.pdf) [4](https://mbse-capella.org/resources/arcadia-reference/Arcadia%20Reference%20-%20Data%20Model.pdf) [32](https://github.com/Systems-Modeling/SysML-v2-Release) The comparison is a specification and source review. The scenarios and acceptance criteria are original engineering fixtures, not executed tool benchmarks. Feature availability in a particular released editor, solver, or add-on requires separate validation. “Capella” means the desktop architecture model and documented core workflow; extensions are identified where relevant. The historical Capella comparison page addresses SysML v1. It is used only to explain Capella design choices, with SysML v2 conclusions checked against v2 sources. [5](https://mbse-capella.org/arcadia_capella_sysml_tool.html) ## Comparison at a glance | Case | Concrete engineering task | Advantage | Main source of advantage | | --- | --- | --- | --- | | S1 | Reuse drives with local cooling limits | SysML v2 | Definitions and contextual specialization | | S2 | Select a valid robot product configuration | SysML v2 | Native variations and constraints | | S3 | Verify a requirement for a specific subject | SysML v2 | Requirements and verification semantics | | S4 | Specify retries and data changes precisely | SysML v2 | Composable action semantics | | S5 | Track one asset through replacement events | SysML v2 | Individuals and temporal portions | | S6 | Express overlapping equipment subsets | SysML v2 | Subsetting and multiplicity | | S7 | Represent a reproducible design trade study | SysML v2 | Analysis and calculation libraries | | S8 | Add a typed engineering vocabulary | SysML v2 | Libraries and semantic metadata | | C1 | Evolve needs into a traced architecture | Capella | Architectural levels and transitions | | C2 | Explain how an exchange reaches its receiver | Capella | Allocation and physical routing model | | C3 | Reuse one function in several capability paths | Capella | Explicit chain involvement objects | | C4 | Reorganize functions and retain overview views | Capella | Grouping semantics and computed links | | C5 | Keep scenarios consistent with interfaces | Capella | Shared references and targeted checks | | C6 | Reuse an architecture fragment across trees | Capella | Multi-root replication and merge workflow | **How to interpret the comparison.** A language advantage means that the relationship has a defined representation and interpretation in the language or its standard libraries. A domain advantage means that the architectural distinction is explicit without designing an additional method library. A tool advantage means that documented operations help construct or maintain the model. These are different development requirements. Confidence is high for the documented positive mechanisms. Relative productivity and the completeness of mappings are engineering assessments, not measured results. Claims of absolute impossibility are deliberately excluded: both environments are extensible, and no formal expressive-equivalence proof was performed. ## Cases favoring SysML v2 ### S1 Reusable assemblies with local constraints **Scenario.** Two robot drives share one motor design. Both have resistance 0.2 ohm. The left operates at 10 A with a 30 W copper-loss limit; the right operates at 15 A with a 50 W limit. Their combined loss must not exceed 60 W. This is a deliberately simplified steady operating-point fixture, not a complete motor thermal model. **SysML v2 advantage.** A drive definition can carry the loss relationship and a constraint. Each usage supplies its own current and cooling limit. Contextual redefinition and inherited structure allow the shared design to evolve while preserving local choices. The official redefinition and constraint examples establish these mechanisms. [8](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/training/05.%20Redefinition/Redefinition%20Example.sysml) [10](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/examples/Simple%20Tests/ConstraintTest.sysml) **Capella comparison.** Component/part typing and REC/RPL support reuse. Capella also has properties, constraints, and expression constructs. The additional work is establishing how per-context calculations, inheritance, and validation compose; dedicated viewpoints or scripts commonly provide the analysis. This is not a claim that Capella cannot store the equation. [5](https://mbse-capella.org/arcadia_capella_sysml_tool.html) [6](https://mbse-capella.org/features.html) **Acceptance criterion.** Compute 20 W and 45 W; accept both local limits and reject the 65 W total. After changing only the right limit, the left remains unchanged. After updating a shared definition, each usage receives the common change once. Distinguish an overridable default from an invariant binding; changing a fixed inherited value must not silently invalidate the model. ### S2 Product alternatives with dependency rules **Scenario.** A robot family offers either a 48 V or a 72 V drive system, optional lidar, and two autonomy algorithms. The 72 V drive requires a matching inverter. The advanced autonomy algorithm requires lidar. A configured product must select exactly one drive system and one algorithm. **SysML v2 advantage.** Variations can apply to structure and behavior, with explicit variants and constraints between selections. The official vehicle example combines engine and transmission choices, optional equipment, behavior alternatives, and compatibility conditions in one family model. [9](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/examples/Variability%20Examples/VehicleVariabilityModel.sysml) **Capella comparison.** Replication supports reusable architecture configurations. A dedicated product-line solution, such as the listed pure::variants connector, adds feature selection and configuration management. A manually drawn collection of optional components does not by itself define selection semantics. The advantage here is native language integration, not superiority over every mature product-line add-on. [7](https://mbse-capella.org/addons.html) **Acceptance criterion.** Reject a 72 V motor with a 48 V inverter and advanced autonomy without lidar. A selected configuration must exclude unselected components, associated behavior, and invalid dangling relationships from the evaluated product. Distinguish a product variant from a runtime operating mode. Selection propagation across relationships must be specified and tested rather than assumed. ### S3 Requirements and verification bound to a subject **Scenario.** The same stopping-distance requirement applies to a small robot and a heavy robot. It includes a speed range and floor-condition assumption. The team must distinguish a claim of satisfaction from a test that actually produced evidence for a specific configuration. **SysML v2 advantage.** Requirements support explicit subjects and assumed and required constraints. Verification cases connect objectives to requirements and a subject, with defined verdict values. The standard verification library provides pass, fail, inconclusive, and error, and a simple Boolean-to-verdict calculation. [11](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/examples/Simple%20Tests/RequirementTest.sysml) [12](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml.library/Systems%20Library/VerificationCases.sysml) **Capella comparison.** Requirements traceability, scenarios, and verification activities can be represented; ARCADIA's wider reference data model explicitly includes tests and results. Requirements integrations and custom viewpoints can add richer structures. The difference is the integrated language contract for reusable requirements and verification cases, not the presence or absence of testing in the methodology. [4](https://mbse-capella.org/resources/arcadia-reference/Arcadia%20Reference%20-%20Data%20Model.pdf) [7](https://mbse-capella.org/addons.html) **Acceptance criterion.** Reuse one requirement definition with two subject bindings. A passing result for the small robot must not become evidence for the heavy robot. An experiment outside the stated assumptions must not be presented as proof of the conditional requirement. Keep requirement satisfaction assertions, execution records, and evidence provenance distinct; those workflow policies require implementation beyond syntax. ### S4 Behavioral algorithms with explicit data changes **Scenario.** A drive startup procedure sends an enable command and waits for acknowledgment until a timeout. It makes at most three attempts, updating the attempt counter each time. A final failure triggers a shutdown action; success starts monitoring. **SysML v2 advantage.** Actions can combine structured conditionals, loops, assignments, and communication. The official structured-control example directly combines branching, changing attribute values, while loops, and iteration over values. The startup procedure can therefore have a defined behavioral representation alongside the architecture. [13](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/examples/Simple%20Tests/StructuredControlTest.sysml) **Capella comparison.** Capella has scenarios and state machines. Modern Functional Chain Description diagrams also have Sequence Links, conditions, and OR, AND, and ITERATE control nodes. It is incorrect to claim that Capella has no control or iteration. Its architectural sequencing and expression facilities do not constitute the same general action language; a complete executable interpretation needs an agreed extension or transformation. [23](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/doc/plugins/org.polarsys.capella.ui.doc/html/05.%20Diagram%20Management/5.5.%20Creation%20of%20Functional%20Chains%20and%20Physical%20Paths.mediawiki) **Acceptance criterion.** Model successful acknowledgment on attempt two and failure after attempt three. An implementation claiming execution support must produce the appropriate traces and attempt counts. Architecture-only tools should preserve the behavior faithfully without claiming to execute it. Keep an information dependency separate from a precedence constraint; neither should be inferred automatically from the other. ### S5 Asset identity and changing configuration over time **Scenario.** A robot uses battery B17 during its morning mission and battery B29 after maintenance. The architecture's battery role remains the same. The team needs to state which physical battery was installed during a particular overheating event. **SysML v2 advantage.** Individuals distinguish a particular asset from a reusable type. Time slices and snapshots describe portions of an occurrence and values at temporal boundaries. The official examples demonstrate individual declarations and attribute values constrained over different temporal portions. [14](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/examples/Timeslice%20and%20Snapshot%20Examples/TimeVaryingAttribute.sysml) [15](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/examples/Simple%20Tests/IndividualTest.sysml) **Capella comparison.** States, scenarios, property values, and external asset data can describe the story. Additional conventions or extensions are needed to give asset identity and temporal configuration a similarly general interpretation. A Capella physical component name alone cannot settle whether it denotes a design role or an individually identified installed item. This comparative boundary is an engineering inference from the reviewed models. [21](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/m2/plugins/org.polarsys.capella.core.data.def/model/PhysicalArchitecture.ecore) [22](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/m2/plugins/org.polarsys.capella.core.data.def/model/Interaction.ecore) **Acceptance criterion.** Ask which battery occupied the role at the event time and obtain B17 or B29 from modeled relationships. Preserve the identity of the robot across replacement. Distinguish simulated or real system time from the revision history of the model file; a SysML snapshot is not a Git commit. ### S6 Equipment subsets without duplicating equipment **Scenario.** A robot has four sensors. Two are cameras; two are safety-critical. One camera is safety-critical, so the groups overlap. The architecture must count four physical sensors, not six or eight, and constrain the safety-critical set to contain only installed sensors. **SysML v2 advantage.** Subsetting explicitly constrains one feature's values to belong to another feature's values. Multiplicity constrains their number. The official example places an engine, transmission, and wheels within a common parts feature using subsetting. Reference features can describe overlapping classifications without asserting extra physical ownership. [16](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/training/04.%20Subsetting/Subsetting%20Example.sysml) [2](https://www.omg.org/spec/KerML/1.0/PDF) **Capella comparison.** References, categories, types, and viewpoints can represent group membership. The extra design work is assigning and enforcing subset, overlap, and counting semantics across those mechanisms. Graphical grouping or labels alone do not specify them. This is a comparative inference, not a claim that a custom Capella validation rule could not enforce the relation. [20](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/m2/plugins/org.polarsys.capella.core.data.def/model/CompositeStructure.ecore) **Acceptance criterion.** Preserve four sensor identities across both groups. Reject a safety-critical member that is not in the installed-sensor set. Do not infer that all sensors belong to a named subgroup: coverage requires an additional constraint. Do not infer that groups are disjoint: disjointness also requires an additional constraint. Mass roll-up must count owned equipment, not every reference to it. ### S7 Trade studies represented as reusable analyses **Scenario.** Choose between three battery packs using mass and mission endurance. One study minimizes mass subject to a 60-minute endurance requirement. Another study uses a different mission duration. The decision must remain connected to the candidate models and the evaluation used. **SysML v2 advantage.** The standard TradeStudies library defines alternatives, an evaluation function, an objective, and a selected result. It includes minimizing and maximizing objectives. A study can specialize this structure and reuse calculations with different inputs, making the decision model itself an explicit artifact. [17](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml.library/Domain%20Libraries/Analysis/TradeStudies.sysml) **Capella comparison.** Architecture justification and competing concerns are central to ARCADIA. Capella supports specialty viewpoints and comparison facilities. Capella may be the more convenient workbench for an existing analysis extension. SysML v2's advantage is the standard representation of the analysis contract, rather than an exclusive ability to perform trade studies. [4](https://mbse-capella.org/resources/arcadia-reference/Arcadia%20Reference%20-%20Data%20Model.pdf) [6](https://mbse-capella.org/features.html) **Acceptance criterion.** For candidate A at 8 kg and 45 minutes, B at 10 kg and 70 minutes, and C at 12 kg and 90 minutes, select B for the 60-minute mission. Select C for an 80-minute mission. Explicitly model the feasible-candidate filter, tie policy, units, and missing-data policy. The standard library does not establish every project's decision policy or supply a universal optimizer. ### S8 Domain vocabulary with reusable semantic meaning **Scenario.** The team adds a concept called SafetyMonitor. Each monitor observes a signal and performs a checking action. The same concept must appear in several projects, with extra review metadata and rules about allowed usage. **SysML v2 advantage.** Model libraries supply specialized definitions. Semantic metadata can cause annotated types to specialize an identified base type, and user-defined keywords offer domain notation. The official example covers situations, causes, failures, and scenarios. [18](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/training/41.%20Language%20Extension/Semantic%20Metadata%20Example.sysml) [1](https://www.omg.org/spec/SysML/2.0/Language/PDF) **Capella comparison.** Capella can be extended through viewpoints and its development framework; properties also support lighter customization. Rich new semantics and editing support may require a language/tool extension. SysML v2 supplies a standard language-level route for many such specializations, although custom diagrams and checks still need tool support. [7](https://mbse-capella.org/addons.html) **Acceptance criterion.** Export and reopen a SafetyMonitor with its library dependencies and preserve its type meaning, observed-signal reference, and metadata. Do not treat an arbitrary tag named SafetyMonitor as sufficient semantics. A second conforming tool can read the standard representation only to the extent that it supports the required language features and libraries; identical UI and custom-rule execution are separate requirements. ## Cases favoring ARCADIA Capella ### C1 Needs and solutions with explicit architectural transitions **Scenario.** An operational need to inspect a facility becomes system capabilities and functions, then a logical architecture and a physical implementation. Later, an operational activity changes. Engineers need to understand which downstream decisions may need revision. **Capella advantage.** ARCADIA supplies explicit engineering perspectives and relationships between their concepts. Capella's iterative transition tooling uses traceability and conservative transformation rules, with a merge view for reviewing candidate changes. Re-running a transition is a supported workflow rather than a team-defined import script. [3](https://mbse-capella.org/resources/arcadia-reference/Arcadia%20Language%20-%20MetaModel.pdf) [24](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/doc/plugins/org.polarsys.capella.transitions.doc/html/11.%20Iterative%20Transitions/11.1.%20Concepts.mediawiki) **SysML v2 comparison.** Packages, parts, actions, requirements, and allocations can encode these perspectives. SysML v2 does not prescribe the ARCADIA level taxonomy, transition rules, or architectural completion checks. A method library plus validation and transformation tooling can close the gap. This is a domain-and-workflow advantage, not greater unrestricted language expressiveness. **Acceptance criterion.** Change one upstream activity, compute a reviewable downstream update, retain traceability, and avoid duplicating unchanged targets. Source deletion must not silently destroy downstream design work. “Conservative” does not mean that target edits can never be moved or affected; transformation rules and conflict handling must be explicit. Allow projects to use the relevant perspectives without forcing every project through every level. ### C2 Traceable communication from function to physical route **Scenario.** A controller function sends torque commands to an actuator function. The functions are allocated to behavioral components hosted on two computers. Communication crosses Ethernet, a gateway, and CAN. Reviewers need to see both what is exchanged and which implementation carries it. **Capella advantage.** Functional exchanges, component exchanges, their allocation objects, behavioral and node physical components, deployment links, physical links, and physical paths distinguish different architectural responsibilities. The actual metamodel contains these relationships, making the chain of explanations explicit. [19](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/m2/plugins/org.polarsys.capella.core.data.def/model/FunctionalAnalysis.ecore) [20](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/m2/plugins/org.polarsys.capella.core.data.def/model/CompositeStructure.ecore) [21](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/m2/plugins/org.polarsys.capella.core.data.def/model/PhysicalArchitecture.ecore) **SysML v2 comparison.** Flows, interfaces, connections, parts, and allocations provide building blocks. The ARCADIA meaning of each relationship and routing obligation must be established by a library and rules. A single generic connection does not preserve all those distinctions. SysML v2 is capable of hosting the richer mapping; it does not supply it automatically. **Acceptance criterion.** From a torque-command exchange, navigate to its implementing communication, allocated endpoints, deployment hosts, and route. After moving one component to another host, identify which routes need review. A drawn link must not imply that bandwidth, latency, protocol compatibility, or failure independence has been proved. Preserve routing participation rather than reducing every path to a label. ### C3 Contextual participation in functional chains **Scenario.** An obstacle-detection function participates in both normal navigation and emergency stopping. The emergency chain has its own sequencing and exchange context. Engineers must reuse the architecture function while distinguishing its participation in each chain. **Capella advantage.** Functional-chain involvement objects reference functions and exchanges separately from the referenced architecture elements. Links carry context, and chains can reference other chains. This supports capability-path descriptions and traceable overlays on an existing functional architecture. [19](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/m2/plugins/org.polarsys.capella.core.data.def/model/FunctionalAnalysis.ecore) [23](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/doc/plugins/org.polarsys.capella.ui.doc/html/05.%20Diagram%20Management/5.5.%20Creation%20of%20Functional%20Chains%20and%20Physical%20Paths.mediawiki) **SysML v2 comparison.** Actions, performances, flows, successions, and references can represent related behavior. There is no standard Arcadia FunctionalChain construct that automatically reproduces its involvement semantics. The current Arcadia library mapping explicitly leaves questions about chain trace objects and exchange context open. [29](https://github.com/eclipse-capella/arcadia-sysmlv2-lib/blob/0ba360d2a50a6dfe026af7c5bcbcfd7e800d4614/doc/ArcadiaLibraryMapping.md) **Acceptance criterion.** One architecture function appears in two chains with different participation records. Editing the function updates shared architectural information; editing the emergency participation does not alter normal-navigation sequencing. Preserve nested chain references and repeated participation without merging them by name. A mapping must state whether a chain describes possible dependencies, ordered performance, or both through separate relationships. ### C4 Functional reorganization with computed overview links **Scenario.** An architect reorganizes 200 leaf functions into new responsibility groups. Existing leaf-to-leaf dependencies should remain valid, and overview diagrams should show the new inter-group dependencies without requiring manual maintenance of every boundary port. **Capella advantage.** Its functional breakdown treats non-leaf functions as grouping elements in the completed analysis. Overview exchanges are computed from dependencies below them. This combination makes regrouping and mixed top-down/bottom-up exploration natural while keeping the detailed dependencies authoritative. [5](https://mbse-capella.org/arcadia_capella_sysml_tool.html) [6](https://mbse-capella.org/features.html) **SysML v2 comparison.** Nested references and custom views can support similar diagrams; SysML v2 does not inherently prohibit cross-hierarchy references or require a user to redraw every delegation. The advantage is Capella's predefined grouping interpretation and computed-view behavior. An executable composite action has different semantics from a folder of architectural functions. **Acceptance criterion.** Move a leaf function to a different group while preserving its identity and actual exchange endpoints. Recompute the overview; drill down from an overview edge to the contributing exchanges. Keep presentation aggregation distinct from new communication or control relationships. If the product supports executable action decomposition too, make the two kinds of hierarchy distinguishable. ### C5 Scenarios and interfaces checked against architecture **Scenario.** A scenario shows a command and acknowledgment between a controller and an actuator. The actuator interface changes. Reviewers need to know whether the scenario still invokes the intended exchange and whether its payloads agree with the architecture. **Capella advantage.** Sequence messages refer to invoked operations or exchanges and expose related functions, parts, and exchange items. Documented rules check message/exchange consistency and payload allocation. Interface checks also detect missing or unused exchange items on interfaces produced by the relevant modeling accelerator. [22](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/m2/plugins/org.polarsys.capella.core.data.def/model/Interaction.ecore) [25](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/doc/plugins/org.polarsys.capella.validation.doc/html/Validation%20Rules/design/well-formedness/interfaces/ValidationRules.mediawiki) [26](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/doc/plugins/org.polarsys.capella.validation.doc/html/Validation%20Rules/design/well-formedness/scenarios/ValidationRules.mediawiki) **SysML v2 comparison.** A disciplined SysML model can share definitions and references between behavioral and structural views. The language does not automatically provide Capella's specific architecture-to-scenario checks, interface derivation conventions, and associated commands. The advantage lies in the integrated domain rules, not in having sequence notation at all. **Acceptance criterion.** Remove an exchange item from the modeled interface and identify the affected scenario messages. Check that each message's endpoints and conveyed items remain compatible with the referenced exchange. A generated interface must retain provenance so the tool can distinguish accidental omission from a deliberate extra service. Do not require every designed interface to contain only items already used by current scenarios. ### C6 Reusing fragments that span several model trees **Scenario.** Reuse a fault-detection pattern consisting of functions, exchanges, a functional chain, two components, and their allocations. Those elements belong to different model hierarchies. A later improvement in one project should be reviewable for incorporation into the reusable pattern. **Capella advantage.** A REC is a collection of references to reusable elements and can span multiple roots. RPLs preserve their relation to that collection. The tooling supports updates from the reusable source to replicas and from a replica back toward the reusable source, with merge review. Documented conformance modes permit different degrees of local adaptation. [27](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/doc/plugins/org.polarsys.capella.re.doc/html/08.%20Replicable%20Element%20%28REC-RPL%29/8.1.%20Introduction.mediawiki) [28](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/doc/plugins/org.polarsys.capella.re.doc/html/08.%20Replicable%20Element%20%28REC-RPL%29/8.3.%20Update%20REC-RPL.mediawiki) **SysML v2 comparison.** Definitions, packages, usages, and specialization support semantic reuse. They do not by themselves specify an operation that extracts an arbitrary existing graph fragment, maps its external references, synchronizes replicas, and promotes selected edits. A SysML tool could implement this. Therefore Capella's strength here is practical reuse workflow, while S1 concerns inheritance semantics. **Acceptance criterion.** Reuse the entire pattern, preserving internal references and explicitly resolving external ones. Keep replica provenance across local edits. Offer a reviewable merge when propagating an improvement; do not silently overwrite differences. Preserve the distinction between inherited common content and intentionally materialized copies. Verify conformance behavior for the supported release instead of assuming every documented mode is fully automated. ## Implications for the new metamodel **Recommendation.** Specify the architecture language and its semantic contract before choosing database classes or an editor framework. Use the cases above as mapping and implementation tests. Start with standard SysML v2 extension mechanisms; introduce independent metamodel constructs only for demonstrated gaps that justify their semantic and interoperability cost. | Priority | Development requirement | Cases | | --- | --- | --- | | First | Separate definition, usage, participation, and individual identity | S1 S5 C3 C6 | | First | Separate containment, performance responsibility, deployment, and routing | C2 C4 | | First | Give allocations and realization links explicit endpoint roles and provenance | C1 C2 C5 | | First | Preserve original references behind computed diagrams and summaries | C3 C4 C5 | | First | Implement expressions, defaults, bindings, and constraints consistently | S1 S3 S6 | | Next | Represent configuration selection separately from runtime state | S2 S5 | | Next | Keep requirements, satisfaction claims, verification, and evidence distinct | S3 | | Next | Support reusable calculations and analysis subjects and objectives | S7 | | Next | Support libraries, typed extensions, and dependency-aware interchange | S8 | | Next | Add iterative transitions and fragment reuse with reviewable merges | C1 C6 | “First” denotes concepts whose absence would distort the architecture or lose information during import. It is not a claim that the whole implementation must ship at once. Behavioral execution, temporal queries, and optimization can be staged after their representational semantics are settled. ## Mapping rules that need explicit decisions **Allocation versus performance.** A statement that a component is responsible for a function is not automatically a complete specification of the function's runtime execution. Document when a function allocation maps to a perform relation, when a separate design-allocation object remains necessary, and how intended and implemented allocations are distinguished. **References versus occurrences.** A function's participation in a chain, a particular execution, and a copied architectural function require different identity rules. Names must never be the primary correspondence key. Preserve the source identity and the mapping provenance through import, transformation, and merge. **Views versus architecture.** An overview edge summarizing several exchanges must retain its contributors. It must not become an additional flow when the model is exported or analyzed. Similarly, visual nesting must not silently change deployment, ownership, or behavior. **Library meaning versus tool behavior.** Record which constraints are represented, which are evaluated, and which are outside the implemented analysis subset. A parser accepting a model is not evidence that its constraints hold or its behavior is executable. ## Current convergence work and its limits On 9 September 2026, Obeo announced Capella for SysON, combining an Arcadia SysML v2 library, a bridge from Capella, and method-specific web tooling. The announcement describes the project as early-stage, with a first MVP targeted for 2027 and broader coverage after that. This is a roadmap, not an assurance of delivered parity. [30](https://blog.obeosoft.com/capella-for-syson) The inspected Arcadia library mapping contains unresolved work on node and behavioral components with deployment, interface meaning and port directions, functional-chain traceability and context, scenarios, physical paths, modes/states, and REC/RPL. Those gaps are useful evidence for a mapping test plan. They are not evidence that SysML v2 cannot express the concepts. [29](https://github.com/eclipse-capella/arcadia-sysmlv2-lib/blob/0ba360d2a50a6dfe026af7c5bcbcfd7e800d4614/doc/ArcadiaLibraryMapping.md) The development team should inspect this work before creating parallel definitions, but should evaluate it against the cases in this report. A mapping that omits a field because it is considered rarely used is not lossless for a project that relies on that field. ## Interoperability is a separate engineering objective SysML v2's ecosystem includes the separately specified Systems Modeling API and Services. It offers a standard integration contract, which is useful for automation and model access. It does not create a proof that two tools exchange every diagram, extension, constraint result, or methodology rule without loss. Capella also has programmatic access and extensions. [31](https://www.omg.org/spec/SystemsModelingAPI/1.0) Define an interchange support matrix: exact preservation, preservation with an explicit mapping, opaque retention, and unsupported content. Report losses. Round-trip comparison should examine element identity, typing, relationships, participation context, and library versions; visual similarity and object counts are insufficient. ## Proposed validation sequence 1. **Represent the fixtures.** Create one small model per case with named identities and expected relationships. Include invalid configurations as well as valid ones. 2. **Exercise changes.** Reallocate a function, move a host, replace an asset, select a variant, rename an exchange, and revise a reusable fragment. Verify each case's acceptance criterion. 3. **Test a mapping.** Import representative Capella content, inspect the semantic correspondence, export it, and compare preserved meaning. Include nested and repeated chain participation. 4. **Test implemented analyses.** Run only claimed capabilities. Separate validation of the model structure from evaluating equations, executing behavior, or proving requirements. 5. **Evaluate engineering usability.** Ask engineers to perform the same architectural change in both workflows. Measure manual edits and unresolved inconsistencies before claiming a productivity advantage. The initial decision should be based on whether the chosen foundation preserves these distinctions and supports the required operations. Breadth of syntax and familiarity of diagrams are useful, but neither alone establishes suitability for the proposed platform. ## Sources and revision basis Primary specifications, official example models, Capella implementation documentation, and maintainer publications support this report. Citations in the case text link directly to the relevant source. Example models are evidence of language mechanisms, not proof of universal tool conformance. The source snapshots inspected were SysML v2 Release **fb97b754f29588b8e9c7a35f370880cd15eb29e7**, Capella **5537297b071fff809285bc63989f5067d675bc52**, and Arcadia SysML v2 library **0ba360d2a50a6dfe026af7c5bcbcfd7e800d4614**. Capella repository documentation can describe development behavior or retain historical limitations; release-specific guarantees require a released-build check. [1](https://www.omg.org/spec/SysML/2.0/Language/PDF) OMG SysML 2.0 Language Specification. March 2026 edition; sections 7 and 8. [2](https://www.omg.org/spec/KerML/1.0/PDF) OMG KerML 1.0 Specification. Typing, specialization, occurrences, and semantics. [3](https://mbse-capella.org/resources/arcadia-reference/Arcadia%20Language%20-%20MetaModel.pdf) ARCADIA Language Reference Meta Model. 2023; conceptual reference, not the complete implementation schema. [4](https://mbse-capella.org/resources/arcadia-reference/Arcadia%20Reference%20-%20Data%20Model.pdf) ARCADIA Reference Engineering Data Model. 2023; architecture, justification, and verification data. [5](https://mbse-capella.org/arcadia_capella_sysml_tool.html) Capella explanation of equivalences and differences with SysML. Historical SysML v1 comparison; used for Capella design rationale only. [6](https://mbse-capella.org/features.html) Capella features and benefits. Computed views, reuse, validation, and specialty viewpoints. [7](https://mbse-capella.org/addons.html) Capella add-on catalog. Requirements, variability, and analysis ecosystem context. [8](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/training/05.%20Redefinition/Redefinition%20Example.sysml) SysML v2 redefinition example. [9](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/examples/Variability%20Examples/VehicleVariabilityModel.sysml) SysML v2 vehicle variability example. [10](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/examples/Simple%20Tests/ConstraintTest.sysml) SysML v2 constraint examples. [11](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/examples/Simple%20Tests/RequirementTest.sysml) SysML v2 requirement examples. [12](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml.library/Systems%20Library/VerificationCases.sysml) SysML v2 standard VerificationCases library. [13](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/examples/Simple%20Tests/StructuredControlTest.sysml) SysML v2 structured control examples. [14](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/examples/Timeslice%20and%20Snapshot%20Examples/TimeVaryingAttribute.sysml) SysML v2 time-varying attribute example. [15](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/examples/Simple%20Tests/IndividualTest.sysml) SysML v2 individual examples. [16](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/training/04.%20Subsetting/Subsetting%20Example.sysml) SysML v2 subsetting example. ## Sources and revision basis (continued) [17](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml.library/Domain%20Libraries/Analysis/TradeStudies.sysml) SysML v2 standard TradeStudies library. [18](https://github.com/Systems-Modeling/SysML-v2-Release/blob/fb97b754f29588b8e9c7a35f370880cd15eb29e7/sysml/src/training/41.%20Language%20Extension/Semantic%20Metadata%20Example.sysml) SysML v2 semantic metadata example. [19](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/m2/plugins/org.polarsys.capella.core.data.def/model/FunctionalAnalysis.ecore) Capella FunctionalAnalysis metamodel. Allocation, chain involvement, sequence links, and control nodes. [20](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/m2/plugins/org.polarsys.capella.core.data.def/model/CompositeStructure.ecore) Capella CompositeStructure metamodel. Parts, interfaces, physical links, and paths. [21](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/m2/plugins/org.polarsys.capella.core.data.def/model/PhysicalArchitecture.ecore) Capella PhysicalArchitecture metamodel. Physical component nature and deployment. [22](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/m2/plugins/org.polarsys.capella.core.data.def/model/Interaction.ecore) Capella Interaction metamodel. Scenario and message references. [23](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/doc/plugins/org.polarsys.capella.ui.doc/html/05.%20Diagram%20Management/5.5.%20Creation%20of%20Functional%20Chains%20and%20Physical%20Paths.mediawiki) Capella functional chains and physical paths guide. Involvements, sequencing, control, and chain composition. [24](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/doc/plugins/org.polarsys.capella.transitions.doc/html/11.%20Iterative%20Transitions/11.1.%20Concepts.mediawiki) Capella iterative transition concepts. Conservative updates and merge review. [25](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/doc/plugins/org.polarsys.capella.validation.doc/html/Validation%20Rules/design/well-formedness/interfaces/ValidationRules.mediawiki) Capella interface validation rules. Includes generated-interface rule DWF_I_23. [26](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/doc/plugins/org.polarsys.capella.validation.doc/html/Validation%20Rules/design/well-formedness/scenarios/ValidationRules.mediawiki) Capella scenario validation rules. Message/exchange and payload consistency checks. [27](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/doc/plugins/org.polarsys.capella.re.doc/html/08.%20Replicable%20Element%20%28REC-RPL%29/8.1.%20Introduction.mediawiki) Capella REC and RPL introduction. Multi-root collections and conformance modes. [28](https://github.com/eclipse-capella/capella/blob/5537297b071fff809285bc63989f5067d675bc52/doc/plugins/org.polarsys.capella.re.doc/html/08.%20Replicable%20Element%20%28REC-RPL%29/8.3.%20Update%20REC-RPL.mediawiki) Capella updates between REC and RPL. Update directions and DiffMerge workflow. [29](https://github.com/eclipse-capella/arcadia-sysmlv2-lib/blob/0ba360d2a50a6dfe026af7c5bcbcfd7e800d4614/doc/ArcadiaLibraryMapping.md) Arcadia SysML v2 library mapping rationale. Inspect open points and TODO sections before assuming mapping coverage. [30](https://blog.obeosoft.com/capella-for-syson) Obeo announcement of Capella for SysON. 9 September 2026; early-stage initiative and roadmap. [31](https://www.omg.org/spec/SystemsModelingAPI/1.0) OMG Systems Modeling API and Services 1.0. Separate API standard; not a universal interchange guarantee. [32](https://github.com/Systems-Modeling/SysML-v2-Release) OMG Systems Modeling Community release repository. Explains the formal adoption and March 2026 editorial update.