# An Open-Source Method for Model-Based Development of Embedded Systems: Experience Report from a CubeSat Student Project

Giorgio Ciacchella, Alzahraa Mohammad, Szymon Zurawski

## ► To cite this version:

Giorgio Ciacchella, Alzahraa Mohammad, Szymon Zurawski. An Open-Source Method for Model-Based Development of Embedded Systems: Experience Report from a CubeSat Student Project. 74th International Astronautical Congress – IAC 2023, IAF – International Astronautical Federation, Oct 2023, Baku, Azerbaijan. hal-04564986

HAL Id: hal-04564986

https://hal.science/hal-04564986

Submitted on 3 May 2024

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# An Open-Source Method for Model-Based Development of Embedded Systems: Experience Report from a CubeSat Student Project

Giorgio Ciacchella, Alzahraa Mohammad, Szymon Zurawski

## ► To cite this version:

Giorgio Ciacchella, Alzahraa Mohammad, Szymon Zurawski. An Open-Source Method for Model-Based Development of Embedded Systems: Experience Report from a CubeSat Student Project. 74th International Astronautical Congress – IAC 2023, IAF – International Astronautical Federation, Oct 2023, Baku, Azerbaijan. [hal-04564986](https://hal.science/hal-04564986v1)

HAL Id: hal-04564986

https://hal.science/hal-04564986v1

Submitted on 3 May 2024

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# An Open-Source Method for Model-Based Development of Embedded Systems: Experience Report from a CubeSat Student Project

Giorgio Ciacchella¹*, Alzahraa Mohammad¹, and Szymon Zurawski¹

¹GU Orbit, University of Glasgow, G12 8QQ Scotland, United Kingdom

*Corresponding author: giorgio.ciacchella@protonmail.com

## Abstract

As space engineering projects become more complex, MBSE (Model-Based Systems Engineering) practices have been gaining popularity to enforce consistency throughout the multiple facets of an integrated system. However, most such approaches are often confined to the top levels of systems engineering, leaving tooling gaps between the design and the implementation, integration, and testing phases, which can be the source of inconsistencies. Exceptions are few and typically proprietary, leaving limited freedom for customisation.

Building on previous work from N7 Space, this paper presents a comprehensive, V-shaped methodology integrating Capella and TASTE workflows into an end-to-end model-centric process for developing embedded software within complex systems. Capella is an opinionated MBSE tool, created by Thales to enforce the Arcadia framework, which structures the design process on multiple levels: Operational, System, Logical, and Physical; TASTE is a model-driven software development toolchain targeting heterogeneous embedded systems, which centres its workflow around Data, Interface, and Deployment views. Both tools are Free and Open-Source Software.

This methodology exploits the parallels between entities in the two tools to rigorously link the design and implementation phases, enabling verification and validation activities based on simple diagram comparisons. Capella is first used to reason about the operational scenarios required to accomplish the chosen mission, then to consistently define the architectures of the system, its logical subsystems, and the physical components. The final products of the design stage are rigorously transitioned to TASTE, exploiting its SDL (Specification and Description Language) support to develop embedded software faithfully to the model. Finally, TASTE's integration with model-checking frameworks enables formal verification to be carried out on selected software requirements, whereas MSC (Message Sequence Chart) generation enables validation of its structure against the designs at multiple levels.

To illustrate the process, we report the resulting software architectures and their integration into the broader system of a student CubeSat project, where this method is currently being adopted to develop and test both flight and ground software, including TTMC, housekeeping, and mission functionalities. While we highlight its particular benefits to student projects, the method's exclusive reliance on open-source tools makes it easily adaptable to more complex use cases, and widely accessible regardless of financial and computational means.

**Keywords** — MBSE, Capella, TASTE

Capella diagrams are referred to by their square-bracket identifiers:

[SFBD] System Function Breakdown

[SDFB] System Function Data Flow

[CSA] Contextual System Actors

[SAB] System Architecture

[LFBD] Logical Function Breakdown

## Notation

Throughout this paper, terms referring to specific entities in Capella and TASTE are typographically marked, respectively *Italicised* and *Underlined*.
# An Open-Source Method for Model-Based Development of Embedded Systems: Experience Report from a CubeSat Student Project

Giorgio Ciacchella¹*, Alzahraa Mohammad¹, and Szymon Zurawski¹

¹GU Orbit, University of Glasgow, G12 8QQ Scotland, United Kingdom

*Corresponding author: giorgio.ciacchella@protonmail.com

## Abstract

As space engineering projects become more complex, MBSE (Model-Based Systems Engineering) practices have been gaining popularity to enforce consistency throughout the multiple facets of an integrated system. However, most such approaches are often confined to the top levels of systems engineering, leaving tooling gaps between the design and the implementation, integration, and testing phases, which can be the source of inconsistencies. Exceptions are few and typically proprietary, leaving limited freedom for customisation.

Building on previous work from N7 Space, this paper presents a comprehensive, V-shaped methodology integrating Capella and TASTE workflows into an end-to-end model-centric process for developing embedded software within complex systems. Capella is an opinionated MBSE tool, created by Thales to enforce the Arcadia framework, which structures the design process on multiple levels: Operational, System, Logical, and Physical; TASTE is a model-driven software development toolchain targeting heterogeneous embedded systems, which centres its workflow around Data, Interface, and Deployment views. Both tools are Free and Open-Source Software.

This methodology exploits the parallels between entities in the two tools to rigorously link the design and implementation phases, enabling verification and validation activities based on simple diagram comparisons. Capella is first used to reason about the operational scenarios required to accomplish the chosen mission, then to consistently define the architectures of the system, its logical subsystems, and the physical components. The final products of the design stage are rigorously transitioned to TASTE, exploiting its SDL (Specification and Description Language) support to develop embedded software faithfully to the model. Finally, TASTE's integration with model-checking frameworks enables formal verification to be carried out on selected software requirements, whereas MSC (Message Sequence Chart) generation enables validation of its structure against the designs at multiple levels.

To illustrate the process, we report the resulting software architectures and their integration into the broader system of a student CubeSat project, where this method is currently being adopted to develop and test both flight and ground software, including TTMC, housekeeping, and mission functionalities. While we highlight its particular benefits to student projects, the method's exclusive reliance on open-source tools makes it easily adaptable to more complex use cases, and widely accessible regardless of financial and computational means.

**Keywords** — MBSE, Capella, TASTE

Capella diagrams are referred to by their square-bracket identifiers:

[SFBD] System Function Breakdown

[SDFB] System Function Data Flow

[CSA] Contextual System Actors

[SAB] System Architecture

[LFBD] Logical Function Breakdown

## Notation

Throughout this paper, terms referring to specific entities in Capella and TASTE are typographically marked, respectively *Italicised* and *Underlined*.
[LDFB] Logical Function Data Flow

[LCBD] Logical Component Breakdown

[LAB] Logical Architecture

[PFBD] Physical Function Breakdown

[PDFB] Physical Function Data Flow

[PCBD] Physical Component Breakdown

[PAB] Physical Architecture

[MSM] Mode and State Machine

[ES] Exchange Scenario

[CII] Contextual Internal Interfaces

[CDB] Class (Data Breakdown)

Additionally, the following acronyms are adopted:

FC Functional Chain

FE Functional Exchange

CE Component Exchange

PC Physical Component

FSM Finite State Machine

SDL Specification and Description Language [1]

MSC Message Sequence Chart [2]

E2E End-to-End Data Flow

# 1 Introduction

In the three decades since its inception [3], Model-Based Systems Engineering (MBSE) has seen increasing adoption [4], mainly in the aerospace industry [5], [6]. However, this has not happened without problems: especially in the embedded systems domain, current shortcomings in tooling and methodology have been identified as significant hindrances to migration from document-based approaches [7]. On the other hand, research has highlighted particular interest in adopting different tools for cross-domain and domain-specific modelling [8], with common workflows and open interfaces [9].

In this context, Capella and TASTE appear as relevant resources. Capella is a tool for general-purpose model-based systems engineering, originally developed by Thales and maintained by the Eclipse Foundation [10]. It is designed to implement and enforce the Arcadia framework for the specification of complex cyber-physical systems [11]–[13]. TASTE is a set of tools for model-based software development targeting heterogeneous embedded systems, developed by the European Space Agency and industry partners

[14]–[17]. While it adopts the specialised representation language AADL, some of its graphical elements were directly inspired by Arcadia/Capella elements<fnref n="1" />.

Both tools are open source, and integration between them was first proposed in [18] as a bridge plugin automating the generation of TASTE model files from a Capella model. This seminal work adopts a mapping which is mostly equivalent to the one we propose; however, it only bridges physical-level modelling in Capella to architectural specification activities in TASTE. We set out to extend this bridge in both breadth and depth, to include Capella modelling and TASTE testing at higher levels of abstraction, along with implementation and verification of individual software components. Conversely, we placed automation beyond the scope of our work – though it is an interesting option for future developments.

The remainder of this paper is structured as follows: sections 2 and 3 outline the theoretical foundations underpinning the workflow and mappings of the proposed method, section 4 details its steps throughout design, implementation, and testing, sections 5 and 6 discuss the process and results of applying it to case-study functionalities, section 7 proposes options to overcome notable limitations of the method itself and the tools it relies on, and section 8 draws the conclusions.

# 2 Capella and TASTE Workflows

This research towards bridging Capella and TASTE considers their stand-alone workflows. Their steps and order are important aspects, as they constrain the scope and focus of comprehensive processes.

The Arcadia methodology implemented by Capella prescribes five consecutive levels: Operational Analysis, System Analysis, Logical Architecture, Physical Architecture, and End-Product Breakdown Structure (EPBS) [12], [13]. However, the two extremes do not model the design of the system itself: Operational Analysis models the environment around the system; EPBS models off-the-shelf parts realising the system. Therefore, as we study system designs and bespoke implementations, only the central three levels are relevant. Throughout these, the system is broken down into smaller, more transparent entities: in System Analysis, it is a simple black box, Logical Architecture allows some segmentation to be resolved in the grey box, and Physical Architecture shows all software and hardware units at the highest granularity.

<footnote n="1">¹Maxime Perrotin, private correspondence.</footnote>
[LDFB] Logical Function Data Flow

[LCBD] Logical Component Breakdown

[LAB] Logical Architecture

[PFBD] Physical Function Breakdown

[PDFB] Physical Function Data Flow

[PCBD] Physical Component Breakdown

[PAB] Physical Architecture

[MSM] Mode and State Machine

[ES] Exchange Scenario

[CII] Contextual Internal Interfaces

[CDB] Class (Data Breakdown)

Additionally, the following acronyms are adopted:

FC Functional Chain

FE Functional Exchange

CE Component Exchange

PC Physical Component

FSM Finite State Machine

SDL Specification and Description Language [1]

MSC Message Sequence Chart [2]

E2E End-to-End Data Flow

# 1 Introduction

In the three decades since its inception [3], Model-Based Systems Engineering (MBSE) has seen increasing adoption [4], mainly in the aerospace industry [5], [6]. However, this has not happened without problems: especially in the embedded systems domain, current shortcomings in tooling and methodology have been identified as significant hindrances to migration from document-based approaches [7]. On the other hand, research has highlighted particular interest in adopting different tools for cross-domain and domain-specific modelling [8], with common workflows and open interfaces [9].

In this context, Capella and TASTE appear as relevant resources. Capella is a tool for general-purpose model-based systems engineering, originally developed by Thales and maintained by the Eclipse Foundation [10]. It is designed to implement and enforce the Arcadia framework for the specification of complex cyber-physical systems [11]–[13]. TASTE is a set of tools for model-based software development targeting heterogeneous embedded systems, developed by the European Space Agency and industry partners

[14]–[17]. While it adopts the specialised representation language AADL, some of its graphical elements were directly inspired by Arcadia/Capella elements<fnref n="1" />.

Both tools are open source, and integration between them was first proposed in [18] as a bridge plugin automating the generation of TASTE model files from a Capella model. This seminal work adopts a mapping which is mostly equivalent to the one we propose; however, it only bridges physical-level modelling in Capella to architectural specification activities in TASTE. We set out to extend this bridge in both breadth and depth, to include Capella modelling and TASTE testing at higher levels of abstraction, along with implementation and verification of individual software components. Conversely, we placed automation beyond the scope of our work – though it is an interesting option for future developments.

The remainder of this paper is structured as follows: sections 2 and 3 outline the theoretical foundations underpinning the workflow and mappings of the proposed method, section 4 details its steps throughout design, implementation, and testing, sections 5 and 6 discuss the process and results of applying it to case-study functionalities, section 7 proposes options to overcome notable limitations of the method itself and the tools it relies on, and section 8 draws the conclusions.

# 2 Capella and TASTE Workflows

This research towards bridging Capella and TASTE considers their stand-alone workflows. Their steps and order are important aspects, as they constrain the scope and focus of comprehensive processes.

The Arcadia methodology implemented by Capella prescribes five consecutive levels: Operational Analysis, System Analysis, Logical Architecture, Physical Architecture, and End-Product Breakdown Structure (EPBS) [12], [13]. However, the two extremes do not model the design of the system itself: Operational Analysis models the environment around the system; EPBS models off-the-shelf parts realising the system. Therefore, as we study system designs and bespoke implementations, only the central three levels are relevant. Throughout these, the system is broken down into smaller, more transparent entities: in System Analysis, it is a simple black box, Logical Architecture allows some segmentation to be resolved in the grey box, and Physical Architecture shows all software and hardware units at the highest granularity.

<footnote n="1">¹Maxime Perrotin, private correspondence.</footnote>
TASTE's workflow mainly comprises three consecutive views: Data, Interface, and Deployment. The Data View defines the data types to be used throughout the system, the Interface View specifies the interfaces among the software components, and the Deployment View allocates them to the appropriate hardware nodes and links. The logic for each software component is developed separately, depending on the language of choice for its implementation.

# 3 Capella-TASTE Mappings

Any research towards bridging Capella and TASTE must consider the seminal work carried out by Kurowski et al. in [18]. The mappings of entities and relationships are a critical aspect, as they set the scope and semantics of supported models.

Up to a certain point, mappings are mostly made intuitive by the intrinsic semantics of each tool. For example, those involved in the allocation of software functions to hardware nodes are conceptually identical between [18] and this paper: software must run on hardware, software interface calls between functions running on different nodes must be mediated by a hardware link, etc. In this regard, the only difference we propose is an extension to higher levels of abstraction: in addition to bottom-level entities, we include nesting and realisation relationships to enable reasoning about subsystems, and even the entire system, similarly to components.

However, at some level of granularity, mappings become quite arbitrary, depending on the specific scope and semantics to target within the limitations of both tools. Most notably, in order to enable a finer representation of logic, we do not equate each bottom-level Capella *Function* to an entire TASTE *Function*, but rather only one step in its implementation.

The full proposed mappings of entities and relationships between Capella's bottom level and TASTE are presented in tables 1 and 2. For brevity, their extensions to higher levels are omitted; however, they can be derived by following realisation relationships throughout our method.

It must also be noted that [18] focused on the development of a Capella plugin to automate the generation of TASTE model files. Therefore, rather than only concerning semantics, its mappings targeted specific objects in TASTE's architecture description language. In contrast, the mappings we propose are agnostic of underlying representations, and instead use diagrams to translate the model between the two tools, as presented in tables 3 and 4.

# 4 Method Walk-Through

Figure 1 presents the main workflow schematic of the proposed method, complying with the recommended workflows for both Capella and TASTE as outlined in section 2. Note the “V” shape formed by its steps.

## 4.1 Design Phase

This phase is performed entirely in Capella through its three main levels: System Analysis, Logical Architecture, and Physical Architecture. While beyond the scope of this paper, we recommend starting from the Operational Analysis level to obtain a justifiable problem statement and mission objective [12], [13].

As illustrated in fig. 1, the workflows for all design levels mainly repeat the same core semantic pattern: breaking down higher-level *Functions* ([*FBD]/[*DFB]), breaking down higher-level *Components* ([*CBD]), allocating the former to the latter ([*AB]), defining component *Modes* and allocating *Functions* and *FEs* to *Modes* and *Transitions* ([MSM]) respectively, and finally representing all this information in a sequence-style diagram ([ES]). These workflows should be driven by realising higher-level *FCs* at the current level [19]. Achieving this realisation is a core consistency principle of the Arcadia method enforced by Capella; moreover, in the process we propose, it is particularly important to adopt it as a design driver because of its implications in the verification and validation phases (section 4.3).

### 4.1.1 System Level

**Function Breakdown/Data Flow** At the System Analysis level, we begin by defining the high-level *Functions* to be performed by the *System* as a black box. This is done in a [SFBD] diagram. We also specify the *FEs* between the different *Functions* involved in accomplishing any given *System Capability*, and collate them in *FCs* that embody the *Capability* realisations. This, along with optionally their breakdown, is done in a [SDFB] diagram. Also optionally, if this level was preceded by Operational Analysis, [SDFB] diagrams can highlight *FC* realisations: this is done by laying out the leaf *System Functions* involved in a *System FC*, and grouping them under their parent *System Functions* which realise the *Operational Activities* involved in the original *Operational FC*.

**Actor Breakdown** Second, we define the *Actors* that exist outwith the *System* but participate in its activities – at this level, because the *System* is a black
TASTE's workflow mainly comprises three consecutive views: Data, Interface, and Deployment. The Data View defines the data types to be used throughout the system, the Interface View specifies the interfaces among the software components, and the Deployment View allocates them to the appropriate hardware nodes and links. The logic for each software component is developed separately, depending on the language of choice for its implementation.

# 3 Capella-TASTE Mappings

Any research towards bridging Capella and TASTE must consider the seminal work carried out by Kurowski et al. in [18]. The mappings of entities and relationships are a critical aspect, as they set the scope and semantics of supported models.

Up to a certain point, mappings are mostly made intuitive by the intrinsic semantics of each tool. For example, those involved in the allocation of software functions to hardware nodes are conceptually identical between [18] and this paper: software must run on hardware, software interface calls between functions running on different nodes must be mediated by a hardware link, etc. In this regard, the only difference we propose is an extension to higher levels of abstraction: in addition to bottom-level entities, we include nesting and realisation relationships to enable reasoning about subsystems, and even the entire system, similarly to components.

However, at some level of granularity, mappings become quite arbitrary, depending on the specific scope and semantics to target within the limitations of both tools. Most notably, in order to enable a finer representation of logic, we do not equate each bottom-level Capella *Function* to an entire TASTE *Function*, but rather only one step in its implementation.

The full proposed mappings of entities and relationships between Capella's bottom level and TASTE are presented in tables 1 and 2. For brevity, their extensions to higher levels are omitted; however, they can be derived by following realisation relationships throughout our method.

It must also be noted that [18] focused on the development of a Capella plugin to automate the generation of TASTE model files. Therefore, rather than only concerning semantics, its mappings targeted specific objects in TASTE's architecture description language. In contrast, the mappings we propose are agnostic of underlying representations, and instead use diagrams to translate the model between the two tools, as presented in tables 3 and 4.

# 4 Method Walk-Through

Figure 1 presents the main workflow schematic of the proposed method, complying with the recommended workflows for both Capella and TASTE as outlined in section 2. Note the “V” shape formed by its steps.

## 4.1 Design Phase

This phase is performed entirely in Capella through its three main levels: System Analysis, Logical Architecture, and Physical Architecture. While beyond the scope of this paper, we recommend starting from the Operational Analysis level to obtain a justifiable problem statement and mission objective [12], [13].

As illustrated in fig. 1, the workflows for all design levels mainly repeat the same core semantic pattern: breaking down higher-level *Functions* ([*FBD]/[*DFB]), breaking down higher-level *Components* ([*CBD]), allocating the former to the latter ([*AB]), defining component *Modes* and allocating *Functions* and *FEs* to *Modes* and *Transitions* ([MSM]) respectively, and finally representing all this information in a sequence-style diagram ([ES]). These workflows should be driven by realising higher-level *FCs* at the current level [19]. Achieving this realisation is a core consistency principle of the Arcadia method enforced by Capella; moreover, in the process we propose, it is particularly important to adopt it as a design driver because of its implications in the verification and validation phases (section 4.3).

### 4.1.1 System Level

**Function Breakdown/Data Flow** At the System Analysis level, we begin by defining the high-level *Functions* to be performed by the *System* as a black box. This is done in a [SFBD] diagram. We also specify the *FEs* between the different *Functions* involved in accomplishing any given *System Capability*, and collate them in *FCs* that embody the *Capability* realisations. This, along with optionally their breakdown, is done in a [SDFB] diagram. Also optionally, if this level was preceded by Operational Analysis, [SDFB] diagrams can highlight *FC* realisations: this is done by laying out the leaf *System Functions* involved in a *System FC*, and grouping them under their parent *System Functions* which realise the *Operational Activities* involved in the original *Operational FC*.

**Actor Breakdown** Second, we define the *Actors* that exist outwith the *System* but participate in its activities – at this level, because the *System* is a black
<table><caption>Table 1: Mapping of entities between Capella (Physical level) and TASTE.</caption><thead><tr><th>Capella</th><th>TASTE</th></tr></thead><tbody><tr><td>Node PC: Root / Fork / Leaf</td><td>(HW Board) / (HW Module) / Device</td></tr><tr><td>Behaviour PC: Root / Fork / Leaf</td><td>Partition / Function Group / Function</td></tr><tr><td>Function</td><td>Function implementation step</td></tr><tr><td>State of Leaf Behaviour PC</td><td>SDL State</td></tr><tr><td>Transition of Leaf Behaviour PC</td><td>SDL Transition</td></tr><tr><td>Physical Port</td><td>Device Port</td></tr><tr><td>Physical Link</td><td>Device Link</td></tr><tr><td>Flow Port: In / Out</td><td>Interface endpoint: Provided / Required</td></tr><tr><td>Interface</td><td>Interface</td></tr><tr><td>Exchange Item</td><td>Interface parameter</td></tr><tr><td>Class</td><td>ASN.1 SEQUENCE type</td></tr><tr><td>Data Type</td><td>Primitive ASN.1 type</td></tr></tbody></table>

<table><caption>Table 2: Mapping of relationships between Capella (Physical level) and TASTE.</caption><thead><tr><th>Capella</th><th>TASTE</th></tr></thead><tbody><tr><td>Root <i>Behaviour PC</i> to <i>Node PC</i></td><td>Deployment of <i>Partition</i> to <i>Device</i></td></tr><tr><td>Fork/Leaf <i>Behaviour PC</i> to Root <i>Behaviour PC</i></td><td>Deployment of <i>Function</i> / <i>Function Group</i> to <i>Partition</i></td></tr><tr><td>Fork/Leaf <i>Behaviour PC</i> to Fork <i>Behaviour PC</i></td><td><i>Function</i> nesting</td></tr><tr><td><i>Flow Port</i> to <i>Physical Port</i></td><td>Deployment of <i>Interface</i> to <i>Device Link</i></td></tr><tr><td><i>Function</i> to Leaf <i>Behaviour PC</i></td><td>Function implementation steps (informal)</td></tr><tr><td><i>Function</i> to FSM <i>Transition</i></td><td>SDL Function implementation steps (formal)</td></tr><tr><td><i>Exchange Item</i> to <i>Interface</i></td><td>Assignment of <i>Parameters</i> to <i>Interface</i></td></tr><tr><td><i>Class</i> or <i>Data Type</i> to <i>Exchange Item</i></td><td><i>Parameter</i> typing</td></tr><tr><td>Child <i>Class</i> to Parent <i>Class</i></td><td>ASN.1 SEQUENCE nesting</td></tr><tr><td><i>Data Type</i> to <i>Class</i></td><td>ASN.1 SEQUENCE field membership</td></tr></tbody></table>

<table><caption>Table 3: Mapping of implementation diagrams between Capella and TASTE.</caption><thead><tr><th>Capella</th><th>TASTE</th></tr></thead><tbody><tr><td>Physical [CDB]</td><td>Data View</td></tr><tr><td>Physical [CII]</td><td>Interface View</td></tr><tr><td>[PAB] PCs View</td><td>Deployment View</td></tr><tr><td>Physical [MSM]</td><td>SDL Implementation</td></tr></tbody></table>

box, no other kind of *Component* is envisioned. This is done in a [CSA] diagram.

**Architecture** Third, we allocate the *Functions* to either the *System* or an *Actor*. This is done in a [SAB] diagram. We recommend starting from a complete view of all *Functions* and *Actors*, and cloning it into one view per *Capability*, only representing the subset of *Functions* and *Actors* involved in the *FCs* that realise it. This is generally helpful to improve

<table><caption>Table 4: Mapping of verification and validation diagrams between Capella and TASTE.</caption><thead><tr><th>Capella</th><th>TASTE</th></tr></thead><tbody><tr><td>Physical [MSM]</td><td>SDL State Chart View</td></tr><tr><td>Physical [ES]</td><td>Simulation MSC</td></tr><tr><td>[PAB] FC View</td><td>Simulation E2E</td></tr><tr><td>Logical [ES]</td><td>Execution Trace MSC</td></tr><tr><td>[LAB] FC View</td><td>Execution Trace E2E</td></tr><tr><td>System [ES]</td><td>Live Execution MSC</td></tr><tr><td>[SAB] FC View</td><td>Live Execution E2E</td></tr></tbody></table>

readability, but particularly important in the proposed method: as illustrated in fig. 1 and detailed in section 4.3.3, these subset views will be involved in the acceptance-level verification activities at the end of the engineering lifecycle.

All three previous steps can be performed con-
<table><caption>Table 1: Mapping of entities between Capella (Physical level) and TASTE.</caption><thead><tr><th>Capella</th><th>TASTE</th></tr></thead><tbody><tr><td>Node PC: Root / Fork / Leaf</td><td>(HW Board) / (HW Module) / Device</td></tr><tr><td>Behaviour PC: Root / Fork / Leaf</td><td>Partition / Function Group / Function</td></tr><tr><td>Function</td><td>Function implementation step</td></tr><tr><td>State of Leaf Behaviour PC</td><td>SDL State</td></tr><tr><td>Transition of Leaf Behaviour PC</td><td>SDL Transition</td></tr><tr><td>Physical Port</td><td>Device Port</td></tr><tr><td>Physical Link</td><td>Device Link</td></tr><tr><td>Flow Port: In / Out</td><td>Interface endpoint: Provided / Required</td></tr><tr><td>Interface</td><td>Interface</td></tr><tr><td>Exchange Item</td><td>Interface parameter</td></tr><tr><td>Class</td><td>ASN.1 SEQUENCE type</td></tr><tr><td>Data Type</td><td>Primitive ASN.1 type</td></tr></tbody></table>

<table><caption>Table 2: Mapping of relationships between Capella (Physical level) and TASTE.</caption><thead><tr><th>Capella</th><th>TASTE</th></tr></thead><tbody><tr><td>Root <i>Behaviour PC</i> to <i>Node PC</i></td><td>Deployment of <i>Partition</i> to <i>Device</i></td></tr><tr><td>Fork/Leaf <i>Behaviour PC</i> to Root <i>Behaviour PC</i></td><td>Deployment of <i>Function</i> / <i>Function Group</i> to <i>Partition</i></td></tr><tr><td>Fork/Leaf <i>Behaviour PC</i> to Fork <i>Behaviour PC</i></td><td><i>Function</i> nesting</td></tr><tr><td><i>Flow Port</i> to <i>Physical Port</i></td><td>Deployment of <i>Interface</i> to <i>Device Link</i></td></tr><tr><td><i>Function</i> to Leaf <i>Behaviour PC</i></td><td>Function implementation steps (informal)</td></tr><tr><td><i>Function</i> to FSM <i>Transition</i></td><td>SDL Function implementation steps (formal)</td></tr><tr><td><i>Exchange Item</i> to <i>Interface</i></td><td>Assignment of <i>Parameters</i> to <i>Interface</i></td></tr><tr><td><i>Class</i> or <i>Data Type</i> to <i>Exchange Item</i></td><td><i>Parameter</i> typing</td></tr><tr><td>Child <i>Class</i> to Parent <i>Class</i></td><td>ASN.1 SEQUENCE nesting</td></tr><tr><td><i>Data Type</i> to <i>Class</i></td><td>ASN.1 SEQUENCE field membership</td></tr></tbody></table>

<table><caption>Table 3: Mapping of implementation diagrams between Capella and TASTE.</caption><thead><tr><th>Capella</th><th>TASTE</th></tr></thead><tbody><tr><td>Physical [CDB]</td><td>Data View</td></tr><tr><td>Physical [CII]</td><td>Interface View</td></tr><tr><td>[PAB] PCs View</td><td>Deployment View</td></tr><tr><td>Physical [MSM]</td><td>SDL Implementation</td></tr></tbody></table>

box, no other kind of *Component* is envisioned. This is done in a [CSA] diagram.

**Architecture** Third, we allocate the *Functions* to either the *System* or an *Actor*. This is done in a [SAB] diagram. We recommend starting from a complete view of all *Functions* and *Actors*, and cloning it into one view per *Capability*, only representing the subset of *Functions* and *Actors* involved in the *FCs* that realise it. This is generally helpful to improve

<table><caption>Table 4: Mapping of verification and validation diagrams between Capella and TASTE.</caption><thead><tr><th>Capella</th><th>TASTE</th></tr></thead><tbody><tr><td>Physical [MSM]</td><td>SDL State Chart View</td></tr><tr><td>Physical [ES]</td><td>Simulation MSC</td></tr><tr><td>[PAB] FC View</td><td>Simulation E2E</td></tr><tr><td>Logical [ES]</td><td>Execution Trace MSC</td></tr><tr><td>[LAB] FC View</td><td>Execution Trace E2E</td></tr><tr><td>System [ES]</td><td>Live Execution MSC</td></tr><tr><td>[SAB] FC View</td><td>Live Execution E2E</td></tr></tbody></table>

readability, but particularly important in the proposed method: as illustrated in fig. 1 and detailed in section 4.3.3, these subset views will be involved in the acceptance-level verification activities at the end of the engineering lifecycle.

All three previous steps can be performed con-
<figure><img src="image_2.png" /><figcaption>Figure 1: V-shaped workflow of the proposed method.</figcaption></figure>

currently in [SAB] diagrams. Indeed, as with most MBSE activities, semantic advancements to the model can be performed as separate steps in separate diagrams only to a limited extent: as guidance for this level, the *Functions* specified should be elicited by being part of a single *FE* that crosses a *System* – *Actor* boundary, or by representing the *System's* action(s) between crossing said boundaries.

**Finite State Machine** Fourth, we model the behaviour of the *System* as an FSM by specifying the *Modes* it can assume, and connecting them through appropriate *Transitions*. At this level, we have found that allocating the *Functions* performed by the *System* to *Modes*, rather than to *Transitions*, results in a more intuitive semantic model. As this approach leaves *Transitions* free to allocate *FEs*, it represents the *System* continuously executing high-level tasks for the entirety of its permanence in a given *Mode*; whenever a task or set of tasks is exhausted, a *Transition* is triggered to bring the *System* to its next *Mode*. Thanks to the relatively informal status of FSMs within Capella, a *Transition-based Function* allocation scheme can be adopted in subsequent levels (and will, in section 4.1.3) without any severe inconsistency, i.e. without introducing any error flagged by Capella's model validation routine. Both these actions are done in a [MSM] diagram. This FSM-based modelling approach holds particular relevance in the proposed method: as elaborated in section 4.3.3, this representation can inform requirements for acceptance-level verification activities at the end of the engineering lifecycle.

**Scenario** Finally, we represent all elements developed so far in a sequence format, which can also convey additional information such as informal timing, loops, branching, and comments. This is done in [ES] diagrams. Again, as with the Architectures, we recommend creating a separate [ES] diagram for each *System Capability* – especially since, unlike Architectures, [ES] diagrams are formally linked to *System Capabilities*. Each diagram should reproduce the *FC(s)* which realise the *Capability*, and state the *Mode* assumed by the *System* whenever it changes. Laying out the diagram this way creates a direct equivalence between Capella's [ES] and TASTE's MSC, enabling their comparison as a verification activity as detailed in section 4.3.3.

### 4.1.2 Logical Level

**System to Logical Transition** We begin the Logical Architecture level by realising the *System Capabilities*, *System Functions*, and *System Actors* into *Logical Capabilities*, *Logical Functions*, and *Logical Actors*, which can conveniently be done through Capella's automatic transition features.

**Function Breakdown/Data Flow** Next, similarly to the previous level, we break down the high-level *Functions* (those inherited from the System
<figure><img src="image_2.png" /><figcaption>Figure 1: V-shaped workflow of the proposed method.</figcaption></figure>

currently in [SAB] diagrams. Indeed, as with most MBSE activities, semantic advancements to the model can be performed as separate steps in separate diagrams only to a limited extent: as guidance for this level, the *Functions* specified should be elicited by being part of a single *FE* that crosses a *System* – *Actor* boundary, or by representing the *System's* action(s) between crossing said boundaries.

**Finite State Machine** Fourth, we model the behaviour of the *System* as an FSM by specifying the *Modes* it can assume, and connecting them through appropriate *Transitions*. At this level, we have found that allocating the *Functions* performed by the *System* to *Modes*, rather than to *Transitions*, results in a more intuitive semantic model. As this approach leaves *Transitions* free to allocate *FEs*, it represents the *System* continuously executing high-level tasks for the entirety of its permanence in a given *Mode*; whenever a task or set of tasks is exhausted, a *Transition* is triggered to bring the *System* to its next *Mode*. Thanks to the relatively informal status of FSMs within Capella, a *Transition-based Function* allocation scheme can be adopted in subsequent levels (and will, in section 4.1.3) without any severe inconsistency, i.e. without introducing any error flagged by Capella's model validation routine. Both these actions are done in a [MSM] diagram. This FSM-based modelling approach holds particular relevance in the proposed method: as elaborated in section 4.3.3, this representation can inform requirements for acceptance-level verification activities at the end of the engineering lifecycle.

**Scenario** Finally, we represent all elements developed so far in a sequence format, which can also convey additional information such as informal timing, loops, branching, and comments. This is done in [ES] diagrams. Again, as with the Architectures, we recommend creating a separate [ES] diagram for each *System Capability* – especially since, unlike Architectures, [ES] diagrams are formally linked to *System Capabilities*. Each diagram should reproduce the *FC(s)* which realise the *Capability*, and state the *Mode* assumed by the *System* whenever it changes. Laying out the diagram this way creates a direct equivalence between Capella's [ES] and TASTE's MSC, enabling their comparison as a verification activity as detailed in section 4.3.3.

### 4.1.2 Logical Level

**System to Logical Transition** We begin the Logical Architecture level by realising the *System Capabilities*, *System Functions*, and *System Actors* into *Logical Capabilities*, *Logical Functions*, and *Logical Actors*, which can conveniently be done through Capella's automatic transition features.

**Function Breakdown/Data Flow** Next, similarly to the previous level, we break down the high-level *Functions* (those inherited from the System
level) into *Functions* appropriate for allocation to subsystems. Again, this is done in a [LFBD] diagram. Particular care should be paid to ensuring the new leaf *Functions* are suitable recipients of new *FEs* which shall realise the previously-specified *FCs* from the System to the Logical level. As this is a semantically complex problem, we suggest performing both the breakdown of *Functions* and the definition of *FEs* in a [LDFB] diagram, which is capable of representing both relationships at once. To do so, we populate the diagram with an existing *FC* inherited from the System level, and all the *Functions* and *FEs* it involves. We then break down the involved *Functions* by creating new *Functions* within them, which will create a semantic parenthood relationship, and define new *FEs* between them to result in the same overall path of the *FC* to realise. This new set of *FEs* constitutes the new *Logical FC*, which we create and configure to formally realise the original *System FC* through the appropriate Capella property.

**Component Breakdown** At the Logical level, the *System* turns from a black box to a grey box, where more granular entities can be discerned as *Logical Components*. Second, therefore, we break down the *System* into its constituting *Logical Components* representing subsystems. This is done in a [LCBD] diagram. Capella does support nesting *Logical Components* with multiple hierarchical tiers, e.g. considering “segments”, “platforms”, “modules”, etc. – and then subsystems; however, that is beyond the scope of this method. If relevant to a project, we recommend shifting that complexity above subsystem entities upstream in the modelling cascade, for instance by adopting a federated model (model-of-models) structure. On the other hand, all complexity below subsystem entities is elaborated at the Physical level, as detailed in section 4.1.3.

**Architecture** Third, we allocate the broken-down *Functions* to the broken-down *Components*. This is done in a [LAB] diagram. Again, we recommend starting from a complete view of all *Functions* and *Components* within the *System*, and cloning it into one view per *Capability*, only representing the subset of *Functions* and *Components* involved in the *FCs* that realise it. This is generally helpful to improve readability, but particularly important in the proposed method: as illustrated in fig. 1 and detailed in section 4.3.2, these subset views will be involved in the integration-level verification activities at one of the most common critical points of the engineering lifecycle.

As guidance for this level, the *Functions* specified

should be elicited by being part of a single *FE* that crosses *Component* boundaries, or by representing the *Component's* action(s) between crossing said boundaries.

The two previous steps can be performed concurrently in [LAB] diagrams. Additionally, the function definition step can also be performed in [LAB] diagrams, but will lack the parenthood relationships with the *Functions* realised from the System level. To adopt this approach, we can simply set those relationships in [LFBD] and/or [LDFB] diagrams as part of this third step.

**Finite State Machine** Fourth, we model the behaviour of each *Logical Component* as an FSM by specifying the *Modes* it can assume, and connecting them through appropriate *Transitions*. At this level, we recommend continuing to allocate *Functions* to *Modes* and *FEs* to *Transitions* for the same reasons as with the System level. Both these actions are done in a [MSM] diagram. Again, this approach holds particular relevance in the proposed method: as elaborated in section 4.3.2, this representation can inform requirements for integration-level verification activities at the crux of the engineering lifecycle.

**Scenario** Finally, we represent all elements developed so far in a sequence format, which can also convey additional information such as informal timing, loops, branching, and comments. This is done in [ES] diagrams. Again, as with the Architectures, we recommend creating a separate [ES] diagram for each *Logical Capability*, each reproducing the *FC(s)* which realise the target *Capability*, and state the *Mode* assumed by each *Logical Component* whenever it changes. Laying out the diagram this way creates a direct equivalence between Capella's [ES] and TASTE's MSC, enabling their comparison as a verification activity as detailed in section 4.3.2.

### 4.1.3 Physical Level

**Logical to Physical Transition** Just like previously, we begin the Physical Architecture level by realising the *Logical Capabilities*, *Logical Functions*, *Logical Actors*, and *Logical Components* into *Physical Capabilities*, *Physical Functions*, *Physical Actors*, and *Behaviour PCs*, which can conveniently be done through Capella's automatic transition features.

**Function Breakdown/Data Flow** Next, similarly to the previous level, we break down the medium-level *Functions* (those inherited from the
level) into *Functions* appropriate for allocation to subsystems. Again, this is done in a [LFBD] diagram. Particular care should be paid to ensuring the new leaf *Functions* are suitable recipients of new *FEs* which shall realise the previously-specified *FCs* from the System to the Logical level. As this is a semantically complex problem, we suggest performing both the breakdown of *Functions* and the definition of *FEs* in a [LDFB] diagram, which is capable of representing both relationships at once. To do so, we populate the diagram with an existing *FC* inherited from the System level, and all the *Functions* and *FEs* it involves. We then break down the involved *Functions* by creating new *Functions* within them, which will create a semantic parenthood relationship, and define new *FEs* between them to result in the same overall path of the *FC* to realise. This new set of *FEs* constitutes the new *Logical FC*, which we create and configure to formally realise the original *System FC* through the appropriate Capella property.

**Component Breakdown** At the Logical level, the *System* turns from a black box to a grey box, where more granular entities can be discerned as *Logical Components*. Second, therefore, we break down the *System* into its constituting *Logical Components* representing subsystems. This is done in a [LCBD] diagram. Capella does support nesting *Logical Components* with multiple hierarchical tiers, e.g. considering “segments”, “platforms”, “modules”, etc. – and then subsystems; however, that is beyond the scope of this method. If relevant to a project, we recommend shifting that complexity above subsystem entities upstream in the modelling cascade, for instance by adopting a federated model (model-of-models) structure. On the other hand, all complexity below subsystem entities is elaborated at the Physical level, as detailed in section 4.1.3.

**Architecture** Third, we allocate the broken-down *Functions* to the broken-down *Components*. This is done in a [LAB] diagram. Again, we recommend starting from a complete view of all *Functions* and *Components* within the *System*, and cloning it into one view per *Capability*, only representing the subset of *Functions* and *Components* involved in the *FCs* that realise it. This is generally helpful to improve readability, but particularly important in the proposed method: as illustrated in fig. 1 and detailed in section 4.3.2, these subset views will be involved in the integration-level verification activities at one of the most common critical points of the engineering lifecycle.

As guidance for this level, the *Functions* specified

should be elicited by being part of a single *FE* that crosses *Component* boundaries, or by representing the *Component's* action(s) between crossing said boundaries.

The two previous steps can be performed concurrently in [LAB] diagrams. Additionally, the function definition step can also be performed in [LAB] diagrams, but will lack the parenthood relationships with the *Functions* realised from the System level. To adopt this approach, we can simply set those relationships in [LFBD] and/or [LDFB] diagrams as part of this third step.

**Finite State Machine** Fourth, we model the behaviour of each *Logical Component* as an FSM by specifying the *Modes* it can assume, and connecting them through appropriate *Transitions*. At this level, we recommend continuing to allocate *Functions* to *Modes* and *FEs* to *Transitions* for the same reasons as with the System level. Both these actions are done in a [MSM] diagram. Again, this approach holds particular relevance in the proposed method: as elaborated in section 4.3.2, this representation can inform requirements for integration-level verification activities at the crux of the engineering lifecycle.

**Scenario** Finally, we represent all elements developed so far in a sequence format, which can also convey additional information such as informal timing, loops, branching, and comments. This is done in [ES] diagrams. Again, as with the Architectures, we recommend creating a separate [ES] diagram for each *Logical Capability*, each reproducing the *FC(s)* which realise the target *Capability*, and state the *Mode* assumed by each *Logical Component* whenever it changes. Laying out the diagram this way creates a direct equivalence between Capella's [ES] and TASTE's MSC, enabling their comparison as a verification activity as detailed in section 4.3.2.

### 4.1.3 Physical Level

**Logical to Physical Transition** Just like previously, we begin the Physical Architecture level by realising the *Logical Capabilities*, *Logical Functions*, *Logical Actors*, and *Logical Components* into *Physical Capabilities*, *Physical Functions*, *Physical Actors*, and *Behaviour PCs*, which can conveniently be done through Capella's automatic transition features.

**Function Breakdown/Data Flow** Next, similarly to the previous level, we break down the medium-level *Functions* (those inherited from the
Logical level) into *Functions* appropriate for allocation to components – where “component” is a generic name for a Physical-level leaf entity, similarly to “subsystem” at the Logical level. Once again, this is done in a [PFBD] diagram, but we recommend performing both *Function* breakdown and *FEs* definition in a [PDFB] diagram. This helps ensure the new leaf *Functions* are suitable recipients of new *FEs* which shall realise the previously-specified *FCs* from the Logical to the Physical level. To do so, we populate the diagram with an existing *FC* inherited from the Logical level, and all the *Functions* and *FEs* it involves. We then break down the involved *Functions* by creating new *Functions* within them, which will create a semantic parenthood relationship, and define new *FEs* between them to result in the same overall path of the *FC* to realise. This new set of *FEs* constitutes the new *Physical FC*, which we create and configure to formally realise the original *Logical FC* through the appropriate Capella property.

**Component Breakdown** At the Physical level, the *System* turns from a grey box to a white box, where all entities can be discerned as *PCs*. Second, therefore, we break down the *System* into its constituting *PCs* representing components and component groups. This is done in a [PCBD] diagram. However, unlike at the previous level, two types of *PC* are envisioned in Capella: *Behaviour PCs* and *Node PCs*; in the context of this method, we map the former to software, and the latter to hardware. As mentioned in section 4.1.3§1, Capella realises *Logical Components* as *Behaviour PCs*, which our *Function*-driven modelling conforms to. So, after breaking down the inherited *Behaviour PCs* to represent software components, we also define *Node PCs* to represent hardware components.

At this level, we also take full advantage of Capella's nesting capabilities by instituting multiple hierarchical tiers to facilitate translation to TASTE: for *Behaviour PCs*, the first level below the root *Physical System* should represent a subsystem (TASTE Partition), each leaf a logic-containing software component (TASTE Function), and any number of forks in between can be used to convey software nesting (TASTE Function Groups); *Node PCs* are not mapped as formally, but we recommend the first level below the root *Physical System* represents a board, each leaf a computing device (TASTE Node), and any number of forks in between can be used to convey hardware stacking. This mapping is further detailed in table 1.

**Architecture** Third, we allocate the broken-down *Functions* to the broken-down *Behaviour PCs*, and the broken-down *Behaviour PCs* to the broken-down *Node PCs*. Both these actions are done in a [PAB] diagram. Once again, we recommend starting from a complete view of all *Functions* and *PCs* within the *System*, and cloning it into one view per *Capacity*, only representing the subset of *Functions* and *PCs* involved in the *FCs* that realise it. This is generally helpful to improve readability, but particularly important in the proposed method: as illustrated in fig. 1 and detailed in section 4.3.1, these subset views will be involved in the most granular unit-level verification activities. We also create a view only including *PCs*, which will be referenced in section 4.2 to create the TASTE Deployment View.

As guidance for this level, the *Functions* specified should represent reasonably atomic implementation steps: decisions, interface calls, I/O operations, etc.

The two previous steps can be performed concurrently in [PAB] diagrams. Additionally, the function definition step can also be performed in [PAB] diagrams, but will lack the parenthood relationships with the *Functions* realised from the Logical level. To adopt this approach, we can simply set those relationships in [PFBD] and/or [PDFB] diagrams as part of this third step.

**Finite State Machine** Fourth, we model the behaviour of each *PC* as an FSM by specifying the *Modes* it can assume, and connecting them through appropriate *Transitions*. At this level, we switch the previously-adopted allocation scheme and allocate both *Functions* and incoming *FEs* to *Transactions*: the former under the “Effects” property, the latter under “Triggers”. Both these actions are done in a [MSM] diagram. This approach is a key element of the proposed method: as detailed in section 4.2 and section 4.3.1, the semantics and views specified in this step will be referenced to implement the software components and verify their correctness at the unit level.

**Scenario** Fifth, we represent all elements developed so far in a sequence format, which can also convey additional information such as informal timing, loops, branching, and comments. This is done in [ES] diagrams. Again, as with the Architectures, we recommend creating a separate [ES] diagram for each *Logical Capability*, each reproducing the *FC(s)* which realise the target *Capability*, and state the *Mode* assumed by each *Logical Component* whenever it changes. Laying out the diagram this way creates a direct equivalence between Capella's [ES] and
Logical level) into *Functions* appropriate for allocation to components – where “component” is a generic name for a Physical-level leaf entity, similarly to “subsystem” at the Logical level. Once again, this is done in a [PFBD] diagram, but we recommend performing both *Function* breakdown and *FEs* definition in a [PDFB] diagram. This helps ensure the new leaf *Functions* are suitable recipients of new *FEs* which shall realise the previously-specified *FCs* from the Logical to the Physical level. To do so, we populate the diagram with an existing *FC* inherited from the Logical level, and all the *Functions* and *FEs* it involves. We then break down the involved *Functions* by creating new *Functions* within them, which will create a semantic parenthood relationship, and define new *FEs* between them to result in the same overall path of the *FC* to realise. This new set of *FEs* constitutes the new *Physical FC*, which we create and configure to formally realise the original *Logical FC* through the appropriate Capella property.

**Component Breakdown** At the Physical level, the *System* turns from a grey box to a white box, where all entities can be discerned as *PCs*. Second, therefore, we break down the *System* into its constituting *PCs* representing components and component groups. This is done in a [PCBD] diagram. However, unlike at the previous level, two types of *PC* are envisioned in Capella: *Behaviour PCs* and *Node PCs*; in the context of this method, we map the former to software, and the latter to hardware. As mentioned in section 4.1.3§1, Capella realises *Logical Components* as *Behaviour PCs*, which our *Function*-driven modelling conforms to. So, after breaking down the inherited *Behaviour PCs* to represent software components, we also define *Node PCs* to represent hardware components.

At this level, we also take full advantage of Capella's nesting capabilities by instituting multiple hierarchical tiers to facilitate translation to TASTE: for *Behaviour PCs*, the first level below the root *Physical System* should represent a subsystem (TASTE Partition), each leaf a logic-containing software component (TASTE Function), and any number of forks in between can be used to convey software nesting (TASTE Function Groups); *Node PCs* are not mapped as formally, but we recommend the first level below the root *Physical System* represents a board, each leaf a computing device (TASTE Node), and any number of forks in between can be used to convey hardware stacking. This mapping is further detailed in table 1.

**Architecture** Third, we allocate the broken-down *Functions* to the broken-down *Behaviour PCs*, and the broken-down *Behaviour PCs* to the broken-down *Node PCs*. Both these actions are done in a [PAB] diagram. Once again, we recommend starting from a complete view of all *Functions* and *PCs* within the *System*, and cloning it into one view per *Capacity*, only representing the subset of *Functions* and *PCs* involved in the *FCs* that realise it. This is generally helpful to improve readability, but particularly important in the proposed method: as illustrated in fig. 1 and detailed in section 4.3.1, these subset views will be involved in the most granular unit-level verification activities. We also create a view only including *PCs*, which will be referenced in section 4.2 to create the TASTE Deployment View.

As guidance for this level, the *Functions* specified should represent reasonably atomic implementation steps: decisions, interface calls, I/O operations, etc.

The two previous steps can be performed concurrently in [PAB] diagrams. Additionally, the function definition step can also be performed in [PAB] diagrams, but will lack the parenthood relationships with the *Functions* realised from the Logical level. To adopt this approach, we can simply set those relationships in [PFBD] and/or [PDFB] diagrams as part of this third step.

**Finite State Machine** Fourth, we model the behaviour of each *PC* as an FSM by specifying the *Modes* it can assume, and connecting them through appropriate *Transitions*. At this level, we switch the previously-adopted allocation scheme and allocate both *Functions* and incoming *FEs* to *Transactions*: the former under the “Effects” property, the latter under “Triggers”. Both these actions are done in a [MSM] diagram. This approach is a key element of the proposed method: as detailed in section 4.2 and section 4.3.1, the semantics and views specified in this step will be referenced to implement the software components and verify their correctness at the unit level.

**Scenario** Fifth, we represent all elements developed so far in a sequence format, which can also convey additional information such as informal timing, loops, branching, and comments. This is done in [ES] diagrams. Again, as with the Architectures, we recommend creating a separate [ES] diagram for each *Logical Capability*, each reproducing the *FC(s)* which realise the target *Capability*, and state the *Mode* assumed by each *Logical Component* whenever it changes. Laying out the diagram this way creates a direct equivalence between Capella's [ES] and
TASTE's MSC, enabling their comparison as a verification activity as detailed in section 4.3.1.

**Interfaces** At this level, as it is the closest to the implementation, the [ES] representation is not the final step; after that is done, we formally define the *Interfaces* between components and the *Data* exchanged through them. This is done across [PAB] and [CII] diagrams.

We start by identifying all *FEs* which cross the boundaries of leaf *Behaviour PCs* in a [PAB] diagram. For each *FE*, we create a *CE* between the traversed *Behaviour PCs*, in the same direction as the *FE*, and allocate the newly-created *Flow Ports* to the respective *Function Ports*. Additional *FEs* crossing the same pair of *Behaviour PCs* in the same direction can be allocated to either the same or a new *CE*, depending on the specific interface architecture required.

We then switch to a [CII] diagram. There, we create an *Interface* for every synchronous call-return *CE* pair or asynchronous call *CE*, and appropriately connect the relevant *Flow Ports* to it: providing it for the *In* direction; requiring it for the *Out* direction. We also create *Exchange Items* representing the parameters passed through each interface, and allocate one to the other accordingly. Due to limitations of TASTE *Interfaces*, we recommend allocating at most one parameter to each interface, and packing all necessary data points into a suitable data structure as part of the next step.

**Data** Finally, we specify the types of said parameters in a [CDB] diagram. This is done by creating the required *Types* (and optionally *Literals*, as in the case of *Enumerations*), and connecting them to the previously-defined *Exchange Items* through *Exchange Item Element* relationships. We represent data structures as *Classes*: for simple ones, we allocate one *Property* per primitive field; for more complex ones, we can also *Aggregate* simpler *Classes*. For clarity, we recommend populating this diagram with “cards” of the existing *Interfaces* as well.

Alternatively, *Interfaces* can also be defined here, and then used for population and allocation in a [CII] diagram.

## 4.2 Implementation Phase

This phase is performed across the Capella diagrams and TASTE views outlined in table 3: as illustrated in fig. 1, this crossing of tooling boundaries mainly consists of populating TASTE views with the content specified in the relevant Capella diagram – and,

thanks to the work done in section 4.1.3, this is largely trivial.

**Data View** We begin by defining the *Data Types* specified in [CDB] as the corresponding primitive ASN.1 types, then move on to simple *Classes* as *SEQUENCEs* of said types, and finish with *Aggregated Classes* as *SEQUENCEs* of said *SEQUENCEs*. The only additional specification to be done at this step is the definition of ranges for primitive types, as mandated by ASN.1 standards.

**Interface View** We begin by instantiating the *Behaviour PCs* laid out in [CII] as TASTE *Functions*. Then, we connect them to each other through *Interfaces* tracing the *Requires-Provides Interface* links, in the direction of the *Flow Ports*. Finally, we assign and type the *Parameters* of each *Interface* according to the allocations of *Exchange Items* to *Interfaces* and their typing. For this final step, it may be helpful to refer to the *Interface* “cards” included in [CDB] earlier.

**Deployment View** We begin by instantiating the *Node PCs* laid out in [PAB] as TASTE *Nodes*, which also spawns a *Partition* within each. Then, we bind the previously-created *Functions* to *Partitions* according to the allocations of leaf *Behaviour PCs* to root *Behaviour PCs*. Similarly, we bind the previously-created *Interfaces* to *Device Links* according to the allocations of *FEs* through *Component Exchanges* to *Physical Links*.

**Function Implementations** At this point, the architecture of the embedded system is fully specified, and the only missing piece is the functional code.

Generally, for each TASTE *Function*, this is implemented by following the individual steps specified in [PAB] as Capella *Functions* allocated to *Behaviour PCs*, in the order defined by their *FEs*. We recommend implementing as much logic as possible in SDL *Functions*, and only outsourcing thin hardware interfaces to a dedicated Hardware Abstraction Layer (HAL) *Function* implemented in C/C++. Taking advantage of one of TASTE's cornerstone features, implementing different *Functions* in different languages is encouraged by this method. However, because most of TASTE's more advanced features rely on formal SDL *Implementations*, we recommend writing an alternative SDL *Implementation* for each non-SDL *Function*, which should mock the *Interfaces* of the actual, non-SDL *Implementation*.

Specifically, SDL *Functions* are implemented by creating and connecting the *States* as laid out in the
TASTE's MSC, enabling their comparison as a verification activity as detailed in section 4.3.1.

**Interfaces** At this level, as it is the closest to the implementation, the [ES] representation is not the final step; after that is done, we formally define the *Interfaces* between components and the *Data* exchanged through them. This is done across [PAB] and [CII] diagrams.

We start by identifying all *FEs* which cross the boundaries of leaf *Behaviour PCs* in a [PAB] diagram. For each *FE*, we create a *CE* between the traversed *Behaviour PCs*, in the same direction as the *FE*, and allocate the newly-created *Flow Ports* to the respective *Function Ports*. Additional *FEs* crossing the same pair of *Behaviour PCs* in the same direction can be allocated to either the same or a new *CE*, depending on the specific interface architecture required.

We then switch to a [CII] diagram. There, we create an *Interface* for every synchronous call-return *CE* pair or asynchronous call *CE*, and appropriately connect the relevant *Flow Ports* to it: providing it for the *In* direction; requiring it for the *Out* direction. We also create *Exchange Items* representing the parameters passed through each interface, and allocate one to the other accordingly. Due to limitations of TASTE *Interfaces*, we recommend allocating at most one parameter to each interface, and packing all necessary data points into a suitable data structure as part of the next step.

**Data** Finally, we specify the types of said parameters in a [CDB] diagram. This is done by creating the required *Types* (and optionally *Literals*, as in the case of *Enumerations*), and connecting them to the previously-defined *Exchange Items* through *Exchange Item Element* relationships. We represent data structures as *Classes*: for simple ones, we allocate one *Property* per primitive field; for more complex ones, we can also *Aggregate* simpler *Classes*. For clarity, we recommend populating this diagram with “cards” of the existing *Interfaces* as well.

Alternatively, *Interfaces* can also be defined here, and then used for population and allocation in a [CII] diagram.

## 4.2 Implementation Phase

This phase is performed across the Capella diagrams and TASTE views outlined in table 3: as illustrated in fig. 1, this crossing of tooling boundaries mainly consists of populating TASTE views with the content specified in the relevant Capella diagram – and,

thanks to the work done in section 4.1.3, this is largely trivial.

**Data View** We begin by defining the *Data Types* specified in [CDB] as the corresponding primitive ASN.1 types, then move on to simple *Classes* as *SEQUENCEs* of said types, and finish with *Aggregated Classes* as *SEQUENCEs* of said *SEQUENCEs*. The only additional specification to be done at this step is the definition of ranges for primitive types, as mandated by ASN.1 standards.

**Interface View** We begin by instantiating the *Behaviour PCs* laid out in [CII] as TASTE *Functions*. Then, we connect them to each other through *Interfaces* tracing the *Requires-Provides Interface* links, in the direction of the *Flow Ports*. Finally, we assign and type the *Parameters* of each *Interface* according to the allocations of *Exchange Items* to *Interfaces* and their typing. For this final step, it may be helpful to refer to the *Interface* “cards” included in [CDB] earlier.

**Deployment View** We begin by instantiating the *Node PCs* laid out in [PAB] as TASTE *Nodes*, which also spawns a *Partition* within each. Then, we bind the previously-created *Functions* to *Partitions* according to the allocations of leaf *Behaviour PCs* to root *Behaviour PCs*. Similarly, we bind the previously-created *Interfaces* to *Device Links* according to the allocations of *FEs* through *Component Exchanges* to *Physical Links*.

**Function Implementations** At this point, the architecture of the embedded system is fully specified, and the only missing piece is the functional code.

Generally, for each TASTE *Function*, this is implemented by following the individual steps specified in [PAB] as Capella *Functions* allocated to *Behaviour PCs*, in the order defined by their *FEs*. We recommend implementing as much logic as possible in SDL *Functions*, and only outsourcing thin hardware interfaces to a dedicated Hardware Abstraction Layer (HAL) *Function* implemented in C/C++. Taking advantage of one of TASTE's cornerstone features, implementing different *Functions* in different languages is encouraged by this method. However, because most of TASTE's more advanced features rely on formal SDL *Implementations*, we recommend writing an alternative SDL *Implementation* for each non-SDL *Function*, which should mock the *Interfaces* of the actual, non-SDL *Implementation*.

Specifically, SDL *Functions* are implemented by creating and connecting the *States* as laid out in the
[MSM] of the matching *Behaviour PC*, and populating *Transitions* with logic to perform the *Functions* allocated to them as Effects.

## 4.3 Testing Phase

This phase is performed across the TASTE views and Capella diagrams outlined in table 4. Here, we detail verification activities at the different levels of abstraction; at all levels, validation can be carried out by respectively executing the *Function/Function Group/Partition* under test.

### 4.3.1 Unit Testing

**FSM Comparison** The first step of unit-level verification takes place while writing SDL Implementations, and consists of comparing the SDL State Chart View generated from the implemented *Function* against the specified [MSM] of the respective *Behaviour PC*. While basic, this is not trivial: the view used to write SDL Implementations focuses on *Transitions*, potentially allowing discrepancies in the state-based representations of complex components. This step is passed if, for each pair of *Function* and leaf *Behaviour PC*, there is a match between the following elements across Capella and TASTE:

* their *States*,

* the *Transitions* between said *States*,

* the triggers of said *Transitions*.

**MSC Comparison** The second step of unit-level verification takes place after compiling the SDL *Functions*, and consists of comparing the fine-grained MSC diagrams generated by executing test cases against their specifications as Physical [ES] diagrams. This step is passed if, for each test case, there is a match between the following elements across Capella and TASTE:

* the *Functions* and the leaf *Behaviour PCs* involved,

* the *States* of said *Functions* and leaf *Behaviour PCs*,

* the *Interface* calls between said *Functions* and the *FEs* between said leaf *Behaviour PCs*.

**E2E Comparison** This auxiliary unit-level verification step takes place after the previous, and consists of comparing the fine-grained E2E view of the generated test case MSCs against their specifications as [PAB] diagrams highlighting the respective *Physical FCs*. This effectively represents a subset of the

same information examined previously, but with a focus on the architectural impact of exchanges rather than their sequencing. This step is passed if, for each test case, there is a match between the following elements across Capella and TASTE:

* the *Functions* and the leaf *Behaviour PCs* involved,

* the *Interface* calls between said *Functions* and the *FEs* between said leaf *Behaviour PCs*.

### 4.3.2 Integration Testing

**MSC Comparison** The first step of integration-level verification consists of comparing coarse versions of test case execution MSCs against their specifications as Logical [ES] diagrams. This step is passed if, for each test case, there is a match between the following elements across Capella and TASTE:

* the *Function Groups* and the *Logical Components* involved,

* the *Interface* calls between said *Function Groups* and the *FEs* between said *Logical Components*.

**E2E Comparison** The auxiliary integration-level verification step consists of comparing coarse versions of test case execution E2E views against their specifications as [LAB] diagrams highlighting the respective *Logical FCs*. This step is passed if, for each test case, there is a match between the following elements across Capella and TASTE:

* the *Function Groups* and the *Logical Components* involved,

* the *Interface* calls between said *Function Groups* and the *FEs* between said *Logical Components*.

### 4.3.3 Acceptance Testing

**MSC Comparison** The first step of acceptance-level verification consists of comparing top-level versions of test case execution MSCs against their specifications as System [ES] diagrams. This step is passed if, for each test case, there is a match between the following elements across Capella and TASTE:

* the system *Partitions* and the *System / System Actors* involved,

* the *Interface* calls between said *Partitions* and the *FEs* between the *System* and said *System Actors*.
[MSM] of the matching *Behaviour PC*, and populating *Transitions* with logic to perform the *Functions* allocated to them as Effects.

## 4.3 Testing Phase

This phase is performed across the TASTE views and Capella diagrams outlined in table 4. Here, we detail verification activities at the different levels of abstraction; at all levels, validation can be carried out by respectively executing the *Function/Function Group/Partition* under test.

### 4.3.1 Unit Testing

**FSM Comparison** The first step of unit-level verification takes place while writing SDL Implementations, and consists of comparing the SDL State Chart View generated from the implemented *Function* against the specified [MSM] of the respective *Behaviour PC*. While basic, this is not trivial: the view used to write SDL Implementations focuses on *Transitions*, potentially allowing discrepancies in the state-based representations of complex components. This step is passed if, for each pair of *Function* and leaf *Behaviour PC*, there is a match between the following elements across Capella and TASTE:

* their *States*,

* the *Transitions* between said *States*,

* the triggers of said *Transitions*.

**MSC Comparison** The second step of unit-level verification takes place after compiling the SDL *Functions*, and consists of comparing the fine-grained MSC diagrams generated by executing test cases against their specifications as Physical [ES] diagrams. This step is passed if, for each test case, there is a match between the following elements across Capella and TASTE:

* the *Functions* and the leaf *Behaviour PCs* involved,

* the *States* of said *Functions* and leaf *Behaviour PCs*,

* the *Interface* calls between said *Functions* and the *FEs* between said leaf *Behaviour PCs*.

**E2E Comparison** This auxiliary unit-level verification step takes place after the previous, and consists of comparing the fine-grained E2E view of the generated test case MSCs against their specifications as [PAB] diagrams highlighting the respective *Physical FCs*. This effectively represents a subset of the

same information examined previously, but with a focus on the architectural impact of exchanges rather than their sequencing. This step is passed if, for each test case, there is a match between the following elements across Capella and TASTE:

* the *Functions* and the leaf *Behaviour PCs* involved,

* the *Interface* calls between said *Functions* and the *FEs* between said leaf *Behaviour PCs*.

### 4.3.2 Integration Testing

**MSC Comparison** The first step of integration-level verification consists of comparing coarse versions of test case execution MSCs against their specifications as Logical [ES] diagrams. This step is passed if, for each test case, there is a match between the following elements across Capella and TASTE:

* the *Function Groups* and the *Logical Components* involved,

* the *Interface* calls between said *Function Groups* and the *FEs* between said *Logical Components*.

**E2E Comparison** The auxiliary integration-level verification step consists of comparing coarse versions of test case execution E2E views against their specifications as [LAB] diagrams highlighting the respective *Logical FCs*. This step is passed if, for each test case, there is a match between the following elements across Capella and TASTE:

* the *Function Groups* and the *Logical Components* involved,

* the *Interface* calls between said *Function Groups* and the *FEs* between said *Logical Components*.

### 4.3.3 Acceptance Testing

**MSC Comparison** The first step of acceptance-level verification consists of comparing top-level versions of test case execution MSCs against their specifications as System [ES] diagrams. This step is passed if, for each test case, there is a match between the following elements across Capella and TASTE:

* the system *Partitions* and the *System / System Actors* involved,

* the *Interface* calls between said *Partitions* and the *FEs* between the *System* and said *System Actors*.
**E2E Comparison** The auxiliary acceptance-level verification step consists of comparing top-level versions of test case execution E2E views against their specifications as [SAB] diagrams highlighting the respective *System FCs*. This step is passed if, for each test case, there is a match between the following elements across Capella and TASTE:

* the *Partitions* and the *System / System Actors* involved,

* the *Interface* calls between said *Partitions* and the *FEs* between the *System* and said *System Actors*.

# 5 Case Study: System-Wide Mode Management

We have applied the proposed method to the development of a system-wide mode management feature for the On-Board Computer (OBC) on a 3U Earth Observation student CubeSat. Consistently with previous modelling, the feature involves managing the mode of the system as the combination of the modes of its subsystems, changing it either based on telecommands (TCs) for ground operations or on location within configurable Areas of Interest (AoIs) for land imaging. We now briefly present the main deliverables in this methodology as comparisons between equivalent diagrams in Capella and TASTE, to highlight their symmetry. These can also be found in [20].

## 5.1 Data View

Figure 2 and listing 1 show the specifications of the data types required for this feature, in Capella's [CDB] diagram and TASTE's ASN.1 Data View respectively.

## 5.2 Interface View

Figure 4 shows the specifications of the software components and interfaces between them as required for this feature, in Capella's [CII] diagram and TASTE's Interface View respectively. In fig. 3, we also include the *Interface* "cards" from the [CDB] diagram, succinctly representing the parameters of each interface and their data types. TASTE interfaces also allocate data parameters, as specified in Capella; however, the respective TASTE configurations are omitted for their verbosity.

To maintain some abstraction in Capella, the Hardware Abstraction Layer (HAL) performing bare-metal operations is omitted from our model. However, in accordance with model-based principles, its functions are devoid of logic, allowing it to be implemented trivially with libraries from the TASTE MSP430-DemoSat project [21].

## 5.3 Deployment View

Figure 5 shows the specifications of the deployment of software components to hardware nodes, in Capella's [PAB] diagram and TASTE's Deployment View. Again, TASTE device links also allocate interfaces, as shown in Capella; however, the respective TASTE configurations are omitted for their verbosity.

At the time of writing, the external board chosen for the Pipeline subsystem is not supported by TASTE. Therefore, our simplified implementation deploys all software components on a singular hardware node.

## 5.4 Function Implementations

Here, we briefly describe the implementations of the software components required for this feature. Images of the full SDL code in TASTE's graphical editor are included in appendix A.

**Mode Change Telecommand Handler** As specified in Capella [22], this component is designed to map mission-oriented mode change TCs to granular system mode change requests and relay reports of their execution, whether telecommanded or automated, from the OBC to the ground. To implement this, we created two states, respectively expecting a TC and a mode change report. We then set up the initial transition to instantiate the mappings (fig. 7) and expect a TC. Finally, we connected the states through a transition to accept the TC, apply the mappings, and request the appropriate mode change (fig. 8), and two identical transitions to accept the mode change report and relay it to the ground (fig. 9).

**System Mode Manager** As specified in Capella [22], this component is designed to propagate system mode change requests throughout all subsystems involved, and collate their responses into a single report to relay to the ground. To implement this, we created three states expecting either a request or a response from each subsystem. We then set up the initial transition to set up the initial mode and expect a change request from the Mode Change Telecommand Handler (fig. 10). Finally, we
**E2E Comparison** The auxiliary acceptance-level verification step consists of comparing top-level versions of test case execution E2E views against their specifications as [SAB] diagrams highlighting the respective *System FCs*. This step is passed if, for each test case, there is a match between the following elements across Capella and TASTE:

* the *Partitions* and the *System / System Actors* involved,

* the *Interface* calls between said *Partitions* and the *FEs* between the *System* and said *System Actors*.

# 5 Case Study: System-Wide Mode Management

We have applied the proposed method to the development of a system-wide mode management feature for the On-Board Computer (OBC) on a 3U Earth Observation student CubeSat. Consistently with previous modelling, the feature involves managing the mode of the system as the combination of the modes of its subsystems, changing it either based on telecommands (TCs) for ground operations or on location within configurable Areas of Interest (AoIs) for land imaging. We now briefly present the main deliverables in this methodology as comparisons between equivalent diagrams in Capella and TASTE, to highlight their symmetry. These can also be found in [20].

## 5.1 Data View

Figure 2 and listing 1 show the specifications of the data types required for this feature, in Capella's [CDB] diagram and TASTE's ASN.1 Data View respectively.

## 5.2 Interface View

Figure 4 shows the specifications of the software components and interfaces between them as required for this feature, in Capella's [CII] diagram and TASTE's Interface View respectively. In fig. 3, we also include the *Interface* "cards" from the [CDB] diagram, succinctly representing the parameters of each interface and their data types. TASTE interfaces also allocate data parameters, as specified in Capella; however, the respective TASTE configurations are omitted for their verbosity.

To maintain some abstraction in Capella, the Hardware Abstraction Layer (HAL) performing bare-metal operations is omitted from our model. However, in accordance with model-based principles, its functions are devoid of logic, allowing it to be implemented trivially with libraries from the TASTE MSP430-DemoSat project [21].

## 5.3 Deployment View

Figure 5 shows the specifications of the deployment of software components to hardware nodes, in Capella's [PAB] diagram and TASTE's Deployment View. Again, TASTE device links also allocate interfaces, as shown in Capella; however, the respective TASTE configurations are omitted for their verbosity.

At the time of writing, the external board chosen for the Pipeline subsystem is not supported by TASTE. Therefore, our simplified implementation deploys all software components on a singular hardware node.

## 5.4 Function Implementations

Here, we briefly describe the implementations of the software components required for this feature. Images of the full SDL code in TASTE's graphical editor are included in appendix A.

**Mode Change Telecommand Handler** As specified in Capella [22], this component is designed to map mission-oriented mode change TCs to granular system mode change requests and relay reports of their execution, whether telecommanded or automated, from the OBC to the ground. To implement this, we created two states, respectively expecting a TC and a mode change report. We then set up the initial transition to instantiate the mappings (fig. 7) and expect a TC. Finally, we connected the states through a transition to accept the TC, apply the mappings, and request the appropriate mode change (fig. 8), and two identical transitions to accept the mode change report and relay it to the ground (fig. 9).

**System Mode Manager** As specified in Capella [22], this component is designed to propagate system mode change requests throughout all subsystems involved, and collate their responses into a single report to relay to the ground. To implement this, we created three states expecting either a request or a response from each subsystem. We then set up the initial transition to set up the initial mode and expect a change request from the Mode Change Telecommand Handler (fig. 10). Finally, we
<figure><img src="image_3.png" /><figcaption>Figure 2: Data View [CDB] in Capella</figcaption></figure>

<caption>Listing 1: Data View in ASN.1 (TASTE)</caption>

OBC-FIRMWARE-DATAVIEW DEFINITIONS ::= BEGIN

Latitude-WGS84     ::= REAL (-90.0 .. 90.0)
Longitude-WGS84    ::= REAL (-180.0 .. 180.0)
Altitude-m        ::= REAL (0.0 .. 100000.0)
Location          ::= SEQUENCE {
    lat             Latitude-WGS84,
    lon             Longitude-WGS84,
    alt             Altitude-m
}

Area-of-Interest  ::= SEQUENCE {
    loc-nw          Location,
    loc-ne          Location,
    loc-se          Location,
    loc-sw          Location,
    enabled        BOOLEAN
}

AoI-List          ::= SEQUENCE (SIZE (4)) OF
    Area-of-Interest
    AoI-List-Index  ::= INTEGER (0 .. 3)

AoI-Config-TC     ::= CHOICE {
    configure        SEQUENCE {
        index           AoI-List-Index,
        aoi             Area-of-Interest
    },
    enable           SEQUENCE {
        index           AoI-List-Index
    },
    disable          SEQUENCE {
        index           AoI-List-Index
    }
}

AoI-Config-Report  ::= SEQUENCE {
    aoi-list-upd     AoI-List
}

Payload-Mode-T     ::= ENUMERATED {
    payload-idle,
    payload-imaging
}

Pipeline-Mode-T     ::= ENUMERATED {
    pipeline-idle,
    pipeline-processing-fp,
    pipeline-processing-lp
}

System-Mode-T      ::= SEQUENCE {
    payload-mode      Payload-Mode-T,
    pipeline-mode     Pipeline-Mode-T
}

Mode-Status-Operation-T  ::= ENUMERATED {
    mode-status-nop,
    mode-status-change
}

Payload-Mode-Status-Report-T  ::= SEQUENCE {
    payload-mode      Payload-Mode-T,
    payload-last-op    Mode-Status-Operation-T
}

Pipeline-Mode-Status-Report-T  ::= SEQUENCE {
    pipeline-mode      Pipeline-Mode-T,
    pipeline-last-op    Mode-Status-Operation-T
}

System-Mode-Status-Report-T  ::= SEQUENCE {
    payload-report
}

Payload-Mode-Status-Report-T,
    pipeline-report

Pipeline-Mode-Status-Report-T
}

Mission-Mode-T      ::= ENUMERATED {
    mission-idle,
    mission-imaging,
    mission-processing
}

Mission-Mode-Change-TC-T  ::= SEQUENCE {
    target-mission-mode  Mission-Mode-T
}

Mission-Mode-Change-Report-T  ::= SEQUENCE {
    target-mission-mode  Mission-Mode-T,
    system-mode-status-report
}

System-Mode-Status-Report-T
}

END
<figure><img src="image_3.png" /><figcaption>Figure 2: Data View [CDB] in Capella</figcaption></figure>

<caption>Listing 1: Data View in ASN.1 (TASTE)</caption>

OBC-FIRMWARE-DATAVIEW DEFINITIONS ::= BEGIN

Latitude-WGS84     ::= REAL (-90.0 .. 90.0)
Longitude-WGS84    ::= REAL (-180.0 .. 180.0)
Altitude-m        ::= REAL (0.0 .. 100000.0)
Location          ::= SEQUENCE {
    lat            Latitude-WGS84,
    lon            Longitude-WGS84,
    alt            Altitude-m
}

Area-of-Interest  ::= SEQUENCE {
    loc-nw          Location,
    loc-ne          Location,
    loc-se          Location,
    loc-sw          Location,
    enabled        BOOLEAN
}

AoI-List          ::= SEQUENCE (SIZE (4)) OF
    Area-of-Interest
    AoI-List-Index  ::= INTEGER (0 .. 3)

AoI-Config-TC     ::= CHOICE {
    configure        SEQUENCE {
        index          AoI-List-Index,
        aoi            Area-of-Interest
    },
    enable          SEQUENCE {
        index          AoI-List-Index
    },
    disable         SEQUENCE {
        index          AoI-List-Index
    }
}

AoI-Config-Report  ::= SEQUENCE {
    aoi-list-upd     AoI-List
}

Payload-Mode-T     ::= ENUMERATED {
    payload-idle,
    payload-imaging
}

Pipeline-Mode-T     ::= ENUMERATED {
    pipeline-idle,
    pipeline-processing-fp,
    pipeline-processing-lp
}

System-Mode-T      ::= SEQUENCE {
    payload-mode      Payload-Mode-T,
    pipeline-mode     Pipeline-Mode-T
}

Mode-Status-Operation-T  ::= ENUMERATED {
    mode-status-nop,
    mode-status-change
}

Payload-Mode-Status-Report-T  ::= SEQUENCE {
    payload-mode      Payload-Mode-T,
    payload-last-op    Mode-Status-Operation-T
}

Pipeline-Mode-Status-Report-T  ::= SEQUENCE {
    pipeline-mode      Pipeline-Mode-T,
    pipeline-last-op    Mode-Status-Operation-T
}

System-Mode-Status-Report-T  ::= SEQUENCE {
    payload-report
}

Payload-Mode-Status-Report-T,
    pipeline-report

Pipeline-Mode-Status-Report-T
}

Mission-Mode-T       ::= ENUMERATED {
    mission-idle,
    mission-imaging,
    mission-processing
}

Mission-Mode-Change-TC-T  ::= SEQUENCE {
    target-mission-mode  Mission-Mode-T
}

Mission-Mode-Change-Report-T  ::= SEQUENCE {
    target-mission-mode  Mission-Mode-T,
    system-mode-status-report
}

System-Mode-Status-Report-T
}

END
<figure><img src="image_4.png" /><figcaption>Figure 3: *Interface* “cards” from [CDB].</figcaption></figure>

connected the states through a chain of transitions, each adding any previous subsystem responses to the report, validating the requested subsystem mode change and, if valid, relaying the request to the subsystem (figs. 11 and 12); the final transition also flushes the completed report to the Mode Change Telecommand Handler (fig. 13). We also added goto-style jumps to skip inapplicable or invalid changes as per previously specified subsystem FSMs.

**Area of Interest Manager** As specified in Capella [22], this component is designed to configure AoIs according to TCs, and compare them with the current location to request system mode changes. To implement this, we created two states, respectively expecting a trigger, such as a configuration TC or a cyclical location request timer, and a response from the location provider. We then set up an initial transition to instantiate detailed system mode mappings

and expect a trigger (fig. 14) – not unlike that of the Mode Change Telecommand Handler, as both components can request mode changes through the same interface. Finally, we connected the states through a transition to accept the TC and execute its AoI configuration instruction (fig. 15), a transition to accept the firing of the timer and request location data (fig. 16), and a transition to accept location data and compare it with the configured AoIs, requesting a system mode change if appropriate (fig. 17).

## 5.5 Unit Testing

### 5.5.1 FSM comparison

Here, we describe the verification of the software components as per section 4.3.1§1, as well as their outcomes. The full comparisons are presented in appendix B.

**Mode Change Telecommand Handler** Figure 18 shows the initial specification of the Mode Change Telecommand Handler component in Capella’s [MSM] diagram, and the State Chart View of its implementation generated by TASTE. Both present the same two states, with a large cycle traversing them both and a smaller one looping around the initial state. Telecommands are only accepted in this state, leading into the large cycle; execution reports are accepted in both, either completing the large cycle or initiating the smaller one. As all examined elements are a match between the two, this verification step is passed.

**System Mode Manager** Figure 19 shows the initial specification of the System Mode Manager component in Capella’s [MSM] diagram, and the State Chart View of its implementation generated by TASTE. Again, comparing the two confirms their match – including the goto-style skips, passing this verification step.

**Area of Interest Manager** Figure 20 shows the initial specification of the Area of Interest Manager component in Capella’s [MSM] diagram, and the State Chart View of its implementation generated by TASTE. Once again, comparing the two confirms their match, passing this verification step.

### 5.5.2 MSC comparison

Here, we describe the verification of the interactions between software components as per section 4.3.1§2,
<figure><img src="image_4.png" /><figcaption>Figure 3: *Interface* “cards” from [CDB].</figcaption></figure>

connected the states through a chain of transitions, each adding any previous subsystem responses to the report, validating the requested subsystem mode change and, if valid, relaying the request to the subsystem (figs. 11 and 12); the final transition also flushes the completed report to the Mode Change Telecommand Handler (fig. 13). We also added goto-style jumps to skip inapplicable or invalid changes as per previously specified subsystem FSMs.

**Area of Interest Manager** As specified in Capella [22], this component is designed to configure AoIs according to TCs, and compare them with the current location to request system mode changes. To implement this, we created two states, respectively expecting a trigger, such as a configuration TC or a cyclical location request timer, and a response from the location provider. We then set up an initial transition to instantiate detailed system mode mappings

and expect a trigger (fig. 14) – not unlike that of the Mode Change Telecommand Handler, as both components can request mode changes through the same interface. Finally, we connected the states through a transition to accept the TC and execute its AoI configuration instruction (fig. 15), a transition to accept the firing of the timer and request location data (fig. 16), and a transition to accept location data and compare it with the configured AoIs, requesting a system mode change if appropriate (fig. 17).

## 5.5 Unit Testing

### 5.5.1 FSM comparison

Here, we describe the verification of the software components as per section 4.3.1§1, as well as their outcomes. The full comparisons are presented in appendix B.

**Mode Change Telecommand Handler** Figure 18 shows the initial specification of the Mode Change Telecommand Handler component in Capella’s [MSM] diagram, and the State Chart View of its implementation generated by TASTE. Both present the same two states, with a large cycle traversing them both and a smaller one looping around the initial state. Telecommands are only accepted in this state, leading into the large cycle; execution reports are accepted in both, either completing the large cycle or initiating the smaller one. As all examined elements are a match between the two, this verification step is passed.

**System Mode Manager** Figure 19 shows the initial specification of the System Mode Manager component in Capella’s [MSM] diagram, and the State Chart View of its implementation generated by TASTE. Again, comparing the two confirms their match – including the goto-style skips, passing this verification step.

**Area of Interest Manager** Figure 20 shows the initial specification of the Area of Interest Manager component in Capella’s [MSM] diagram, and the State Chart View of its implementation generated by TASTE. Once again, comparing the two confirms their match, passing this verification step.

### 5.5.2 MSC comparison

Here, we describe the verification of the interactions between software components as per section 4.3.1§2,
<figure><img src="image_5.png" /><figcaption>Figure 4: Comparison of Interface Views between Capella ([CII]) and TASTE, including detail of the OBC subsystem (bottom).</figcaption></figure>
<figure><img src="image_5.png" /><figcaption>Figure 4: Comparison of Interface Views between Capella ([CII]) and TASTE, including detail of the OBC subsystem (bottom).</figcaption></figure>
<figure><img src="image_6.png" /><figcaption>Figure 5: Comparison of Deployment Views between Capella ([PAB]) and TASTE.</figcaption></figure>

as well as their outcomes. The full comparisons are presented in appendix C.

**Telecommanded Mode Management** As specified in Capella [22], this feature is expected to be triggered by an external telecommand requesting a system-wide mode change. Within the OBC, the Mode Change Telecommand Handler translates this into a set of target subsystem modes; the System Mode Manager then propagates transition instructions throughout the relevant subsystems, and collects their execution reports. These are relayed back to the Mode Change Telecommand Handler, and ultimately to the ground station. As illustrated in fig. 21, the model [ES] template was instanced into three separate test cases with different data values. In the first case, the requested mode matches the current mode, and the System Mode Manager correctly skips executing any of the “ALT” blocks in the [ES]. In the second and third cases, the requested mode requires a transition, which is again correctly propagated by the System Mode Manager, either to a single subsystem or to both. As all examined elements are a match between the two, this verification step is passed.

**Area of Interest Management** As specified in Capella [22], this feature expects the OBC's Area of Interest Manager to react to two triggers: an external TC to configure an AoI, and an automated timer to request location data from the ADCS. If the received location data matches an active AoI, a mode change request is sent to the System Mode Manager. As illustrated in fig. 22, the model [ES] template was again instanced into two separate test cases, each changing AoI values rather than location data. This was done to improve repeatability, and results in each instance including two external TCs and one automated trigger instead of one TC and two triggers. In the first case, the automated comparison correctly requests a transition to idle mode both before configuring any AoI and after configuring a new inactive AoI. In the second case, the AoI is activated, correctly resulting in a request for imaging mode, then deactivated

again, correctly resulting in a request for processing mode. Again, as all examined elements are a match between the two, this verification step is passed too, and confirms that swapping different location data for different AoI configurations had no significant effect on the correct operation of the feature.

### 5.5.3 E2E comparison

Here, we describe the verification of the interactions between software components as per section 4.3.1§3, as well as their outcomes. The full comparisons are presented in appendix D.

**Telecommanded Mode Management** As specified in Capella [22], this feature is expected to involve a chain of interface calls from the ground station to the OBC's System Mode Manager, then (based on the “ALT” blocks of the respective [ES]) up to two interface calls, to the subsystem mode trackers for Payload and Pipeline respectively, and finally a return chain back to the ground station. As illustrated in fig. 23, all examined elements are a match between the two, so this verification step is passed.

**Area of Interest Management** As specified in Capella [22], this feature is expected to involve a chain of interface calls from the ground station to the OBC's Area of Interest Manager, immediately leading into the return chain back to the ground station. Regularly, the Area of Interest Manager autonomously requests data from the ADCS and, optionally, a transition from the System Mode Manager. As illustrated in fig. 24, most examined elements are a match between the two again: the System Mode Manager incorrectly appears as not involved. However, this is the result of a known limitation of this view at the time of writing, which prevents it from displaying one-way calls without a return path. Therefore, this verification step can be considered passed too.
<figure><img src="image_6.png" /><figcaption>Figure 5: Comparison of Deployment Views between Capella ([PAB]) and TASTE.</figcaption></figure>

as well as their outcomes. The full comparisons are presented in appendix C.

**Telecommanded Mode Management** As specified in Capella [22], this feature is expected to be triggered by an external telecommand requesting a system-wide mode change. Within the OBC, the Mode Change Telecommand Handler translates this into a set of target subsystem modes; the System Mode Manager then propagates transition instructions throughout the relevant subsystems, and collects their execution reports. These are relayed back to the Mode Change Telecommand Handler, and ultimately to the ground station. As illustrated in fig. 21, the model [ES] template was instanced into three separate test cases with different data values. In the first case, the requested mode matches the current mode, and the System Mode Manager correctly skips executing any of the “ALT” blocks in the [ES]. In the second and third cases, the requested mode requires a transition, which is again correctly propagated by the System Mode Manager, either to a single subsystem or to both. As all examined elements are a match between the two, this verification step is passed.

**Area of Interest Management** As specified in Capella [22], this feature expects the OBC's Area of Interest Manager to react to two triggers: an external TC to configure an AoI, and an automated timer to request location data from the ADCS. If the received location data matches an active AoI, a mode change request is sent to the System Mode Manager. As illustrated in fig. 22, the model [ES] template was again instanced into two separate test cases, each changing AoI values rather than location data. This was done to improve repeatability, and results in each instance including two external TCs and one automated trigger instead of one TC and two triggers. In the first case, the automated comparison correctly requests a transition to idle mode both before configuring any AoI and after configuring a new inactive AoI. In the second case, the AoI is activated, correctly resulting in a request for imaging mode, then deactivated

again, correctly resulting in a request for processing mode. Again, as all examined elements are a match between the two, this verification step is passed too, and confirms that swapping different location data for different AoI configurations had no significant effect on the correct operation of the feature.

### 5.5.3 E2E comparison

Here, we describe the verification of the interactions between software components as per section 4.3.1§3, as well as their outcomes. The full comparisons are presented in appendix D.

**Telecommanded Mode Management** As specified in Capella [22], this feature is expected to involve a chain of interface calls from the ground station to the OBC's System Mode Manager, then (based on the “ALT” blocks of the respective [ES]) up to two interface calls, to the subsystem mode trackers for Payload and Pipeline respectively, and finally a return chain back to the ground station. As illustrated in fig. 23, all examined elements are a match between the two, so this verification step is passed.

**Area of Interest Management** As specified in Capella [22], this feature is expected to involve a chain of interface calls from the ground station to the OBC's Area of Interest Manager, immediately leading into the return chain back to the ground station. Regularly, the Area of Interest Manager autonomously requests data from the ADCS and, optionally, a transition from the System Mode Manager. As illustrated in fig. 24, most examined elements are a match between the two again: the System Mode Manager incorrectly appears as not involved. However, this is the result of a known limitation of this view at the time of writing, which prevents it from displaying one-way calls without a return path. Therefore, this verification step can be considered passed too.
## 5.6 Higher-Level Testing

For the sake of brevity, we omit the MSC and E2E verification activities at higher levels of abstraction – subsystem integration and system acceptance. In light of the simplicity of the features presented in this paper, these can be derived by reducing the unit-level diagrams to only consider the exchanges that cross the boundaries between entities at the chosen level.

## 6 Results

The presented system mode management feature was integrated with hardware and launched in our experimental sounding balloon mission *CloudView*, reaching an estimated altitude of over 35km over a flight time of approximately 3 hours.

As the hardware node for the Pipeline subsystem is (yet) unsupported by TASTE, its software was developed separately, and communication with the OBC handled through the HAL; additionally, due to time constraints, the Area-of-Interest-based and telecommand-based triggering of mode changes was substituted with simple recurring timers. However, apart from said exceptions, the core architecture and logic were unchanged, and ran successfully for the entire duration of the mission, capturing and processing images such as the one shown in fig. 6.

<figure><img src="image_7.png" /><figcaption>Figure 6: NGB (Near-infrared, Green, Blue) picture triggered by the OBC during the system's imaging state.</figcaption></figure>

## 7 Limitations and Further Work

Despite the successful outcome of applying the proposed method, some inherent shortcomings are evident.

In its current proposal, it relies on manual processes for implementation and verification, despite our attempt to formalise them as much as possible. Not only are these tedious, repetitive activities – more importantly, they represent significant entry points for inconsistencies and bugs, which would defy the core concept of this work. However, we expect this to be feasibly addressable: the architectural implementation steps can be automated by analysing the Capella model and generating the appropriate TASTE files based on the chosen semantic mappings, as demonstrated in [18].

Likewise, back-propagating low-level changes from TASTE to Capella is also a time-consuming activity, despite its critical role in maintaining consistency between the models when complying with embedded constraints. Again, an approach similar to that of [18] but with reversed order could be used to automate this: the TASTE model would be analysed first, then the Capella model would be adjusted based on the chosen semantic mappings. However, this is not a semantically trivial task, as some changes might require further back-propagation into higher levels of abstraction and likely arbitrary design decisions.

Particular cases are the verification activities, where the capabilities of the tools either enable or hinder attempts to automate different steps.

An example of the first case is FSM comparison. Currently, this is only envisioned at the component level, and performed manually. In addition to being an opportunity to miss discrepancies, this approach fails to address the levels that would benefit the most from this step: components are the simplest entities in the model, and therefore the most trivial to verify; conversely, as complexity grows at higher levels of abstraction, unforeseen interactions might arise within subsystems and ultimately the entire system, which the current proposal would leave unchecked. However, TASTE already supports exhaustive model-checking capabilities [23]–[26], which would enable this activity to be automated, formalised, and extended to all levels.

An example of the second case is MSC comparison. Capella appears to lack an exact match for TASTE's MSCs: [ES] diagrams represent exchanges and states, but have no means of representing the values of the data exchanged. Similarly, TASTE lacks the means
## 5.6 Higher-Level Testing

For the sake of brevity, we omit the MSC and E2E verification activities at higher levels of abstraction – subsystem integration and system acceptance. In light of the simplicity of the features presented in this paper, these can be derived by reducing the unit-level diagrams to only consider the exchanges that cross the boundaries between entities at the chosen level.

## 6 Results

The presented system mode management feature was integrated with hardware and launched in our experimental sounding balloon mission *CloudView*, reaching an estimated altitude of over 35km over a flight time of approximately 3 hours.

As the hardware node for the Pipeline subsystem is (yet) unsupported by TASTE, its software was developed separately, and communication with the OBC handled through the HAL; additionally, due to time constraints, the Area-of-Interest-based and telecommand-based triggering of mode changes was substituted with simple recurring timers. However, apart from said exceptions, the core architecture and logic were unchanged, and ran successfully for the entire duration of the mission, capturing and processing images such as the one shown in fig. 6.

<figure><img src="image_7.png" /><figcaption>Figure 6: NGB (Near-infrared, Green, Blue) picture triggered by the OBC during the system's imaging state.</figcaption></figure>

## 7 Limitations and Further Work

Despite the successful outcome of applying the proposed method, some inherent shortcomings are evident.

In its current proposal, it relies on manual processes for implementation and verification, despite our attempt to formalise them as much as possible. Not only are these tedious, repetitive activities – more importantly, they represent significant entry points for inconsistencies and bugs, which would defy the core concept of this work. However, we expect this to be feasibly addressable: the architectural implementation steps can be automated by analysing the Capella model and generating the appropriate TASTE files based on the chosen semantic mappings, as demonstrated in [18].

Likewise, back-propagating low-level changes from TASTE to Capella is also a time-consuming activity, despite its critical role in maintaining consistency between the models when complying with embedded constraints. Again, an approach similar to that of [18] but with reversed order could be used to automate this: the TASTE model would be analysed first, then the Capella model would be adjusted based on the chosen semantic mappings. However, this is not a semantically trivial task, as some changes might require further back-propagation into higher levels of abstraction and likely arbitrary design decisions.

Particular cases are the verification activities, where the capabilities of the tools either enable or hinder attempts to automate different steps.

An example of the first case is FSM comparison. Currently, this is only envisioned at the component level, and performed manually. In addition to being an opportunity to miss discrepancies, this approach fails to address the levels that would benefit the most from this step: components are the simplest entities in the model, and therefore the most trivial to verify; conversely, as complexity grows at higher levels of abstraction, unforeseen interactions might arise within subsystems and ultimately the entire system, which the current proposal would leave unchecked. However, TASTE already supports exhaustive model-checking capabilities [23]–[26], which would enable this activity to be automated, formalised, and extended to all levels.

An example of the second case is MSC comparison. Capella appears to lack an exact match for TASTE's MSCs: [ES] diagrams represent exchanges and states, but have no means of representing the values of the data exchanged. Similarly, TASTE lacks the means
to fully handle MSCs at all levels of abstraction: generation is only supported at the component and system levels while execution is only supported at the system level; subsystem-level generation relies on manual reduction of component-level diagrams, and its execution is not supported. Therefore, work on automating and formalising these activities would require prior extensions of Capella, TASTE, or both.

## 8 Conclusions

In this paper, we have presented a process to bridge the native MBSE workflows of Capella and TASTE. We have presented the novel mappings it relies on, and detailed the steps in its design, implementation, and verification stages, which extend [18] in both breadth and depth – at the cost of manual execution. Additionally, we have demonstrated the method’s reliability by applying it to the development of case-study flight software, which successfully powered an autonomous stratospheric balloon mission. Among the shortcomings we have identified in our method and its tools, FSM verification stands out as a particularly interesting candidate for future improvements.

## Acknowledgements

The authors wish to particularly thank: Dr. Anna Lito Michala and Dr. Oana Andrei from the University of Glasgow for providing their expertise in reviewing embedded software and model-checking practices; Mr. Maxime Perrotin from the European Space Agency, Michał Kurowski and Rafał Babski from N7Space, for giving up their free time to troubleshoot and overcome the limitations of TASTE.

## References

[1] ITU-T Study Group 17, ITU-T Z.100: Specification and Description Language - Overview of SDL-2010, Recommendation, version 11.0, Jun. 13, 2021. [Online]. Available: https://handle.itu.int/11.1002/1000/14670, in force.

[2] ITU-T Study Group 17, ITU-T Z.120: Message Sequence Chart (MSC), Recommendation, version 5.0, Feb. 13, 2011. [Online]. Available: https://handle.itu.int/11.1002/1000/11063, in force.

[3] A. W. Wymore, Model-Based Systems Engineering: An Introduction to the Mathematical Theory of Discrete Systems and to the Tricotyledon Theory of System Design. CRC Press, Apr. 5, 1993, 732 pp., ISBN: 978-1-351-43108-8.

[4] SEBoK. "Model-based systems engineering adoption trends 2009-2018 – SEBoK." (2023), [Online]. Available: https://sebokwiki.org/w/index.php?title=Model-Based_Systems_Engineering_Adoption_Trends_2009-2018.

[5] M. Bone and R. Cloutier, "The current state of model based systems engineering: Results from the OMG™ SysML request for information 2009," presented at the 8th Conference on Systems Engineering Research (CSER), Hoboken, NJ, USA, Mar. 17, 2010. [Online]. Available: http://www.omgsysml.org/SysML_2009_RFIayoResponse_Summary-bone-cloutier.pdf.

[6] R. Cloutier, "2018 Model Based Systems Engineering Survey," presented at the 2019 INCOSE MBSE Workshop (Torrance, CA, USA), Jan. 27, 2019. [Online]. Available: https://www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:incose_mbse_iw_2019:03_2018_mbse_analysis-10.pdf.

[7] A. Vogelsang, T. Amorim, F. Pudlitz, P. Gersing, and J. Philipps, "Should I Stay or Should I Go? On Forces that Drive and Prevent MBSE Adoption in the Embedded Systems Industry," in Product-Focused Software Process Improvement, M. Felderer, D. Méndez Fernández, B. Turhan, M. Kalinowski, F. Sarro, and D. Winkler, Eds., ser. Lecture Notes in Computer Science, Cham: Springer International Publishing, 2017, pp. 182–198, ISBN: 978-3-319-69926-4. DOI: 10.1007/978-3-319-69926-4_14.

[8] M. Rashid, M. W. Anwar, and A. M. Khan, "Identification of trends for model based development of embedded systems," in 2015 12th International Symposium on Programming and Systems (ISPS), Apr. 2015, pp. 1–8. DOI: 10.1109/ISPS.2015.7245004. [Online]. Available: https:
to fully handle MSCs at all levels of abstraction: generation is only supported at the component and system levels while execution is only supported at the system level; subsystem-level generation relies on manual reduction of component-level diagrams, and its execution is not supported. Therefore, work on automating and formalising these activities would require prior extensions of Capella, TASTE, or both.

# 8 Conclusions

In this paper, we have presented a process to bridge the native MBSE workflows of Capella and TASTE. We have presented the novel mappings it relies on, and detailed the steps in its design, implementation, and verification stages, which extend [18] in both breadth and depth – at the cost of manual execution. Additionally, we have demonstrated the method’s reliability by applying it to the development of case-study flight software, which successfully powered an autonomous stratospheric balloon mission. Among the shortcomings we have identified in our method and its tools, FSM verification stands out as a particularly interesting candidate for future improvements.

# Acknowledgements

The authors wish to particularly thank: Dr. Anna Lito Michala and Dr. Oana Andrei from the University of Glasgow for providing their expertise in reviewing embedded software and model-checking practices; Mr. Maxime Perrotin from the European Space Agency, Michał Kurowski and Rafał Babski from N7Space, for giving up their free time to troubleshoot and overcome the limitations of TASTE.

# References

[1] ITU-T Study Group 17, ITU-T Z.100: Specification and Description Language - Overview of SDL-2010, Recommendation, version 11.0, Jun. 13, 2021. [Online]. Available: https://handle.itu.int/11.1002/1000/14670, in force.

[2] ITU-T Study Group 17, ITU-T Z.120: Message Sequence Chart (MSC), Recommendation, version 5.0, Feb. 13, 2011. [Online]. Available: https://handle.itu.int/11.1002/1000/11063, in force.

[3] A. W. Wymore, Model-Based Systems Engineering: An Introduction to the Mathematical Theory of Discrete Systems and to the Tricotyledon Theory of System Design. CRC Press, Apr. 5, 1993, 732 pp., ISBN: 978-1-351-43108-8.

[4] SEBoK. "Model-based systems engineering adoption trends 2009-2018 – SEBoK." (2023), [Online]. Available: https://sebokwiki.org/w/index.php?title=Model-Based_Systems_Engineering_Adoption_Trends_2009-2018.

[5] M. Bone and R. Cloutier, "The current state of model based systems engineering: Results from the OMG™ SysML request for information 2009," presented at the 8th Conference on Systems Engineering Research (CSER), Hoboken, NJ, USA, Mar. 17, 2010. [Online]. Available: http://www.omgsysml.org/SysML_2009_RFIayoResponse_Summary-bone-cloutier.pdf.

[6] R. Cloutier, "2018 Model Based Systems Engineering Survey," presented at the 2019 INCOSE MBSE Workshop (Torrance, CA, USA), Jan. 27, 2019. [Online]. Available: https://www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:incose_mbse_iw_2019:03_2018_mbse_analysis-10.pdf.

[7] A. Vogelsang, T. Amorim, F. Pudlitz, P. Gersing, and J. Philipps, "Should I Stay or Should I Go? On Forces that Drive and Prevent MBSE Adoption in the Embedded Systems Industry," in Product-Focused Software Process Improvement, M. Felderer, D. Méndez Fernández, B. Turhan, M. Kalinowski, F. Sarro, and D. Winkler, Eds., ser. Lecture Notes in Computer Science, Cham: Springer International Publishing, 2017, pp. 182–198, ISBN: 978-3-319-69926-4. DOI: 10.1007/978-3-319-69926-4_14.

[8] M. Rashid, M. W. Anwar, and A. M. Khan, "Identification of trends for model based development of embedded systems," in 2015 12th International Symposium on Programming and Systems (ISPS), Apr. 2015, pp. 1–8. DOI: 10.1109/ISPS.2015.7245004. [Online]. Available: https:
// ieeexplore.ieee.org/abstract/
document/7245004.

[9] T. Amorim, A. Vogelsang, F. Pudlitz, P. Gersing, and J. Philipps, “Strategies and Best Practices for Model-Based Systems Engineering Adoption in Embedded Systems Industry,” in *2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP)*, May 2019, pp. 203–212. DOI: 10.1109/ICSE-SEIP.2019.00030. [Online]. Available: https://ieeexplore.ieee.org/abstract/document/8804427.

[10] S. Bonnet, J.-L. Voirin, D. Exertier, and V. Normand, “Not (strictly) relying on SysML for MBSE: Language, tooling and development perspectives: The Arcadia/Capella rationale,” in *2016 Annual IEEE Systems Conference (SysCon)*, Apr. 2016, pp. 1–6. DOI: 10.1109/SYSCON.2016.7490559. [Online]. Available: https://ieeexplore.ieee.org/document/7490559.

[11] P. Roques, “MBSE with the ARCA-DIA Method and the Capella Tool,” in *8th European Congress on Embedded Real Time Software and Systems (ERTS 2016)*, Toulouse, France, Jan. 2016. [Online]. Available: https://hal.science/hal-01258014.

[12] J.-L. Voirin, *Model-Based System and Architecture Engineering with the Arcadia Method*. Elsevier, Nov. 22, 2017, 390 pp., ISBN: 978-0-08-101794-4.

[13] P. Roques, *Systems Architecture Modeling with the Arcadia Method: A Practical Guide to Capella*. Elsevier, Nov. 22, 2017, 294 pp., ISBN: 978-0-08-101792-0.

[14] M. Perrotin, E. Conquet, P. Dissaux, T. Tsiodras, and J. Hugues, “The TASTE Toolset: Turning human designed heterogeneous systems into computer built homogeneous software,” in *ERTS2010, Embedded Real Time Software & Systems*, Toulouse, France, May 2010. [Online]. Available: https://hal.science/hal-02264382.

[15] M. Perrotin, E. Conquet, J. Delange, and T. Tsiodras, “TASTE: An open-source tool-chain for embedded system and software development,” in *Embedded Real Time Software and Systems (ERTS2012)*, Toulouse, France, Feb. 2012. [Online]. Available: https://hal.science/hal-02191871.

[16] M. Perrotin, E. Conquet, J. Delange, A. Schiele, and T. Tsiodras, “TASTE: A Real-Time Software Engineering Tool-Chain Overview, Status, and Future,” in *SDL 2011: Integrating System and Software Modeling*, I. Ober and I. Ober, Eds., ser. Lecture Notes in Computer Science, Berlin, Heidelberg: Springer, 2012, pp. 26–37, ISBN: 978-3-642-25264-8. DOI: 10.1007/978-3-642-25264-8_4.

[17] M. Perrotin, K. Grochowski, M. Verhoef, et al., “TASTE in action,” in *8th European Congress on Embedded Real Time Software and Systems (ERTS 2016)*, Toulouse, France, Jan. 2016. [Online]. Available: https://hal.science/hal-01289678 (visited on 03/11/2024).

[18] M. Kurowski, A. Wójcik, M. Kocon, et al., “Capella to TASTE MBSE bridge,” presented at the Model Based Systems and Software Engineering Workshop, Noordwijk, The Netherlands, Sep. 28–29, 2020. [Online]. Available: https://indico.esa.int/event/329/timetable.

[19] P. Boan and B. Attanasio, “Functional Chain Approach for Avionics Modelling and Simulation,” presented at the Model Based Space Systems and Software Engineering Workshop, Noordwijk, The Netherlands, Sep. 29–30, 2021. [Online]. Available: https://indico.esa.int/event/386/timetable.

[20] G. Ciacchella, A. Mohammad, and S. Zurawski. “IAC23.D1,IP,6,x77646 Interactive Poster,” IAC23 Interactive Posters. (Oct. 2–6, 2023), [Online]. Available: https://iac2023-iaf.ipostersessions.com/default.aspx?SID=B6-B6-08-15-0D-B5-9F-07-EF-43-D7-23-EC-37-78-9C.
// ieeexplore.ieee.org/abstract/
document/7245004.

[9] T. Amorim, A. Vogelsang, F. Pudlitz, P. Gersing, and J. Philipps, “Strategies and Best Practices for Model-Based Systems Engineering Adoption in Embedded Systems Industry,” in *2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP)*, May 2019, pp. 203–212. DOI: 10.1109/ICSE-SEIP.2019.00030. [Online]. Available: https://ieeexplore.ieee.org/abstract/document/8804427.

[10] S. Bonnet, J.-L. Voirin, D. Exertier, and V. Normand, “Not (strictly) relying on SysML for MBSE: Language, tooling and development perspectives: The Arcadia/Capella rationale,” in *2016 Annual IEEE Systems Conference (SysCon)*, Apr. 2016, pp. 1–6. DOI: 10.1109/SYSCON.2016.7490559. [Online]. Available: https://ieeexplore.ieee.org/document/7490559.

[11] P. Roques, “MBSE with the ARCA-DIA Method and the Capella Tool,” in *8th European Congress on Embedded Real Time Software and Systems (ERTS 2016)*, Toulouse, France, Jan. 2016. [Online]. Available: https://hal.science/hal-01258014.

[12] J.-L. Voirin, *Model-Based System and Architecture Engineering with the Arcadia Method*. Elsevier, Nov. 22, 2017, 390 pp., ISBN: 978-0-08-101794-4.

[13] P. Roques, *Systems Architecture Modeling with the Arcadia Method: A Practical Guide to Capella*. Elsevier, Nov. 22, 2017, 294 pp., ISBN: 978-0-08-101792-0.

[14] M. Perrotin, E. Conquet, P. Dissaux, T. Tsiodras, and J. Hugues, “The TASTE Toolset: Turning human designed heterogeneous systems into computer built homogeneous software,” in *ERTS2010, Embedded Real Time Software & Systems*, Toulouse, France, May 2010. [Online]. Available: https://hal.science/hal-02264382.

[15] M. Perrotin, E. Conquet, J. Delange, and T. Tsiodras, “TASTE: An open-source tool-chain for embedded system and software development,” in *Embedded Real Time Software and Systems (ERTS2012)*, Toulouse, France, Feb. 2012. [Online]. Available: https://hal.science/hal-02191871.

[16] M. Perrotin, E. Conquet, J. Delange, A. Schiele, and T. Tsiodras, “TASTE: A Real-Time Software Engineering Tool-Chain Overview, Status, and Future,” in *SDL 2011: Integrating System and Software Modeling*, I. Ober and I. Ober, Eds., ser. Lecture Notes in Computer Science, Berlin, Heidelberg: Springer, 2012, pp. 26–37, ISBN: 978-3-642-25264-8. DOI: 10.1007/978-3-642-25264-8_4.

[17] M. Perrotin, K. Grochowski, M. Verhoef, et al., “TASTE in action,” in *8th European Congress on Embedded Real Time Software and Systems (ERTS 2016)*, Toulouse, France, Jan. 2016. [Online]. Available: https://hal.science/hal-01289678 (visited on 03/11/2024).

[18] M. Kurowski, A. Wójcik, M. Kocon, et al., “Capella to TASTE MBSE bridge,” presented at the Model Based Systems and Software Engineering Workshop, Noordwijk, The Netherlands, Sep. 28–29, 2020. [Online]. Available: https://indico.esa.int/event/329/timetable.

[19] P. Boan and B. Attanasio, “Functional Chain Approach for Avionics Modelling and Simulation,” presented at the Model Based Space Systems and Software Engineering Workshop, Noordwijk, The Netherlands, Sep. 29–30, 2021. [Online]. Available: https://indico.esa.int/event/386/timetable.

[20] G. Ciacchella, A. Mohammad, and S. Zurawski. “IAC23.D1,IP,6,x77646 Interactive Poster,” IAC23 Interactive Posters. (Oct. 2–6, 2023), [Online]. Available: https://iac2023-iaf.ipostersessions.com/default.aspx?SID=B6-B6-08-15-0D-B5-9F-07-EF-43-D7-23-EC-37-78-9C.
[21] R. Babski, M. Kurowski, K. Grochowski, and M. Perrotin, "Tiny Runtime to Run Model-Based Software on CubeSats," presented at the Model Based Systems and Software Engineering Workshop, Noordwijk, The Netherlands, Sep. 28-29, 2020. [Online]. Available: https://indico.esa.int/event/329/timetable.

[22] G. Ciacchella. "Astraeus-01 System Model." (2023), [Online]. Available: https://guorbit.github.io/obc-model/cloudview-1/html_export/output/obc-model/index.html.

[23] S. Duncan, "Model-based techniques for space microcontroller applications," Sep. 29, 2020.

[24] M. Kurowski, R. Babski, S. Duncan, M. Perrotin, and M. Webster, "Model Checking for Formal Verification of Space Systems," presented at the Model Based Systems and Software Engineering Workshop, Noordwijk, The Netherlands, Sep. 29-30, 2021. [Online]. Available: https://indico.esa.int/event/386/timetable.

[25] I. Dragomir, M. Bozga, I. Ober, D. Silveira, E. Alaña, and T. M. Jorge, "Formal Verification of Space Systems Designed with TASTE," presented at the Model Based Space Systems and Software Engineering Workshop, Noordwijk, The Netherlands, Sep. 29-30, 2021. [Online]. Available: https://indico.esa.int/event/386/timetable.

[26] I. Dragomir, C. Redondo, T. M. Jorge, et al., "Model-Checking for TASTE designed Space Software Systems: Results and Lessons Learned," presented at the Model-Based Systems and Software Engineering Workshop, Toulouse, France, Nov. 23-24, 2022. [Online]. Available: https://indico.esa.int/event/407/timetable.
[21] R. Babski, M. Kurowski, K. Grochowski, and M. Perrotin, "Tiny Runtime to Run Model-Based Software on CubeSats," presented at the Model Based Systems and Software Engineering Workshop, Noordwijk, The Netherlands, Sep. 28-29, 2020. [Online]. Available: https://indico.esa.int/event/329/timetable.

[22] G. Ciacchella. "Astraeus-01 System Model." (2023), [Online]. Available: https://guorbit.github.io/obc-model/cloudview-1/html_export/output/obc-model/index.html.

[23] S. Duncan, "Model-based techniques for space microcontroller applications," Sep. 29, 2020.

[24] M. Kurowski, R. Babski, S. Duncan, M. Perrotin, and M. Webster, "Model Checking for Formal Verification of Space Systems," presented at the Model Based Systems and Software Engineering Workshop, Noordwijk, The Netherlands, Sep. 29-30, 2021. [Online]. Available: https://indico.esa.int/event/386/timetable.

[25] I. Dragomir, M. Bozga, I. Ober, D. Silveira, E. Alaña, and T. M. Jorge, "Formal Verification of Space Systems Designed with TASTE," presented at the Model Based Space Systems and Software Engineering Workshop, Noordwijk, The Netherlands, Sep. 29-30, 2021. [Online]. Available: https://indico.esa.int/event/386/timetable.

[26] I. Dragomir, C. Redondo, T. M. Jorge, et al., "Model-Checking for TASTE designed Space Software Systems: Results and Lessons Learned," presented at the Model-Based Systems and Software Engineering Workshop, Toulouse, France, Nov. 23-24, 2022. [Online]. Available: https://indico.esa.int/event/407/timetable.
A Function Implementations

<figure><img src="image_8.png" /><figcaption>Figure 7: TASTE SDL implementation of the Mode Change Telecommand Handler's initial transition.</figcaption></figure>
A Function Implementations

<figure><img src="image_8.png" /><figcaption>Figure 7: TASTE SDL implementation of the Mode Change Telecommand Handler's initial transition.</figcaption></figure>
<figure><img src="image_9.png" /><figcaption>Figure 8: TASTE SDL implementation of the Mode Change Telecommand Handler's transition from "Wait for TC" to "Wait for Report".</figcaption></figure>

<figure><img src="image_10.png" /><figcaption>Figure 9: TASTE SDL implementation of the Mode Change Telecommand Handler's transition from "Wait for Report" to "Wait for TC".</figcaption></figure>

<figure><img src="image_11.png" /><figcaption>Figure 10: TASTE SDL implementation of the System Mode Manager's initial transition.</figcaption></figure>
<figure><img src="image_9.png" /><figcaption>Figure 8: TASTE SDL implementation of the Mode Change Telecommand Handler's transition from "Wait for TC" to "Wait for Report".</figcaption></figure>

<figure><img src="image_10.png" /><figcaption>Figure 9: TASTE SDL implementation of the Mode Change Telecommand Handler's transition from "Wait for Report" to "Wait for TC".</figcaption></figure>

<figure><img src="image_11.png" /><figcaption>Figure 10: TASTE SDL implementation of the System Mode Manager's initial transition.</figcaption></figure>
<figure><img src="image_12.png" /><figcaption>Figure 11: TASTE SDL implementation of the System Mode Manager’s transition from “Wait for Trigger” to “Wait for Payload Response”.</figcaption></figure>

<figure><img src="image_13.png" /><figcaption>Figure 12: TASTE SDL implementation of the System Mode Manager’s transition from “Wait for Payload Response” to “Wait for Pipeline Response”.</figcaption></figure>
<figure><img src="image_12.png" /><figcaption>Figure 11: TASTE SDL implementation of the System Mode Manager’s transition from “Wait for Trigger” to “Wait for Payload Response”.</figcaption></figure>

<figure><img src="image_13.png" /><figcaption>Figure 12: TASTE SDL implementation of the System Mode Manager’s transition from “Wait for Payload Response” to “Wait for Pipeline Response”.</figcaption></figure>
<figure><img src="image_14.png" /><figcaption>Figure 13: TASTE SDL implementation of the System Mode Manager's transition from “Wait for Pipeline Response” to “Wait for Trigger”.</figcaption></figure>

<figure><img src="image_15.png" /><figcaption>Figure 14: TASTE SDL implementation of the Area of Interest Manager’s initial transition.</figcaption></figure>
<figure><img src="image_14.png" /><figcaption>Figure 13: TASTE SDL implementation of the System Mode Manager's transition from “Wait for Pipeline Response” to “Wait for Trigger”.</figcaption></figure>

<figure><img src="image_15.png" /><figcaption>Figure 14: TASTE SDL implementation of the Area of Interest Manager’s initial transition.</figcaption></figure>
<figure><img src="image_16.png" /><figcaption>Figure 15: TASTE SDL implementation of the Area of Interest Manager's transition about "Wait for Trigger".</figcaption></figure>

<figure><img src="image_17.png" /><figcaption>Figure 16: TASTE SDL implementation of the Area of Interest Manager's transition from "Wait for Trigger" to "Wait for Location".</figcaption></figure>
<figure><img src="image_16.png" /><figcaption>Figure 15: TASTE SDL implementation of the Area of Interest Manager's transition about "Wait for Trigger".</figcaption></figure>

<figure><img src="image_17.png" /><figcaption>Figure 16: TASTE SDL implementation of the Area of Interest Manager's transition from "Wait for Trigger" to "Wait for Location".</figcaption></figure>
<figure><img src="image_18.png" /><figcaption>Figure 17: TASTE SDL implementation of the Area of Interest Manager's transition from “Wait for Location” to “Wait for Trigger”.</figcaption></figure>
<figure><img src="image_18.png" /><figcaption>Figure 17: TASTE SDL implementation of the Area of Interest Manager's transition from “Wait for Location” to “Wait for Trigger”.</figcaption></figure>
## B FSM Comparisons

<figure><img src="image_19.png" /><figcaption>Figure 18: Comparison between FSM views of the Mode Change Telecommand Handler component in Capella ([MSM]) and TASTE.</figcaption></figure>

<figure><img src="image_20.png" /><figcaption>Figure 19: Comparison between FSM views of the System Mode Manager component in Capella ([MSM]) and TASTE. Capella ([MSM]) and TASTE.</figcaption></figure>

<figure><img src="image_21.png" /><figcaption>Figure 20: Comparison between FSM views of the Area of Interest Manager component in Capella ([MSM]) and TASTE.</figcaption></figure>
## B FSM Comparisons

<figure><img src="image_19.png" /><figcaption>Figure 18: Comparison between FSM views of the Mode Change Telecommand Handler component in Capella ([MSM]) and TASTE.</figcaption></figure>

<figure><img src="image_20.png" /><figcaption>Figure 19: Comparison between FSM views of the System Mode Manager component in Capella ([MSM]) and TASTE. Capella ([MSM]) and TASTE.</figcaption></figure>

<figure><img src="image_21.png" /><figcaption>Figure 20: Comparison between FSM views of the Area of Interest Manager component in Capella ([MSM]) and TASTE.</figcaption></figure>
## C MSC Comparisons

<figure><img src="image_22.png" /><figcaption>Figure 21: Comparison between MSC views of the Telecommanded Mode Change feature in Capella ([ES]) and TASTE.</figcaption></figure>
## C MSC Comparisons

<figure><img src="image_22.png" /><figcaption>Figure 21: Comparison between MSC views of the Telecommanded Mode Change feature in Capella ([ES]) and TASTE.</figcaption></figure>
<figure><img src="image_23.png" /><figcaption>Figure 22: Comparison between MSC views of the Area of Interest Management feature in Capella ([ES]) and TASTE.</figcaption></figure>
<figure><img src="image_23.png" /><figcaption>Figure 22: Comparison between MSC views of the Area of Interest Management feature in Capella ([ES]) and TASTE.</figcaption></figure>
## D E2E Comparisons

<figure><img src="image_24.png" /><figcaption>Figure 23: Comparison between E2E views of the Telecommanded Mode Change feature in Capella ([PAB]) and TASTE.</figcaption></figure>
## D E2E Comparisons

<figure><img src="image_24.png" /><figcaption>Figure 23: Comparison between E2E views of the Telecommanded Mode Change feature in Capella ([PAB]) and TASTE.</figcaption></figure>
<figure><img src="image_25.png" /><figcaption>Figure 24: Comparison between MSC views of the Area of Interest Management feature in Capella ([PAB]) and TASTE.</figcaption></figure>
<figure><img src="image_25.png" /><figcaption>Figure 24: Comparison between MSC views of the Area of Interest Management feature in Capella ([PAB]) and TASTE.</figcaption></figure>