Hugo Bruneliere
email: hugo.bruneliere@imt-atlantique.fr

Florent Marchand De Kerchove
email: florent.marchand-de-kerchove@imt-atlantique.fr

Gwendal Daniel
email: gdaniel@uoc.edu

Jordi Cabot
email: jordi.cabot@icrea.cat

Towards Scalable Model Views on Heterogeneous Model Resources

Keywords: neering, Abstraction, modeling and modularity, • Information systems Modeling, Views, Scalability, Persistence, Database, Design Time, Runtime

When engineering complex systems, models are used to represent various systems aspects. These models are often heterogeneous in terms of modeling language, provenance, number or scale. They can be notably managed by different persistence frameworks adapted to their nature. As a result, the information relevant to engineers is usually split into several interrelated models. To be useful in practice, these models need to be integrated together to provide global views over the system under study. Model view approaches have been proposed to tackle such an issue. They provide an unification mechanism to combine and query heterogeneous models in a transparent way. These views usually target specific engineering tasks such as system design, monitoring, evolution, etc. In our present context, the MegaM@Rt2 industrially-supported European initiative defines a set of large-scale use cases where model views can be beneficial for tracing runtime and design time data. However, existing model view solutions mostly rely on in-memory constructs and low-level modeling APIs that have not been designed to scale in the context of large models stored in different kinds of sources. This paper presents the current status of our work towards a general solution to efficiently support scalable model views on heterogeneous model resources. It describes our integration approach between model view and model persistence frameworks. This notably implies the refinement of the view framework for the construction of large views from multiple model storage solutions. This also requires to study how parts of queries can be computed on the contributing models rather than on the view. Our solution has been benchmarked on a practical large-scale use case from the MegaM@Rt2 project, implementing a runtime -design time feedback loop. The corresponding EMF-based tooling support and modeling resources are fully available online.

INTRODUCTION

Different, and quite often, many kinds of models are used when engineering complex systems. This is notably the case for systems of systems or Cyber-Physical Systems (CPSs) [START_REF] Derler | Modeling Cyber-Physical Systems[END_REF], where models have to represent both software and hardware aspects. Depending on the concerned application domains, the nature and number of the involved models can vary significantly: they can rely on various modeling languages, come from different sources or be very large. Moreover, these models usually contain complementary information that is not uniformly spread among them. Thus, engineers need to combine these different models in order to have a better vision and understanding of the whole system. The combined models are intended to support particular engineering activities such as system design, development, monitoring or adaptation/evolution.

The MegaM@Rt2 collaborative project1 is a recent and large European initiative supported by both industry and academic partners. As part of its continuous system engineering approach [START_REF] Afzal | The MegaM@Rt2 ECSEL Project: MegaModelling at Runtime -Scalable Model-Based Framework for Continuous Development and Runtime Validation of Complex Systems[END_REF], the project notably aims at providing a runtime ↔ design time feedback loop that could be deployed and used in different industrial domains. Such a feedback loop can bring interesting benefits in the above-mentioned engineering activities, for instance. To realize this in practice, model views are used to transparently relate together all the required (design and runtime) models.

Several model view approaches have already been proposed in order to provide support for such views [START_REF] Bruneliere | A Featurebased Survey of Model View Approaches[END_REF]. Based on MDE, they allow specifying, creating and handling views on possibly heterogeneous models. Once built, the views can be used to uniformly manipulate and query the data coming from the different contributing models. However, most of the view approaches have only been deployed on models of small to medium size (e.g. manually created design models) and not on large to very large models (e.g. automatically-generated runtime models). Scalability is one of the main issues hampering the adoption of MDE in the industry [START_REF] Hutchinson | Model-Driven Engineering Practices in Industry: Social, Organizational and Managerial Factors that Lead to Success or Failure[END_REF], and is a major challenge to be addressed in MegaM@Rt2 as well. Moreover, the support for strongly interconnected models coming from different data sources (e.g. databases) appears to be the focus of only a few of the proposed approaches. Those are problems that are also particularly relevant in the context of MegaM@Rt2.

In this paper, we present the current status of our work towards efficiently supporting scalable model views over heterogeneous model resources. This includes the following contributions:

(1) A conceptual integration approach for the complementary use of model view and model persistence frameworks. (2) A scalable realization of this approach combining the EMF Views [START_REF] Bruneliere | EMF Views: A View Mechanism for Integrating Heterogeneous Models[END_REF] model view solution with the NeoEMF [START_REF] Daniel | NeoEMF: A Multi-database Model Persistence Framework for Very Large Models[END_REF] and CDO [START_REF]Connected Data Objects (CDO)[END_REF] model persistence frameworks. (3) An evaluation of our approach and current implementation on a large-scale and realistic scenario from the MegaM@Rt2 project. The rest of this paper is organized as follows. Section 2 motivates our work by introducing the MegaM@Rt2 context, use case and related objectives. Section 3 presents our conceptual approach to integrate model view techniques and model persistence frameworks as a solution. Section 4 details how we implemented this conceptual approach on top of well-known MDE solutions based on the Eclipse Modeling Framework (EMF). Section 5 provide an evaluation of our approach and implementation via different scalability benchmarks performed on a MegaM@Rt2 use case. Finally, Section 6 reviews the related work while Section 7 concludes with our main lessons learned and planned future work.

BACKGROUND & MOTIVATION

The MegaM@Rt2 collaborative project2 is a large and industriallysupported European initiative that officially started on April 2017. It relies on a wide consortium composed of 27 partners from 6 different national clusters (Sweden, France, Spain, Italy, Finland & Czech Republic) including large companies such as Atos, Thales, Nokia, Volvo and Bombardier. MegaM@Rt2 aims at incorporating methods and tools in order to develop a continuous system engineering and validation approach that can be practically deployed in various industrial domains [START_REF] Afzal | The MegaM@Rt2 ECSEL Project: MegaModelling at Runtime -Scalable Model-Based Framework for Continuous Development and Runtime Validation of Complex Systems[END_REF]. To this intent, the project also comes with 9 case studies covering a variety of potential application areas: aeronautics, railway, warehouse, telecommunication, etc. One of its main expected contributions is notably to propose a runtime ↔ design time feedback loop that is (re)usable in these different contexts. In order to realize this, scalable model-based methods and tools are being considered to improve the productivity, quality and predictability of such large complex industrial systems.

MegaM@Rt2 deliverables reporting the project's progresses have already been produced during the first year of the project and new ones are currently being developed [START_REF]MegaM@Rt2 Project[END_REF].

MegaM@Rt2 Use Case

From the current MegaM@Rt2 results (notably the description of the industrial requirements and case studies), we have been able to extract a general scenario that concretely illustrates the need for scalable model views and their persistence. Thus, let us consider the realization of the previously mentioned runtime ↔ design time feedback loop via a view gathering 4 different models covering both runtime and design time aspects of a given system in the project. As shown on Figure 1, this view relies on a runtime log model (that conforms to a simple trace metamodel), a Java code model (that conforms to the Java metamodel from MoDisco [START_REF] Bruneliere | MoDisco: A Model Driven Reverse Engineering Framework[END_REF]), a component model (that conforms to OMG UML [START_REF]Unified Modeling Language (UML)[END_REF]) and a requirement model (that conforms to OMG ReqIF [START_REF]Requirements Interchange Format (ReqIF)[END_REF]).

On the one hand, the runtime log model and (to a lesser extent) the Java model can be considered as runtime models. They can potentially be very large, especially the runtime log model which represents actual system execution traces. Thus, a typical solution to store and access them in a scalable way is to rely on database model persistence frameworks. The used technical solution then depends on the nature of the model, its access/handling scenario or the required features.

On the other hand, the component model and requirement model can be considered as design models. They are generally of a reasonable size compared to the runtime ones, because they are very often manually specified. Hence, they can be handled by standard modeling frameworks relying on in-memory constructs and/or XML-based files.

A concrete example of the view from Figure 1 is given in Figure 2. By using this view, an engineer can navigate transparently within and between the four contributing models as if they were all part of the same single model. Thus, from a particular runtime information collected at system execution (here a trace.Log element), one can move back to the originating Java code instructions (here java.ClassDeclaration elements). One can then follow links to the components (here uml.Component elements) the code implements, and up to the actual requirements these components fulfill (here reqif10.SpecObject elements).

Such a view combining different models can also be queried as any regular model, in order to extract relevant data out of it. For example, one can obtain all the requirements that are related to a given execution trace (runtime to design time traceability). Or, the other way around, one can get all the execution traces that correspond to a particular requirement (design time to runtime traceability). We could imagine many other similar queries also relevant in the context of MegaM@Rt2, according to different needs of the industrial partners.

To summarize, the main benefit of using a view is to collect in a transparent way information that is spread among different models. Without such a view, the engineer has to query the different models one by one and then aggregate the obtained results by herself. This includes recreating the mappings between related elements from different models in the view. Instead, using a view, queries traversing several contributing models (such as the queries mentioned previously) can be expressed and computed naturally as if dealing with a single model.

Objectives

In the MegaM@Rt2 context, it is not sufficient to be able to build model views: the view mechanism must scale up when aggregating very large models provided by the industrial partners. More generally, the need for scalable modeling solutions has been observed in several industrial contexts [START_REF] Hutchinson | Model-Driven Engineering Practices in Industry: Social, Organizational and Managerial Factors that Lead to Success or Failure[END_REF][START_REF] Whittle | The State of Practice in Model-Driven Engineering[END_REF], and is also recognized as a long-term challenge from a research perspective [START_REF] Dimitrios S Kolovos | A Research Roadmap Towards Achieving Scalability in Model Driven Engineering[END_REF]. However, existing model view solutions do not handle large and very large models well, if at all (cf. Section 6).

In the present paper, we target the building, handling and querying of scalable model views over heterogeneous model resources. We consider here heterogeneity in terms of both the used modeling languages (i.e. metamodels) and the underlying persistence solutions. We can notably leverage database model persistence frameworks that are particularly adapted to address scalability-related issues. Thus, we propose the following roadmap for our approach:

(1) Refining the model view framework to model resources using different persistence solutions. (2) Persisting any view-specific information in a scalable way.

(3) Loading views and accessing view elements with a reasonably low overhead. (4) Querying views efficiently, e.g. by leveraging persistencespecific optimizations.

In Section 3, we describe our conceptual approach to achieve these goals. This approach has been implemented relying on the EMF ecosystem (cf. Section 4) and evaluated in practice on our Me-gaM@Rt2 use case (cf. Section 5). At the time of writing, we have successfully tackled (1), ( 2) and (3), and partially addressed (4).

INTEGRATION APPROACH

In what follows, we describe our general approach to support scalable model views on heterogeneous model sources. This section introduces, for each goal listed in Section 2.2, a conceptual solution to the related issue(s). The overall objective is to be able to build views that do scale up in practice: views that are built on top of several models where some are too large to be loaded, handled and stored only in memory (e.g. using the base EMF features, cf. Section 4). This is made possible notably by relying on models that can be persisted and manipulated, when necessary, using appropriate database backends. The general approach we consider is depicted in Figure 3. file system, coming with some file import/export capabilities in different serialization formats. This default mechanism is used to store the design models introduced in our running example (cf. Section 2.1).

Database Persistence Frameworks have been proposed to connect the modeling framework to databases of various kinds (relationalbased, graph-based, etc.). These solutions are typically used to store large models (e.g. the runtime models of our running example, cf. Section 2.1) with a reduced memory footprint.

In the general case, the Model View Framework must be correctly integrated with the Modeling Framework and comply with its Generic API. This allows client applications to query views as regular models. Moreover, for model views to scale with large models, the Model View Framework has to leverage the characteristics of the Database Persistence Frameworks. This notably requires various refinements and optimizations from both sides. The next subsections describe the important goals we have identified in order to realize such a scalable integration.

Building Views on Heterogeneous Model Sources

This goal is of primary importance in MegaM@Rt2, and is a prerequisite to the three subsequent ones. As said earlier, most (if not all) modeling frameworks provide a default file serialization support, usually relying on XML-based format(s). However, they are very often not supporting other data sources. This is notably the case when needed to load/store models from/into different kinds of databases (e.g. relational, graph, etc.). Such databases can be existing ones, e.g. handled by external applications, or can be created just for the sake of modeling.

Model view approaches generally rely on the model persistence support provided by their underlying modeling framework. Thus, they usually lack of support for scalable model persistence solutions, e.g. relying on databases. As a consequence, it is required to perform the integration of the model view framework with such database persistence framework(s). This way, depending on the nature of the contributing models, different persistence backends can be selected and combined in the context of a same view. This is the case in our running scenario from Section 2.1, for example.

Such an integration can be performed in different ways. In some cases, it can be realized indirectly. The considered modeling framework can be first refined to be able to use the database persistence framework. Then, the view framework can simply rely on the general interface of the modeling framework in order to access transparently the underlying database resources. In some other situations, a direct connection can be required between the model view framework and the persistence framework. This notably allows implementing particular optimizations that could not be realized if passing by the modeling framework, cf. Section 4.1 for technical examples of these.

Persisting the View Information in a Scalable Way

Depending on the view specification, additional data can also be required in order to be able to fully compute it. For instance, this is the case when a given view provides new relationships between elements coming from different models, or when it adds new properties to elements from one of the involved models.

When initializing such a view, this view-specific information has to be obtained in some way. One possibility is to compute it at runtime when loading the view. This can be based on the data available from the contributing models and on some predefined queries executed on top of them. Another option is to collect it from an existing data source or a dedicated additional model. Such a model can come from manual inputs from the view users. It can also be the result of the running of an external application. In either cases, the view mechanism has to be able to retrieve the appropriate information in order to build the view.

Related scalability problems can occur when this view-specific data is too large to be handled correctly by the default support from the used modeling framework. Indeed, depending on the nature of the view, this extra data can be even larger than some of the contributing models themselves (e.g. as in our running scenario from Section 2.1). In these cases, it is required to be able to persist a view-specific model (storing this data) by using a more scalable database persistence framework. Adopting such a strategy can reduce significantly the memory footprint of given views, thus allowing to manipulate views that could not be loaded otherwise. Section 4.2 describes how this can be realized in practice.

Optimizing the View Loading and Element Access

With very large views, some operations can rapidely become heavy in terms of execution time and memory consumption. This can even go to a point where the view is not really usable anymore. For example, this is the case when the response time is too long (e.g. when the user navigates the view) or when the view simply ends by crashing. The situation is notably critical during the process of initializing/loading the view, as it can require a significant number of model element accesses.

Relevant performance gains can be obtained by applying various lazy loading techniques at different levels. In the general case, any hit to an actual model element has to be delayed as much as possible and must only occurs when strictly needed. Such optimizations also concern accesses to both the various contributing models (cf. Section 3.1) and the view-specific elements (cf. Section 3.2). Ideally, all these accesses must be delayed without impacting the overall correctness of the view.

Moreover, depending on the used persistence framework(s), the model view framework can be refined differently. For given model element accesses, the view framework can directly benefit from specific capabilities provided by a database type (e.g. graph). For instance, the view framework can leverage the database API to turn full traversals of models into more selective requests, as traversals are time-and memory-intensive for large models. Section 4.3 gives more technical insights on how such optimizations can look like.

Optimizing the View Querying

Once a view has been correctly created and loaded (cf. Section 3.3), it can be navigated and queried as any regular model according to the needs of the engineering activity it supports. As said earlier, the view framework usually relies on a generic interface provided by a modeling framework and shared between different tools from a same ecosystem. This way, it also natively supports the execution of queries defined in languages supported by this modeling framework.

However, when implementing this in practice, performance issues can arise. For instance, some models can be serialized in standard XML-based files while others can be stored in databases (cf. Section 3.1). In this situation, using the default querying support might not take advantage of backend-specific optimizations. Thus, more elaborated schemes have to be considered. The optimization of model querying techniques has already been studied (cf. Section 6), but not really in the context of model views. Base operations (e.g. allInstances in OCL) can be costly to execute with the default behavior of the modeling framework. For better efficiency, such operations could be delegated to the various persistence frameworks used in a view. This is illustrated in Figure 4 where an OCL query navigates the view from Section 2.1 and returns the number of design requirements that are impacted by a specified runtime event, captured as a log from an execution trace. This query can be optimized by delegating the allInstances call to the database persistence framework that contains the related elements, thus bypassing the default (less efficient) implementation of the modeling framework.

More generally, large performance gains are possible by splitting a query (on a given view) into a request plan that is better suited to the underlying persistence frameworks. This requires the model view framework to be able to split any query, delegate its execution and collect its results by leveraging the specificities of the different persistence backends. We have made first concrete steps towards this, as described in Section 4.4.

IMPLEMENTATION

We have concretely implemented the conceptual approach described in Section 3 by relying on EMF [START_REF] Steinberg | EMF: Eclipse Modeling Framework[END_REF] as our core Modeling Framework. Based on our own knowledge and expertise, we made the choice of using EMF Views [START_REF] Bruneliere | EMF Views: A View Mechanism for Integrating Heterogeneous Models[END_REF] as our Model View Framework. Concerning the Persistence Frameworks, we used both NeoEMF [START_REF] Daniel | NeoEMF: A Multi-database Model Persistence Framework for Very Large Models[END_REF] and CDO [START_REF]Connected Data Objects (CDO)[END_REF] as supporting graph and relational database backends (respectively). In what follows, we detail how all these technical solutions have been combined together in practice to address the four different key points of our conceptual approach. Our current implementation is freely available from a branch of the EMF Views source code repository3 .

Building Views with EMF Views on Models

stored in NeoEMF and CDO 4.1.1 EMF Views for Model Views. EMF Views4 is a model view mechanism that reuses the well-known concept of view in databases and transpose it to the modeling world. It embeds a lightweight model virtualization framework that can be used on top of any EMF-based model. This way, it allows to create (currently readonly) views that aggregate elements coming from different models. EMF Views itself is fully compliant with the EMF API and the views it produces act as standard models: they can be navigated, queried and taken as inputs of model transformations. The approach has the following characteristics:

• Lightweight: elements in a view are only proxies to actual elements from the contributing models (which are never copied). This allows for a low overhead when creating and navigating views. • Filtering: existing elements, attributes or references from the contributing models can be hidden in a view. • Virtualization: views can contain new elements, attributes or references that exist only at the view level and are not part of the contributing models. • Non-intrusiveness: all the additional view-specific information (pointers to contributing models, filters, virtual elements, references between different models) is described in a separate weaving model5 and does not imply any change on the contributing models. EMF Views is released as a set of open source Eclipse plugins. Its native integration with EMF-based tools as well as its characteristics constitute an interesting starting point for our implementation. Note that alternative view mechanisms are also considered in the related work (cf. Section 6).

CDO and NeoEMF for Model Persistence.

The Connected Data Objects model repository (CDO) [START_REF]Connected Data Objects (CDO)[END_REF] is a model persistence framework designed to handle large EMF models by relying on a client-server repository structure. CDO is based on a lazy-loading mechanism and supports transactions, access control policies as well as concurrent model editing. CDO's default implementation uses a relational database connector to serialize models into SQL compatible databases. However, the modular architecture of the frameworks can be extended to support different data storage solutions (even if, in practice, only relational connectors are used and regularly maintained).

NeoEMF6 is a complementary model persistence framework that relies on the scalable nature of NoSQL databases to store and manipulate large models. NeoEMF supports three model-to-database mappings, i.e. graph, key-value and column stores. Each one of them is adapted to a specific modeling scenario, such as atomic element accesses (key-value) or complex navigations (graph). As other persistence solutions, NeoEMF provides a lazy-loading mechanism that allows to obtain significant gains in terms of performances.

Since CDO and NeoEMF are two of the main actors in the field of scalable model persistence, we chose to rely on them in our implementation.

4.1.3 Integration. Since EMF Views, NeoEMF and CDO are all part of the EMF ecosystem, integrating them together is a straightforward task since they all implement the same EMF model handling API. It is mostly a matter of telling EMF Views how to retrieve and load the right model resources. However, CDO and NeoEMF resources require platform-specific initialization code (such as specific URI schemes, resource factory implementations and data store configurations) that had to be integrated into EMF Views. Note that this code is also available from the EMF Views/NeoEMF integration repository (cf. the URL indicated earlier in this section). Once loaded, all the model resources are navigated through the standard modeling API. This way, the persistence frameworks transparently delegate the operations to the databases in a scalable manner

Persisting the View Information with NeoEMF

As explained before, EMF Views uses a weaving model that represent the view-specific information. This model can potentially contain entries for many elements coming from the different contributing models. Thus, it can get as large or even larger (depending on the view) than the contributing models themselves. In order to improve the scalability of our approach on large-scale views (such as in our running example from MegaM@Rt2, cf. Section 2), we chose to persist this model using NeoEMF instead of using the default XMI serialization.

Since the weaving model is also defined as a standard EMF model, its migration to NeoEMF has been done quite transparently by changing the model serialization behavior (and initializing the corresponding database backend). Persisting the weaving model in NeoEMF allows us to handle views that cannot fit in memory otherwise.

Optimizing the View Loading and Element Access in EMF Views

When dealing with large database resources, many operations of the EMF API that had little to no overhead with small in-memory resources now potentially bear high costs in execution time and memory consumption. So we had to pay extra attention to minimize the impact of such operations. For instance, checking whether a reference has any contents can be done by calling the EList.isEmpty operation. A naive implementation of this operation compares the size of the collection against zero, where getting the size is an O(n) operation. On small in-memory resources, n is small and a call to the isEmpty operation triggers no issue. On large database resources, n is large and the overhead of hitting the database can become a bottleneck. A better implementation of isEmpty rather checks if at least one element exists, and thus exits early when this is not the case. Similarly, getting the nth element of a multivalued reference by using the EList.get operation can be costly if the implementation first builds a list containing all the elements of the reference, regardless of the index requested. If, instead, the implementation navigates to the index and looks no further, then we make less hits to the database and the operation has a minimal cost.

We significantly improved EMF Views for large model resources by following these ideas. As introduced in Section 3.3, our key tenet was: delay actual hits to the resource as much as possible.

Another important improvement of EMF Views concerned the view loading process. As said previously, weaving models can be large depending on the number (and contents) of virtual references. Previously, EMF Views eagerly populated these virtual references when loading the view. Each virtual reference thus delayed loading the view further: for larger weaving models, this meant several seconds or even minutes. Here again, the optimization lies in laziness: delaying work that can be done later. In this case, we have to populate virtual references only when they are first accessed. If some virtual associations are never looked up then we never have to load them from the weaving model, thus avoiding the loading cost. Making this change to EMF Views enabled loading views with large weaving models with no overhead in terms of time.

A third point of optimization was to tweak the way the data is stored into the graph database handled by NeoEMF. The runtime log model of our example (cf. Section 2.1) is a large model but a flat one. It contains a top-level element holding a large collection of execution logs (some of which have also children). Our experiments have shown that this flat structure was reducing the performances of NeoEMF. To solve this issue, we developed a new mapping from model to graph for NeoEMF, using in-database linked lists. This mapping, dedicated to large collections, allowed us to speed up the creation of the runtime log model and the access to its elements by a factor of 30.

Optimizing the View Querying in OCL

Since views are regular EMF models, querying tools like OCL or transformation tools like ATL can be applied transparently on views (regardless of the underlying persistence framework used by the contributing models). However, relying only on the EMF API leaves a lot of performance on the table. Base operations, like allInstances in OCL, can be quite costly to execute naively using the EMF API [START_REF] Wei | An Efficient Computation Strategy for allInstances[END_REF]. On the contrary, persistence backends may provide more efficient ways to execute such operations. For example, NeoEMF resources expose a getAllInstances method which can compute the set of instances of a given classifier. This method is around 40 times faster than using the EMF API directly.

We extended the standard OCL interpreter in order to specialize some operations according to the data store they target. In the following paragraph we detail our implementation of the allInstances operation, but other native operation implementations can be easily defined to enhance query computation performances. However, our implementation still needs a generic operation delegation mechanism that, along with the support for other query languages, is currently left for future work (cf. Section 7).

The OCL API provides a way to customize the behavior of the allInstances operation through a Model Manager (or Extents Map in the legacy implementation). We define a custom extents map that allows to specialize the allInstances call according to the concrete data stores used in a given view. When instances of a classifier are looked up, the extents map redirects the call to the view that fetches instances-using native database calls-from each contributing model and them combines these instances as the result. Compared to the standard OCL implementation that iterates the entire model to match elements of a given type, this approach benefits from the low-level optimizations of the databases (such as built-in indexes and caches). We show in our evaluation that such optimization can dramatically improve query computation performances (cf. Section 5).

EVALUATION

To evaluate our integration approach and its current implementation, we applied them on the use case from the MegaM@Rt2 project (cf. Section 2.1). In this section, we focus on measuring the time overhead of our current implementation, because it directly impacts the interactive user experience (as opposed to batch processing). However, as dealing with on-disk resources is inevitably (one to two orders of magnitude) slower than dealing with in-memory resources, matching the speed of in-memory resources is not a realistic goal. Thus, we rather insist on the asymptotic behavior of our approach and on gains made by our optimizations.

For reproducibility, the complete source code of the performed benchmarks (including the models and views) as well as more detailed results are available online 78 . All the benchmarks have been realized on a laptop with an i7-7600 (2.80GHz) processor, 32GB of RAM, and M.2 PCIe SSD, using OpenJDK 64-bit 1.8.0.

Overview

We built two versions of the same view answering to the Me-gaM@Rt2 use case.

The first version is fully file-based: all four contributing models and the view-specific information (i.e. the weaving model) are serialized using standard EMF-XMI. Thus, once loaded, the view resides fully in memory.

The second version demonstrates our capability to build views over heterogeneous model resources. It uses a mix of file-based and database resources as contributing models. More precisely, the Runtime Log model and the weaving model are persisted in a Neo4j graph database handled by NeoEMF, using our mapping developed for optimizing flat models (cf. Section 4.3) Furthermore, we also evaluated the scalability of both versions of the view. To this intent, for each version we considered different sizes for the Runtime Log model, going from 10 1 to 10 6 elements. This way, we have been able to measure the performance of the view creation, loading and querying up to large-scale models, as required in our MegaM@Rt2 context.

Benchmark 1: Creating the View-specific Information

The first benchmark evaluates the creation of the view-specific data, stored as a weaving model, that is needed by the view in order to be loaded. This benchmark notably measures the overhead of navigating and populating such databases resources, compared to in-memory EMF resources. The weaving model contains the new (virtual) links between the different models composing the view. Recall that in Figure 2, we create three virtual links: (1) we connect a given execution Log to the Java ClassDeclaration that emitted it; (2) we relate the Java Package this ClassDeclaration is part of to the UML Component that represents it at design level; (3) we link this UML Component to the corresponding ReqIF SpecObject, i.e. the requirement the UML Component is supposed to support.

As a consequence, creating the weaving model implies checking different matches between two elements coming from two contributing models. For large models, such as the Runtime Log from the MegaM@Rt2 scenario, these matches can be very numerous. In these cases, the whole matching process can take a significant amount of time. Table 1 compares the time it takes to create the weaving model using the two versions of our view, while Table 2 compares the sizes of the persisted weaving models on disk. The Size column in both tables refers to the number of log elements in the Runtime Log model.

A first observation is that, while models stored in databases are, as expected, slower to create than models serialized in XMI, the overhead for the heterogeneous views diminishes when models get larger. This is possibly indicating a better asymptotic performance. A second observation is that the weaving models persisted in databases are overall 50 times larger than the ones persisted in XMI, and this factor is constant across model sizes. The large size of the persistence format used by the database backend can be explained by the creation of many indexes and logs when initializing the resource. Even disk, the compromise is made in favor of faster lookup as we will see in next two benchmarks.

Benchmark 2: Loading the View

In the second benchmark, we evaluated both the loading of a view and the iteration over all its contents. Again, we performed this on the two versions of the view (full XMI vs. databases + XMI). This benchmark measures the overhead of accessing the content of the different models contributing to the view. Table 3 compares the time it takes to load the two versions of the view, while Table 4 compares the time required to iterate over the full content of the view.

A first point is that loading the heterogeneous view takes a relatively low and constant time (between 1 and 4 seconds), regardless of the size of the Runtime Log model (i.e. the largest one) contributing to the view. For the largest model size, it takes four times longer to load the first view compared to the similar heterogeneous view which uses our approach. This difference can be explained by the lazy loading of our approach, where most of the actual loading takes place when navigating model elements.

When iterating over the full content of the view, the overhead remains relatively small, but slightly increases as the Runtime Log model gets larger. For the largest size, the heterogeneous view is Size XMI XMI (Opt.) Hetero. Hetero. (Opt.) 10 1 42 times slower to navigate, which is around the expected speed difference between RAM and disk. This large increase in time can be partly explained by the data model of the underlying database, for which exhaustive iteration is a very costly operation due to numerous loads/unloads between database and memory. While a full iteration scenario may not be very common in practice, it is a useful reminder that the choice of data representation can have a strong impact on performance.

Benchmark 3: Querying the View

In the third benchmark, we measured the time it took to successfully run three different OCL queries on top of our view. The considered OCL queries are the following:

(1) Log.allInstances()->size() The first query simply counts all the instances of Log elements in the view, and thus only accesses the Runtime Log model via the view. The other two traverse the complete view, i.e. they access to elements from all of the four contributing models.

Table 5 compares the time it takes to execute query (1) on the two versions of our view. Tables 6 and7 do the same for queries (2) and (3), respectively. In these three tables, the two additional (Opt.) columns refer to optimized views that use the custom extents map we described in Section 4.4. One observation is that, on the heterogeneous view, the queries can be 11 to 30 times slower than on the XMI view, which is still lower than the expected speed difference between RAM and disk. The optimized versions are a 2-to 6-fold improvement, which brings the overhead down to 3 to 30 times slower, as the optimizations also benefit the XMI view. The effect of the specialization of the allInstances operation on the Runtime Log model stored in database is the most evident on the last line of Table 5. For the other two queries, the improvement is lower, but still significant. Some further gains may lie in fully specializing the queries into backend-specific request plans, as proposed in Section 3.4.

Size

RELATED WORK

Several solutions have already been proposed in order to support the definition, creation and handling of views over models. We have already studied and tried to classify them according to their main characteristics [START_REF] Bruneliere | A Featurebased Survey of Model View Approaches[END_REF]. From what we have been able to observe so far, there are currently not many proofs that these solutions do scale up in the context of very large models. This can be considered as an important issue in this area, as scalability is key to related challenges such as view update or incremental maintenance (such as seen in our detailed study).

Moreover, few model view approaches focus on integrating strongly interconnected models coming from different data sources. For instance, ModelJoin [START_REF] Burger | View-based Model-driven Software Development with ModelJoin[END_REF] proposes a DSL for querying different models and building a view as a result. However, it does not currently provide particular support for various model persistence backends (other than the EMF default ones). On the contrary, Open-Flexo [START_REF] Fahad | Addressing Modularity for Heterogeneous Multi-model Systems using Model Federation[END_REF] is natively intended to support several data sources. But it privileges graphical (manual) modeling to specify views and does not come with an extended querying support at view-level. These are important aspects that were lacking in our current MegaM@Rt2 context.

Another relevant approach is Epsilon [START_REF] Kolovos | Eclipse development tools for epsilon[END_REF], a modeling platform defining a family of languages to query, transform and compare models. Among these languages, Epsilon provides EML [START_REF] Kolovos | Merging models with the epsilon merging language (EML)[END_REF], that allows to merge models, and Epsilon Decoration [START_REF] Dimitrios S Kolovos | Constructing and navigating noninvasive model decorations[END_REF], that allows to decorate an existing model with additional features. These can be seen as kind of equivalent to a (partial) support for model views. Compared to our solution based on EMF Views [START_REF] Bruneliere | EMF Views: A View Mechanism for Integrating Heterogeneous Models[END_REF], Epsilon does not currently provide optimized strategies to heterogeneous backend queries, nor allows to decorate multiple models/metamodels. Moreover, it only relies on in-memory structures to store both the merging and decoration constructs, which can be a limitation in terms of scalability.

There has also been several initiatives more related to the model querying domain. For example the VIATRA [START_REF] Varró | Road to a Reactive and Incremental Model Transformation Platform: Three Generations of the VIATRA Framework[END_REF] project, relying on IncQuery [START_REF] Ujhelyi | EMF-IncQuery: An Integrated Development Environment for Live Model Queries[END_REF] for efficient incremental querying, is a reactive model transformation platform. The platform also embeds some capabilities for manipulating multiple models and defining sorts of views over them [START_REF] Debreceni | Query-driven incremental synchronization of view models[END_REF]. VIATRA and our approach work best in different scenarios. VIATRA is very efficient when the contributing models fit in memory and queries are executed multiple times over the same view. Our solution is rather designed to access models from different sources (notably from databases), and to benefit from their internal structure in order to efficiently perform single query computations. However, incremental querying could be integrated to our solution by experimenting on the use of IncQuery over our views (in addition to OCL as described in this paper).

A few approaches have been proposed to improve the computation of model-level queries over several scalable persistence solutions. The Mogwaï tool [START_REF] Daniel | Mogwaï: a Framework to Handle Complex Queries on Large Models[END_REF] is a translation approach that maps OCL constructs to Gremlin [START_REF]The Gremlin Language[END_REF], a graph database language: generated queries are sent directly to the database for computation, thus bypassing the limitation of current modeling frameworks. A similar approach is used in the Hawk query framework [START_REF] Barmpis | Hawk: Towards a scalable model indexing architecture[END_REF], that dynamically translates Epsilon queries into graph database native calls. However, these solutions focus on specific data sources and are not designed to handle heterogeneous backends (such as in a view). Nevertheless, they could be integrated to our solution in order to speed-up parts of queries related to the backend they target.

Finally, in the data warehouse community, views on heterogeneous storage solutions have already been studied for relational databases [START_REF] Gupta | Selection of views to materialize in a data warehouse[END_REF]. They regained interest quite recently thanks to polystore data warehouses [START_REF] Chevalier | How can we implement a Multidimensional Data Warehouse using NoSQL?[END_REF]. On the query side, CloudMdsQL [START_REF] Kolev | CloudMdsQL: querying heterogeneous cloud data stores with a common language[END_REF] is a SQL-like language for querying multiple data stores within a single query. To do so, it extends the standard SQL syntax with additional constructs allowing to embed native datastore queries. A similar approach can be found in generic query frameworks such as Apache Drill 9 . Such solutions could also be integrated to our approach to improve the overall computation of queries and views on models stored in heterogeneous data backends.

CONCLUSION: LESSONS LEARNED & FUTURE WORK

In this paper, we presented our approach to support the efficient creation and handling of model views over heterogeneous largescale models. We started by detailing our conceptual solution to integrate model views and model persistence frameworks, emphasizing on important goals to be addressed. Then we described our current EMF-based implementation of this conceptual approach, that is being developed in the context of the MegaM@Rt2 industrial project. We also summarized our evaluation of this approach and implementation onto a view scenario taken from MegaM@Rt2. In the current state, our work has shown promising results when creating and loading views on very large models. Our evaluation has also shown that there is still room for improvement when querying large-scale views using our approach, even though we already started to address some frequently encountered cases. We believe that, 9 https://drill.apache.org/ by continuing to leverage model persistence-specific optimizations, we can achieve scalability at a low overhead with our solution.

Lessons Learned. From our experience in this paper, we can attest to the benefit of relying on a standard API (such as the EMF one) when it comes to integrating together different tools. This largely facilitated the initial combination of the EMF Views, NeoEMF and CDO tools in order to obtain a solution working on basic cases. However, relying on such generic API can also hinder performance when tackling larger-scale scenarios. Firstly, the generic API may hide some of the features and capabilities of the underlying tools, and so prevent from using them. For instance, the NeoEMF API exposes additional efficient methods for navigating model resources, but these methods are not available to EMF Views when only relying on the standard EMF API. Secondly, using such generic API can also hide the actual impact of some actions. Various backends may have weak spots in their implementation of the generic API, and some usage patterns may be preferred to others for performance or even correctness reasons. For example, when creating a model and adding elements to it using EMF, the order of some operations may matter to the persistence backends while it may have no impact on standard in-memory resources. In this case, a naive use of the generic API may lead to surprising performance issues. Ultimately, to minimize the overhead of views on large models, we have to consider more elaborated strategies. We can notably identify when it is relevant to delegate a given operation or not, and to which persistence backend. Thanks to our approach, we have been able to embed such practical knowledge into our integrated model view solution. This way, users do not have to pay the full cost of the generic API while still benefiting from its genericity and interoperability capabilities.

Future Work. In the next steps of our work, we will push further our experiments by also testing model transformation tools on our views, such as ATL [START_REF] Jouault | ATL: A Model Transformation Tool[END_REF] or VIATRA [START_REF] Varró | Road to a Reactive and Incremental Model Transformation Platform: Three Generations of the VIATRA Framework[END_REF] ones. To this intent, we can use the view information to delegate parts of the transformation computations directly to the underlying database backends. We plan to do this by integrating scalable query/transformation approaches, such as Mogwaï [START_REF] Daniel | Gremlin-ATL: a scalable model transformation framework[END_REF] for instance. Another possible work is to extend our integration approach to additional model handling and querying environments, such as Epsilon [START_REF] Kolovos | Eclipse development tools for epsilon[END_REF] or KMF [START_REF] Fouquet | An Eclipse Modelling Framework Alternative to Meet the Models@Runtime Requirements[END_REF] for instance. Moreover, we could also study how incremental querying techniques [START_REF] Bergmann | Incremental Evaluation of Model Queries over EMF models[END_REF] could be integrated in our approach (in addition to the reuse of some already realized optimizations, at OCL-level for instance [START_REF] Edward D Willink | Deterministic Lazy Mutable OCL Collections[END_REF]). Finally, we are going to continue the developments around our model view solution and apply them in the context of other use cases from the MegaM@Rt2 project. For example, we already have plans to build views tracing the architectural models of an industrial system with runtime models representing the configuration and running of corresponding physical machines.

Figure 1 :

 1 Figure 1: Running use case from the MegaM@Rt2 industrial project.

Figure 2 :

 2 Figure 2: Concrete example of a view in MegaM@Rt2 (based on the use case from Figure 1).

A

  Modeling Framework is usually composed of two main parts: a Core component providing the inner behavior (i.e. model manipulation facilities) and a Generic API as the interface provided externally for (re)use by Model-based Tools. The Modeling Framework also often provides a base File Persistence Framework relying on the local Modeling Framework (Core)

Figure 3 :

 3 Figure 3: A conceptual approach for integrating model view and model persistence capabilities.

Figure 4 :

 4 Figure 4: Optimizing model view querying by delegating to model persistence backends.

Table 1 :

 1 . The Java Source Code model is persisted in a relational database handled by CDO. Only Time (in minutes) to create the view-specific models (weaving models).the two remaining models, namely the UML Component model and the ReqIF Requirement model, are serialized as XMI files handled by the standard EMF implementation.

	Size XMI Hetero. Overhead
	10 1 0.001	0.051 38
	10 2 0.001	0.028 23
	10 3 0.001	0.058 52
	10 4 0.004	0.293 81
	10 5 0.098	1.778 18
	10 6 8.460	22.556 3

Table 2 :

 2 though the heterogeneous resources are larger on Size (in megabytes) of the view-specific models (weaving models) on disk.

	Size	XMI	Hetero. Overhead
	10 1	0.011	0.704 64
	10 2	0.036	1.828 51
	10 3	0.285	13.284 47
	10 4	2.799	130.736 47
	10 5	28.112	1316.776 47
	10 6 282.994 13263.500 47
	Size	XMI Hetero. Overhead
	10 1	0.788	2.265 2.87
	10 2	0.257	0.870 3.39
	10 3	0.245	0.750 3.06
	10 4	0.389	0.811 2.08
	10 5	0.921	2.482 2.69
	10 6 12.214	3.006 0.25

Table 3 :

 3 Time (in seconds) to load the view.

	Size XMI Hetero. Overhead
	10 1 1.468	5.049 3
	10 2 0.641	3.029 5
	10 3 0.469	2.222 5
	10 4 0.623	2.833 5
	10 5 0.948	6.795 7
	10 6 1.946	82.323 42

Table 4 :

 4 Time (in seconds) to iterate over the full content of the view.

Table 5 :

 5 Time (in seconds) to run the OCL query (1).

	1.083	0.049	5.655	4.722
	10 2 0.683	0.025	2.694	3.000
	10 3 0.477	0.019	2.087	1.744
	10 4 0.433	0.022	2.707	1.905
	10 5 0.872	0.576	7.777	2.309
	10 6 5.485	0.752	85.030	14.544
	Size XMI XMI (Opt.) Hetero. Hetero. (Opt.)
	10 1 1.093	0.116	5.075	4.043
	10 2 0.711	0.031	3.478	2.563
	10 3 0.527	0.033	3.256	2.087
	10 4 0.570	0.068	5.336	3.173
	10 5 1.050	0.241	16.604	9.626
	10 6 6.294	4.008 178.444	114.733

Table 6 :

 6 Time (in seconds) to run the OCL query (2).

Table 7 :

 7 Time (in seconds) to run the OCL query (3).

		XMI XMI (Opt.) Hetero. Hetero. (Opt.)
	10 1	1.133	0.186	4.473	3.860
	10 2	0.664	0.026	2.575	2.270
	10 3	0.688	0.046	2.148	1.869
	10 4	0.691	0.248	5.138	3.147
	10 5	1.757	0.857	18.518	12.843
	10 6 12.722	7.647 251.451	154.621

http://megamart2-ecsel.eu/

http://megamart2-ecsel.eu/

https://github.com/atlanmod/emfviews/tree/integrate-neoemf

https://github.com/atlanmod/emfviews/

We do not elaborate in this paper how such weaving model can be obtained in general (the initial EMF Views paper[START_REF] Bruneliere | EMF Views: A View Mechanism for Integrating Heterogeneous Models[END_REF] covers this point), but we describe one construction scheme in Section 5.2.

https://github.com/atlanmod/neoemf/

https://github.com/atlanmod/scalable-views-heterogeneous-models

http://remodd.org/content/towards-scalable-views-heterogeneous-model-resources

ACKNOWLEDGMENTS

This work has received funding from the ECSEL Joint Undertaking under grant agreement No. 737494 (MegaM@Rt2 project). This Joint Undertaking receives support from the European Union's Horizon 2020 research and innovation program and from Sweden, France, Spain, Italy, Finland & Czech Republic.


Editor B Antonio

R Paolo

Impedance control using a cascaded loop force control.

Sylvain Devie, Pierre-Philippe Robet, Yannick Aoustin, and Maxime Gautier

Abstract-In this paper, a cascaded loop force control is implemented on a robot while considering the flexibility of the force sensor connecting the end effector to the tool. A classical frequency approach using a bandwidth and a phase margin is used to tune this controller. The aim is to find an equivalence between the proposed control law and a classical impedance control law. The apparent impedance of this system is calculated and can be seen as the desired impedance for a classical impedance control law. Using this equivalence the cascaded loop force controller can be tuned as an impedance controller, and can be shown to behave equivalently in simulations and experiments on a one degree of freedom (dof ) robot.

Index Terms-Force Control, Compliance and Impedance Control, Industrial Robots

I. INTRODUCTION

C ONTROLLING the interaction with the environment is one of the most challenging fields of today's robotics. Several applications can be considered. For example, in industrial applications like polishing, a robot can be used. In this case it has to apply a specific force onto the environment, while exhibiting a variable impedance. However, this paper focuses on another field of application, co-botics, where the robot has to work with a human to perform a collaborative task. The classical co-botics applications are tele-operation tasks, where the operator manipulates a master arm to perform a task with a slave arm, and co-manipulation, where the operation is executed by the robotic arm manipulated by the operator. This paper focuses on this latter application.

This paper focuses on two different approaches to force control -the cascaded loop control and the impedance control. These control laws are based on the mechanical model of the robot, which is supposed to be sufficiently close to reality thanks to formal algorithms that efficiently compute robot models [START_REF] Khalil | Reducing the computational burden of the dynamic models of robots[END_REF] and allow accurate identification of the dynamic parameters.

In [START_REF] Khatib | Motion and force control of robot manipulators[END_REF], a control law was proposed to control the force and the position of a rigid robot using a stiff force sensor by decoupling force and position control using a closed loop. However, the proposed experiments showed a force overshoot at the point of impact with the environment. At the same time, impedance control was formulated by Hogan in [START_REF] Hogan | Impedance Control: An Approach to Manipulation[END_REF] as the achievement of the desired relation between external force and robot movement. In the case of co-manipulation, it allows us to control the robot in order to control the dynamic response felt by the operator when he manipulates it. Ever since, impedance control has become the general way to control the interaction between a robot and its environment. An equivalent control law has been proposed in [START_REF] Goldenberg | Implementation of force and impedance control in robot manipulators[END_REF], requiring an exact model of the robot.

One of the main problems of the conventional force controllers is that their performances are degraded in the presence of dynamic perturbations. To solve this problem, in [START_REF] Morel | A reactive external force loop approach to control manipulators in the presence of environmental disturbances[END_REF], an external force loop is proposed in order to encapsulate an inner force-based impedance loop. This external loop allows modifying the reference trajectory of the inner impedance controller online. The opposite approach was proposed by the same authors in [START_REF] Morel | Impedance based combination of visual and force control[END_REF]. In this paper, an inner force loop was encapsulated into an outer position-based impedance control carried out by vision. For this impedance control, the target impedance of the robot was limited to only a damping coefficient, which is also the aim of this paper. The advantage of using vision-based control is the possibility to design the two loops separately. However, this kind of controller needs a powerful processor and time to process. This is why this paper focuses on encoder-based measurement.

The classical approach to impedance control concentrates on robotic systems in which the joint elasticity is neglected. But in the case of classical industrial robots, the flexibility of the joints of the robot limit the performance of these control laws. In [START_REF] Ott | Decoupling based Cartesian impedance control of flexible joint robots[END_REF], Ott et al. proposed an impedance control law taking into account this flexibility by decoupling the dynamics of the torque from one of the links. They proposed a proof of stability and an experimental validation with a one dof robot. In [START_REF] Ott | On the Passivity-Based Impedance Control of Flexible Joint Robots[END_REF] they proposed two controllers, using an outer impedance control loop with an inner torque loop in order to achieve the desired dynamic behaviour with respect to an external force acting on the load side. This proposed model for the robot is similar to the one defined and used by this paper. However, the flexibility considered here is the flexibility of the force sensor, which is ten times as large as that of the joints. Other approaches for impedance control considering the flexibility of the robot are presented in [START_REF] Ozawa | A new impedance control concept for elastic joint robots[END_REF] and [START_REF] Ferretti | Impedance control for elastic joints industrial manipulators[END_REF] for one dof.

The use of a one dof prismatic robot is a good solution for this kind of study, as recently shown in [START_REF] Yashiro | Fast Stiffness Estimation using Acceleration-based Impedance Control and its Application to Bilateral Control[END_REF]. There, an acceleration-based impedance control law is used in a teleoperation scenario for fast environmental stiffness estimations with a time delay. In [START_REF] Seki | Improvement of Force Transmission Performance Considering Nonlinear[END_REF] a bilateral tele-operation control is improved by considering a non-linear model for the perturbation observer.

In [START_REF] Lamy | Achieving efficient and stable comanipulation through adaptation to changes in human arm impedance[END_REF], a cascaded loop using proportional (P) correction for the velocity loop and proportional and integral (PI) correction for the force loop is proposed. Then the equivalent impedance of the full system is calculated -it is equivalent to a apparent mass proportional to the integral correction of the system. Experiments are made for one dof of a Stäubli RX90. In this paper, a similar control law is proposed, using a PI controller on an inner velocity loop to control the performance of the system and a P controller on an outer force loop to control the transparency of the system. The apparent impedance of the control law is a mass-damper system where the mass depends on the parameters of the PI inner velocity controller and the damper depends of the P outer force controller. This control law has been defined in a previous study [START_REF] Devie | Accurate force control and co-manipulation control using hybrid external command[END_REF] and applied on a known system with one dof ( [START_REF] Gautier | Dynamic Identification of flexible joint manipulators with an efficient closed loop output error method based on motor torque output data[END_REF], [START_REF] Hamon | Dynamic Modeling and Identification of Joint Drive with Load[END_REF], [START_REF] Robet | Cascaded loops control of DC motor driven joint including an acceleration loop[END_REF]).

The main contribution of this paper is to compare this control law to a classical impedance controller ( [START_REF] Hogan | Stable execution of contact tasks using impedance control[END_REF]). The aim is to create an equivalence between the two control laws, allowing us to tune the first one [START_REF] Devie | Accurate force control and co-manipulation control using hybrid external command[END_REF] according to a desired impedance and tune the second one [START_REF] Hogan | Stable execution of contact tasks using impedance control[END_REF] according to the desired performance of the first control law. This equivalence, will allows the utilisation of the classical tool of automatism in the case of robot interacting with the environment. It will be obtained by calculating the apparent impedance of the cascaded loop control and apply it as a reference for the impedance control law. The cascaded closed loop used is an advantage because it allows us to tune the apparent mass and damping coefficient while considering the two loops independently. The stiffness term of the impedance control law will correct the errors due to the experimental conditions in an innovative manner -it is not used as a apparent stiffness like the classical impedance controller, but as a control stiffness that makes an integral term appear.

This paper is outlined as follows -Section 2 describes the experimental set-up and its modelling. Section 3 presents the closed loop controller, the calculation of its apparent impedance and the impedance controller targeting this impedance. Section 4 is devoted to simulations and experimental validations and Section 5 offers our conclusion.

II. MODELLING

In this study, the EMPS (Electro Mechanical Positioning System) robot is considered (Fig. 1). It is a standard configuration of a drive system for the prismatic joints of robots or machine tools. It is composed of a Maxon DC motor which drives a carriage by a Star high-precision low-friction ball screw. The carriage moves a load in translation. The motor rotor and the ball screw are connected by a flexible coupling. Two incremental encoders are present on the robot: one on the motor side and one on the load side. The first one measures the motor position and the second one measures the position of the ball screw.

In the following, let us consider that the robot is rigid in the operational frequency range, which implies that the inner Fig. 1: EMPS robot main components flexibility does not create oscillations. All variables are given in SI units on the load side. The motor force τ 1 is proportional to the motor torque, according to the reduction ratio r of the ball screw. This torque is proportional to the electric current inside the motor according to the torque constant of the motor k t . An inner current loop is applied on the exit of the control law. The bandwidth of this loop is sufficiently high to consider a linear relation G i between the reference voltage of the inner current loop v I (V) and the electric current inside the motor. These relations allow us to write:

τ 1 = r.k t .G i .v I = G τ .v I (1)
For the following study, a tool interacting with the environment is fixed to the carriage. A force sensor is used in order to measure the interaction force between the robot and the environment through this tool (Fig. 2). This sensor is a spring with a stiffness coefficient K r12 given by the manufacturer, and this has been checked experimentally.

The mechanical system has two degrees of freedoms (dof s) : one rigid dof q 1 and one flexible dof q 2 . The position q 1 of the end effector of the robot is measured and controlled thanks to an encoder sensor. The position q 2 is the relative deformation of the force sensor spring defined in order to have τ e = 0 when q 2 = 0, where τ e is the force measured by the sensor. It defines the position x of the end-effector thanks to (2).

x = q 1 + q 2 (2) Fig. 2: Definition of the considered system. Body 1 is the controlled mass of the robot and is connected to one end of the force sensor. Body 2 is the tool, is connected to the other end of the force sensor, and interacts with the environment.

In the following, body 1 contains the moving part of the robot, including the rotor of the motor, the power transmission gear and the attached end of the force sensor. Body 2 represents the other extremity of the force sensor and the tool, which is in contact with the environment.

For each body i = [1, 2], M i is the inertia, which is equivalent to a mass in translation (kg), F vi is the viscous damping coefficient (N/(m/s)) and F ci is the Coulomb friction (N).

With respect to the reference frame fixed to the robot, the dynamic model of the horizontal mechanical device is as follows [START_REF] Gautier | Dynamic Identification of flexible joint manipulators with an efficient closed loop output error method based on motor torque output data[END_REF]:

τ 1 = M 1 q1 + F v1 q1 + F c1 sign( q1 ) -K r12 (x -q 1 ) τ * e = M 2 ẍ + K r12 (x -q 1 ) (3)
with τ 1 the actuation force on body 1 and τ * e the interaction force from the environment on body 2. In the following, let us differentiate the force τ * e applied on the system from the environment and the force τ e = K r12 (xq 1 ) measured by the force sensor.

The interaction force τ * e applied on the system and the velocity ẋ are linked by the impedance of the environment: Z e = τ * e / ẋ. If the robot is controlled in order to apply a specific force on the environment, Z e (N/(m/s)) is the impedance of this environment. Three particular cases can be considered for the impedance. The softest case is the free case: τ * e = 0 so Z e = 0, which means that there is no obstacle and the robot is free to move. The hardest case is the constraint case: ẋ = 0 so Z e -→ ∞, which means that the environment is an infinitely rigid obstacle, the direct consequence is that x is constant.

III. CONTROL DESIGN A. Cascaded loop control

The previous study [START_REF] Devie | Accurate force control and co-manipulation control using hybrid external command[END_REF], a simple control law was studied for the force control using an IP correction for the velocity loop and a P correction for the force loop. Then, this control law was adapted in order to perform the co-manipulation task.

In the co-manipulation case, the environmental impedance depends on the impedance of everything interacting with the robot, including the environment and the operator's hands, it is supposed to be unknown. In this case, the control system is illustrated in Fig. 3. The velocity loop is used to control the performance of the system and the force loop is mostly used to control its transparency. Here, by increasing the gain k e1 , we increase the transparency. However, a very high gain can lead to instability. We consider τ re f the desired effort applied by the robot on the operator's hand, it can be seen as an offset of effort that the operator has to apply. In order get an easy co-manipulation with τ e = 0 when the robot is not moving ( q1 = q2 = 0), we choose τ re f = 0.

Thanks to this reference, the system allows a linear relationship between the external force τ e and the velocity reference qre f . If the external perturbation has a low frequency, the relation τ e = k c q1 can be used in order to calculate the correction gain of the closed loops.

In the following, we consider M 2 ẍ τ * e . In this case we have τ * e = τ e . In this case, (3) becomes (4).

τ 1 = M 1 q1 + F v1 q1 + F c1 sign( q1 ) -τ * e (4)
In order to calculate the correction and the performance of the system, we consider that the frequency range of τ e (< 20 rad/s) is small compared to the bandwidth of the velocity loop (100 rad/s), giving us a linear relation between the velocity and the external force: τ e = k c q1 with k c = 1/k e1 .

Imposing the phase margin φ v at a frequency ω v leads to T vo ( jω v ) = q1 q1 re f -q1 = 1e j(-π+φ v ) and gives the values of k v1 and t v . The closed velocity loop is defined with a transfer function of second order, the cut-off frequency ω 0v = K v /M 1 and a damping coefficient

z v = (t v + C K v ) ω 0v 2 , with K v = k v1 G τ /t v and C = F v1 -k c .
According to Fig. 3 and considering a reference for τ re f = 0 for co-manipulation applications, the open loop transfer function of the velocity loop is given by the equation:

T vo (s) = q1 (s) v q(s) -q1 (s) = k v1 G τ t v s 1 M 1 s +C + k v1 G τ ( 5
)
with C = F v1 -k c . Imposing the phase margin φ v at a frequency ω v leads to T vo ( jω v ) = 1e j(-π+φ v ) and gives the values of k v1 and t v . This criterion ensures the stability of the system and allows to calculate some characteristics of the control, like the overshoot of the response time. However, the passivity analysis, which is currently used in case of robot/environment interaction only assure the stability, it is not necessary here.

B. Equivalent impedance

The apparent impedance of the robot is the impedance felt by the operator when he manipulates the robot. By separately considering the two blocks of Fig. 3, it is possible to write the following equation:

Z 1 (s) = τ 1 (s) + τ e (s) q1 (s) τ 1 (s) = A(s)τ e (s) -B(s) q1 (s) (6)
with:

• Z 1 = (M 1 s + F v1 ) the impedance of the robot, • A(s) = k e1 k v1 G τ t v s = K v k c s • B(s) = k v1 G τ 1 + t v s t v s = K v 1 + t v s s .
Let us now define the equivalent impedance of the robot from (6):

Z r = τ e q1 (s) = Z 1 + B(s) A(s) + 1 (7)
This equation can be written in the following form:

Z r = k c M 1 s 2 + (F v1 + K v t v )s + K v k c s + K v (8)
At low frequencies ω K v /k c , which is in the frequency range of our applications, the denominator of ( 8) is equivalent to a gain K v . Similarly, for ω K v /M 1 we simplify the numerator to get:

Z r = k c (F v1 + K v t v )s + K v K v (9)
According to the previous section:

t v = 2z v ω 0v - F v1 -k c K v (10) Z r = 2z v k c ω 0v (1 + k c 2z v ω 0v M 1 )s + k c (11)
So we can define the apparent impedance as Z r = M a s + F va , with:

• M a = 2z v k c ω 0v (1 + k c 2z v ω 0v M 1
) the apparent mass,

• F va = k c the apparent damping. This simplified impedance is equivalent to the one of eq. ( 8) in the considered frequency range, as shown in Fig. 4. The numerical value of the mechanical parameters are given in the following section. We use this simplified assumption in the remainder of this paper. Fig. 4: Bode diagram of the apparent impedance of (8) and its simplified version [START_REF] Yashiro | Fast Stiffness Estimation using Acceleration-based Impedance Control and its Application to Bilateral Control[END_REF], the numerical values of the parameters are defined in the next section.

From this control law, no stiffness coefficient K 0 can be identified. However, it would be possible to identify such a stiffness with another kind of cascaded loop. For example, adding a position loop in parallel to the force loop allows us to define an apparent stiffness K 0 . However, the control law presented in this paper behaves like a mass damper system and does not use any apparent stiffness other than the stiffness of the force sensor. Hence in order to ensure the equivalence between the two control laws, the stiffness coefficient K 0 will be considered null in the first set of experiments below.

However, the apparent impedance of the robot at the point of interaction with the environment is Z a = τ * e / ẋ. It should not be confused with Z e which is the impedance of the environment at the point of interaction with the robot. According to the second equation of (3):

q1 (s) = sq 1 (s) = s K r12 (Z 2 ẋ(s) -τ * e (s)) (12)
with Z 2 = M 2 s + K r12 /s, [START_REF] Yashiro | Fast Stiffness Estimation using Acceleration-based Impedance Control and its Application to Bilateral Control[END_REF] and [START_REF] Seki | Improvement of Force Transmission Performance Considering Nonlinear[END_REF] give:

Z r = τ * e Z 2 x -τ * e K r12 s (13)
The expression of Z a becomes:

Z a = Z r Z 2 K r12 s + Z r (14)
When M 2 ẍ can be neglected with respect to τ * e , which is the case in the considered applications, this equation becomes:

Z a = Z r 1 + Z r K r12 s (15)
This means that the apparent impedance strongly depends on the stiffness of the force sensor measuring the interaction between the robot and the environment. If this stiffness has high values, Z a is equivalent to Z r . If this stiffness has very low values, τ * e is not transmitted to the robot and it is equivalent to a low pass filter.

C. Impedance control

Let us now consider an impedance control. From (4), we get:

τ 1 + τ * e = M 1 q1 + F v1 q1 + F c1 sign( q1 ) (16)
The considered model for the impedance control is given by Fig. 6. The goal here is to control the robot in order to give it a specific apparent inertia Z a = τ * e / ẋ. However, at low frequencies, ẋ ≈ q1 . This is the case when the resonance frequency of the robot K r12 /M 1 is low compared to ω v . Usually, this impedance is chosen to have the following desired behaviour:

τ * e = M a q1 + F va q1 + K 0 (q 1 -q 1 0 ) (17)
q 1 0 is the position reference for the impedance controller. The gain K 0 is usually chosen according to the desired apparent stiffness K a , with

K -1 a = K -1 0 + K -1 r12 ( 18
)
According to this equation, the apparent stiffness cannot be higher than K r12 . However, in this specific case, the apparent stiffness was not identified in the precedent section. It will be calculated in another method in the next section. Let us define the acceleration q1 :

q1 = 1 M a (τ * e -F va q1 -K 0 (q 1 -q 1 0 )) (19)
By substituting ( 19) into ( 16), the controlled force is:

τ 1 = (τ e -τ re f ) M 1 -M a M a + (F v1 -F va M 1 M a ) q1 -K 0 M 1 M a (q 1 -q 1 0 ) + F c1 sign( q1 ) (20)
The main focus of this study is to compare the behaviour of the system controlled by this force to the one controlled by the cascaded loop represented in Fig. 3.

Let us now verify whether the apparent impedance of this control law corresponds with the one presented in the previous section. By injecting (20) into (4) with τ re f = 0, we get the equation represented in Fig. 5. It can be simplified into:

τ e = M a q1 + F va q1 + K 0 M 1 M a (q 1 -q 1 0 ) (21)
According to this equation, we get Z r = τ e / q1 = Z a , with Z a defined in ( 15) at low frequency. If this apparent impedance is considered, both control laws are equivalent. Here, M a and F va are chosen from the expression of Z r in the previous section in order to have a correlation between the two control laws. The gain K 0 is chosen equal to 0 N/m.

IV. EXPERIMENTAL VALIDATION AND DISCUSSION

The EMPS robot is used. This robot was fully identified in previous studies [START_REF] Gautier | Dynamic Identification of flexible joint manipulators with an efficient closed loop output error method based on motor torque output data[END_REF], the numerical values of the parameters used in the previous section are: M 1 = 105 kg, F v1 = 212 N/(m/s), F c1 = 18.5 N, G τ = 35 N/V and K r12 = 2 10 4 N/m. The considered mass M 1 is the equivalent mass of the robot, including the parts moving in rotation, like the rotor, and the parts moving in translation, like the carriage. The position of the payload is calculated thanks to the encoder sensor and a backward derivative is used to calculate the velocity.

First of all, a simulation will be presented in order to compare the effects of the two control laws on a system that is perfectly known. Then these control laws will be tested on hardware.

A. Simulations

Let us consider the following scenario: the robot is free to move and an operator applies a specific force τ e on the end-effector. This force is measured by the force sensor and used to control the robot. Then, the evolution of the velocity of the robot is observed in order to compare the two control laws. The system is simulated thanks to Simulink in order to compare the two control laws in a controlled environment, using the parameters of I.

z v = √ 2 k v1 = 7.5 10 2 M a = 9 kg w v = 100 rad/s t v = 2.8 10 -2 s F va = 323 N/(m/s) k c = 323 N/(m/s) k e1 = 3.1 10 -3 K 0 = 0 N/(m/s)
The aim of these simulations is to show the equivalence between both control laws, supposing the robot is perfectly identified. Here, the stiffness K 0 does not appear in the apparent impedance of the cascaded loop, so it is chosen to be equal to zero in the case of impedance control. The Coulomb friction in the robot is equivalent to a constant perturbation, which is compensated by the integral correction in the case of the cascaded loop. However, in the case of impedance control, a friction compensation is applied instead. For the experiments on the real system, this is not possible because of the identification error of the friction model (up to 5%). Thus a specific integration will be discussed in the experimental part.

Simulations were performed with these parameters for the two control laws. For the first one, a step signal was applied for the force τ e and the evolution of the velocity q1 was observed. The evolution of this velocity is presented in Fig. 7a for the two control laws. The goal is to design a control with an apparent impedance equals to the desired damping factor F va = k c , similar to [START_REF] Morel | Impedance based combination of visual and force control[END_REF]. 7 shows that, for the same input, the velocity in steady state is the same for the two control laws. The response time to reach 5% of the final value is 76 ms for the closed loop control law and 85 ms for the impedance control law. However, the velocity obtained with the closed loop control law has a second order transfer function behaviour during the transitional time. On the other hand, the velocity obtained with the impedance control law has a first order transfer function behaviour during the transitional regime. This difference is not very visible in Fig. 7a because the damping coefficient z v was chosen to be larger than 1.

Other simulations were executed with these parameters in order to check the bandwidth of these control laws. The parameters of Table I were applied to the two control laws and a sinusoidal function was used for the force input. In this configuration, Fig. 7b shows the evolution of the velocity amplitude as the frequency of the input increases. This figure shows that, if the bandwidth of the impedance control law (4 Hz) is similar to the one of the cascaded loop control law (4 Hz), their velocities are very close. These results prove the equivalence of the two control laws for this specific configuration. According to several simulations, the response of the two controls laws are the same during the transitional regime, with a maximum difference of 10 ms for the response time. But if the damping coefficient z v is reduced to below 1, the response of the control law using the cascaded loop should decrease and have an overshoot, which is the classical behaviour of a second order closed loop, while the response of the impedance closed loop should keep its first order behaviour. However the behaviour at steady state is the same and the maximal difference for the time response is up to 15 ms for a damping coefficient of √ 2/2. So, even if the behaviour is slightly different during the transitional regime the equivalence between the two control laws is valid for any damping coefficient.

B. Experiments

Experiments were performed with the parameters presented in Table I on the EMPS robot. The main difficulties appearing for the comparison of the two control laws in co-manipulation is that the action from the operator is not perfectly repeatable. However, the force τ e applied by the operator is far smaller than the force τ m applied by the motor. Because of this assumption, the effort from the environment can be neglected in the dynamics of the body 1. The input of the control law is divided into the force from the operator and the force from the environment. We choose to simulate the action from the operator, and to consider the effort from the environment to be equal to the one measured by the force sensor. For the experiments, the robot is placed in front of a stiff obstacle.

In the first case, the stiffness K 0 is still considered equal to 0 N/m in order to make a comparison of the two control laws. The input force has values equal to 1 N for t > 0 and -1 N for t < 0. This specific input allows us to use a square signal for the reference force, and to easily repeat the experiment. The evolutions of the velocity q1 and the external force τ e are showed in Fig. 8 for the two control laws.

According to this figure, the response time of the impedance control law is half of the one from the cascaded loop control law, and the steady state behaviour is not the same for the two control laws. This difference is mostly due to the approximation of the friction parameters. Actually, in the case of the EMPS robot, the approximation of the Coulomb and viscous damping has a maximal accuracy of 2 N, which is the order of magnitude of the force applied on the robot. In order Fig. 8: Evolution of velocity for the two control laws for a step input, during the transitional time without environmental reaction, with K 0 = 0.

to have the same behaviour for the two control laws, an integral correction has to be applied in the impedance control law in order to track the reference position q 1 0 . We decided to build this integral correction using the unidentified coefficient K 0 . Here, we do not consider a desired stiffness for the dynamic behaviour of the system, but a control stiffness K 0 around a position q 1 0 defined from the measurement of the external force by:

q 1 0 = t 0 k e1 τ e (u) du (22)
Three values were considered for the stiffness K 0 in order to be stable and have a behaviour similar to the cascaded loop in transitional regime. These values are of the order of magnitude of the stiffness of the force sensor and can be expressed as a function of it: K r12 , K r12 /2 and K r12 /3. The evolution of the velocity, for no environmental reaction is shown in Fig. 9 Fig. 9: Velocity for the two control laws for a step input, during the transitional time without environmental reaction, with differents values for K 0 .

As shown in this figure, the behaviour of the robot controlled with the closed loop control law is coherent with the simulation results: the high damping coefficient allows no overshoot, the integral correction leads us to null steady state error and the response time to 5% of the final value is equal to 86 ms thanks to the chosen dynamics. For the impedance control, it appears that the choice of the gain K 0 has a significant influence on the dynamics of the system. Taking this parameter to be equal to K r12 leads us to feel an apparent stiffness equal to K r12 /2, but the velocity response presents an overshoot because of the rigidity of the system. On the other hand, a coefficient K 0 that is too low decreases the performance of the controller. A good match between the two control laws is obtained for K 0 = K r12 /2. In this case, the apparent stiffness is equal to K r12 /3. Similar to the cascaded loop control law, this one presents no overshoot. It has a response time equal to 88 ms. The evolution of the velocity q1 and the external forces are shown in Fig. 10 when the robot is in contact with the stiff obstacle. In this case, all the control laws present the same behaviour. In steady state, before touching the obstacle, the velocity is constant and equal to k e1 τ e . Then, when the end-effector touches the stiff obstacle, the velocity decreases to zero with a first order transfer function behaviour. During this operation, the curves of the velocities from all the control laws are superimposed and have a response time that is far longer than the one of the free phase. During this phase, the dynamics of the system depend on the obstacle, which is stiffer than the force sensor. A rigid wall is present on the other side of the stiff obstacle. The response shown in Fig. 10 during these phases depends on the equivalent stiffness of the Robot + Obstacle system, which is almost the same for the four control laws.

These experiments show that the control law proposed using a cascaded closed loop is equivalent to an impedance control law using apparent mass and damping, which can be calculated according to the parameters of the control law, and an apparent stiffness which can be built in order to add an integral correction to the basic impedance control law.

V. CONCLUSION

In this paper, a force control law using a cascaded loop was presented in order to perform a co-manipulation task. The apparent inertia of a specific robot using this control law was calculated and used in order to make an impedance control law. It appears that the apparent mass and the apparent damping of this impedance can be calculated according to the dynamic parameters of the robot.

Simulations proved the equivalence between these two control laws under certain assumptions and the experiments showed the limit of this equivalence. However, it is possible to push these limits by building an integral correction in the impedance control law.

Fig. 3 :

 3 Fig. 3: Cascaded closed loop of speed (blue) and force (orange) in the case of co-manipulation.

Fig. 5 :Fig. 6 :

 56 Fig. 5: Impedance closed loop in the case of co-manipulation.

  (a) Velocity for the two control laws for a step input. (b) Velocity amplitude, as a function of the force input frequency for the two control laws.

Fig. 7 :

 7 Fig. 7: Simulation: Velocity, for a force input.

Fig.

  Fig.7shows that, for the same input, the velocity in steady state is the same for the two control laws. The response time to reach 5% of the final value is 76 ms for the closed loop control law and 85 ms for the impedance control law. However, the velocity obtained with the closed loop control law has a second order transfer function behaviour during the transitional time. On the other hand, the velocity obtained with the impedance control law has a first order transfer function behaviour during

Fig. 10 :

 10 Fig. 10: Velocity for the two control laws for a step input for the full experiment, including the contact phase with a stiff obstacle.

TABLE I :

 I Parameters of the first set of experiments

	Dynamic parameters	closed loop gains apparent impedance

ACKNOWLEDGEMENTS

The project is co-funded by the European Union. Europe is now investing in Pays de la Loire with the European Regional Development Fund.