Alexandr Klimchik
email: alexandr.klimchik@emn.fr

Yier Wu
email: yier.wu@emn.fr

Stéphane Caro
email: stephane.caro@irrcyn.ec-nantes.fr

Benoît Furet
email: benoit.furet@univ-nantes.fr

Anatol Pashkevich
email: anatol.pashkevich@emn.fr

Accuracy improvement of robot-based milling using an enhanced manipulator model

Keywords: Robot-based milling, elastostatic calibration, gravity compensator

The paper is devoted to the accuracy improvement of robot-based milling by using an enhanced manipulator model that takes into account both geometric and elastostatic factors. Particular attention is paid to the model parameters identification accuracy. In contrast to other works, the proposed approach takes into account impact of the gravity compensator and link weights on the manipulator elastostatic properties. In order to improve the identification accuracy, the industry oriented performance measure is used to define optimal measurement configurations and an enhanced partial pose measurement method is applied for the identification of the model parameters. The advantages of the developed approach are confirmed by experimental results that deal with the elastostatic calibration of a heavy industrial robot used for milling. The achieved accuracy improvement factor is about 2.4.

Introduction

At present, the conventional CNC machines are progressively replaced in industry by robotic manipulators to perform main manufacturing tasks. For those applications, industrial robots are considered to be very competitive due to their manufacturing flexibility, large workspace, cost-effectiveness and so on. At the same time, the robotic-based machining introduces some difficulties. For instance, link and joint compliances become non-negligible when robot is under substantial external loading. So, in order to achieve high processing accuracy, essential revision of relevant mathematical models and control strategies are required.

The stiffness modeling of robotic manipulators has been in the focus of the research community for more than 30 years [START_REF] Salisbury | Active stiffness control of a manipulator in Cartesian coordinates[END_REF]. There exist different approaches that are able to take into account particularities of serial and parallel manipulators [START_REF] Merlet | Parallel Mechanisms and Robots[END_REF]Gosseling 2008 , Kövecses, and[START_REF] Kövecses | The stiffness matrix in elastically articulated rigid-body systems[END_REF]. Among a number of existing stiffness modeling approaches, the Virtual Joint Modeling (VJM) method looks the most attractive in robotics. Its main idea is to take into account the elastostatic properties of flexible components by presenting them as equivalent localized virtual springs [START_REF] Pashkevich | Enhanced stiffness modeling of manipulators with passive joints[END_REF]. However the stiffness modeling of the manipulators with gravity compensators has not found enough attention yet. Another difficulty related to the stiffness modeling of robotic manipulator is the identification of its model parameters. This problem is quite new in robotics, the existing approaches are suitable for strictly serial manipulators mainly [START_REF] Dumas | Joint stiffness identification of sixrevolute industrial serial robots[END_REF]. Therefore, the paper aims to obtain a sophisticated elastostatic model for heavy industrial robots with a gravity compensator and to identify their parameters.

Problem of the compliance errors compensation

In common engineering practice, robot behavior under an external loading can be described by the following force-deflection relation (Klimchik et al. 2012a)

    1 θ θ θθ θ •• T      t J K H J F (1)
where θ J and θθ H are the Jacobian and Hessian matrices respectively, the matrix θ K describes the elastic properties of the manipulator components. This model al- lows us to compute the end-effector deflection t due to the external loading F . Since the manipulator deflection caused by the loading is known, it can be used to improve the positioning accuracy by means of error compensation technique (Fig. 1). However in practice, only geometrical parameters are provided by the robot manufacturer, while elastostatic parameters should be identified using dedicated calibration techniques. Usually the force-deflection relation (1) is rearranged in the linear model suitable for the identification procedure, which is a linear mapping between the parameters to be identified and the end-effector displacement 11 ,... ;

( 1 , ,)

TT i i i i i i ni ni i im       t A k A J J J F J F (2)
where the vector k collects elastostatic parameters of the matrix

1 θ θ   kK .
It should be mentioned that such a model can be efficiently applied for strictly serial manipulators (without closed-loops) while for heavy manipulators with a gravity compensator this procedure should be revised in order to take into account particularities of the stiffness model. Another difficulty here is related to the gravity compensator modeling, whose parameters are usually not given. Hence, the goal of this work is to obtain a sophisticated elastostatic model that can be used for compliance errors compensation. Accordingly, two problems should be considered: (i) developing the model for the compensator and methodology for the identification of its parameters; (ii) integration of the compensator into conventional elastostatic model and identification of its parameters.

Parameters of the enhanced manipulator model and their identification

Considered industrial robot KUKA KR-270 incorporates gravity compensator that is used to balance link-weights but also affects manipulator elastostatic properties. The mechanical structure of the gravity compensator under study is presented in Fig. 2. The compensator incorporates a passive spring attached to the first and second links, which creates a closed loop that generates the torque applied to the second joint of the manipulator. The compensator geometrical model includes three node points P 0 , P 1 , P 2 , which yield three principal geometrical parameters 12 ,

L P P  , 02 , a P P  , 01 , s PP 
. Let us also introduce some auxiliary parameters (such as x a and y a ), whose geometrical meaning is described in Fig. 2. The fact that the gravity compensator affects on the second joint only allows us to replace the constant parameter 2 K  in the model ( 1) by the non-linear one that also takes into account elasto-static properties of the compensator.

The variable s describing the compensator spring deflection can be computed as the function of second joint coordinate 2 q as follows:

2 2 2 2 cos( ) 2 s a L aL q      (3)
Fig. 2 Gravity compensator and its model Therefore, the equivalent stiffness of the second joint (comprising both the manipulator and compensator stiffnesses) can be expressed as

22 0 2 0 2 2 2 2 sin cos co ( ) ( ) s() c s aL L q q K K K a q s s                  (4)
where c K is the gravity compensator stiffness, the value 0 s corresponds to the distance 01 ,

PP for the unloaded spring. This allows us to extend the classical stiffness model (1) of the serial manipulator by modifying the virtual spring parameters in accordance with the compensator properties. In this case, the Cartesian stiffness matrix C K can be computed using following expression

  1 1T C θ θ θθ θ ( ( ) ) ••    K J K q H J (5)
which includes both the first and second order derivatives (Jacobians and Hessians) of the functions   , gqθ describing the manipulator geometry ((Pashkevich et al. 2011)). Here, the vectors q and θ collect actuator coordinates and the cor- responding deflections.

The equivalent stiffness of the second joint (4) depends on several geometrical parameters ( ,, xy L a a ) that are unknown and should be identified using reference points illustrated in Fig. 2b. Taking into account particularities of the experimental setup for the geometric parameters identification, where for each measurement of the point P 1 joint coordinate 2 q is given, the value of L can be computed as

11 m TT i i i i i m i L    p R u u u (6)
where

1 1 m i i ii m     p p p , 1 1 m i i ii m     u u u , [cos , sin , 0] T i i i qq  u , i
p is the Cartesian coordinate vector of point P 1 for the ith measurement and m is the number of measurements and the orthogonal matrix T  R V U can be obtained using the following SVD-factorization

1 m i i T i    u p U ΣV
  11 1 1 1 1 1 1 1 0 1 2 k m k m k m j j j j j i i i i i j i j T ii i j i TT s k m                 p I n n p p p n n p (7)
where

1 1 m j j j i i l l m     p p p , 1 1 m j j j j j i i i i i l TT sm     p p p p , j i
p is the Cartesian coordinate vector of point P 0j for the ith measurement, k is the number of refer- ence points and m is the number of measurements. Here, the vector n is the last column of the matrix V of the following SVD-factorization

11 km jj ii ji TT    p p U ΣV .
Since all geometrical parameters are known, the elastostatic ones can be identified. To take into account the compensator influence while retaining the approach developed for serial robots without compensators, manipulator elastostatic parameters can be identified into two steps. The first step aims to compute the extended set of elastic parameters that includes all equivalent virtual springs for the second joint by using the standard least-square technique

1 ( ) ( ) ( ) 11 • TT mm p p p i i i i ii                 k B B B p (8)
where the vector i p is the small displacement of the end-effector under the ex- ternal loading i F , matrix () p i B is a rearranged matrix i A that integrates positional components only and takes into account structure of the vector k . The second step deals with the identification of the gravity compensator parameters and compliance of joint #2 that can be obtained from the following equation

    22 1 0 0 11 • qq i T c c i mm TT ii ii K K K K s        C C C (9)
where q m is the number of different angles 2 q in the experimental data,

        22 2 2 2 cos sin cos 1 • / • / • i i i i L q L s a L s a qq a           C (10)
In order to ensure high calibration efficiency, the design of experiments should be considered while choosing measurement configurations. To the best of our knowledge, the best results for particular industrial applications can be achieved by using the test-pose based approach (Klimchik et al. 2012b), which reduces optimal pose selection to the following optimization problem:

  1 ( ) ( ) 00 1 , } ( ) ( ) 1 trace min T q T ii m j p j p i pp j i m i          qw A A A A (10)
Here matrix () 0 p A has the same structure as matrix () p i A , but is defined by the desired test pose configuration 0 q and the external loading 0 F . The values of 0 q , 0 F are usually related to a typical machining configuration and force generated by the tool-workpiece interaction. Such an approach allows us to ensure the highest positioning accuracy after compensation compliance errors caused by the technological process.

Using theoretical results presented in this section, it is possible to obtain a sophisticated elasto-static model that can be used for further error compensation. In the next section, these results are used to obtain the stiffness model of the KUKA KR-270 robot.

Experimental results and comparison analysis

The main geometric parameters of the gravity compensator are L, a x and a y (see Figure 2). They can be identified by using relative locations of points P 0 and P 1 with respect to point P 2 . Since the adopted geometric model is a planar one, here the laser tracker base frame is defined in a particular way in order to ensure that the marker locations relative to the XY-plane are not significant. Another important issue is related to the selection of the marker point locations on the rigid part of the gravity compensator. To ensure high identification accuracy, these markers should be located on the opposite sides of the compensator rotational axis, such that the optimal conditions

1 cos 0 k j j j R     and 1 sin 0 k j j j R    
are satisfied. To increase the identification accuracy, four marker points are used in the calibration experiments and are denoted as P 01 , P 02 , P 03 and P 04 respectively. Their locations are presented in Fig. 1, where the radii

q             .
The values of the identified geometrical parameters and corresponding confidence intervals are given in Table 1. For the identification of manipulator elastostatic parameters, 15 measurement configurations (with 5 different values of q 2 ) were obtained based on the proposed industry oriented performance measure (10), for which the position coordinates of the reference points (P 1 , P 2 and P 3 ) were measured three times (before and after the loading). The corresponding experimental setup is illustrated in Fig. 3. The desired elastostatic parameters have been obtained using a two-step identification procedure. On the first step, the base and tool transformations have been computed. On the second step, all measurement data as well as the obtained base and tool transformations have been used for the identification of the manipulator elastostatic parameters. Corresponding numerical results are given in Table 2. To show the advantages of the developed approach, the manipulator accuracy after calibration has been compared for two distinct plans of calibration experiments. The first one has been obtained using the industry-oriented performance measure and implements enhanced numerical routines. In this case, the manipulator was presented as a quasi-serial chain, and the calibration data were obtained using the enhanced partial pose measurements. The second plan used measurement configurations that were selected semi-intuitively, in accordance with some kinematic performance measures [START_REF] Dumas | Joint stiffness identification of sixrevolute industrial serial robots[END_REF]. A relevant manipulator model corresponding to the strict serial architecture, and the calibration data were obtained using conventional full-pose measurements.

Using these two sets of calibration data, the identification yielded two slightly different sets of manipulator parameters (Table 2). Then, the obtained parameters (both sets) may be used to compute the end-effector positions for the validation configurations (that were not used in both identification routines). Comparing these results with the corresponding position measurements, it is possible to evaluate the "calibration quality" and relevant plans of the experiments.

For comparison purposes, the manipulator accuracy improvement due to elastostatic errors compensation has been studied based on the error analysis before and after compensation. Relevant results are shown in Table 3, where the maximum and RMS values of the distance-based residuals are provided. As follows from the obtained results, using the identified elastostatic parameters, it is possible to compensate 91.2% of the end-effector deflections (in average). In general, the manipulator positioning accuracy has been improved by a factor of 11.1 compare to a non-compensated robot. Compare to the previous results, the compensation efficiency has been increased by a factor of 2.4 using almost the same number of configurations, which is also referred to as the accuracy improvement factor. Hence, the above presented analysis shows the advantages of theoretical contributions presented in this work. The developed calibration technique allows us to increase essentially the manipulator positioning accuracy under external loading using a reasonable number of measurement configurations. It should be noted that the obtained elastostatic parameters can be used for elaso-dynamic analysis also.

Conclusion

The paper deals with the accuracy improvement of a heavy industrial robot employed in milling. It provides a sophisticated geometric/elastostatic model for quasi serial manipulator with gravity compensator and techniques for the identification of the model parameters. In order to improve the identification accuracy, design of experiments technique based on industry oriented performance measure was used. The advantages and practical significance of the proposed approach have been shown by experimental results and a comparison analysis. The improvement factor is about 2.4.

Fig. 1

 1 Fig. 1 Off-line compliance errors compensation strategy

  x and y coordinates of the vector

  measurement data have been obtained using laser-tracer Leica for the set  2 0 ,30 , 60 , 90 , 120 , 140

Fig. 3

 3 Fig. 3 Experimental setup for manipulator elastostatic calibration

Table 1 .

 1 Identification results for the compensator geometric parameters

		L [mm]	ax [mm]	ay [mm]
	Value	184.72	685.93	123.30
	CI	±0.06	±0.70	±0.69

Table 2 .

 2 Manipulator elastostatic parameters obtained using different approaches,[µrad/Nm]

		k	k	k	k	k	k
		1	2	3	4	5	6
			.297
	The results obtained in this work	0.623		0.416	2.786	3.483	2.074
			0.278
			-145°0	-95°-45°0°
	(Dumas et al. 2011)	3.798	0.248	0.276	1.975	2.286	3.457

Table 3 .

 3 The manipulator accuracy improvement after elastostatic error compensation.

	Criterion	Before compensation	After compensation (Dumas 2011) [This work]	Improvement factor (Dumas 2011) [This work]
	max [mm]	8.28	1.77	0.78	4.6	10.4
	RMS[mm] 5.90	1.27	0.53	4.6	11.1

Acknowledgements

The work presented in this paper was partially funded by the ANR (Project ANR-2010-SEGI-003-02-COROUSSO), France and FEDER ROBOTEX, France.


Anna Giannakou
email: agiannakou@lbl.gov

Louis Rilling
email: louis.rilling@irisa.fr

Christine Morin

Jean-Louis Pazat

SAIDS: A Self-Adaptable Intrusion Detection System for IaaS Clouds

published or not. The documents may come   L'archive ouverte pluridisciplinaire

I. INTRODUCTION

IaaS clouds allow customers (called tenants) to deploy their IT as virtualized infrastructures. However IaaS clouds features, such as multi-tenancy and elasticity, generate new security vulnerabilities [START_REF] Deshmukh | Understanding DDoS Attack & its Effect in Cloud Environment[END_REF] for which the security monitoring must be partly run by the cloud provider to give visibility at the virtualization infrastructure level. Unfortunately the same IaaS clouds features make the virtualized infrastructures frequently reconfigurable and thus affect the ability of a provider-run security monitoring system to detect attacks [START_REF] Shirazi | Assessing the impact of intra-cloud live migration on anomaly detection[END_REF]. This work addresses these issues for security monitoring systems based on off-the-shelf network intrusion detection systems (NIDSs) like Suricata [START_REF]Suricata Open Source IDS Engine[END_REF]. a) Objectives: A security monitoring system tailored for IaaS clouds should address the following objectives:

1) self-adapt to infrastructure changes at the topology level (VM creation, deletion, migration and virtual network reconfigurations; physical server addition and removal), the traffic level (changes in the incoming and outgoing load), the application level (set of services deployed in the VMs and their updates); 2) enable tenants to customize the security monitoring using Service Level Agreements (SLAs); 3) scale with the monitoring load; 4) keep respecting security monitoring SLAs even during reconfigurations and introduce no new vulnerabilities in the provider's infrastructure. b) Related work: Several approaches [START_REF] Roschke | Intrusion Detection in the Cloud[END_REF], [START_REF] Mazzariello | Integrating a network IDS into an open source Cloud Computing environment[END_REF], [START_REF] Ficco | Intrusion Detection in Cloud Computing[END_REF] propose Intrusion Detection Systems for cloud environments and partly satisfy Objectives 2 and 3 but not the self-adaptation objective 1. RemoteTrans [START_REF] Kourai | Secure offloading of legacy idses using remote vm introspection in semi-trusted clouds[END_REF] self-adapts only to applicationlevel infrastructure changes and does not address Objective 3. VESPA [START_REF] Wailly | VESPA: Multi-layered Selfprotection for Cloud Resources[END_REF], a self-protection monitoring architecture for IaaS clouds, addresses a different class of self adaptation based on security incidents but not Objective 1 and addresses neither multi-tenancy nor Objective 2. VMware NSX [START_REF]VMware NSX for vSphere Network Virtualization Design Guide ver 3.0[END_REF] addresses all objectives by allowing tenants to deploy a tightly-coupled NIDS (as well as other security appliances) for each VM or security group of VMs. However, similarly to [START_REF] Mazzariello | Integrating a network IDS into an open source Cloud Computing environment[END_REF], the resulting scalability is questionable because the amount of resources allocated to the NIDSs are not based on the monitoring load changes and thus should be over-provisioned.

*The work was done while the first author was working at Inria. SAIDS consists of seven components depicted in Figure 1: the API, the Adaptation Manager (AM), the Infrastructure Monitoring Probes (IMP), the Local Intrusion Detection Sensors (LIDSs), the Adaptation Worker (AW), the Master Adaptation Driver (MAD), and the Mirror Worker (MW). The API extends the provider's API to allow tenants to write high-level descriptions of their monitoring requirements. These requirements are translated to SAIDS-specific adaptation arguments. The API definition is left for future work.

The LIDSs run on dedicated nodes under control of one MAD per node. A single node can host multiple LIDSs. An LIDS is composed of an AW and an off-the-shelf NIDS. Finally, we include one Mirror Worker per compute node. To synchronize the VM lifecycle with adaptation actions, SAIDS also features an optional safety mechanism on compute nodes.

The AM makes the adaptation decisions that affect the LIDSs upon the occurrence of dynamic events in the cloud infrastructure. Adaptation decisions are based on a monitoring strategy matching the SLAs and a maintained view of which LIDSs monitor each subset of VMs.

The IMPs detect topology changes (e.g. VM migration) and relate all necessary information to the AM (VM ID, internal and external IP address, port on the local switch, etc).

The LIDSs are responsible for analyzing network traffic that flows through subsets of local switches, depending on the monitoring strategy selected. The detection technique used can either be signature-or anomaly-based.

The AW has four roles: 1) makes the NIDS load its new configuration while keeping analyzing traffic as negotiated in the SLA; 2) notifies the MAD upon completion of the adaptation process; 3) monitors the NIDS for failures and restarts it when necessary and 4) periodically reports LIDS-specific monitoring metrics (e.g. packet drop rate) to the MAD.

The MAD translates the adaptation parameters from the AM to LIDS-specific rules and reconfigures the traffic distribution on the local switch when a new LIDS is instantiated. The MAD also notifies the AM about performance degradation of existing LIDS(s). The MAD can handle multiple reconfiguration requests in parallel.

The MW guarantees that the traffic from a subset of VMs is correctly mirrored to the corresponding LIDS(s) node(s).

Finally, the safety mechanism prevents the VM that is involved in a dynamic event (e.g. a migrated VM) from resuming its execution before the adaptation process is completed. Tenants can choose to disable the safety mechanism.

Local Switch

Adaptation Worker

Ruleset

Mirror Worker

Fig. 1. SAIDS architecture III. EVALUATION We evaluated the ability of SAIDS to guarantee adequate performance and minimized cost, for both tenants and the cloud provider, combined with a sufficient level of detection. We define the tenant-associated cost as the performance overhead in cloud hosted applications and the provider-associated cost as the time overhead in normal cloud operations and the increase in resource consumption.

We evaluated SAIDS performance in two aspects: adaptation speed and scalability. Adaptation speed refers to the time required for SAIDS to perform a full adaptation loop, from the time a dynamic event occurs until all involved LIDSs are successfully reconfigured. Scalability refers to the number of adaptation loops that SAIDS can handle in parallel and the overhead induced by parallelism in the reaction time of each phase of the adaptation loop. We studied scalability at the MAD and the AM levels. For the MAD level we evaluated the maximum number of LIDSs that a MAD can handle in parallel while for the AM level we evaluated the maximum number of MADs that an AM can handle in parallel.

The cost analysis refers to associated penalties on deploying SAIDS from the provider's and tenants standpoints. On the provider's side we calculated the overhead imposed by SAIDS to normal cloud operations (e.g. VM migration) while for the tenants we examined if SAIDS imposes any overhead in their applications performance.

Results obtained show that SAIDS imposes negligible overhead on normal cloud operations and that the performance overhead for tenants is also negligible. Since SAIDS LIDSs are passive monitoring devices that work on a copy of the VM-related traffic it does not impose any network overhead in the applications deployed in the monitored VM. Moreover, the traffic between different SAIDS components is using the management network, thus no additional traffic is created in the monitored network.

In our experiments, we measured that a single MAD located in a node with 24GB of RAM can handle up to 50 LIDSs, as each LIDS requires 460.1MB of RAM. We also showed that SAIDS is scalable with about 25% overhead in managing around 100 MADs and 5000 LIDSs compared to the fastest case of managing a single MAD and 50 LIDSs with no LIDS initially running. The memory capacity of our testbed limited the number of LIDSs managed in parallel to 5000, but when deploying SAIDS in a production cloud [START_REF]OVH Dedicated Servers[END_REF], where compute nodes have larger amounts of hardware resources, the number of LIDSs could significantly increase without expecting prohibitive performance overhead.

IV. FUTURE WORK

In the future we would like SAIDS to handle other types of IDSs, like host-based IDSs or network analyzers, and address failures in the reconfiguration of an LIDS. We plan to combine the security monitoring of tenants and the provider. As a medium term goal, we plan to implement the API used for expressing tenant monitoring requirements, address multitenancy and to include security events in the categories of adaptation sources.

  c) Contribution: In this context, we designed, implemented, and evaluated SAIDS, a self-adaptable NIDS framework for IaaS clouds based on off-the-shelf NIDSs and that addresses Objectives 1 to 4. II. SAIDS SAIDS brings the following features. (1) Probes detect the need for adaptation and SAIDS components are reconfigured accordingly. (2) Tenants can define service-specific NIDS rules in the SLA. (3) New NIDS instances are automatically deployed to scale with the traffic workload. Finally, (4) topologylevel infrastructures changes are synchronized with SAIDS components reconfigurations to always monitor the network traffic seen by tenants' VMs according to the SLAs.


Andrey Sadovykh
email: a.sadovykh@innopolis.ru

Wasif Afzal
email: wasif.afzal@mdh.se

Dragos Truscan
email: dragos.truscan@abo.fi

Pierluigi Pierini
email: pierluigi.pierini@intecs.it

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

Alessandra Bagnato
email: alessandra.bagnato@softeam.fr

Abel Gómez

Jordi Cabot
email: jordi.cabot@icrea.cat

Orlando Avila-García
email: orlando.avila@atos.net

On a Tool-Supported Model-Based Approach for Building Architectures and Roadmaps: The MegaM@Rt2 Project Experience

Keywords: Model-Driven Engineering, Requirement Engineering, Architecture, Roadmap, UML, SysML, Traceability, Document Generation, Modelio

MegaM@Rt2 is a large European project dedicated to the provisioning of a model-based methodology and supporting tooling for system engineering at a wide scale. It notably targets the continuous development and runtime validation of such complex systems by developing a framework addressing a large set of engineering processes and application domains. This collaborative project involves 27 partners from 6 different countries, 9 industrial case studies as well as over 30 different software tools from project partners (and others). In the context of the MegaM@Rt2 project, we elaborated on a pragmatic model-driven approach to specify the case study requirements,

Introduction

MegaM@Rt2 is a three-years project, funded by European Components and Systems for European Leadership Joint Undertaking (ECSEL JU) under the H2020 European program, that started in April 2017 [START_REF] Ecsel | Rt2 Project Website[END_REF][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][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 main goal is to create an integrated framework incorporating methods and tools for continuous system engineering and runtime verification and validation (V&V) [START_REF] Fitzgerald | Continuous software engineering: A roadmap and agenda[END_REF][START_REF]ISO/IEC/IEEE International Standard -Systems and Software Engineering -Life cycle processes -Requirements engineering[END_REF]. The underlying objective is to develop and apply scalable model-based methods and tools in order to provide improved productivity, quality, and predictability of large and complex industrial systems [START_REF]ISO/IEC Systems and Software Engineering -Systems and software Quality Requirements and Evaluation (SQuaRE) -System and software quality models[END_REF]. As of writing this paper, the project has entered in its final year where the MegaM@Rt2 framework is being validated on industrial use cases to assess the quantified benefits. Up till now, a number of deliverables have been completed and the details of publicly available deliverables are on the project's website 1 .

One of the main challenges to overcome in MegaM@Rt2 is to cover requirements coming from diverse and heterogeneous industrial domains, rang-ing from transportation and telecommunications to logistics. Among the partners providing use cases in the project, we can cite Thales, Volvo Construction Equipment, Bombardier Transportation and Nokia (among others). These organizations have different product management and engineering practices, as well as regulations and legal constraints. This resulted in a large and complex catalog of requirements to be realized by architecture building blocks at different levels of abstraction. Thus, the development of the MegaM@Rt2 framework has been based on a feature-intensive architecture and a related implementation roadmap.

The MegaM@Rt2 framework plans to integrate more than 30 tools implementing the above mentioned methods and satisfying requirements from the case studies. The tool features are grouped in three complementary conceptual tool sets:

1. MegaM@Rt2 Systems Engineering Tool Set regroups a variety of current engineering tools featuring AADL, EAST-ADL, Matlab/Simulink, AUTOSAR, Method B or Modelica, SysML and UML in order to precisely specify both functional and non-functional properties. Moreover, system level V&V and testing practices will also be supported by this tool set. 2. MegaM@Rt2 Runtime Analysis Tool Set seeks to extensively exploit system data obtained at runtime. Different methods for model-based V&V and model-based testing (MBT) will be rethought and/or extended for runtime analysis. Model-based monitoring will allow to observe executions of a system (in its environment) and to compare it against the executions of corresponding model(s). Monitoring will also allow a particular system to be observed under controlled conditions, in order to better understand its performance. 3. MegaM@Rt2 Model & Traceability Management Tool Set is a key part of the framework as it is dedicated to support traceability and integration between models across all layers of the system design and execution (runtime). This can go from highly specialized engineering practices to low-level monitoring. Relying on the unification power of models, it should provide efficient means for describing, handling and keeping traceability/mappings between large-scale heterogeneous software and system artifacts.

Model-based approaches for specification have been developed consistently during almost two decades [START_REF] Di Ruscio | Guest editorial to the special issue on success stories in model driven engineering[END_REF], and automated document generation was one of the first benefits offered by the Model-driven Architecture (MDA) [START_REF]OMG: Model Driven Architecture (MDA) Guide rev. 2.0[END_REF]. Indeed, models as the first-class entities of the engineering process should contain all the necessary information for the design documentation. However, several challenges arise. Firstly, the architect team should decide the right organization for the global architecture model(s). Secondly, it should be carefully planned which level of details is appropriate for the design of the individual contributions. Thirdly, it should be considered that the architecture model(s) will be used during all the duration of the project for numerous purposes. Thus they need to be prepared to accommodate for changes in methodology. Fourthly, several documents need to be generated by extracting the relevant information from all over the architecture model(s). This article is an extension of our previous paper that introduced the tool supported, model-driven architecture of the MegaM@Rt2 framework [START_REF] Sadovykh | A Tool-supported Approach for Building the Architecture and Roadmap in MegaM@Rt2 Project[END_REF]. In the present article, we go in further detail to elaborate on MegaM@Rt2 architecture. In particular, we describe both the roadmap for the development of architecture components throughout the project and the modeldriven oriented individual components for the three MegaM@Rt2 tool sets: MegaM@Rt2 Systems Engineering Tool Set, MegaM@Rt2 Runtime Analysis Tool Set and MegaM@Rt2 Model & Traceability Management Tool Set. We also provide details on the functional interfaces as well as the details on the subordinate components.

The rest of the paper is structured as follows. Section 3 presents the model-driven approach we propose for architecture specification. Section 4 describes the tooling we developed in order to support this proposed approach. Section 5 explains the obtained results when applying our modeldriven approach to build the MegaM@Rt2 framework architecture. Section 6 presents the gap analysis between the framework requirements derived from industrial needs and the tool purposes provided by different tool providers as well as the roadmap. Section 7 ends the paper with discussions on the practical lessons we have learned from all this work so far.

State-of-the-Art

Model-based design (MBD) has proven to be a powerful engineering method for developing highly complex and critical embedded systems [START_REF] Ali | An industrial application of robustness testing using aspect-oriented modeling, uml/marte, and search algorithms[END_REF]. Using models, designers are able to capture the properties of the system. They can also analyse its behaviour to detect errors and subsequently revise the design in a very cost-effective manner [START_REF] Selic | The pragmatics of model-driven development[END_REF]. Examples of systems devel-oped using MBD include aerospace, medical, railway and automotive systems. Nevertheless, in most cases, software code in cyber-physical systems is written directly using low-level programming languages, and without following a model-driven development process. This makes the design and runtime traceability more difficult. Thus, these various development processes and practices need to be revisited and integrated accordingly, following such a model-based methodology.

Several modelling methods for embedded systems based on UML/MARTE have been proposed. The Co-Fluent methodology [START_REF] Robert | COFLUENT Methodology for UML: UML SysML MARTE Flow for CoFluent Studio[END_REF] captures application and hardware architecture by means of composite diagrams and SysML blocks. UML activity diagrams are used to specify application execution flows. The MARTE HRM profile is used for capturing the hardware platform.

MoPCoM [START_REF] Koudri | Mopcom methodology: Focus on models of computation[END_REF] is a design methodology for the design of real-time embedded systems which supports UML and the MARTE profile for system modelling. Specifically, MoPCoM uses the NFP MARTE profile for the description of real-time properties, the HRM MARTE profile for platform description, and the Alloc MARTE profile for architectural mapping [START_REF] Vidal | A co-design approach for embedded system modeling and code generation with uml and marte[END_REF].

In [START_REF] Liehr | Generation of MARTE Allocation Models fromActivity Threads[END_REF], a UML/MARTE-based methodology relying on activity threads is proposed in order to reduce the effort required to capture the set of architectural mappings. An activity thread is a UML activity diagram where each path reflects a design alternative, that is, an architectural mapping. However, the main disadvantage of using UML is that, as a consequence of being a general-purpose language and being initially tacked to an object-oriented paradigm, it introduces what is called accidental complexity: models become large, complex, and far from the domain.

The Aspect Oriented Software Development (AOSD) explores the idea of Separation of Concerns (SoC) to identify concerns in software development and encapsulate them in appropriate modules. This approach has been promoted from the implementation phase, at code level, to other prior phases in the software engineering life-cycle, at the model level: Aspect-Oriented modelling (AOM). AOM combines the ideas behind AOSD with those of model-based software development, where the main focus is placed on how different concerns of the system can be modelled independently and combined later on via composition mechanisms (e.g., model transformations). The benefits of using AOM in industrial context as an enabler for scalable modelling, reducing modelling complexity and facilitating model evolution have been noted in [START_REF] Ali | An industrial application of robustness testing using aspect-oriented modeling, uml/marte, and search algorithms[END_REF]. In addition, controlled experiments have shown that using aspect-oriented modelling techniques creates better quality models [START_REF] Ali | Assessing quality and effort of applying aspect state machines for robustness testing: A controlled experiment[END_REF] and significantly improves the readability of specifications [START_REF] Ali | Does aspect-oriented modeling help improve the readability of uml state machines?[END_REF].

There is a diversity of mature AOM approaches proposed in the literature, which roughly could be classified into i) asymmetric, which support the distinction between cross-cutting and non-crosscutting concerns, ii) symmetric, which do not. Due to this diversity of approaches, a conceptual reference model (CRM) it is proposed [START_REF] Wimmer | A survey on uml-based aspect-oriented design modeling[END_REF] that provides a common understanding for the basic ingredients of AOM concepts, aiming at supporting the comparison of the different approaches. Different AOSD frameworks have been released in last decade, and some of them have got distinct popularity (i.e. AspectJ). Examples of how to use AOSD to inject support for cross-cutting concerns, including logging are available in the literature [START_REF] Chiba | Aspect-oriented programming beyond dependency injection[END_REF].

Model driven engineering (MDE) aims at promoting models as the main artefacts for software development, including at runtime. Having models present at runtime is made with several objectives and techniques [START_REF] Szvetits | Systematic literature review of the objectives, techniques, kinds, and architectures of models at runtime[END_REF] [START_REF] Blair | Models@ run.time[END_REF]. Model execution consists in defining a model that is interpreted with a dedicated engine implementing an execution semantics [START_REF] Cariou | Characterization of adaptable interpreted-dsml[END_REF]. With model execution, the ability to run a model prior to its implementation is a timesaving and henceforth cost-saving approach, making possible detecting and fixing problems at design time by simulating the model and directly reusing the model at runtime through its execution. Another way to handle models at runtime is to have models reflecting the system contents and being causally connected with it. Such models (named models@runtime) can be used for managing the system adaptation (QoS aspects, environment changes, etc.). As shown in [START_REF] Filieri | Run-time efficient probabilistic model checking[END_REF] the increasing maturity and success of models@runtime techniques tends to blur the traditional distinction between design and runtime, creating a long continuum that includes design, runtime, maintenance and evolution. Through the application of runtime/real-time analysis (incl. machine learning and data analytics) an increase in both the precision and speed of pinpointing vital information can be expected. Reflecting models can also be used in the fault localisation or verification purposes. Models can help in monitoring and storing the current state of the system by defining, for instance, an execution trace. This trace can be analysed either at runtime, in parallel with the system execution, or afterwards. Runtime Validation consists of validating a design at runtime through additional monitoring mechanisms and some kinds of recovery procedures. In general, this does not require understanding the cause of the bug, but only the symptom and the remedy [START_REF] Bayazit | Complementary use of runtime validation and model checking[END_REF].

Architecture Specification Approach

We adopted a practical approach for the architecture specification that is particularly adapted to collaborative projects such as MegaM@Rt2, integrating tools coming from several parties [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][START_REF] Bruneliere | The MegaM@Rt2 Approach and Tool Set[END_REF]. As modeling language, we took a Systems Modeling Language (SysML) [START_REF] Omg | OMG Systems Modeling Language (OMG SysML)[END_REF] subset for requirements specification and a Unified Modeling Language (UML) [START_REF]OMG: Unified Modeling Language (UML), Ver. 2.5[END_REF] subset for the high-level architecture specification. The approach to define the MegaM@Rt2 framework architecture is depicted in Figure 1. We split the architecture model in several parts, dividing the responsibilities among: the Work Package (WP) leaders, the tool providers and the case study providers.

At the Requirements/Purposes level, the needs of industrial partners have been collected and classified by means of Case Study Requirements, from which we specified (Activity 1) the MegaM@Rt2 Framework Requirements. For the latter, we identify (Activity 2) a set of Tool Component Purposes that will realize the case study requirements. At the architecture level, each Conceptual Tool Set Component and the relevant interfaces are identified (Activity 3) to satisfy framework requirements. Then, for the Conceptual Tool Set we specify (Activity 4) concrete Tool Set Components to realize the desired functionality. Those Tool Set Components expose features (i.e. purposes) that are progressively available, during the project time frame, based on specific development plan. The roadmap is defined as the set of tools components purposes available at each project milestone.

In addition, to support the integration of each Tool Set Component into the MegaM@Rt2 Framework, the following additional elements have been identified:

• Common Interfaces, specified by tool providers, to support data and model exchange between tools

• Common Deployment Frameworks, specified by tool providers, to highlight possible issues related to hardware and software platforms

Tooling Approach

Appropriate tooling support is important for the success of the modeldriven engineering process shown in Figure 1. In order to provide tool support for our architecture specification approach, we selected the Modelio and Constellation tools [START_REF] Desfray | Model repositories at the enterprises and systems scale the modelio constellation solution[END_REF] provided by one of the project participants, namely SOFTEAM.

As mentioned in the introduction, there are different types of stakeholders collaborating in this approach: case study providers, tool providers, work package leaders, project managers, etc. In total, it resulted in around 50 users editing and reading the model. When collecting inputs from so many stakeholders, it was important to provide guidelines and diagram templates. Otherwise, the integration work would have become extremely challenging. As such, we defined a set of template diagrams both for specifying requirements and for collecting tool purposes. Users were able to clone these templates inside the model to describe their concrete tools.

In the next subsections we are providing more details on how different features of the tool were used to support our approach.

Architecture Specification

Modelio is an MDE workbench supporting standard modeling languages such as UML and SysML, among others. All the modeling notations can be stored in the same global model repository which is important, not only for collaborative modeling, but also for model traceability and management.

Requirements Modeling

In our approach, requirements originated from 9 case study providers and 22 tool providers. In order to have an uniform approach for requirement specification that would later on facilitate gap analysis and roadmap identification, we defined requirement templates that were used to define the expected requirements properties to be collected, such as criticality for the case study requirements and planned release date for tool purposes.

Modelio allowed us to edit requirements in both a diagram view and a tabular view (see Figure 2). The requirements were manually edited or automatically imported from other documents, e.g. MS Excel.

Architecture Modeling

At the architecture level, we used Class and Deployment diagrams. We limited modeling to a subset of UML to enforce the common understanding of the architecture and to simplify editing. In particular, we chose to use UML Components, Interfaces, Associations, Generalizations and Dependencies.

For collecting information about tool components, we defined a template for the architecture specification that included: a class diagram -to specify functional interfaces, tool components subordinates2 and the relation to the conceptual tool set in the framework, and deployment diagrams -to iden- tify the execution environment of the tool component. In addition, Package diagrams were used to define the high-level structure of the MegaM@Rt2 framework architecture.

For instance, Figure 3 shows that the MegaM@Rt2 framework architecture is composed of three parts corresponding to the three WPs of the project: System Engineering, Runtime Analysis, and Model and Traceability Management, respectively.

In Modelio, the documentation can be added in the textual notes (as shown in the lower part of Figure 3) or as separate documents. Both plain text and rich text notes are supported. In our work, we deliberately restricted editing to plain text notes to make sure that the generated documents are formatted correctly.

Requirements Traceability

Once the requirements have been specified, for each tool component we defined a traceability matrix to map case study requirements to framework requirements, and respectively framework requirements to tool purposes as described by Activities 1 and 2 of the modeling approach in Figure 1. This allowed us to use traceability diagrams, as the one in Figure 4, to visualise the whole set of dependencies for a given requirement. This approach proved beneficial not only for the requirement analysis and tool set integration planning, but also for identifying common interfaces for tool components and visualising gaps for the requirements analysis.

Generating Documents

Modelio offers model query and document generation facilities that were used for editing and maintaining specifications in the project. The template editor (Figure 5) was particularly useful to implement custom extraction of model elements in order to create specific sections of the document.

In the example below, the template specifies that the generator will search for a Tool Components package, from which it will extract UML components in order to generate the tool section of the document. This document section will include introductory paragraph, Purpose subsection, subsections for all class and deployment diagrams as well as section on the owned interfaces.

When editing the architecture model, it is quite useful to see the generation result. Thus, along with developing custom document templates, we integrated the document generation to the Modelio interface. That way regular users could call the document generation directly from the tool using a context menu (Figure 6).

Collaborative Model Editing

Modelio Constellation [START_REF] Desfray | Model repositories at the enterprises and systems scale the modelio constellation solution[END_REF] is the model sharing, collaborative editing, versioning and configuration management facility that allow modellers to work together on the same common and shared model. Indeed, authoring the architecture deliverables in MegaM@Rt2 project required the contributions of 27 partners. Thus, around 50 users worked together on a single model. On a regular basis, users connected to the Constellation server, synchronized the local model with the central repository, edited the architecture and generated the documents with always updated templates. The version control was enabled by Apache Subversion 3 . The documentation templates and user interfaces for document generation were developed continuously and had to be rolled out to the whole large team of modellers without interrupting the work process. It was important to provide versioning and conflict resolution when editing touched the common artifacts. Last but not least, several different deliverable were generated out of the same model. Therefore, the branching facility allowed to fix the state when the deliverable were released.

The MegaM@Rt2 Framework

In this section, we describe the MegaM@Rt2 Framework and its constituent parts. This framework is a result of the architecture specification approach described in Section 3. This description follows a common pattern:

• We describe the high-level purpose of each component including possible roadmap for feature implementation;

• We outline the functional interfaces that help to figure out the main features and possible means for integration;

• We shortly detail the subordinates the constituent parts of each component; • For the individual tools, we clarify their relation to the MegaM@Framework conceptual tools.

All in all we intend to provide traceability linking use case requirements to conceptual tools of the framework to individual tools by partners.

The MegaM@Rt2 Framework is the main technical result of the MegaM@Rt2 project. The Framework regroups several interconnected tool sets including tool sets for Holistic System Engineering, Model and Traceability Management as well as for Runtime Analysis. Those tool sets are highly interconnected to achieve the goal of linking system models with the runtime analysis of large scale industrial systems. Figure 7 presents an architectural overview of the MegaM@Rt2 framework.

MegaM@Rt2 Systems Engineering Tool Set

Model-based design (MBD) has proven to be a powerful engineering method for developing highly complex and critical embedded systems. In most cases, software code in cyber-physical systems (CPSs) is written directly using low-level programming languages, and without following a model-driven development process. This makes the design and runtime traceability more difficult. Thus, these various development processes and practices need to be revisited and integrated accordingly, following such a model-based methodology. MegaM@Rt2 Systems Engineering approach integrates a variety of current engineering practices like AADL, EAST-ADL, but also Matlab/Simulink, AUTOSAR and Method B or Modelica as required by the project's industrial case studies. Artefacts (requirements specifications, design models, software components) produced by each of these heterogeneous practices will be represented and combined in a global system model providing a complete and holistic view of the CPS. Notably, the system model will include a precise specification of the desired functional and non-functional properties on the system level.

Purpose of System Engineering Tool Set Component

The System Engineering Tool Set must integrate, formalize and coordinate both general purpose and domain-specific existing languages, methodologies and tools to support modelling, analysis and validation of complex heterogeneous systems.

Functional Interfaces

Following Figure 8 presents the functional interfaces (used & realized) of the System Engineering Tool Set.

Subordinates

Figure 9 shows the constituent parts of the MegaM@Rt2 System Engineering Tool Set.

The details of the subordinate components of the MegaM@Rt2 System Engineering Tool Set is as following:

• Metamodel and Support: This tool component provide functionality for working with standard and domain-specific metamodels. In addition, it provides the support services such as document generation. • Requirement Modelling: Requirements modelling is an important part of the engineering process. This component provide tools for specifying, eliciting and tracing the requirements.

• System Architecture Modelling: MegaM@Rt2 targets bringing the runtime trace information to the system architecture level. This component deals with the system level of the engineering process.

• Detailed Design Modelling: This component provides capability to specify the detailed design models, which may include specific models for software and hardware.

• Model Verification & Validation: This component provides a set of capabilities for design-time verification and validation.

Interfaces Specific to System Engineering Tool Set Component

The interfaces that are specific to System Engineering Tool Set Component are described below:

• IF-MODEL-EDIT-GUI: A Graphical User Interface (GUI) that supports the user in all the modelling activities, • IF-SYSTEM-MODEL: Interface to provide model artifacts for management and traceability purposes and exchange runtime analysis results and feedback,

• IF-SYSTEM-LEVEL-VERIFICATION&VALIDATION: Interface to provide verification and validation technique and results for management and traceability purposes and exchange runtime analysis results and feedback,

• IF-DOC: Document generation facility is dedicated to derivation of various documentation from the models,

• IF-XMI: XML Metadata Interchange, Version 2.5.

MegaM@Rt2 Runtime Analysis Tool Set

Model-based design approaches aim to obtain a running application thanks to productive models defined at design time. In the MegaM@Rt2 project, we apply such an approach by using and combining automated code generation, model execution, runtime verification, trace analysis [START_REF] Flemström | From natural language requirements to passive test cases using guarded assertions[END_REF] and online model-based testing. To achieve these goals, we propose to use executable models, which are related to aspect-oriented modelling (AOM) for models at runtime. Such models specify the behavior of an application and are either interpreted or compiled. The interpreted approach consists in implementing an execution engine that takes as input a model and interprets its contents. The running system is then the couple formed by the execution engine and the model it interprets. The compiled view consists in generating another model or code for a dedicated execution platform. Executable versions of the system will be obtained at runtime either by automatically generating the code from runtime models or employing models which can be executed at runtime, either standalone or part of a system implementation. Therefore, we will develop specific code generators and model interpreters enabling to manage large-scale models at runtime, as well as model execution tools to perform monitoring and tracing for analysis, online verification and model-based testing. In this context, traditional methods for analysis, online verification and model-based testing need also to be rethought and/or extended in order to fully tackle the specifics of runtime models and contained information. Verification and testing methods need to target large models that take into account traceability information and modularization (e.g., using AOM).

Purpose of Runtime Analysis Tool Set Component

The Runtime Analysis Tool Set Component realizes the following purposes:

• To use AOM techniques to facilitate code generation, runtime verification and validation.

• To support runtime analysis methods combining model-based development, validation and verification techniques.

• To use AOM techniques to facilitate code generation, runtime verification and validation.

• To support runtime analysis methods combining model-based development, validation and verification techniques.

• To be able to manage complex and large-scale models.

• To take advantage of the relationships between a set of runtime models.

• To offer partial verification and validation methods, able to give an answer under strong time constraints but with only a certain confidence level.

• To provide requirement traceability facilities at runtime. • To improve trace analysis results and localization of faults because of trace monitoring and online testing at runtime.

• To verify functional as well as non-functional properties in a synergic way by combining trace monitoring and online testing at runtime.

• To enable the trace analysis tools to collect and analyse information from different sources and using different techniques.

Functional Interfaces

Following Figure 10 presents the functional interfaces (used & realized) of the Runtime Analysis Tool Set.

Subordinates

Figure 11 shows the constituent parts of the MegaM@Rt2 Runtime Analysis Tool Set.

The details of the subordinate components of the MegaM@Rt2 Runtime Analysis Tool Set are as following: • Traces analysis tool set: Tool for reasoning on system properties based on traces analysis.

• Traces collection tool: Tool for capturing and collecting traces in a unified format for further analysis.

• Runtime verification and online testing tools: Algorithms and tools for verification of runtime models as well as model-based test generation and execution in a continuous and simultaneous manner.

Verification and testing/monitoring methods targeted at large models, and which take into account traceability information and modularization e.g, using AOM will be developed.

• Monitoring and logs analysis tool set: Tools for monitoring system, network events and execution traces to synthesize related runtime models [START_REF] Brahneborg | A black-box approach to latency and throughput analysis[END_REF]. AIPHS supports the monitoring action on target by distributing sniffer elements into target architecture. It stores logs on internal buffers to be read at the end of the application execution. In the near future, logs will be stored automatically in memory thanks to a Direct Memory Access (DMA).

• Probes injection tool: Tool for probes injection to runtime artifacts based on the properties defined on the system level.

• Code generation facilities help to translate the various models into the code for specific targets such as Java, C++, C programming languages.

Interfaces Specific to Runtime Analysis Tool Set Component

The interfaces that are specific to Runtime Analysis Tool Set Component are described below:

• IF-EXECUTABLE-ENVIRONMENT: The Runtime and Analysis Tool

Set has an interface with the executable environment in order to capture the traces of execution.

• IF-RUNTIME-MODEL: Interface to manage and configure model execution at runtime.

• IF-TRACE-GENERATION: Interface to manage and parameterize the generation of execution traces during runtime execution.

• IF-TRACE-COLLECTION: Interface to collect execution traces and to arrange/filter the related information into a given format.

• IF-TRACE-ANALYSIS: Interface to manage and execute runtime analysis of collected execution traces.

• IF-PROBES-INJECTION: Interface to inject monitoring capabilities during execution at runtime.

• IF-RUNTIME-VERIFICATION: Interface to define properties to be checked and to configure their verification at runtime.

• IF-ONLINE-TESTING: Interface to configure and perform online testing.

• IF-MONITORING&LOG-ANALYSIS: Interface to configure monitoring directives and log analysis rules to be applied during model or system execution.

MegaM@Rt2 Model & Traceability Management Tool Set

A key ingredient of MegaM@Rt2 is its dedicated support for traceability across all layers of the system design and execution, from highly specialized engineering practices to low-level log entries. This is what enables continuous integration practices at the Systems Engineering level. To make this possible, MegaM@Rt2 combines, in a highly scalable infrastructure, metamodeling and trace impact inference techniques.

Relying on the unification power of models and model-based techniques, megamodelling (also called Global Model Management or modeling in the large) provides efficient means of describing, handling and managing the many different heterogeneous artifacts (models, metamodels, transformations, generators, logs etc.) implied by the large-scale industrial scenarios in MegaM@Rt, including the different kinds of relationships between them (refinement, extension, equality, combination, etc.). A megamodel is a model but a very special kind of a model, one whose model elements are models themselves. Therefore, a megamodel is way to register and manage all engineering resources available in a given project via model-based techniques.

Megamodelling will be used in MegaM@Rt2 in order to deal as efficiently as possible with the many involved (modelling) artifacts, workflows or configurations required at both design time and runtime. It will also be used to preserve the relevant traceability information between these two levels, notably in order to allow providing proper reusable feedback from runtime to design time. Thus, we will develop a methodological loop between models at design time and runtime levels. Relying on this same general approach as well as on common generic interfaces and language, we expect to develop several solutions covering different technical environments used by partners in the project. This includes a fully open source Eclipse/EMF-based solution, and a Modelio based-one.

Purpose of Model & Traceability Management Tool Set Component

The Model & Traceability Management (MTM) Tool Set Component realizes the following purposes:

• To provide base model management capabilities.

• To provide model indexing/referencing capabilities for large sets of models.

• To provide model storage capabilities for large scale (sets of) models.

• To provide model querying capabilities for large scale (sets of) models.

• To provide model cartography/view capabilities over large sets of interrelated models.

• To provide model cartography/view capabilities over large sets of interrelated models.

• To provide model versioning capabilities over large sets of interrelated models.

• To provide model access-control capabilities over large sets of interrelated models.

• To provide model import/export capabilities from/to WP2-WP3 & other modeling solutions.

• To provide integration with source code repositories & continuous development solutions.

• To provide traceability capabilities between design/system models and runtime models.

• To provide inter-model trace storage capabilities for large scale (sets of) models.

• To provide inter-model trace querying capabilities for large scale (sets of) models.

• To provide inference capabilities from runtime models to design/system models.

• To provide automated inference computation capabilities (from runtime to design models).

• To provide inference information analysis capabilities (from runtime to design models).

Functional Interfaces

Following Figure 12 presents the functional interfaces (used & realized) of the Model & Traceability Management Tool Set.

Subordinates

Figure 13 shows the constituent parts of the MegaM@Rt2 Model & Traceability Management Tool Set.

The details of the subordinate components of the MegaM@Rt2 Model & Traceability Management Tool Set are as following:

• Base Model Management Infrastructure: Scalable infrastructure for performing base operations and manipulations on models of different kinds.

• Advanced Model Management Infrastructure: More advanced infrastructure for dealing with complex model management activities: views, access-control, etc.

• Model Integration Infrastructure: Integration infrastructure for allowing model interchanges with other environments (notably model-based ones).

• Model Traceability Infrastructure: Infrastructure for dealing with intermodel traceability and feedback from the available traceability information.

Interfaces Specific to Model & Traceability Management Tool Set Component

The interfaces that are specific to Model & Traceability Management Tool Set Component are described below: • IF-MODEL-CARTOGRAPHY: Advanced cartography capabilities for efficiently obtaining relevant views on models, either design/system ones or runtime ones, which are parts of large sets of interrelated models.

• IF-MODEL-REFERENCING: Advanced referencing capabilities for efficiently indexing different models, either design/system ones or runtime ones, which are parts of large sets of interrelated models.

• IF-MODEL-ACCESS-CONTROL: Advanced access-control capabilities for efficiently providing restricted views over different models, either design/system ones or runtime ones, which are parts of large sets of interrelated models.

• IF-MODEL-QUERY: Advanced querying capabilities for efficiently retrieving different models, either design/system ones or runtime ones, which are parts of large sets of interrelated models.

• IF-MODEL-STORAGE: Advanced storing capabilities for efficiently saving different models, either design/system ones or runtime ones, which are parts of large sets of interrelated models.

• IF-MODEL-VERSIONING: Advanced versioning capabilities for efficiently managing over time different models, either design/system ones or runtime ones, which are parts of large sets of interrelated models.

• IF-INFERENCE-ANALYSIS: (Semi-)automated mechanisms to efficiently use at the system/design model-level the previously computed inference information (from the runtime models).

• IF-INFERENCE-COMPUTATION: Automated mechanisms to calculate relevant inference information from the runtime models (e.g. representing execution traces) to be then further used at the system/design model-level.

• IF-TRACE-STORAGE: Advanced storing capabilities for efficiently saving traceability links between different models within large sets of interrelated models.

• IF-TRACE-QUERY: Advanced querying capabilities for retrieving already existing traceability links between different models within large sets of interrelated models.

Gap Analysis and Roadmap

Gap Analysis

As mentioned in the introduction of this article, another goal of our approach was to perform a gap analysis between the framework requirements derived from industrial needs and the tool purposes provided by different tool providers. During this process we identified two different types of gaps: unsatisfied framework requirements and unused tool component purposes. The unsatisfied framework requirements are framework requirements that are not satisfied by any tool component purpose. These requirements were addressed either by the tool providers in the project by creating additional development plans and corresponding tool purposes, or they were deferred to be satisfied by tools external to the project. The unused tool component purposes are those tool features that are available from the tools provided by tool providers participating in the project, but which are not explicitly requested by any case study provider. Creating such a list of unused tool purposes allowed tool providers to increase awareness about their tools among project participants, and in some cases resulted in case study providers in defining additional case study requirements.

Having all information centralized in one single model, different stakeholders involved in defining the MegaM@rt2 architecture were able to easily query and visualize the case study requirements, framework requirements and tool component purposes, and to incrementally update the mapping among them.

The gap analysis was done per work package. In total, we have elicited 106 case study requirements from 9 case study providers, and based on them we extracted 91 megaM@Rt framework requirements, as follows: 37 for WP2 -System Engineering , 39 for WP3 -Runtime Analysis, and 15 for WP4 -Model & Traceability Management. These were analyzed and linked against 28 tools which provided 223 tool purposes. During the gap analysis, we identified 2 case study requirements not satisfied by any tool purpose (one in WP2 and one in WP3) and 10 unused tool purposes (all in WP3).

Roadmap -Planning and Tracking

As discussed in Section 5, when we collected tool purpose specifications from the tool providers in MegaM@Rt2, we also collected information regarding at which project milestone the tool feature corresponding to a tool purpose will be available. In MegaM@rt2, we have had four different release milestones: baseline -M0 (beginning of the project), initial -M15, intermediate -M20, and final -M32. An excerpt from the generated roadmap for different framework requirements is shown in the Table 1.

By analyzing the release date of the tool purposes, we could also provide a general view of when different framework requirements will be completely satisfied in the project. In Figure 2 given in Section 4, one can observe that for instance framework requirement SYS-010100 is satisfied already at the beginning of the project (shown as 'Baseline'), whereas framework requirement SYS-000001 will be satisfied only at the final milestone of the project (shown as 'Final').

Having such a holistic approach to traceability and development plans for tool components allowed not only for individual project participants to plan their activity in the project in detail, but it also facilitated the project level management activities. In addition, defining the initial plan for the development of the MegaM@Rt2 framework allowed us to easily monitor the evolution of the project and check for deviations for the plan at different reporting periods. For instance, WP leaders could see what set of features are planned for the framework components at which release for tracking.

The information provided by tool providers was regularly revisited and updated when needed to reflect the latest status of development. They indicated whether a feature development is planned, done, postponed or cancelled. The roadmap and traceability documentation enabled the WP leaders and case study providers to assess the progress of the entire framework and plan the case study execution accordingly. Table 2 provides an example of a status report where the MODELIO-060 tool purpose, that was supposed to be available at in the intermediate release, is delayed. In addition, it shows which are the case study requirements affected by this release.

Discussion and Conclusion

In this paper, we presented the generic approach we used in order to identify and specify the architecture of the MegaM@Rt2 framework using modeldriven principles and practices. Our approach, supported by corresponding tooling dedicated to its application in actual projects, enforced coordination and collaboration among many different stakeholders. This way, it also contributes to improve the manageability of complex projects. Indeed, the main benefit of our model-driven approach is that all information is collected from different stakeholders and stored using one single common model (and using a single tool in our case). In our particular MegaM@Rt2 context, we further elaborated on the proposed framework and its various components centered around three different complementary tool sets.

The produced general architecture model was used as a common and shared reference (stored in a central repository), that every project partner can access and update using model versioning techniques. In addition, having all the required information in one single location allowed us 1) to constantly monitor the status of the process and to trace the requirements of the framework components, 2) to easily generate the necessary artifacts (such as documents, tables, diagrams) from the model whenever needed. Although the architectural modeling of the MegaM@Rt2 framework is realized using a subset of UML/SysML (for a better common understanding and to simplify editing, as mentioned in Section 4.1.2), the MegaM@Rt2 approach and tool sets themselves are by no way limited to any subset of UML or even to any particular metamodel or domain specification language (DSL). Indeed, many tools from these tool sets can potentially handle any model of any type when required in the context of a particular use case or scenario (cf. the different MegaM@Rt2 use cases and corresponding types of models for example).

It is important to notice that MegaM@Rt2 framework is meant to be generic in the way both functional and non-functional requirements (such as safety and security, for instance) can be expressed. The modeling languages that are part of MegaM@Rt2 framework (e.g., MARTE and SysML) are well-suited for modeling a variety of requirements at different levels (e.g. from component to system level), as shown by existing studies [START_REF] Tsadimas | Extending sysml to explore non-functional requirements: The case of information system design[END_REF][START_REF] Sena Marques | Integrating UML, MARTE and sysml to improve requirements specification and traceability in the embedded domain[END_REF][START_REF] Jamro | Sysml modeling of functional andnon-functional requirements foriec61131-3 control systems[END_REF]. Some industrial use cases from the project have specific non-functional requirements to meet, for example explicit safety requirements of the train control management system for Bombardier Transportation, Sweden. These requirements can be met by the MegaM@Rt2 framework that provide such support, e.g., Modelio [START_REF] Bagnato | Fostering analysis from industrial embedded systems modeling[END_REF] or EMF Views [START_REF] Bruneliere | Towards scalable model views on heterogeneous model resources[END_REF] allow creating viewpoints with specific metamodels using MARTE sub-profiles (for example).

The MegaM@Rt2 framework is also designed to be extensible and open, in order to provide connectivity with other existing tools and technologies. The interfaces of the three complementary tool sets (cf. Sections 5.1.4, 5.2.4 and 5.3.4) have been specified to enable extensions with other tools and components implementing these interfaces. Thus, it is possible to integrate, import and then use external tools whenever necessary as part of a process following the MegaM@Rt2 approach. Moreover, in order to integrate non-compatible models, there is always the option to design and implement model transformations from/to model formats supported in MegaM@Rt2. Note that we are also currently working to standardize the framework interfaces as much as possible to facilitate extensibility. For example, Common Trace Format (CTF)4 is being investigated as a possible solution for sharing runtime data in an uniform way and to better connect related tools altogether.

Using a model-based architectural approach, such as in the MegaM@Rt2 project, also comes with open challenges and current limitations. We discuss them in what follows.

The first of such challenges was that different project participants had different levels of familiarity with modeling tools in general (and with Modelio and Constellation in particular, as used in our MegaM@Rt2 context). This issue has been addressed by providing several project-wide online webinars along with proper documentation on describing how the tools can be used to support the architecture specification approach. The tooling support team was helpful in solving the licensing issues, helping with installation and resolving model versioning conflicts. This contributed to facilitate the deployment and adoption of the proposed approach and corresponding tooling.

A second challenge came from the fact that 50 modellers worked collaboratively with the models. This could potentially trigger many inconsistencies, conflicts and omissions in the collected information. We were able to support model versioning and collaborative modeling thanks to the features provided by the selected repository solution (Constellation). In addition, we decided to split the model in several parts (one corresponding to each work package) and we provided clear guidelines on how the it is/has to be organized. In this way, we have been able to ensure that our central architectural model stays consistent and correctly maintainable over time.

A third challenge came from the limitations of the selected tools. For instance, there were different restrictions on how the styling of the documents generated from the models could be configured and how the information could be visualized using different types of diagrams. Moreover, manual effort is also required in order to create the initial document templates and to configure the document generators accordingly. However, once all this generation infrastructure was created, it could be easily reused whenever relevant. It allowed to (re)produce the targeted documentation in an efficient (semi-automated) way, and as many times as needed.

In addition to the challenges and limitations discussed before, some industrial partners were already using an existing company/internal tool chain that is not supposed to be part of our project tool sets. In this case, they still provided their requirements which were then mapped (currently manually) in order to fit with the MegaM@Rt2 tool set capabilities. However, in such cases, the industrial partners had to perform an additional validation step: they had to consider the acceptance of their requirements using both the MegaM@Rt2 tool set capabilities as well as the capabilities of their in-house solution. Despite of this, and from a more general project consortium perspective, the benefits of using the common shared approach and tooling we proposed are still interesting.

Overall, the feedback collected from the different partners (industrial and academic ones) in the MegaM@Rt2 project showed that the application we made of our approach was mostly positive in terms of both productivity and user experience. Moreover, we already plan to capitalize on this effort. Thus, the corresponding tooling support that has been developed and deployed will be further reused in the context of other architecture documents later in the project, and possibly in the context of other large collaborative projects in the future.

Figure 1 :

 1 Figure 1: Overview of the Architecture and Development Process in MegaM@Rt2.

Figure 2 :

 2 Figure 2: Requirements Editing with Modelio.

Figure 3 :

 3 Figure 3: Editing Architecture and Documentation with Modelio.

Figure 4 :

 4 Figure 4: Example: Traceability Links Among the Tool Set, Framework and Case Study Requirements.

Figure 5 :

 5 Figure 5: Example: Custom Document Generation Template for Individual Tools Section.

Figure 6 :

 6 Figure 6: Example: Architecture Document Generated with Modelio Document Publisher.

Figure 7 :

 7 Figure 7: MegaM@Rt2 Architecture Overview.

Figure 8 :

 8 Figure 8: Functional Interfaces (Used & Realized) of the MegaM@Rt2 System Engineering Tool Set.

Figure 9 :

 9 Figure 9: Constituent Parts (Subordinates) of the MegaM@Rt2 System Engineering Tool Set.

Figure 10 :

 10 Figure 10: Functional Interfaces (Used & Realized) of the MegaM@Rt2 Runtime Analysis Tool Set.

Figure 11 :

 11 Figure 11: Constituent Parts (Subordinates) of the MegaM@Rt2 Runtime Analysis Tool Set.

Figure 12 :

 12 Figure 12: Functional Interfaces (Used & Realized) of the MegaM@Rt2 Model & Traceability Management Tool Set.

Figure 13 :

 13 Figure 13: Constituent Parts (Subordinates) of the MegaM@Rt2 Model & Traceability Management Tool Set.

  1, XMI.

	Publication Date: June 2015 Link: https://www.omg.org/spec/XMI
	• IF-REQIF: OMG Requirements Interchange Format, Version 1.2, Re-
	qIF Publication Date: July 2016 https://www.omg.org/spec/ReqIF/
	• IF-UML2: Object Management Group Unified Modeling Language,
	Version: 2.5.1 (UML2) Publication Date: December 2017 IPR Mode:
	RF-Limited Link: https://www.omg.org/spec/UML/
	A specification defining a graphical language for visualizing, specify-
	ing, constructing, and documenting the artifacts of distributed object
	systems.

• IF-SysML: OMG System Modeling Language, Version 1.5, SysML Publication Date: May 2017 Link: https://www.omg.org/spec/SysML/ • IF-MARTE: Object Management Group (OMG): UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded Systems, Version 1.1 (MARTE) Publication Date: June 2011 Link: https://www.omg.org/ spec/MARTE • IF-fUML: OMG Semantics of a Foundational Subset for Executable UML Models, Version 1.3, FUML Publication Date: October 2017 Link: https://www.omg.org/spec/ FUML • IF-DSL: this interface allows exchanging DSLs artifacts across different system engineering components, i.e. between different tools covering different parts of the system engineering process.

Table 1 :

 1 Example of Allocating Tool Purposes to Framework Requirements Depending on Their Release Date (MODELIO = https://www.modelio.org/, PAPYRUS = https:// www.eclipse.org/papyrus/, CERTIFYIT & MBEETLE = https://www.smartesting.

	com/)
	ID	Baseline (M0)	Initial	Intermediate	Final (M32)
			(M15)	(M20)
	1	MODELIO		PAPYRUS,	PAPYRUS,
				MODELIO	MODELIO
	2	CERTIFYIT			MBEETLE

Table 2 :

 2 An Example Status Report.

	Purpose		Properties	Comments/Release		Affected
					notes			CSR
	MODELIO-060:	Criticality:	Holistic system en-	CSY 01,
	Modelio shall sup-	High	Re-	gineering support is	NOK 02,
	port extra-functional	lease:	In-	postponed	till	fur-	NOK 01,
	properties in holistic	termediate	ther progress on the	TRT 03,
	system	engineering	Status:		methodological aspects	TEK 09,
	approach.		Postponed	in WP2 and clarifica-	TRT 02,
					tion of requirements	TRT 04,
					and scenarios by the	TRT 05
					case study providers.

Subordinates refer to the constituent parts of the component.

https://subversion.apache.org/

https://diamon.org/ctf/

Acknowledgments

This project has received funding from the Electronic Component Systems for European Leadership Joint Undertaking under grant agreement No. 737494. This Joint Undertaking receives support from the European Union's Horizon 2020 research and innovation program and from Sweden, France, Spain, Italy, Finland and Czech Republic. Wasif Afzal is also sponsored in part by the Swedish Knowledge Foundation under Grant 20160139 (Test-Mine).