Equivalences and differences
between SysML and Arcadia/Capella

Among the standards from which Arcadia and Eclipse Capella™ are inspired, the SysML language is definitely prominent. This page explains why Arcadia/Capella is to some extent a SysML-like solution to design the architecture of complex systems using models.

Webinar

This webinar illustrates the main equivalences and differences
between SysML and Arcadia/Capella with substantial rationales


Webinar Sysml Arcadia Capella

Overview

Designing complex and critical systems, and more generally architectures that are subject to multiple functional and non-functional constraints, is an activity which requires a level of rigor that can only be provided by formalized and tooled modeling approaches like the ones based on Arcadia/Capella and SysML tools.

SysML Arcadia/Capella
Positioning

SysML is a standard and a general-purpose modeling language for modeling systems. SysML provides very rich and advanced expression means covering a very broad spectrum of applications, spanning from high-level architecture modeling to detailed design at the frontier of simulation.

Inspired by SysML concepts, the Arcadia/Capella solution focuses on the design of systems architectures. For the sake of an easier learning curve and because of the precise scope addressed by Arcadia/Capella, the expression means are sometimes reduced compared to SysML. The ultimate goal of Arcadia/Capella is to have systems engineers embrace the cultural change of MBSE rather than having modeling “experts” owning the model on behalf of systems engineers. Therefore, Arcadia/Capella are strongly driven by the current practices and concerns of system engineering practitioners.

Method

SysML is not associated to a particular method even though several engineering methods can be followed. As such, SysML only provides a vocabulary, but it does not specify when to use one concept or another, how to organize models, etc.

The Arcadia method enforces an approach structured on different engineering perspectives establishing a clear separation between system context and need modeling (operational need analysis and system need analysis) and solution modeling (logical and physical architectures), in accordance with the IEEE 1220 standard and covering parts of ISO/IEC/IEEE 15288.

Language

Technically, the SysML language itself is defined as an extension of the Unified Modeling Language (UML). Both UML and SysML are general-purpose languages targeting wide spectrums of engineering domains and are relying on software-originated engineering paradigms using types, inheritance, etc.

The Arcadia concepts are mostly similar to the UML/SysML standard (about 75%) and the NATO Architecture Framework (NAF) standard (5%). Interoperability with SysML tools is possible using ad-hoc imports/exports. Because of the focus on architectural design, some of the SysML concepts have been simplified or specialized in order to better match the concepts system engineering practitioners already use in their engineering documents and assets. This is the case of the concepts related to functional analysis for instance.

Diagrams

SysML includes diagrams inherited from UML2 and adds new diagrams:

  • 4 diagrams are the same as UML2 diagrams (Sequence, State Machine, Use Case and Package);
  • 3 diagrams are extensions of UML2 diagrams (Activity, Block definition and Internal Block);
  • 2 diagrams are new diagram types (Requirement and Parametric).

Arcadia method is supported by various kinds of diagrams largely inspired by UML and SysML:

  • Architecture diagrams;
  • Dataflows diagrams;
  • Functional chains diagrams;
  • Sequence diagrams;
  • Tree diagrams;
  • Mode and States diagrams;
  • Classes and Interfaces diagrams.

In practice, the operational added value of the MBSE approach is based on many other criteria such as the definition of project modeling objectives, the implementation of adapted methods, the skills of the teams, the involvement of the hierarchy, the integration with the existing information system and third party tools, etc. In short, there are a other aspects to consider when evaluating when to use a SysML tool or Capella than just the language.

Similarities and equivalences between SysML and Arcadia

For the main SysML diagrams, Arcadia proposes a twin diagram.
See below the similarities and equivalences between SysML diagrams and the corresponding ones in Arcadia:


Block Definition Diagram

Internal Block Diagram

Activity Diagram

Sequence Diagram

State Machine Diagram

Use Case Diagram

Requirement Diagram

Parametric Diagram

 

Block Definition Diagram

Arcadia/Capella

What is performed through Block Definition Diagrams in SysML is achieved in Arcadia through two kinds of diagrams:

  • Component Breakdown Diagrams show the component hierarchy through a graphical tree.

  • Component Interface Diagrams show composition relationships between components through graphical containment and relationships between components and interfaces through ports. Component properties are not displayed graphically.

Internal Block Diagram

Arcadia/Capella

Arcadia Architecture Diagrams describe the assembly of components in terms of internal breakdown and connections.

Note: See the dedicated section in Differences to understand how the concepts of parts, blocks and cardinalities are managed in Capella.

Activity Diagram

SysML

The Activity Diagram is a behavior diagram representing the flow of control and objects between activities.

Sequence Diagram

SysML

Sequence Diagrams describe the interaction information with a focus on the time sequence.

This diagram represents the sending and receiving of messages between the interacting entities called lifelines, where time is represented along the vertical axis. The sequence diagrams can represent highly complex interactions with special constructs to represent various types of control logic, reference interactions on other sequence diagrams, and decomposition of lifelines into their constituent parts.

State Machine Diagram

Arcadia/Capella

The Modes and States Machines in Capella are extremely close to SysML. The constructs are the same, but Capella adds a bit of semantics (difference between modes and states, articulation with functional analysis and interfaces).

Use Case Diagram

Arcadia/Capella

Capabilities in Capella are equivalent to SysML use cases and Capabilities Diagrams largely ressemble SysML Use Case diagrams. Capabilities are intensively used in Capella to organize the functional analysis: the involvement of stakeholders in a given capability is enriched by a specification of the stakeholder functions performed in the context of this capability.

Requirement Diagram

SysML

SysML includes a graphical construct to represent text based requirements and relate them to other model elements. The Requirements Diagram captures requirements hierarchies and requirements derivation, and the satisfy and verify relationships allow a modeler to relate a requirement to a model element that satisfies or verifies the requirements. The requirement diagram provides a bridge between the typical requirements management tools and the system models.

Class Diagrams

SysML

The UML Class Diagram does not belong to the official subset of UML diagrams available in SysML (it is replaced by the Block Definition Diagram which is based on the UML Class Diagram, with restrictions and extensions). However, it is presented here, as it is frequently used in addition to SysML diagrams.

Parametric Diagrams

SysML

Parametric Diagrams are a restricted form of Internal Block Diagram that shows only the use of constraint blocks along with the properties they constrain within a context. Parametric Diagrams are used to support engineering analysis, such as performance or mass properties analysis.

Differences between SysML and Arcadia/Capella

The purpose of Arcadia and Capella is to have systems engineers embrace the cultural change of MBSE, rather than having modeling “experts” owning the model on behalf of systems engineers. The following differences are motivated by the commitment to reach this goal and result from the integration of the actual practices and concerns of systems engineers who do not necessarily have software engineering background.


Functional Analysis

Integration Functions / Components / Interfaces

Management of "Instances", or "Definitions and Usages"

 

Functional Analysis

Functional analysis is a classical technique broadly used by systems engineers. Arcadia and Capella provide methodological guidance and engineering helpers to support this technique that has been mostly left out of SysML V1.

The mapping of Capella functions to SysML activity is the most natural one in terms of semantics. Capella functions are verbs specifying the actions expected from the component they are allocated to. This section describes the structural differences between SysML activities/actions and Capella functions.


SysML

The articulation between several Activity Diagrams relies on two major concepts: activities are described by different kinds of actions including some that can reference other activities, and the parameters of a given activity are connected (delegated) to the output or input pins of the actions describing it. This strong encapsulation mechanism favors the reuse of activity definitions in multiple contexts but imposes constraints on what can be represented in one single diagram and makes bottom-up workflows more difficult to implement.

Integration Functions / Components / Interfaces

The biggest objective of the Arcadia method is to secure the architectural design activity through identification and justification of the interfaces. This is achieved by providing a global approach to conduct functional, structural, and interface modeling in parallel:

  • Identification of the functional expectations of the subsystems (allocation of functions to components)
  • Identification of the functional dependencies between the subsystems (specification of the exchanges between functions ideally with a structural description of the exchanged items)
  • Allocation of functional dependencies to assembly relationships between subsystems (allocation of functional ports to component ports, allocation of functional exchanges to component exchanges, etc.)
  • Specification of the interfaces provided and required through component ports (with a possible automated deduction based on all the above-mentioned specification)

Instead of showing the actual element name, the label of functional dependencies can show references towards the exchanged items.

The following diagram details the content of the interfaces between the components, deduced from the functional analysis and multiple allocations.

This integration of the functions / components / interfaces triptych is not straightforward to implement and enforce in SysML v1. This global approach promoted in Capella also comes with a set of assistance tooling enforcing the model correctness regarding this integration and providing automation means.

Note: The topic of a better integration between structure and behaviour is currently being investigated within the SysML v2 SST submission team.

Management of "instances", or "definitions and usages"

The SysML Internal Block Diagram is dedicated to model the internal structure of a block. SysML relies on a generic block/part paradigm: in an Internal Block Diagram, a block can be decomposed into parts (usages) which are themselves typed by other blocks (definitions). A bicycle “block” has two parts “front wheel” and “rear wheel” which are both typed by the block “wheel”. The “wheel” definition is captured in one dedicated block and the same definition can be reused many times in the system through the part concept.

It is possible in Capella to use the same block/part paradigm than in SysML. The following diagrams show how the memory card compartment of the camera can have two slots. There is only one “Memory Card” component, but it is referenced twice. The component breakdown diagram shows the unicity of the “Memory Card” component.

However, Capella is configured by default for an instance-driven modeling. Return of experience showed that systems engineers are not necessarily comfortable with the workflow of creating definition elements first (“blocks” or “components”) and then referencing them from specific usage elements (“parts”).

In addition, architectural design in Capella also consists in performing non functional analyses where it is critical to be able to distinguish the different occurrences of each element and to be able to give them different properties or values. For example, safety analyses typically require to distinguish between the execution of an “identical” function in two distinct components.

This means components and functions in Capella are by default considered as instances or usages.

To support this approach, Capella provides automated mechanisms allowing the replication and synchronization of model elements (REC and RPL, for Records and Replica).

Note: This topic is known as “usage-based modeling” in the SysML v2 submission SST team, the goal being to have a language able to efficiently support multiple creation workflows. The outcome of this effort might at some point be taken into account in Capella.