PRFC Pascal Roques
email: pascal.roques@prfc.fr

MBSE with the ARCADIA Method and the Capella Tool

Keywords: Modeling, Model, MBSE, System Engineering, DSML, Modeling Tool, ARCADIA, Capella

Much more than just yet another modelling tool, Capella [1] is a model-based engineering solution that has been successfully deployed in a wide variety of industrial contexts. Based on a graphical modelling workbench, it provides systems, software and hardware architects with rich methodological guidance relying on ARCADIA, a comprehensive model-based engineering method.

The ARCADIA/Capella DSML is inspired by UML/SysML and NAF standards, and shares many concepts with these languages. It is the result of an iterative definition process driven by systems and software architects working in a broad spectrum of business domains (transportation, avionics, space, radar, etc.). It enforces an approach structured on successive engineering phases which establishes clear separation between needs (operational need analysis and system need analysis) and solutions (logical and physical architectures), in accordance with the IEEE 1220 standard.

In this paper, we will explain why a lot of industrial companies, such as Airbus, Airbus DS and Areva, are currently interested in using Capella and running modeling pilot projects with it.

Introduction

Much more than just yet another modelling tool, Capella is a model-based engineering solution that has been successfully deployed in a wide variety of industrial contexts. Based on a graphical modelling workbench, it provides systems, software and hardware architects with rich methodological guidance relying on ARCADIA, a comprehensive model-based engineering method:  Ensure engineering-wide collaboration by sharing the same reference architecture  Master the complexity of systems and architectures  Define the best optimal architectures through trade-off analysis  Master different engineering levels and traceability with automated transition and information refinement

Referring to the well-known three pillars of MBSE, we could say that ARCADIA provides both a modeling language and a modeling approach, and that Capella knows perfectly the language and the method. [START_REF] Normand | Model-driven systems engineering: SysML & the MDSysE approach at Thales[END_REF] through an iterative process involving operational architects from all the Thales business domains (transportation, avionics, space, radar, etc.).

It enforces an approach structured on successive engineering phases which establishes clear separation between needs (operational need analysis and system need analysis) and solutions (logical and physical architectures), in accordance with the IEEE 1220 standard.

ARCADIA recommends three mandatory interrelated activities, at the same level of importance:

 Need Analysis and Modeling  Architecture Building and Validation  Requirements Engineering Figure 2: ARCADIA three mandatory interrelated activities

Steps and activities of the method have been defined precisely and tested on real projects inside Thales for several years. To summarize briefly, the main messages are the following ones:

 Besides requirement engineering, drive an operational need analysis, describing final user expectations, usage conditions, and realistic IVVQ conditions, and a system need analysis, describing both the requested behavior of the system under study and its external interfaces  Structure the system and build a logical architecture, by searching for the best compromise between design drivers and non-functional constraints. Each viewpoint deals with a specific concern such as functional consistency, interfaces, performances, real time, safety, security, integration, reuse, cost, risk, schedule, and the ease of adaptation  Secure development and IVVQ through a physical architecture which deals with technical and development issues, favoring separation of concerns, efficient and safe component interaction

The ARCADIA Domain Specific Modeling Language (DSML)

The ARCADIA DSML is inspired by UML/SysML and NAF standards, and shares many concepts with these languages. But a Domain-Specific Modeling Language was preferred in order to ease appropriation by all stakeholders. ARCADIA is mostly based on functional analysis, and then allocation of the functions to components [START_REF] Voirin | Modelling languages for Functional Analysis put to the test of real life[END_REF].

The richness of the ARCADIA DSML is comparable to SysML [START_REF] Omg | Systems Modeling Language (SysML)[END_REF]

System Analysis

Dataflow diagrams are available in all Arcadia engineering levels. They represent information dependency between functions. These diagrams provide rich mechanisms to manage complexity: Computed simplified links between high-level Functions, categorization of Exchanges, etc. Functional Chains can be displayed as highlighted paths. Figure 9: System Functions / Operational Activities Matrix example

To summarize, the ARCADIA DSML covers all aspects of standard architecture modelling in each engineering phase including:

 Capability-driven model organization with scenarios and functional chains  Functional analysis and allocation to components and resources  Interfaces, bit-precise data models, behaviors, etc.

An overview of the ARCADIA main concepts through the engineering levels is given by the next figure.

Additional important concepts such as scenarios, states and modes, classes, capabilities, etc. are not shown but also available to the modeler.

The Capella Modeling Tool

The Capella workbench is an Eclipse application implementing the ARCADIA method providing both a Domain Specific Modeling Language (DSML) and a dedicated toolset.

A very interesting feature of Capella consists in an embedded methodology browser, reminding ARCADIA principles to the user and providing efficient methodological guidance. This activity browser provides a methodological access to all key activities of Capella, and thus to the creation of all main diagrams, level by level. It is the main entry point to a model and is both meant for beginners and power users.

Figure 11: Capella Methodological Activity Browser

As graphical representations of elements play a key role in communication, Capella relies on a consistent color scheme. In particular, all function-related elements are green, and all componentrelated elements are blue. This favors enhanced model readability for all stakeholders (architects, V&V practitioners, specialty engineers, managers, etc.).

Another very useful feature of Capella is the capability to navigate inside the model elements (independently of the diagrams) through a contextual semantic browser. More practical than the standard hierarchical view of the model, the semantic browser instantaneously provides the context of model elements trough meaningful queries. It is the preferred way to navigate in models and diagrams and to quickly analyze the relationships between model elements. As Capella was progressively specified and enhanced by using earlier versions of the tool on Thales internal projects, it contains a lot of very efficient features such as:

 Automatic computation of graphical simplifications (for instance information exchanges between lower-level functions can be automatically displayed on higher-level functions)  Automated contextual diagrams: content is automatically updated according to preselected model elements and predefined semantic rules  Filters: enable the user to show simplified views of a given diagram by selecting display options and automatically hiding / showing specific model elements Another advanced feature of Capella is the ability to create reusable model elements, either simple ones like types and classes, or complex ones, such as complete physical components with ports, functions, etc. A Replicable Elements Collection (REC, for Record) is a definition of an element which can be reused in multiple contexts / models. A Replica (RPL, for Replay) is an instantiation of a REC. RECs can be packaged in external libraries, which can be shared between several projects.

Figure 14: Capella Replicable Elements Mechanism

To widen the perspective, Capella does not work in isolation, but on the contrary fits into a wider engineering landscape, as many bridges can be developed to:

 Initialize Capella models from upstream engineering outputs (typically coming from Architecture Frameworks such as NAF)  Confront architecture models to specialty engineering tools (performance, safety, etc.)  Iteratively populate downstream engineering (subsystems, code generation, etc.)

SysML with a tool vs ARCADIA / Capella: elements of comparison

As we explained earlier, the ARCADIA DSML is inspired by UML/SysML and NAF standards, and shares many concepts with these languages. But a Domain-Specific Modeling Language was preferred in order to ease appropriation by all stakeholders, usually not familiar with general-purpose, generic languages such as UML or SysML. Previous experiments inside Thales proved that system engineers not coming from software were not at ease with the object-oriented concepts proposed by UML (and subsequently by SysML). So ARCADIA is mostly based on functional analysis, and then allocation of the functions to components. The vocabulary of the DSML has proven to be easily understood by system engineers. So, basically, ARCADIA was defined first in Thales, from the engineering problems encountered in real projects. Then came the need for a software tool enabling to create and manage ARCADIA models. The first experiments were done using existing UML tools such as Rational Software Modeler, Objecteering and Rhapsody, and defining UML profiles on top of them [START_REF] Normand | Model-driven systems engineering: SysML & the MDSysE approach at Thales[END_REF]. At the time of these first tries, the commercial tools were not easy at all to customize, and in particular it was difficult to remove unused commands or menus. So Thales people decided to create their own tool, dedicated to ARCADIA, encouraged by the emergence of enabling technologies based on the Eclipse platform. ARCADIA definition can really be seen as the specification of the Capella modeling tool.

If we try to compare with another possible solution, namely use a standard modeling language, such as SysML, and an existing commercial tool, such as Rhapsody, we can spot several important differences. SysML and Rhapsody (as the other commercial SysML tools) are based on UML, which is a disadvantage for system engineers who have not been exposed to object-oriented concepts (notions of operation, generalization / specialization in block diagrams, and even of object flows and object nodes in the activity diagram). These object-oriented origins are clearly an obstacle to adoption by system engineers who are not familiar with the world of software development [START_REF] Aracic | Select and deploy a conceptual modelling language. Some Keys[END_REF].

Another big problem is that SysML is only a language, and each company needs to elaborate an adapted modeling strategy. But then, how to teach the method to the modeling tool? Each commercial tool claims it offers an API to build specific add-ons, but this represents clearly a big amount of work. A prototype is provided by IBM with the Harmony for SE toolkit [7], but experiments in Thales proved that this toolkit is not more than a proof of concept and very difficult to use on real projects. For instance, the automated transitions between modeling phases were not iterative and incremental, as is the case with Capella, but merely one-shot.

Conclusion

The development of Capella (called Melody then) started in Thales in 2008 after a few years of experience with development of profile-based UML/SysML solutions. It is now widely deployed on operational projects in all Thales domains worldwide (defense, aerospace, space, transportation, identity and security, etc.).

Growing a community of interest and of users is a major objective of the Capella open sourcing initiative [1]. The goal is to favor the emergence of an ecosystem of organizations, including industries that would drive the Capella roadmap according to operational needs, service and technology suppliers that would develop their business around the solution, and academics that would pave the future of the engineering ecosystem.

The 3-years Clarity consortium [8] is dedicated to building this ecosystem. Since the start of the Clarity project, one year ago, such big industrial companies as Airbus, Airbus DS and Areva have already begun to experiment Capella internally. In the meantime, technology providers such as Artal, All4Tec, Scilab, have also begun to work in order to bridge Capella with simulation tools, safety engineering tools, etc. The rationale behind Clarity is that a strong adoption of this industrial solution will bring a major competitive advantage for industrial actors but also for technology and service providers.

Figure 1 :

 1 Figure 1: The three pillars of MBSE with ARCADIA/Capella

Figure 3 :

 3 Figure 3: ARCADIA engineering levels Of course, these messages are very similar to the recommendations of the INCOSE SE Handbook [3].

Figure 4 :

 4 Figure 4: Operational Architecture Blank diagram (OAB) example

Figure 5 :

 5 Figure 5: System Data Flow Blank diagram (SDFB) example Architecture diagrams are used in all Arcadia engineering phases. Their main goal is to show the allocation of Functions onto Components. Functional Chains can be displayed as highlighted paths. In System Need Analysis, these diagrams contain one box representing the System under study plus the Actors.

Figure 6 :

 6 Figure 6: System Architecture Blank diagram (SAB) example

Figure 7 :

 7 Figure 7: Logical Exchange Scenario diagram (LES) examplePhysical ArchitectureAt this level, we also use the preceding types of diagrams, but we will show different types once again. Tree diagrams represent breakdowns of either Functions or Components.

Figure 8 :

 8 Figure 8: Physical Functional Breakdown diagram (PFBD) example Matrix views are also available to display the different kinds of relationship between model elements. At each level, for example, two matrices are available showing the realization relationship to the upper level elements.

Figure 10 :

 10 Figure 10: Summary of ARCADIA main concepts

Figure 12 :

 12 Figure 12: Capella Contextual Semantic BrowserCapella can go further than traditional modeling tools thanks to its knowledge of ARCADIA. For instance, the tool will check that each model element at a given engineering level is realized by a similar element at the next engineering level.Capella organizes model checking rules in several categories: integrity, design, completeness, traceability, etc. Architects can define validation profiles focusing on different aspects. Whenever possible, quick fixes provide fact and automated solutions.

Figure 13 :

 13 Figure 13: Capella Model Checking results example

Figure 15 :

 15 Figure 15: Capella "Big Picture"

Figure 16 :

 16 Figure 16: MBSE 3 pillars implementation: a comparison


Maria Predari

Aurélien Esnard

Aurélien Esnard New

New graph partitioning techniques for load balancing of coupled simulation

R R e e s s u u l l t t s s M M e e t t h h o o d d s s

Graph Operators

Repartition

Projection

Extension

Partition

• Restriction: returns a subgraph of a graph induced to a set of edges.

• Partition: returns a balanced partition of a graph or subgraph with respect to an imbalance factor.

• Projection: returns a Nway partition on a graph similar to a Nway partition on another graph.

• Repartition: returns a Mway balanced partition using a former Nway partition on the same graph.

• Extension: returns a balanced partition using an existing partition on a subgraph of the graph.

Coupling intefaces

Which algorithm we use for the actual partitioning and why?

Nowadays, the most common approaches to solve the graph partitioning problem are based on the multilevel approach to compress the problem and on the recursive bisection heuristic to solve it on a smaller instance. The partition is then projected back to the original graph structure applying local refinement algorithms.

RB example in 8 parts

Why RB paradigm is not good for the copartitioning

I I n n t t r r o o d d u u c c t t i i o o n n

Graph Model: • vertex represents computation task • edge represents communication cost

In the field of scientific computing, the load balancing is a crucial issue which determines the performance of parallel applications. A very common approach to solve the loadbalancing problem is based on graph model. To equilibrate the load between N processors, one performs a (Nway) graph partitioning in N parts, each part being assigned to a given processor.

Objectives:

• balance computational load (nb vertices per part) • minimize communication costs (nb edgecut)

Applications that emerge nowadays in reallife problems often have more complex structure and may consist of numerous component simulations, coupled together representing different models.

Problem during coupling phase:

• computations highly imbalanced • bad data distribution among components Find a couplingaware partitioning that takes into account the coupling phase explicitly as a trade off to the partitioning during the regular phase.

Graph

Future Work

In the field of aeronautic propulsion the behavior of hot components is impacted by complex interactions between different physics such as turbulent combustion, radiation and heat conduction. To predict such thermal environments, coupling of these different heat transfer models is necessary.

Experiment3:

  initial fixed vertices (repartition scheme) Experiment1: no initial fixed vertices • 3 experimental cases • 2 implementations KGGGP_G, KGGGP_L (global and local) • comparison with SCOTCH, kMETIS, PaToH, Zoltan • evaluate partitioning quality, time performance Experiment2: initial fixed vertices (bubble scheme)2 "major" messages 1 "major" message, 4 "minor" messages Major messages are prefered since with one communication cost we exchange more information!Types of messages for components with different discretization alignmentExperimental results of copartitioning algorithms AWARE and PROJREPART• synthetically generated mesh structures • use of KGGGP implentation as partitioning algorithm • dependancies on the surface of mesh structures • comparison with NAIVE method • imbalance tolerence up to 5% of total weight

  " vertices should remain in place after the partitioning To describe our copartitioning algorithms, we use sequences of graph operators that may be implemented with any known partitioning algorithm, such as recursive bisection, spectral based partitioning, etc Example of coupled simulation with 2 components A, B (cubic structures) and coupling intersection on the surface. Each structure has different discretization (hexaedric and tetraedric). component model is partitioned independently • NAIVE is used as the stateoftheart for copartitioning • components are not aware their coupling interfaces Imbalance during coupling phase!

  Extension, Projection and Repartition operators need to handle vertices that must remain in place during the partitioning procedure (fixed vertices) RB based algorithm can not successfully respect both the inherent numbering constraint and the additional constraint of fixed vertices. This problem mainly appears when the part numbering of fixed vertices opposes to those of RB. Partition of square graph with fixed vertices using RB based algorithm (in 4 parts) Uncoarsening with kway refinements Results of KGGGP on the square graph with fixed vertices • extension of greedy bisection to k parts • at each step, selection of the best global displacement of all vertices to all parts • selection based on an edgecut minimization criterion • use of FMlike structures Implementation of KGGGP inside SCOTCH's multilevel framework: KGGGP sucessfully partition the graph with initial fixed vertices in 4 parts as opposed to RB! after refinements before refinements

  algorithm for graph partitioning KGGGP that handles initial fixed vertices • two new copartitioning algorithms, AWARE and PROJREPART for coupled simulations• good load balancing during the coupling phase for both methods at a slight increase of edgecut • in simple experiments the number of messages exchanged between components is minimized

  • 2 codes: fluid flow solver, heat transfer solver for solids • fluid solver: hexaedric discretization • heat solver:hexaedric and prism discretization • coupling in the surfaces • test copartitioning algorithms with real life coupled simulations • implement parallel version of KGGGP algorithm Example graph structure of fluid and heat solver with their coupling interfaces (red regions) Copartitioning overview Restriction PROJREPART: components are also aware of other component's coupling interface

Maria Predari 1 , Esnard Aurelien 2 1

  . Inria, University of Bordeaux, France (maria.predari@inria.fr), 2. Inria, University of Bordeaux, France (aurelien.esnard@inria.fr).

	N N e e w w g g r r a a p p h h p p a a r r t t i i t t i i o o n n i i n n g g t t e e c c h h n n i i q q u u e e s s f f o o r r l l o o a a d d
	b b a a l l a a n n c c i i n n g g o o f f c c o o u u p p l l e e d d s s i i m m u u l l a a t t i i o o n n