Webinar
This webinar illustrates the main equivalences and differences
between SysML and Arcadia/Capella with substantial rationales
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:
|
Arcadia method is supported by various kinds of diagrams largely inspired by UML and SysML:
|
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.
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:
What is performed through Block Definition Diagrams in SysML is achieved in Arcadia through two kinds of diagrams:
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.
The Activity Diagram is a behavior diagram representing the flow of control and objects between activities.
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.
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).
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.
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.
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.
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 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.
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.
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:
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.
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.
