Julien Deantoni

João Cambeiro

Soroush Bateni
email: soroush@utdallas.edu

Shaokai Lin
email: shaokai@berkeley.edu

Marten Lohstroh
email: marten@berkeley.edu

Debugging and Verification Tools for LINGUA FRANCA in GEMOC Studio

à 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.

I. INTRODUCTION

Cyber-physical systems (CPSs) are becoming increasingly complex, built using an intricate composition of complicated software, hardware, and networked systems. This complexity in design inherently makes CPS development difficult and error-prone. Consequently, the challenges associated with managing concurrency, timing, and distributed computing also multiply proportionally. To tackle these challenges, very recently, a comprehensive solution is proposed in the form of LINGUA FRANCA (LF) [START_REF] Lohstroh | Toward a Lingua Franca for deterministic concurrent systems[END_REF], a polyglot coordination language designed for the deterministic composition of concurrent, time-sensitive, and potentially distributed reactive components called reactors. LF is aimed at simplifying the design and implementation of CPSs through a programming model with sophisticated runtime support that delivers deterministic behavior under quantifiable assumptions.

LF provides a coordination layer based on reactors [START_REF] Lohstroh | Reactors: A deterministic model for composable reactive systems[END_REF], [START_REF] Lohstroh | Reactors: A deterministic model of concurrent computation for reactive systems[END_REF], a model of computation that combines aspects from actors, discrete-event systems, and synchronous languages. This coordination layer is meant to complement mainstream programming languages. So far, LF supports C, C++, Python, and TypeScript as target languages, each of which requires a dedicated code generator and a supporting runtime library. As LF becomes more popular and adds support for more target languages, two issues arise.

First, the underlying code generators and runtime libraries can become tedious to debug. Currently, each code generator and runtime library is subjected to an extensive suite of regression tests that verify strict compliance with the reactor semantics and the LF syntax. However, if a regression test fails, there is not much to go by other than the end result of the test. During the development phase of a new target (or while adding new language features) it may be helpful to the developers to have an easy way to compare the execution trace of a failing test against the set of valid traces (i.e., linearizations of one partial-order trace) permitted by the reactor model. Such capability can help reveal how and why a certain violation of the reactor semantics has occurred.

Second, from a higher-level user perspective, debugging an LF program is currently only possible on the basis of generated code, by executing it using the debugging facilities of the target language (e.g., gdb for C), or with the help of print statements. But this tends to be cumbersome-particularly for lower-level languages like C-because the generated code obfuscates the high-level structure of the program.

To enable a more sophisticated debugging functionality in LF, one could look at existing approaches that are developed for other domain-specific languages (DSLs) that establish a mapping between the DSL and the implementation language [START_REF] Pavletic | Extensible debuggers for extensible languages[END_REF], [START_REF] Chis | The moldable debugger: A framework for developing domain-specific debuggers[END_REF]. However, since LF is polyglot, the substantial task of creating such a mapping would have to be repeated for each individual target language. Hence, we pursue a more flexible design that is nonetheless capable of integrating into the LF IDE. Contributions. As a starting point for our debugging framework, we use GEMOC Studio [START_REF] Bousse | Execution framework of the GEMOC studio (tool demo)[END_REF]. We then implement the two following methods to debug an LF program: a) Interactive debugger: We directly weave an abstract execution model of LF into its syntactic definition, so that LF reaction code (assumed to be written in Groovy for our proof-of-concept implementation) can be interpreted through this abstract model. More precisely, we use the GEMOC MoCCML approach, which relies on a clock calculus to support the definition of concurrent and timed operational semantics.

a u t h o r v e r s i o n

Based on this, we implement a rich debugging environment with the possibility to go forward and backward in time, as well as to inspect the state of the LF program directly at the LF level of abstraction. Our developed tooling also provides model animation and supports exhaustive simulation of the program. b) Trace debugger: We add the possibility to inject execution traces obtained from the execution of compiled LF programs directly in the development environment. This enables target runtime developers to validate execution traces that are obtained through a standardized tracing interface against the LF semantics, and detect any deviation thereof from the correct behavior. Unlike the interactive debugger, which requires reaction code to be interpreted, this feature is compatible with any target that has a runtime capable of producing execution traces.

We provide a brief overview of LF and the GEMOC MoCCML approach in Section II. We discuss the operational semantics of LF and its implementation in GEMOC in Section III. We demonstrate the usage of our tooling in Section IV. Finally, we position our contributions with respect to related work in Section V and conclude in Section VI.

II. BACKGROUND

A. Lingua Franca LINGUA FRANCA (LF) [START_REF] Lohstroh | Toward a Lingua Franca for deterministic concurrent systems[END_REF] is a new polyglot coordination language aimed to simplify the design and implementation of concurrent, time-sensitive, and distributed software. It provides supported target languages with a semantic notion of time, deterministic concurrency, and transparent exploitation of parallelism. LF is based on the reactor model [START_REF] Lohstroh | Reactors: A deterministic model for composable reactive systems[END_REF], [START_REF] Lohstroh | Reactors: A deterministic model of concurrent computation for reactive systems[END_REF], in which components-homonymously called reactors-are composed under a discrete-event semantics. Reactors follow much of the style of actors [START_REF] Hewitt | A universal modular ACTOR formalism for artificial intelligence[END_REF], with the crucial difference that communication between reactors is timestamped, and deterministic unless specified otherwise. The goal of LF is to relegate the many difficulties associated with concurrent programming [START_REF] Lee | The problem with threads[END_REF] as much as possible to the supporting runtime system, away from the program logic.

Reactors have ports which allow them to be connected to other reactors. Beside connections, reactors can also be composed hierarchically (through containment). The functionality of a reactor is expressed through its reactions, which execute in response to the presence of one or more triggers. A triggering event is always associated with a tag that denotes the current logical time. Any outputs that a reaction produces will have the same tag of the event that triggered it. Hence, reactions are logically instantaneous, following principles of synchronous programming [START_REF] Benveniste | The synchronous approach to reactive and real-time systems[END_REF].

In LF, reactions are written in verbatim target code. Each of these target code segments is treated by the LF compiler as a "black box." The compiler merely inserts them into the appropriate locations within the target code it generates on the basis of the composition of reactors specified by the LF program. All that matters to the compiler and the runtime system are the dependencies between reactions, which inform the orders in which reactions can be executed without breaking the reactor semantics. This approach allows the runtime system to transparently exploit parallelism, without any engineering effort or hints in the form of pragmas needed from the application developer.

B. The GEMOC MoCCML approach

GEMOC studio [START_REF] Bousse | Execution framework of the GEMOC studio (tool demo)[END_REF] is an Eclipse project1 that provides a set of metalanguages for the definition of the operational semantics of programming languages. Specifically, GEMOC studio supports languages that are specified using the Eclipse Modeling Framework (EMF) [START_REF] Steinberg | EMF: eclipse modeling framework[END_REF], which is a modeling framework and code generation facility for building language tools and applications based on a structured data model called an Ecore model. The current implementation of LF is based on Xtext2 , a framework that automatically generates an Ecore model based on a textual language definition (an Xtext grammar). In GEMOC studio, the Ecore model, which merely captures the syntactic aspects of the language, can be complemented with a Model of Concurrency and Communication (MoCC) [START_REF] Combemale | Reifying concurrency for executable metamodeling[END_REF], [START_REF] Deantoni | Operational semantics of the model of concurrency and communication language[END_REF], [START_REF] Deantoni | Towards a meta-language for the concurrency concern in DSLs[END_REF] to define an execution semantics with formal support of concurrency and timing. In this approach, the operational semantics is defined by four different artifacts:

1) The runtime program state, which represents the state of the program during execution. Inspired by the approach of attribute grammars [START_REF] Knuth | The genesis of attribute grammars[END_REF], the runtime state is woven directly into the concepts of the languages (i.e., into the Ecore model) by using Kermeta 3 (K3) 3 -an action language (i.e., a language for specifying state transitions systems) primarily designed for implementing the execution semantics of Ecore metamodels. 2) A set of rewriting rules, which manipulate the runtime program state. These are also woven into the Ecore model and defined imperatively using K3. 3) A set of Domain Specific Events (DSEs), which are events of interest in the concurrent and timed execution semantics of the language. They are part of the MoCC and define the observable atomic actions in an execution trace. Some of these events are associated with a rewriting rule and act as handle on the rewriting rules call. Like other artifacts, they are also woven into the Ecore model by using a mapping provided by the MoCCML language [START_REF] Deantoni | ECL: the event constraint language, an extension of OCL with events[END_REF]. The mapping also contains behavioral invariants, which define ordering constraints that must be respected for any execution, and use constraints as defined in the next item. 4) A set of formal domain-specific constraints, put in conjunction, to be enforced during execution. These constraints induce a partial order of the DSE instances. They are specified by using CCSL constraints as defined originally [START_REF] Deantoni | CCSL denotational semantics[END_REF], or by using constraint automata introduced in MoCCML [START_REF] Deantoni | Operational semantics of the model of concurrency and communication language[END_REF]. Such constraints allows expressing mixtures of synchronous and asynchronous a u t h o r v e r s i o n ordering requirements on DSEs; enabling the symbolic specification of partially ordered sets of clock ticks, which is well-suited for the description of large sets of model control flow [START_REF] Deantoni | Towards formal system modeling: Making explicit and formal the concurrent and timed operational semantics to better understand heterogeneous models[END_REF]. For a specific program conforming to the abstract syntax, the DSEs (and the associated constraints) are instantiated in a classical object-oriented way: for each instance of a concept in a program, the DSEs that were woven in the concept are instantiated. MoCCML and CCSL are based on the notion of logical time [START_REF] Lamport | Time, clocks, and the ordering of events in a distributed system[END_REF], [START_REF] Fidge | Logical time in distributed computing systems[END_REF], which was originally designed for distributed and concurrent systems, but which was also used in synchronous languages. They generalize different descriptions of time, based on the notion of clocks-a clock being an ordered set of instants. A DSE instance is then a clock.

Solving an instance of a MoCCML model (i.e., doing a run) results in a schedule. A schedule over a set of clocks is a possibly infinite sequence of steps, where a step is a set of ticking clocks. For each step, one or several clock(s) can tick depending on the imposed constraints. Note that since MoCCML describes partial orders, there possibly exist various schedules for a single specification, which represent different acceptable interleavings of actions (i.e., reaction invocations in the LF program). The operational semantics of a MoCCML model [START_REF] Deantoni | Operational semantics of the model of concurrency and communication language[END_REF] specifies how to construct acceptable schedules step-by-step, and is given as a mapping to a Boolean expression on Boolean variables in bijection with the clocks. In a step, a boolean variable valuated to true means that the clock ticks; and if valuated to false that the clock is absent. Each time a constraint is added to the specification, it adds Boolean constraints, which depend on the definition of the constraint and its internal state. Boolean expressions are put in conjunction so that each added constraint reduces the set of acceptable schedules (also referred to as a trace containment according to [START_REF] Alur | Alternating refinement relations[END_REF]).

Instances of MoCCML models are inputs to the TIMESQUARE tool suite [START_REF] Deantoni | TIMESQUARE: Treat your models with logical time[END_REF], which supports their simulation and is part of the GEMOC engine in the MoCCML approach. Each time a clock ticks, the associated rewriting rule is applied. If various clocks tick during a single step, then the rewriting rule application order is undefined and should consequently not be significant. It is possible to define a data dependent concurrency model (which amounts to the symbolic partial order being pruned at runtime according to the program runtime state [START_REF] Latombe | Weaving concurrency in executable domain-specific modeling languages[END_REF]). This is used, for instance, to specify the control flow of a classical if-then-else statement. Depending on the evaluation of the branch predicate (the outcome of which depends on the model state), either the then or the else branch is taken.

To make a complete definition of the concurrency model, it is also possible to define priorities between the different DSEs [START_REF] Gascon | Priority in logical time partial orders with synchronous relations[END_REF]. Intuitively, for a specific program, if (and only if) according to the constraints, two clocks cannot tick together in the same step, then the clock with the highest priority is chosen at that step.

From the definition of the concurrent and timed operational semantics in MoCCML, GEMOC studio offers an omniscient debugger [START_REF] Lewis | Debugging backwards in time[END_REF] (to go forward and backward in the execution trace and explore new interleaving) and an assertion checker (to check if some constraints are enforced or not during the execution). Extensions realized in the context of this paper also provides an integration with the CADP model checker [START_REF] Garavel | CADP 2011: a toolbox for the construction and analysis of distributed processes[END_REF]. Finally any GEMOC engine can use addons and we developed one for graphical model animation (to help understand the execution).

III. OPERATIONAL SEMANTICS OF LINGUA FRANCA

A. Intuitive Description

The semantics of LF is a hybrid between 1) a discrete event model with support for superdense time [START_REF] Lee | Operational semantics of hybrid systems[END_REF] and 2) a dataflow model to handle concurrency and potential interleaving. Consequently, a run of an LF program evolves around the following two notions.

1) temporal dependencies: These are induced by timed concepts such as timers or actions and connections that have a specified delay. Each synchronous-reactive tick is associated with a logical time represented by a tag (i.e., a pair of integers that represent a time value and a microstep). A new event is enqueued with a tag strictly greater than the current tag. All events are handled in tag order. Each event is tied to a particular trigger that determines which reaction(s) it activates. Time advancement (i.e., reassignment of the current tag such that it is equal to the tag of the event on top of the event queue) cannot occur before all events for the current tag have been handled, and all triggered reactions have executed. Reaction code can schedule a future event to occur after a specified delay through invocation of the schedule routine (e.g., schedule(action1, 10msec) where action1 has to be part of the same reactor and has to be declared as an effect of the reaction). Note that an action can also be scheduled with zero delay, in which case, the resulting event will have a tag with the same time value as the current logical time, but the microstep will be incremented by one.

2) data dependencies: Defined between reactions, they impose ordering constraints on the invocation of reactions during a particular synchronous-reactive tick. A data dependency between two reactions can either be specified explicitly by ordering the reactions inside a single reactor (allowing them to operate on shared state), or by establishing a connection between two ports of distinct reactors (one of which being an effect of the first reaction, the other being a source of the second reaction). These statically known data dependencies are conservative approximations of the actual data dependencies that exist between reactions at runtime; whether reaction code invokes set on a port may depend on the reactor's state and current inputs. A reaction r 1 with an effect y that is connected to a downstream port x known as the trigger of another reaction r 2 will cause r 2 to be triggered if it calls set on y. But r 1 , even if triggered, has no obligation to produce an output (and thus r 2 may not execute, even if r 1 does). This is why the reactor model can also be characterized as a "sparse synchronous" model [START_REF] Edwards | The sparse synchronous model[END_REF].

a u t h o r v e r s i o n

While temporal dependencies are concerned with ordering events on a logical timeline, data dependencies are concerned with partially ordering reactions that occur at the same tag. Time advancement acts as a synchronization barrier for the execution of reactions at a particular tag. As such, we could say that temporal dependencies apply at a coarser grain than data dependencies. Another way to view the interaction between the two is that the preservation of data dependencies has a higher priority than time advancement.

B. Encoding in GEMOC

This section outlines the encoding of the LF operational semantics in terms of the four artifacts introduced in section II-B. The entire encoding can be obtained from GitHub 4 .

1) Runtime Program State: The runtime state σ of an LF program is determined by the following tuple: {P pcv , S scv , A buf , Q E } where P pcv is the set of current values pcv associated with elements in P , the set of ports in the program; S scv is the set of current values scv associated with elements in S, the set of state variables in the program; A buf is the data buffer associated with elements in A, the set actions in the program (including those implied by connections with a specified delay); and Q E is a global priority queue.

In our K3 code, Q E is referred to as eventQ, and its elements are STA (scheduled time advancement) objects. An STA instance represents a scheduled event, identified by a reference to a timed concept (either an action, a timer or a timed connection) and the tag (relative to the current time) at which it must be released. Scheduled events are always stored in an increasing tag order. Furthermore, pcv is represented by currentValue, which is woven into the Variable aspect, a superclass of Port (see Listing 1). When currentValue equals null, it is considered absent (and present otherwise). The type of currentValue is ClonableObject, so that it can be copied. This is required by the framework to allow the omniscient debugger to do backward navigation in time and to construct the state space of the program. 2) Rewriting Rules: The rewriting rules typically modify the runtime program state. For instance, there are two schedule rewriting rules in charge of adding a timed action at the appropriate place in the event queue:

rt, tc ∈ Q E , σ ⇒ f alse σ ; (σ Q E ∪ { rt, 0, tc }) (1) rt, tc ∈ Q E , σ ⇒ true σ ; (σ Q E ∪ { rt, maxµs rt,tc + 1, tc }) (2)
where rt, tc is a tuple for a timed concept tc to be scheduled at the (relative) tag rt; where rt, X, tc is the scheduled time advancement of tc at the tag rt and microstep X and where maxµs rt,tc is the maximum microstep index of the existing scheduled time advancement in Q E corresponding to the timed concept tc at time rt.

These two rewriting rules are encoded as shown in Listing 3. The maxµs rt,tc is stored in lastMS (declared on line 7) and computed along the loop starting on line 8 in case rt, tc ∈ Q E (tested on line 10). The remainder of the code implements the Q E ∪ { rt, X, tc } ensuring the priority order in the queue and the computation of X. Following the same principle, the other rewriting rules have been developed, and most of them are simple. One rewriting rule is a bit more elaborate: the one in charge of executing the code defined in a reaction. Note that since this is encoded in a rewriting rule, it is seen as atomic from a MoCC point of view. Listing 4 provides the code implementing the reaction execution rewriting rule. The reaction code is encoded in the Groovy language (https://groovy-lang.org/). The rewriting rule is in charge of putting the appropriate context variables in the scope of the Groovy code (lines 3 to 5) and to actually execute the code (lines 7 to 9). Note that in addition to the code, we prefix it with the definition of LF specific functions (line 9) to make them available in the reaction code (e.g., the set or the schedule routines). Finally, we check (from lines [START_REF] Combemale | Reifying concurrency for executable metamodeling[END_REF] We have defined a total of 16 rewriting rules. It is important to notice that there is no control flow between these rewriting rules. The two following subsections define the DSEs that act as handles on the invocations of rewriting rules and MoCCML constraints that define the partial order(s) in which rewriting rules must be invoked.

3) Domain Specific Events: The DSEs represent the observable atomic actions in the traces produced by the semantics. As such, it encompass small/big steps semantics. An excerpt of the DSE definition is given in listing 6. For instance, in the context of a Reaction (line 1 to 3), we can observe the start and the finish of the execution. We can also notice that the start DSE is associated with the exec() rewriting rule explained in the previous subsection. Looking at the Variable DSE, we reified present, which occurs when the variable has been set, and absent, which occurs when it has not been set. Finally, updates occurs each time a variable is present or absent. We can see that there exists an isPresent DSE, which is used to define how the MoCC is pruned depending on the actual runtime state of the system. It calls the isPresent() predicate, and according to the result forbids either present or absent (lines 8 to 11). A similar mechanism determines whether a timed concept can be released or not (not shown in the listing). Finally, we reified two types of actions at the root concepts (see lines 13 to 14 of listing 6): atFutureTag, whose instance occurrences represent a call to the atFutureTag() rewriting rule when a timed concept releases (see III-A1); atCurrentTag, which represents events that happen at the current tag, such as ports being set and reactions being invoked (see III-A2). This reification has been done to allow the definition of priorities between them, defining the high level order of actions in a LF program, i.e., atCurrentTag events have a higher priority than atFutureTag events. Listing 6. Some of the DSEs for LF 4) Model of Concurrency and Communication: After the DSEs have been defined on the language, we specified how they are constrained. This is done by reusing existing constraints as defined by CCSL and by defining some domainspecific constraints based on MoCCML automata. Constraining the DSEs is done by defining behavioral invariants in MoCCML, which define when and how to apply the constraints.

In the following, we reuse the CCSL Causes constraint, which takes two DSEs (clocks c 1 and c 2 ) as arguments and specifies that ∀k ∈ N, the k th instant of c 1 to coincide with or precede the k th instant of c 2 .

In Listing 7, the Causes constraint is applied in the context of a Connection (line 1) in case it has no delay specified (line 3). In this case, the first argument of the Causes constraint is the presence of data in the left port (i.e., the source port), and the presence of a data on the right port (i.e., the target port), as defined in line 3. The same pattern is used to specify that the absence of data is propagated through a Connection. In case the Connection has a non-zero delay, meaning that it goes through the event queue instead of propagating downstream directly 5 , we use combination of a CCSL constraint and a MoCCML automaton, which is defined as represented in Figure 1. In the initial state (idle) the connection can be started, which results in the scheduling of its associated action (see the schedule() function in Listing 3). starts can be done several times. Then, when a time advancement a u t h o r v e r s i o n occurs, the connection enters the toCheck state, waiting to check if it can be released or not 6 . When the check is performed, the connection goes in the checked state. There, two outgoing transitions are possible. Either the connection releases, or it waits. These transitions are to be put in relation with the connection between the MoCC and the runtime state of the system. In short, the canT ick event is associated function to a predicate that checks in the event queue if the connection can release or not. This forbids the related DSE, allowing only one of the checked state outgoing transitions to be taken. This constraint is applied in Listing 8, lines 2 to 4. This automaton is not sufficient and causalities must be defined between some of the DSEs used in the automaton and the ones from the source and target of the connection. This is done by again using the Causes constraint (see lines 5 to 14). In short, the presence of a data in the source port starts the connection (schedules it), when the connection releases it, this causes the presence of a data in the target port and when the source port is absent, or, when the connection waits, it causes an absence in the target port. Other constraints follow the same pattern. In total, we define 56 behavioral invariants to specify the scheduling of LF rewriting rules.

IV. DEBUGGING AND VERIFICATION TOOLS

We employ a simple example, depicted in the bottom portion of Figure 2, to illustrate the tooling resulting from the encoding of LF operational semantics in GEMOC Studio. More examples are provided in the GitHub repository mentioned in Section III. The sensor fusion LF program defines three 6 Intuitively, the semantics of the automaton is given as a mapping to a Boolean expression on the Boolean variable corresponding to the clocks used in the automaton. For instance, in the idle state, the resulting boolean constraint is ¬(release ∨ canT ick ∨ wait∨) ∧ (starts ∨ atF utureT ag) reactors. Two reactors (Sensor1 and Sensor2) produce values periodically every 20ms and 10ms respectively. A Fusion reactor has a reaction, Fusion.1, that is triggered by (either of) the sensor outputs, performs the data fusion, and schedules an action that triggers reaction Fusion.2 only if both sensor values were present. This schedule is done with a zero delay, causing Fusion.2 to be triggered at the next microstep. This example is simple but illustrative since it contains concurrency, interleaving between the sensor reactions, triggering of a reaction with multiple triggers, as well as reaction code dependent scheduling of actions. Interactive debugger. First, without modifying the existing tooling, we obtain a development environment where one can see the runtime state of the model directly on the graphical representation of the model, can step by step choose a specific scheduling of the reactions among the one accepted by the semantics, and can go back in time to explore new scheduling, provided that the reaction code is written in Groovy. Figure 2 shows a screenshot of a part of the environment. On the top left, the logical steps that can be executed at the current step are proposed. On top right a view of the multi-branch execution trace is provided. It represents different explorations of an execution: blue dots are executed steps, green dots are steps that were possible but not chosen, orange dots are current possible steps in a specific branch and the different lines represent places where the user decided to go back in time to explore a different interleaving. On the bottom of the picture, the existing graphical representation of the LF program is annotated to give a view over the runtime state of the model at the current execution step. We believe these different views help the developer to better understand both the underlying semantic model and the behavior of their particular model.

Finally, if one wants to verify temporal properties of a LF program, we propose two non-exclusive possibilities. First, one can add new MoCCML constraints as assertions in the specification. The assertion constraints are not enforced but checked during a specific debug session. Second, if the state space of the program is finite, one can ask for an exhaustive simulation which creates the whole state space of the program in a format suitable to be used as input of the CADP model checker [START_REF] Garavel | CADP 2011: a toolbox for the construction and analysis of distributed processes[END_REF] and amenable to verification of temporal properties written in the Model Checking Language (MCL [START_REF] Mateescu | A model checking language for concurrent value-passing systems[END_REF]). The diagnosis obtained from the CADP tool can then be injected into the debugging environment. The small example introduced in this section has a finite state space of 56 states and 110 transitions computed in 10 seconds. Trace debugger. When a model is considered as correct by the developer (using Groovy to sketch out the logic of the reactions), they can specialize the reaction code for a specific target (e.g., in the C language with two threads) and obtain an executable source code. In this case, to enable native debugging, it is also possible to ask the generated code for a trace that provides a standardized explanation of the program's execution (e.g., reaction triggering, etc.). In our method, we offer the possibility to inject these traces back into the simulation environment to replay what actually happened From the dot representation of the trace, a MoCCML scenario is automatically generated. First, it constrains the specific order of reaction execution and time advancement and second, to support data dependent control it modifies the RTD as retrieve from the trace. It is then possible to use the debugging environment for this specific trace.

Note that many reusable improvements of the GEMOC studio have been required to support the LF semantics, e.g., the priority mechanism previously defined at the model level 7 https://gephi.org/users/supported-graph-formats/graphviz-dot-format/ 8 https://wiki.lf-lang.org/tracing/ has been added in the MoCCML mapping meta language; a new MoCCML scenario language with support of RTD modification has been developed and tooled; the support of data dependent state spaces have been developed; a generic KLighD animator has been developed. These changes are available in a the continuous integration of the GEMOC studio but cannot be detailed in this paper.

V. RELATED WORK

There exist various alternative formalisms capable of specifying the concurrent and timed operational semantics of LF (e.g., TESL [START_REF] Boulanger | TESL: a language for reconciling heterogeneous execution traces[END_REF], Timed Automata [START_REF] Alur | Timed automata[END_REF], synchronous languages [START_REF] Benveniste | The synchronous languages 12 years later[END_REF], and Maude [START_REF] Rivera | Formal specification and analysis of domain specific models using Maude[END_REF] to name a few). Using an external language to provide a language semantics usually requires a (possibly complex) mapping between the source and the target language(s). Doing so has two main drawbacks. First, the execution, debugging, or analysis are done on the target language which creates a semantic gap that may be difficult to fill by the developer or by the tooling. Second, for an evolving language like LF, experimentation with new features may be difficult to do since it may require changes to the runtime implementation or the mapping.

Sirjani et al. [START_REF] Sirjani | Verification of cyberphysical systems[END_REF] proposed to use Timed Rebeca, a timed and reactive language based on actors, to perform model checking on LF programs. This is convenient since the semantics of LF and Rebeca are close. However, no automatic transformation, nor a way to fill the resulting semantic gap between the LF code and the Rebeca models are provided. Instead, our approach directly augments the original LF language implementation with an abstract operational model and tooling, avoiding drawbacks mentioned earlier.

There also exists related work in the field of embedded DSLs, where the DSL is defined as syntactic sugar for the host DSL and the execution/analysis relies on the execution capabilities of the host language [START_REF] Pavletic | Extensible debuggers for extensible languages[END_REF], [START_REF] Chis | The moldable debugger: A framework for developing domain-specific debuggers[END_REF], [START_REF] Li | Debugging with domain-specific events via macros[END_REF], [START_REF] Voelter | Language modularization and composition with projectional language workbenches illustrated with mps[END_REF]. In these approaches, the debugger has to do extra work to make the results understandable to the user of the DSL. There also exist debuggers provided by language workbenches [START_REF] Lindeman | Declaratively defining domain-specific language debuggers[END_REF], [START_REF] Klint | A meta-environment for generating programming environments[END_REF]. However, these approaches are not supported anymore, are not based on any well-defined formalism, and provide no support for omniscient debugging or state space analysis.

VI. CONCLUSION & FUTURE WORK

We present a framework for analyzing and debugging LF programs and runtime implementations. We follow the GEMOC MoCCML approach, in which we augment the language artifacts in the existing compiler implementation with instrumentation that encodes the operational semantics of the language. As a result, we obtain access to advanced tools like an omniscient debugger, exhaustive simulation, and graphical representations like diagram animation. This functionality depends on the ability to interpret Groovy reaction code to support data dependent control. Even with a "black box" treatment of reaction code, however, our tooling proves useful (albeit to a more limited extent) when applied to execution traces, which can be produced by any target runtime.

a u t h o r v e r s i o n

All together, we believe the proposed tooling provides a handy way to understand LF programs. Only 1300 lines of code are written to implement the LF semantics and obtain an omniscient debugging environment of LF programs. An extra 550 lines of code are necessary to obtain tuning of the graphical animation and another 350 lines of code are necessary to obtain the trace to dot utility.

Our work does not yet support all the features of LF. Two important features are not supported yet: the link with physical time and handling multiple instantiations of the same reactor. During an LF execution, the logical time always lags behind physical time, and if the next available tag is early, the runtime waits for physical time to catch up [START_REF] Lohstroh | Toward a Lingua Franca for deterministic concurrent systems[END_REF]. During a debugging session using breakpoints, it is not clear how such a link between the logical time and physical time should be addressed. The issue regarding multiple instantiations stems from a limitation of the MoCCML compiler, and is to be addressed in near future.

Fig. 1 .

 1 Fig. 1. MoCCML automaton for Connection life cycle

a u t h o r v e r s i o nFig. 2 .

 2 Fig. 2. An LF program under debugging

  Listing 1. Implementation of the pcv runtime state A similar mechanism is used to encode S scv and A buf . Q E is woven into the root concept of the program (i.e., Model) and encoded as an EventQ, an extension of List<STA>. The current tag is also woven in the root concept of the program (lines 4 and 6 of Listing 2). However, this runtime data should be excluded from the state space (to avoid infinite state space since time increases monotonically)-this is the purpose of the @NotInStateSpace annotation. The GEMOC framework automatically generates the appropriate getters and setters for the elements of the runtime state of the program that are needed for omniscient debugging and state space construction. Listing 2. Implementation of the Q E runtime state

		4	public var Integer currentTime = 0
		5	@NotInStateSpace
		6	public var Integer currentMicroStep = 0
		7	[...]
		8	}
	1	@Aspect(className=Variable) class VariableAspect{
	2	public ClonableObject currentValue
	3	}
	1	@Aspect(className=Model) class ModelAspect {
	2	public var eventQ eventQ=new EventQ()
	3	@NotInStateSpace
		4 https://github.com/jdeantoni/LinguaFrancaInGemoc/

https://eclipse.org/gemoc/

http://eclipse.org/xtext/

https://diverse-project.github.io/k3/

In LF, a connection with a delay is syntactic sugar for a reactor that outputs a given input with the specified delay by scheduling an action that it subsequently reacts to.


domain: math scco sdv

text:
Arthur Desbois

come

Brain-Computer Interface using OpenViBE, an open-source software platform for Brain-Computer Interfaces [hands-on tutorial]

Brain-Computer Interface (BCI) using OpenViBE, an open-source software platform for Brain-Computer Interfaces [hands-on tutorial]

Arthur Desbois 1 , Marie-Constance Corsi 1 1 Aramis project-team, Inria Paris, Paris Brain Institute, Paris, France OpenViBE is a software platform dedicated to designing, testing and using brain-computer interfaces (BCIs). It can be used to acquire, filter, process, classify and visualize brain signals in real time. During the first part of the session, a general overview of the BCI context and of the software will be given. We will also present several examples of use of OpenViBE in the BCI domain. During the second part, we will propose a step-by-step tutorial in which participants will design a simple motor imagery based BCI scenario from pre-recorded EEG signals.


João Cambeiro
email: joao.cambeiro@etu.univ-cotedazur.fr

Julien Deantoni
email: julien.deantoni@univ-cotedazur.fr

Vasco Amaral

Supporting the Engineering of Multi-Fidelity Simulation Units With Simulation Goals

Keywords: Model fidelity, Model, Simulation, Model-Based System Engineering

To conceive a CPS is a complex and multidisciplinary endeavour involving different stakeholders, potentially using a plethora of different languages to describe their views of the system at different levels of abstraction. Model-Driven Engineering comes, precisely, as a methodological approach to tackle the complexity of systems development with models as first-class citizens in the development process. The measure of realism of these models with respect to the real (sub)system is called fidelity. Usually, different models with different fidelity are then developed during the development process. Additionally, it is very common that the development process of CPS includes an incremental (and collaborative) use of simulations to study the behaviour emerging from the heterogeneous models of the system. Currently, the different models, with different fidelity, are managed in an ad hoc manner. Consequently, when a (Co-)simulation is used to study a specific property of the system, the choice of the different models and their setup is made manually in a non-tractable way. In this paper we propose a structured new vision to CPS development, where the notion of simulation goal and multi-fidelity simulation unit are first-class citizens. The goal is to make a clear link between the system requirements, the system properties, the simulation goal and the multi-fidelity simulation unit. The outcome of this framework is a way to automatically determine the model at an adequate fidelity level suitable for answering a specific simulation goal.

I. INTRODUCTION

A Cyber-Physical System (CPS) [START_REF] Lee | Introduction to embedded systems: A cyberphysical systems approach[END_REF] is an integration of computation with physical processes whose behavior is defined by both physical and cyber parts. To understand the emerging behavior of the system, one cannot comprehend the computational and physical parts separately. It is then required that several stakeholders, some of which are specialists in various domains involved in the system, participate and collaborate in the system development process.

The Model-Based System Engineering (MBSE) [START_REF] Wymore | Model-based systems engineering[END_REF] approach is an appropriate option to use during the system lifecycle to tackle the challenge of designing and maintaining a complex system that deals with multiple domains. MBSE is a methodological approach (supported by methods and tools) to tackle the complexity of systems development systematically. This entails promoting the use of models throughout the system development process, during which several versions of the system models are produced, and usually, it is possible to observe an increase in the fidelity of the models over time.

The fidelity of a model of a system is determined by how accurately it can reproduce the properties of the system under study [START_REF] Lee | Introduction to embedded systems: A cyberphysical systems approach[END_REF]. It is also considered as a measure of realism [START_REF] Gross | Report from the fidelity implementation study group[END_REF] of a model or simulation. The fidelity level of a model can be a qualitative description such as "high", "medium", or "low" assigned by an expert on the domain of the model or a quantitative description if a higher precision of the semantics of the value is required.

At each step of this iterative development process, it is essential not to lose track of the desired system properties that initially set the system requirements.

Simulation and Co-Simulation [START_REF] Gomes | Co-simulation: a survey[END_REF], [START_REF] Zeigler | Theory of modeling and simulation: discrete event & iterative system computational foundations[END_REF] are methods that enable the study of the emerging behavior of the system by executing the developed models in isolation or in a collaborative way. It is part of the Verification & Validation (V&V) [START_REF] Roza | The generic methodology for verification and validation to support acceptance of models, simulations and data[END_REF] process. Intermediate simulations at each iteration step of the development procedure are used to validate a subset of the system requirements. When there is a will to validate only a subset of the requirements, it means that there is a specific simulation goal, which targets specific requirements. Additionally, [START_REF] Choi | Multi-fidelity modeling & simulation methodology for simulation speed up[END_REF], [START_REF] Bayoumy | A reference error formulation for multi-fidelity design optimization[END_REF] show a trade-off between fidelity and the time and computational resources necessary to perform the simulation. As the fidelity of models increases, the time and computational resources required to perform the simulation also increases.

Currently, the relationships between the system requirements and the simulation goals are usually left implicit or managed in an ad-hoc manner. This forbids reasoning on what models, at which fidelity level, are appropriate to fulfil the simulation goal. Some low fidelity models may not be appropriate because they do not define the properties required by the requirements of interest or because their definition is not accurate enough. Some high fidelity models may not be appropriate since their computation time is too long.

Modelling traceability exists [START_REF] May | Systems and software engineering-architecture description[END_REF], [START_REF] Villar | Mega-modeling of complex, distributed, heterogeneous cps systems[END_REF] and could be used as a partial solution, however it usually does not consider simulation setup/results and how the simulation goals are defined.

Multi-fidelity models are already known and used [START_REF] Choi | Multi-fidelity modeling & simulation methodology for simulation speed up[END_REF], [START_REF] Bayoumy | A reference error formulation for multi-fidelity design optimization[END_REF] to achieve more efficient (Co-)simulations with respect to the simulation time and the required computational resources. However, these approaches do not consider the notion of simulation goal as a rationale of their choices, letting them

a u t h o r v e r s i o n

implicit and non-tractable.

In the following sections, we present our early work towards formalizing a framework that defines simulation goals and multi-fidelity simulation units as first-class citizens and, considering a simulation goal, determines automatically a set of system models suitable to be used to set up the (co)simulation. In section II, we start by refining the notion of multi-fidelity using a running example. In section III, we present an overview of our framework. In section IV, we describe work that relates to our approach. Finally, in section V we conclude our paper discussing possible research roadmaps.

II. ILLUSTRATION OF MULTI-FIDELITY WITH A RUNNING EXAMPLE

In this section, we present several examples of how multifidelity is present in the Smartlab case study [START_REF] Cambeiro | A building automation case study setup and challenges[END_REF]. The Smartlab is a Building Automation System (BAS) CPS [START_REF] Wang | An integrated scheme for cyber-physical building energy management system[END_REF] deployed in a computer science lab. Since humans participate in the CPS's feedback loop, this system is considered a particular type of CPS, the Human-in-the-loop CPS (HiTLCPS) [START_REF] Munir | Cyber physical system challenges for human-in-the-loop control[END_REF]. In Figure 1 we present a Product Breakdown Structure (PBS) [START_REF] Servello | Work breakdown structure[END_REF] of the Smartlab. The system components are primarily divided, judging if they are members of the system's computational or plant parts. In the case study, humans are not mere participants in the system plant. They are considered components of the system, and they also assume the roles of sensors by assessing the temperature and light conditions available in the room and the role of actuators by performing tasks requested by the system controller. The IoT platform plays a central role in managing the 92 sensors that measure the internal /external light levels, temperature, room occupancy and energy consumption. It also manages 49 actuators comprised of lights, the air conditioning unit (AC), and the power sockets.

We elected, as the property of interest for the examples in this section, the system energy consumption. The Smartlab is an actually deployed system, and from its operation, it is possible to collect real data. The observed system energy consumption behavior is the reference that will be used to determine the fidelity of the produced models during the system development. It is the accuracy of the models to reproduce the existing system energy consumption that will define their fidelity level.

Figure 2 presents the measured energy consumption and its variation during one day at the Smartlab. The energy consumption is divided into two categories: the AC unit's energy consumption which is responsible for most of the energy used during the case study, and the rest of the equipment operating in the laboratory like the light management system and the energy consumption measured by the power sockets. Considering the breakdown structure presented in Figure 1, the sum of the energy consumption of the AC unit, IoT platform hardware and the measured energy consumption at the power sockets determine the total energy consumption. One cannot overlook that each one of these terms can be influenced by system properties belonging to the following domains: The fidelity of a model does not increase simply by injecting more details into it [START_REF] Zeigler | Theory of modeling and simulation: discrete event & iterative system computational foundations[END_REF]. A higher fidelity is achieved by adding details that better characterize the set of properties of interest. Figure 3 presents an example of a high-level timed model that focuses on relevant aspects of the system, the management of thermal and light conditions available in the laboratory to a u t h o r v e r s i o n determine our property of interest. This model considers the HiTL participation in the system. Humans play the sensor role by providing qualitative assessments of the temperature and light conditions available in the laboratory (connectors in Figure 3 marked as 1 and 2). They also play the actuator role by performing tasks requested by the system to change the temperature and light conditions like opening/closing a window or opening/closing a blind, respectively (connectors marked as 3 and 4).

In the early stages of the development process, the focus might be on getting the basic functionality working. Due to the complexity required to model the HiTL, the models related to the HiTL might not be available yet, so this component is not considered by the temperature and light controllers. The lumped model can be obtained from the presented model by eliminating the connectors between the human block and the temperature and light controllers blocks. Although the model is suitable to check if the required basic functionality is satisfied, the fidelity of our property of interest, the system energy consumption is lower given that the contribution of the HiTL is not faithfully reproduced. It is then possible that the various models developed during the system lifecycle present different fidelity levels for the system properties.

Choosing different levels of participation of the HiTL in the system models, leads to developing several versions of the Human block (marked as 5). The various versions can be differentiated by their functional interface and the set of observable properties at the interface level. If we consider that in one version of the Human model, the role of sensor is not supported, then the visible light assessment property is not part of the Human block set of observable properties, and at the functional interface, the connectors marked as 2 and 4 do not exist on this version of the model. When integrating models at the different fidelity levels, if the interconnected models are not compatible at the interface level (ex. a required input by a model is not produced by the connected model), modifications on one or both the models are required to make the interfaces of both models compatible. An example of this could be the use of a version of the light controller (marked as 7) that has as one of its inputs, the feedback provided by the HiTL that will be integrated with a version of the Human model's where the set of observable properties does not include the assessment of the visible light property.

To assess the fidelity of a model to reproduce an observable property, it is also necessary to determine how close its representation at the interface level is from its representation on the actual system. The main operational goals of a light level agent (marked as 8) are the collection of the measured data from the available sensors, the pre-processing of the collected data and the delivery of the data to the light controller. In the deployed system, the light agent collects data from 5 indoor light sensors, and at the interface level, exposes each of the collected light level values. Again, an early version of the light agent developed to check some basic functionality requires at the interface level an abstracted representation of the visible light level in the room depicting the average visible light level in the room. The changed representation of the property at the interface level can lead to incompatibilities when communicating with the light controller, as the output representation should match the expected input representation.

III. PROPOSED FRAMEWORK OVERVIEW

MBSE is a system engineering methodology that uses models as primary artefacts throughout the system lifecycle. In the requirements elicitation phase, the system stakeholders define the system requirements from the desired system properties. System properties are defined as differentiating factors that can be measured or computed, while a system requirement is a valuation of a system property that can be satisfied or not.

The system development usually includes the decomposition of the system into sub-systems, by following approaches like the Product Breakdown Structure approach as depicted in Figure 4 where the system is decomposed in sub-systems.

Simulation is a popular method to V&V the behaviour of a system with respect to the requirements. A simulation unit (SU) is a virtual version of a system's (sub-)system to be used in a simulation context. Its objective is to mimic behaviourally its system counterpart. Since we are dealing with multi-fidelity, multiple SUs (with different fidelity levels) related to a single sub-system exist. A stakeholder can use simulations to validate one requirement of interest for him. For this, he has to identify the system properties, which are constrained by this requirement and observe if the evolution of the value of these properties during the simulation conforms to the requirement. In our approach, we propose to define a simulation goal explicitly. A simulation goal determines the requirements that must be verified during the simulation. Additionally, a simulation goal defines some extra-functional properties regarding the simulation. The simulation extrafunctional properties are quality attributes of the simulation, like accuracy or the time necessary to perform the simulation.

Since different versions of the SU with different fidelity levels may exist, the stakeholder must decide which SU he should use according to the simulation goal. As the fidelity of models increases, the time and computational resources required to perform the simulation also increases [START_REF] Choi | Multi-fidelity modeling & simulation methodology for simulation speed up[END_REF], [START_REF] Bayoumy | A reference error formulation for multi-fidelity design optimization[END_REF].

We are currently working on a framework that guides the framework user in selecting the sets of models, possibly at different fidelity levels that can be used in a simulation to answer a simulation goal. We propose a new type of SU, the multi-fidelity SU, to approach multi-fidelity systematically. Its structure is presented in Figure 4. This unit encapsulates all SUs that are related to the same sub-system. The same observable property can have different fidelity values in different SUs, depicted in Figure 4 as the property's fidelity measure.

At the interface level, the multi-fidelity unit exposes a set of observable properties. An observable property of a metafidelity SU is a system property for which at least one of the meta-fidelity SU encapsulated SUs can be used to observe its behaviour during a simulation. There are no observable properties at the interface level of a multi-fidelity SU that are not part of the system properties set required to define

a u t h o r v e r s i o n

Fig. 4. Proposed Multi-fidelity Framework Overview the system requirements. In Figure 4 depicts that the system requirements constrain the set of system properties candidates and that the set of observable properties of a multi-fidelity SU is a subset of the system properties. Also represented at the interface level are the SUs simulation extra-functional properties. The valuation of these properties in a SU may result from previous utilizations of the SU in (co-)simulations. These properties can be a factor in a stakeholder decision of which SU to use for answering a simulation goal. To facilitate the identification of which SUs of the multi-simulation unit can be used to answer a simulation goal, expressed as a combination of system properties and simulation properties, a feature diagram [START_REF] Käköla | Software product lines[END_REF] representing the supported combinations of observable properties and simulation properties is available. This allows exposing at the interface level all the functionality supported by the encapsulated SUs. Considering the Smartlab example presented in section 2, a HiTL multi-fidelity SU would include all the various versions of the HiTL SUs developed. It would expose all the properties that result from the participation of humans in the various roles supported at the interface level.

In [START_REF] Zeigler | Theory of modeling and simulation: discrete event & iterative system computational foundations[END_REF] the authors define an experimental frame as a specification of the conditions that the system can be experiment with. It is also proposed a definition for the scope frame of a model as the most relaxed conditions that a model is suitable to be used. A model is deemed suitable to be used on a particular experimental frame if the experimental frame can be derived from the scope frame of the model. We intend to adapt these concepts to a multi-fidelity context, where the notion of experimental frame is linked to the notion of simulation goal and the scope of a model is linked to the set of observable properties that is possible to study from the emerging behaviour of a set of SUs in a (co)simulation. Then in the framework context, a set of SUs is suitable to answer a simulation goal if the frame defined by the system properties of interest and the simulation extra-functional properties expressed in the simulation goal can be derived from the scope frame (bounded by set of observable properties of the SUs.

If we consider a requirement, R1, expressed as "The participation of humans over the period of one month in tasks to evaluate the temperature and light conditions in the laboratory assigned by the system results in energy consumption savings higher than 10%". A simulation goal could be the verification of R1 in less than 5 minutes. The frame defined by the simulation goal is bounded by the time simulation property that requires a timed SU to check if the property holds, the system properties of interest necessary to answer the simulation goal, the energy consumption, the human as a temperature sensor, the human as a light sensor, and light and temperature controllers that require the assessment of humans, of the light and temperature conditions. The scope frame of a set of SUs obtained from the timed Smartlab model presented in section II includes all the properties that bound the simulation goal frame, and it also incorporates the system properties of humans as temperature and light conditions actuators. It is then possible by applying a simple projection operation on the scope frame of the set of SUs to derive the frame defined by the simulation goal. The set of SUs is then appropriated to verify R1 in a co-simulation. Finally, to set up a co-simulation, it is necessary to address the challenge presented in section II where a system property may have different representations at the interface level of different SUs. When connecting two SUs, each belonging to a different multi-fidelity unit, it is the task of the modeller responsible for a particular SU that to make the interface of the SU compatible with the enclosing multi-fidelity SU interface. We propose the use of adaptors as, e.g. used in SystemC [START_REF] Grötker | System Design with SystemCTM[END_REF]. In Figure 5, we present a possible use of an adaptor that makes it possible to overcome the challenge presented in section II, where the representation of a SU observable property does not match the a u t h o r v e r s i o n representation of a property that belongs to the input set of a target SU. In the example, the adaptor converts a multi-valued representation of the light levels measured in the room, sent by the light agent SU to an averaged value compliant with the representation format that the light controller SU requires. At the current stage of our work, we should note that providing an answer on whether a combination of models validates a requirement is not a framework's goal. Neither is the ordering of the selected sets of models based on a particular criterion.

IV. RELATED WORK

Several research works using multi-fidelity modelling have been reported in the literature [START_REF] Choi | Multi-fidelity modeling & simulation methodology for simulation speed up[END_REF], [START_REF] Bayoumy | A reference error formulation for multi-fidelity design optimization[END_REF], [START_REF] Bayoumy | A relative adequacy framework for multimodel management in multidisciplinary design optimization[END_REF]- [START_REF] Geiselhart | Integration of multifidelity multidisciplinary computer codes for design and analysis of supersonic aircraft[END_REF]. Typically these works focus on how to select a model with the desired accuracy that is less computational and time demanding to simulate [START_REF] Fernández-Godino | Issues in deciding whether to use multifidelity surrogates[END_REF]. In [START_REF] Choi | Multi-fidelity modeling & simulation methodology for simulation speed up[END_REF], [START_REF] Bayoumy | A reference error formulation for multi-fidelity design optimization[END_REF], [START_REF] Bayoumy | A relative adequacy framework for multimodel management in multidisciplinary design optimization[END_REF], multiple models with different fidelity levels are used during a simulation for simulation speed up. A region of interest is defined where the use of a highfidelity model is required to keep the simulation error at a low level. A low-fidelity model is used in the other regions since its lower accuracy does not prevent that the simulation is performed with an acceptable accuracy. In [START_REF] Franceschini | Towards adaptive abstraction in agent based simulation[END_REF] an adaptive abstraction approach is used to achieve the simulation speed up. During a simulation, switching between abstractions of a model occurs based on a validity frame that tests if the more simple version of the model can reproduce a system property with an acceptable accuracy. When the more abstracted model cannot be used in a predictable way, the simulator switches to the less abstracted (more detailed) model. In our opinion, this work opens up the possibility of research to determine if a link between multi-abstraction and multi-fidelity exists. The existing work provides a valuable source of information on how multi-fidelity is present in system engineering in multiple domains. We seek to extend current works by proposing a framework where the simulation properties are not determined a priori.

V. CONCLUSION

We proposed a methodological framework that makes explicit the link between the system requirements, the system properties, the simulation goal and the multi-fidelity SU. Using these links it is possible to reason on which level of fidelity can be used during a (Co-)simulation for a specific simulation goal. While the framework is still a work in progress, we foresee relevant research questions to be solved as a result of it. Namely, if there is a relation between fidelity and abstraction and if known abstraction techniques can be applied in a multifidelity context.

Fig. 1 .Fig. 2 .

 12 Fig. 1. Smartlab PBS

Fig. 3 .

 3 Fig. 3. A high-level model of the Smartlab

Fig. 5 .

 5 Fig. 5. An adapter is used to compatibilize the SUs interfaces