Coupling Methodology and Tooling for Systems Modelling: ARCADIA and Capella at Thales

by Joe Silmon, Jean-Luc Voirin, and Stéphane Bonnet
Thales S.A.


Thales S.A. is a global provider of engineering solutions and consultancy to the security, space, transportation, aerospace, and defense industries. In all sectors, Thales analyses customer needs and develops solutions that can include combinations of new technologies, existing Thales products, and integrated parts from other suppliers. The Thales engineering methodology and tool set enables engineering teams to manage the high complexity of modern technology in areas such as inter-bank secure transactions, safety-critical train control for metros and main line railways, and military C4I (Command, Control, Communications, Computers, and Intelligence).



Model-based systems engineering has often come under criticism for being tool-driven and failing to solve the problems engineers are facing on projects. The notion of models as “shelf ware” has come about in part due to a disjoint between approaches, engineering procedures, and media of communication. The ARCADIA design approach and the Capella system modelling tool have been developed to more tightly couple the output of modelling with the needs of an engineering process. In this article, we describe their background, and illustrate how the two fit together, allowing engineers to realize benefits in both pure model-based scenarios and more pragmatic model-supported scenarios.





Copyright © 2017 by Joe Silmon, Jean-Luc Voirin, and Stéphane Bonnet.  All rights reserved.



In early 2006, Thales decided to launch an in-depth engineering transformation plan, to face new challenges and new customer expectations worldwide. This plan led to the development, in collaboration with the partners of the Clarity consortium, of an engineering method offering a language to describe engineering assets, and a tool for describing those assets using formal models.

The method is called ARCADIA, and is currently in use in most Thales units and technical domains worldwide, where security, performance, and safety are critical to success. The method and its dedicated modelling tool, named Capella, have been designed to support tightly coupled development and engineering teams, with real-life, full scale, short loop assessment of each feature to be considered.

In this paper, we will give an outline of ARCADIA’s structure and principles, and details of Capella’s features and user interface.



ARCADIA and Capella are two distinct solutions that work together for the implementation of model-based systems engineering (MBSE). As illustrated in Figure 1, ARCADIA (which stands for ARChitecture And Design Integrated Approach) covers the methodology and the high-level conceptual ontology and viewpoints.


Capella elaborates on these with more detail to provide a comprehensive set of diagrams and notation elements. ARCADIA may be used with other tools, but Capella has been purpose-built to provide the notation and diagrams needed to create models that exactly fit with ARCADIA’s approach.



Figure 1 - Scope split between ARCADIA and Capella


See reference 1 for more details on the three highlighted areas of MBSE.


Purpose of ARCADIA


ARCADIA is a model-based method and language devoted to systems, software, and hardware architecture engineering to:

  • Understand the real customer need;

  • Define and share the system architecture among engineering stakeholders;

  • Support cooperation between different engineering levels, along with specialities (safety, security, performance, product line etc.);

  • Validate and justify system design early in the life cycle; and

  • Ease and master IVVQ (Integration, Validation, Verification, Qualification).

ARCADIA principles and modelling language

The ARCADIA definition is driven by a few structuring principles:

  • Extended functional analysis to define both need and solution behavior;

  • Separation of need analysis and solution architecture definition;

  • Separation of operational need analysis and definition of system contribution to this need (system need analysis);

  • Separation of functional/behavioral description, and structural decomposition;

  • Differentiation between the structuring of behavioral/logical components and physical hosting components.

This favors separation of concerns, so as to adapt to different life cycles, provides capabilities for impact analysis, and allows efficient management of architecture alternatives, reuse, etc.


Major concepts of the ARCADIA method and framework

The following subsections illustrate the general semantic concepts covered by ARCADIA, using Capella diagrams as examples. These diagrams are taken from an openly-available demonstrator model that can be downloaded, along with the Capella tool, here.


Functional analysis

Figure 2 - Example of system analysis implemented in the System Dataflow diagram in Capella


Functional analysis is structured by missions and capabilities, dealing with system use case description using functional data flows. Each (leaf) function in the dataflow produces outputs and requires inputs through ports. Function ports are linked to each other by exchanges expressing only possible dependencies between functions.
For each capability, several sequence scenarios or functional chains illustrate how the dataflow functions and exchanges contribute to the capability.

Concurrent Modes and states machines can be defined (for the system and behavioral components), fully integrated and connected with the dataflow and scenarios, and expressing conditions for functional contents availability in each mode or state, and combinations.


Data analysis


Figure 3 - Example of a data model implemented with Capella's Class Diagram


A data model describes exchanges contents based on class-organized structures. These classes can be grouped into Exchange Items, to be exchanged between functions or components. Exchange items may carry a communication paradigm (such as flow event, operations, etc.).


Behavioral structure


Figure 4 - Example of behavioural structure at the top level of the system, implemented with the Capella System Architecture diagram


In logical and physical architecture perspectives, behavioral components are defined to implement functions. Component ports are linked by behavioral exchanges, grouping functional exchanges. Component interfaces are defined on ports, and group exchange items (see below). These exchange items are originated from functional exchange contents.

Hosting structure

Behavioral components are hosted by implementation components that deliver needed resources to them. Each behavioral component is hosted by one implementation component, and behavioral exchanges are carried via physical links between implementation components ports.

Figure 5 - Example of hosting architecture implemented with the Physical Architecture diagram in Capella

Other considerations

All model elements included within functional and structural modelling in ARCADIA are instances (i.e. unique and individual elements constituting a part of the system). Reusability is implemented with specific constructs called Replicable Elements, instead of type/instance constructs. Replicable Elements can be defined individually or as collections, and can be stored in libraries to build product-line reference architecture models for future use.

The initial DSL semantics is deliberately not focused on precise executable semantics, so as to adapt to various needs in terms of viewpoint analyses, models of computations, and simulation flavors/objectives. Each domain may enrich it according to its own needs.


Five major perspectives, tightly integrated with the language, structure the model according to major engineering activities and concerns, each one dealing with specific engineering issues and outputs. These are listed below, together with an example of how elements can be traced from one level to another, providing instant justification for design features and assurance that requirements are met by architecture.


Table 1 - the five ARCADIA perspectives and their architectural concerns



The scope and target of a method have direct consequences on the associated tooling. ARCADIA does not cover the full spectrum of design activities: its focus is primarily on architectural design, excluding, for example, low-level behavioral modelling or simulation. The original audience for the ARCADIA/Capella solution was primarily systems engineers with diverse backgrounds and skills.


At one end of the spectrum, standard or universal languages such as SysML target a wide variety of domains and modelling intentions. At the other end, specialized modelling languages have reduced coverage and more focused intentions, as they are intended to provide solutions for particular domains. These characteristics make them more likely to provide richer semantics and enhanced formalism.

Today, most modelling tools support SysML and provide various degrees of extensibility and customization. Therefore, the most common approach to implement MBSE methodological guidance is to enrich the SysML language with method-specific profiles, adding semantics and to provide relevant productivity and validation tooling.

Between 2003 and 2006, this alternative was the first-line approach for ARCADIA method support. A few man-years’ worth of development went into the creation of a UML profile and a significant amount of associated tooling such as model transformations and validations. The developed solution suffered not only from language complications, but from ergonomics issues as well and was quickly rejected by the pilot practitioners. 

Capella is neither a SysML profile nor a domain-specific language (DSL). The core meta-model of the Capella notation has been strongly inspired by SysML and the diagrams provided are very similar. However, when considering the SysML language as a reference, the meta-model of Capella is simultaneously simplified, modified and enriched.

  • Simplified or modified: whenever SysML concepts were more complex than necessary to model architectures, they were either excluded (many low-level behavior modeling constructs are absent) or simplified (components, parts, instances);

  • Enriched: ARCADIA implements an architectural framework, where description languages such as SysML do not; the Capella tool implements this framework in its meta-model.

The main advantage of this hybrid approach is that Capella diagrams can be read and understood (to a certain extent) by engineers having no particular knowledge of Arcadia. The lessons learnt in the simplification of SysML are being fed back through our membership of the SysML 2 working group.

Capella is an original solution in the landscape of modelling workbenches for several reasons including the tight coupling between the method and the tool, the availability of multiple productivity tools, the artefacts allowing to master design complexity and the fact that it is an open source solution.

Tight coupling between the method and the tool

Its tight coupling with the ARCADIA method is one of the key aspects of Capella. In addition to having its concepts directly aligned on the ARCADIA ones, three features strongly enforce the implementation of the method in Capella models:

  • All projects are initialized with a model structure which reflects the ARCADIA engineering perspectives;

  • The graphical aspect of elements in all edition view and diagrams is aligned with the ARCADIA ones. For example, green is dedicated to functional analysis, blue is dedicated to structural elements and red is dedicated to interfaces;

  • A method explorer is the key interaction interface for Capella models, as illustrated in Figure 6


Figure 6 - Capella screenshot indicating features of the user interface


The customizable method explorer lists all major modelling activities for each perspective, proposes shortcuts to the most suitable graphical representations, and provides an index for all existing diagrams for each activity. This explorer is of course a great help for beginners, eliminating the blank page syndrome. But beyond that, it is a powerful tool to navigate in Capella models.

Value-added productivity tools

A system model obeys construction rules. It is a graph, where elements are interconnected in multiple ways. Productivity tools help end-users create their models in a more efficient way, taking into account existing model parts to initialize others. A simple example is the one of interfaces between components, which is one of the key objectives of ARCADIA.

In the method, functions are connected to each other with functional exchanges expressing dependencies (data, energy, etc.). These dependencies are specified with formal descriptions (typically using class diagrams). As functions are allocated to components, it is straightforward to deduce the content of interfaces between components based on the dependencies between their allocated functions. Capella provides dedicated generation algorithms, validation rules and associated quick fixes.

Productivity or automation tools not only accelerate day-to-day modelling activities; they also improve the consistency and correctness of models by reducing human mistakes. Other productivity tools of Capella include automated and iterative model transitions from one Arcadia perspective to another, brushing of layouts between diagrams, etc.

Another key feature is the instant querying capability of the “semantic browser” (see Figure 7). This area of the user interface is populated by the relationships of any selected object on a diagram. A user can instantly query what an element is related to and which other views it appears in.

Complexity mastering

One of the main rationales for the deployment of model-based systems engineering is to be able to cope with the growing complexity of systems. It is mandatory for a modelling tool to provide concrete help to master this complexity.

This starts with reducing the incidental complexity. By simplifying the underlying modelling concepts (when compared to SysML for example), Capella minimizes the learning curve and improves the readability of models. While this is necessary, it is not sufficient and providing mechanisms to concretely help visualize and navigate models is essential.

The most illustrative example is the way Capella manages functional analysis with computed graphical simplifications favoring readability, understanding, and analysis. The ARCADIA method specifies that only leaf functions can ultimately have input and output object flows, own ports, and be allocated to structural elements.


Figure 7 - Example of the semantic browser populated with relationships


In Capella, ports and object flows appearing on non-leaf functions either reflect an intermediate design that is not yet finalized, or are a computed synthesis. The ports owned by children functions can be artificially displayed on parent functions, making the production of synthetic views such as the alternative representations 1 and 2 in Figure 8 possible at no cost.

This Capella implementation is also well adapted to different workflow (top-down, bottom-up). Refinement work consists in creating sub functions and drag-dropping existing ports. Bottom-up approaches simply consist of grouping leaf functions in parent ones and relying on the automated production of synthetic views.

Figure 8 - Synthetic views computed by Capella

Open source


Capella has been developed as a proprietary workbench by Thales for about six years before it was made open source in 2014. The ecosystem around Capella is now growing significantly, with major industrial organizations adopting the Arcadia method. Coupling with other engineering tools such as Safety Architect or the simulation modelling environment Citrus are direct results of this open sourcing strategy enabling open innovation around Capella.

Open source does not necessarily mean “free” for an adopting organization, because professional support and coaching are often required to increase the chances of success. However, open source means “open”:  end-user organizations can join the Capella industry consortium, contribute and influence the development roadmap.

This openness is the highest guarantee of sustainability and freedom to customize, exploit, and enrich the tool according to their needs. Open source means organizations can shape the future of Capella and take the control of their modelling environment. 

Scalability and applicability


ARCADIA can be used to implement a fully model-based systems engineering process, but it can add value to more traditional processes through careful scaling of the tasks undertaken and the models created.

For example, on a recent metro railway project, there was a clear distinction between core required functionality and the project-specific needs. Core functionality had been developed around thirty years ago for Thales’ first unattended metro railway (the Vancouver Skytrain). Hence, the design processes predate ARCADIA and, indeed, Thales itself in its current form.

This functionality, and the underlying design paradigm, were developed using formal requirements-based methods compliant with applicable international standards. The functions have been implemented, verified, and validated many times. Retrospectively modelling this functionality applying ARCADIA would add minimal value for a very large effort.

In contrast, the project-specific needs, such as external interfaces to depots, other systems belonging to the metro operator, and metro trains interoperating with main line trains under the protection of other signaling systems, were complex and not universally understood. Here, the project team implemented a scaled-back ARCADIA approach: not trying to engineer the entire system, but identifying the specific areas of interest and taking the ARCADIA approach to define their architecture within the context of an established system.

Whilst not approaching the level of maturity that is aspired to by MBSE purists, this pragmatic solution proved its value by assisting the engineering team in formalizing system requirements for these complex areas. The model-supported approach interleaves model artefacts with traditional requirements-based artefacts, as shown in Figure 9. This allowed the engineering teams to continue using established processes, but with model content to enhance existing documents, where they added value.


Figure 9 - Model-supported systems engineering




The journey towards model-based systems engineering is not straightforward. To equip engineering teams with the know-how and practical experience to implement such a paradigm shift is a major challenge.
By developing process-based tools and techniques that tie more closely in with current thinking and with corporate procedures, the ARCADIA and Capella teams have put into the hands of the engineering community a comprehensive toolkit with which to model their problem space and system architecture, whilst reducing the need for specialized training and years of theoretical learning. The open-source approach has seen collaboration between organizations and the development of a thriving ecosystem of tools.

List of acronyms and abbreviations used in this article

Term Explanation


Architecture and design integrated approach


Domain-specific language


Integration, verification, validation, and qualification


Model-based systems engineering


Systems modelling language


Unified modelling language


[1] Holt, Jon and Perry, Simon. SysML for systems engineering, 2nd edition: a model-based approach. IET, 2014. ISBN 9-781849-196512.


Web links:
Capella website:

Capella in-flight entertainment demonstrator model:

ARCADIA introduction on the Capella website:

Clarity consortium website:

Safety Architect website:

Citrus website:







"The course provides very good references and training material, including the CDROM, etc."

Requirements Analysis & Specification Writing Course
delegate, Melbourne, Australia

PPI currently presents courses on 6 continents


Featured Course

Requirements Analysis & Specification Writing
Las Vegas, NV

13 - 17 November, 2017

Requirements Analysis and Specification Writing are sciences practiced by many, mastered by surprisingly few. And yet, the payoff from achieving excellence in these areas is large. The two aspects, Requirements Analysis and Specification Writing, are treated as separate but related topics, each in a course of three and two days duration.

Brochure | Register Now

Systems Engineering NEWSLETTER

SyEN makes informative reading for the project professional, containing scores of news and other items summarizing developments in the field of systems engineering and in directly related fields.